1.4.5 微服务升级
做好微服务的部署和保护仅仅是开始，在系统不断地开发和发展时，你也需要升级微服务。关于如何执行此操作，有许多重要的考虑因素，我们将在后面的章节中进行讨论（如版本控制、滚动更新、蓝绿部署和金丝雀部署）。Kubernetes开箱即用地为其中许多概念提供了直接的功能支持，以及构建在其上的生态系统，进而可以为用户提供多种选项和定制化的解决方案。
系统升级的目标通常是零停机时间，并在出现问题时可以安全回滚。Kubernetes部署提供了支持这个目标的基本原语，例如更新部署、暂停部署以及回滚部署。你可以在这些坚实的基础上构建特定的工作流程。服务升级的机制通常包括将其镜像升级到新版本，有时还需要更改其支持资源和访问权限，如存储卷、角色、配额、限制等。
1.微服务扩展
使用Kubernetes扩展微服务有两个方面：第一个是扩展Pod的数量以支持特定的微服务，第二个是扩展集群的总容量。你可以通过更新部署的副本数轻松地显式扩展微服务，但这需要你时刻保持警惕。对于处理的请求数量在不同时间段存在较大差异的服务（例如，工作时间与下班时间，或工作日与周末），你可能需要花费大量精力进行应对。Kubernetes提供了基于CPU、内存或自定义指标的Pod水平自动扩展（Horizontal Pod Autoscaler，HPA）功能，可以自动扩展服务。
以下示例演示了如何将目前固定3个副本的nginx部署调整为在2到5之间弹性伸缩，其依据是实例的平均CPU利用率：
Kubernetes会持续监控属于nginx部署的Pod的CPU利用率。当在特定时间段内（默认情况下为5分钟）的平均CPU使用率超过90%时，它将增加副本到最多5个，直到利用率下降到90%以下。HPA也可以缩减资源，但是即使CPU利用率为0，部署也将始终维持至少2个副本。
2.微服务监控
现在，你的微服务已经在Kubernetes上部署并运行，并且在需要时更新微服务的版本。Kubernetes会进行一些自动修复和扩展，但是，你仍然需要监控系统并跟踪错误和性能指标。这不仅对于解决问题很重要，而且对于发现系统潜在需要的改进、优化和成本削减也很重要。
有几类相关的监控信息需要特别关注：
·第三方程序日志
·应用程序日志
·应用程序错误
·Kubernetes事件
·指标
当涉及由多个微服务和多个支持组件组成的系统时，其日志的数量往往是巨大的。解决方案是采用集中式日志管理，即将所有日志都存放在一个位置，然后根据需要再进行划分。此外，除了错误日志本身，通常将相关的元数据（例如栈跟踪）记录在特有的系统（例如sentry[1]或rollbar[2]）中也是非常有价值的。对于检测系统性能和运行状况或者变化趋势，很多指标都是有帮助的。
Kubernetes提供了几种用于监控微服务的机制和抽象，其生态系统也提供了许多有用的项目。
3.日志
以下几种方法可以实现Kubernetes的集中日志管理。
·在每个节点上运行日志代理。
·向每个应用程序Pod中注入日志边车（sidecar）容器。
·让应用程序将其日志直接发送到集中的日志服务。
每种方法都各有利弊，最主要的是Kubernetes支持以上所有方法，使得容器和Pod的日志可以被充分利用。
请参阅4.指标
Kubernetes自带cAdvisor（https://github.com/google/cadvisor）组件，这是一个集成在kubelet中用于收集容器指标的工具。Kubernetes过去提供了一个称为heapster的指标服务器，该服务器需要额外的后端和UI。目前，Prometheus开源项目是指标服务器方面的翘楚。如果你使用Google的GKE运行Kubernetes，那么Google Cloud Monitoring是一个不错的选择，它不需要在集群中安装其他组件。其他云提供商也提供集成好的监控解决方案，例如，Amazon EKS[3]和Amazon CloudWatch[4]。
[1] 请参考https://sentry.io/welcome/。——译者注
[2] 请参考https://rollbar.com/。——译者注
[3] 请参考https://aws.amazon.com/eks/。——译者注
[4] 请参考https://aws.amazon.com/cloudwatch/。——译者注