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

历经重重考验，系统在生产环境中成功落地以后，可能依然面临系统没法适用大规模应用的挑战，所以咱们须要对K8s集群的关键指标进行追踪。Rancher 资深解决方案架构师将在本文中介绍须要追踪的内容及其缘由，让您在面对问题时有所准备。

---

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

若是上述描述和你的团队如今的境况很像，并且大家的系统已经在生产环境中运行了，那么恭喜你，你已经经过了第一轮考验。

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

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

这一状况是可能发生的，而你也应该为此作好准备。这也是本系列文章所要提到的。在本系列教程中咱们将向你介绍须要追踪的内容，为何追踪它们，以及面对可能的根本缘由时须要作的缓解处理。

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

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。