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

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

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

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。

创作场景

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