管理 Kubernetes 集群时需要关注的关键指标

有时我们在面对分布式系统工程时常感到痛苦。构建分布式系统真的很难，无论是哪个行业的企业，都希望我们在解决他们的业务问题的同时，还能考虑潜在的大规模业务问题。与大规模部署随之而来的一大挑战，是用户还要考虑创建新特性和避免回档。就算能够非常出色地实现这些目标，用户仍然会担忧很多其他问题，例如信息是否安全、是否遵从法规，以及企业的这一投资是否真的有足够价值。

如果上述描述和你的团队现在的境况很像，而且你们的系统已经在生产环境中运行了，那么恭喜你，你已经通过了第一轮考验。

无论你多么努力建立了一个出色的系统，有时意想不到的事还是会发生。有很多这样的先例。一个杰出的产品，或者是病毒式应用，可能会带来前所未有的成功，而成功之后你就会发现，原先你以为的、你的系统面对大规模应用时的处理方式，好像不适用了。

Pokemon Go 云数据存储的每秒处理数（预期 vs 实际）

来源： Bringing Pokémon GO to life on Google Cloud，发布于 2018 年 5 月 30 日

这一情况是可能发生的，而你也应该为此做好准备。这也是本系列文章所要提到的。在本系列教程中我们将向你介绍需要追踪的内容，为什么追踪它们，以及面对可能的根本原因时需要做的缓解处理。

我们会介绍每一种指标、追踪它的方法以及你可以对应采取的措施。我们将使用不同的工具收集和分析这些数据。教程不会涉及到太多细节的内容，但会提供拓展链接，让大家可以获取更多信息。话不多说，让我们开始吧。

Metrics：用于监控，不止监控

这一系列文章主要关注的是如何监控和运行 Kubernetes 集群。使用日志是一个不错的方法，但在大规模部署的情况下，日志在事后分析工作中可能有很大作用，却难以在过程之中不断警告运维人员那些正在出现的越来越严重的问题。 Metrics Server 可以监控容器的 CPU 和内存使用情况，以及容器所运行在的节点的情况。

这让运维人员能够设置并监控 KPI（关键绩效指标）。这些运维定义层面的东西可以为运维团队提供一种确定应用程序或者节点何时不健康的方法。同时也给他们提供了查看问题所需要的所有数据。

此外，Metrics Server

(https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/)允许 Kubernetes 启用 Horizontal Pod Autoscaling

(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)。该功能可以让 Kubernetes 在扩展 pod 实例数量时，是基于 Kubernetes Metrics API 报告的指标以及这些指标反映出来的 API 对象数量来进行扩展的。

在 Rancher Kubernetes 集群中设置 Metrics Server

从 Kubernetes 1.8 版本开始，Metrics Server 以 Kubernetes Monitoring Architecture

(https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)插件的方式成为了拉取容器指标的标准。在该标准出现之前，默认使用的是 Heapster，现在已经弃用，而开始支持 Metrics Server。

很快，Metrics Server 就将可以在 Rancher 2.0 配置的 Kubernetes 集群上运行了。您可以在 Rancher 的 Github repo 中查看 Rancher 2.0 最新版本的发布动态，一起期待：https://github.com/rancher/rancher/releases。

如果想让 Metric Server 工作，你必须通过 Rancher Server API 修改集群的定义。这样可以允许 Rancher 服务器修改 Kubelet 以及 KubeAPI 参数，让它们包含 Metrics Server 正常运行所需要的标记。

有关如何在 Rancher Provisioned 集群上执行这一操作，以及修改其他 hyperkube-based 集群的说明，可以参考 github 的这一链接：https://github.com/JasonvanBrackel/metrics-server-on-rancher-2.0.2。