本文转载自微信公众号《大数据DT》，作者BrendanBurns。转载本文请联系大数据DT公众号。Kubernetes集群由两种类型的组件组成，即控制平面和工作节点。控制平面包括APIServer、etcd、Scheduler、ControllerManager。工作节点包括kubelet、ContainerRuntime、kube-proxy、kube-dns和Pod。您需要监控所有这些组件以确保集群和应用程序正常运行。Kubernetes以多种方式公开这些组件的指标，让我们看看可以使用哪些不同的组件来收集集群的指标。1.cAdvisorContainerAdvisor（或cAdvisor）是一个开源项目，用于收集节点上容器的资源使用情况和指标。cAdvisor内置于kubelet中，它运行在集群中的每个节点上。它通过Linuxcgroups（ControlGroup，控制组）收集内存和CPU指标。cgroups是Linux内核的一项功能，用于隔离CPU、磁盘I/O或网络I/O等资源。cAdvisor还通过Linux内核内置的statfs收集磁盘指标。你不需要关心这些技术的实现细节，但是你应该了解这些指标是如何暴露的，你需要收集什么类型的信息。最后，您应该将cAdvisor视为所有容器指标的可信来源。2.MetricsServerKubernetesMetricsServer和MetricsServerAPI取代了已弃用的Heapster。Heapster在datasink的架构上存在一些不足，导致在Heapster的核心代码中引入了大量的厂商解决方案。这个问题最终通过在Kubernetes中将资源指标API（ResourceMetricsAPI）和自定义指标API（CustomMetricsAPI）实现为一个聚合API来解决。这使得在不更改API的情况下在不同的实现之间切换成为可能。MetricsServerAPI和MetricsServer有两个方面需要了解。首先，MetricsServer是ResourceMetricsAPI的典型实现。它通过kubeletAPI收集CPU、内存等资源指标，存储在内存中，供KubernetesScheduler、HPA（Horizo??ntalPodAutoscaler）和VPA（VerticalPodAutoscalerPodAutoscaler）使用。其次，自定义指标API允许监控系统收集任意指标，这将允许在监控解决方案中构建自定义适配器，将监控范围扩展到核心资源指标之外。例如，Prometheus构建了第一个自定义指标适配器，它允许您使用基于自定义指标的HPA。这根据场景提供了更好的可扩展性，因为您可以根据此类外部指标引入队列大小和规模等指标。MetricsAPI的标准化为扩展传统的CPU和内存指标提供了更多可能性。3.kube-state-metricskube-state-metrics是Kubernetes的附加组件，用于监控存储在Kubernetes中的对象。cAdvisor和MetricsServer用于提供有关资源使用情况的详细指标，而kube-state-metrics侧重于识别集群中对象的状态。以下是kube-state-metrics可以回答的一些问题：Pod集群中部署了多少个Pod？有多少Pod处于pending状态？是否有足够的资源来满足Pod的请求？部署有多少Pod正在运行或预期有多少副本可用？哪些部署已更新？Node工作节点的状态是什么？集群中分配了多少个CPU？有没有不可调度的节点？约伯是什么时候开始的？约伯什么时候结束？有多少工作失败了？在撰写本文时，kube-state-metrics可以跟踪22种Kubernetes对象类型，并且这个范围还在不断扩大。您可以从官方Github存储库中找到相关文档。作者简介：BrendanBurns，微软Azure杰出工程师，Kubernetes开源项目联合创始人，现任微软副总裁，从事云应用开发十余年。EddieVillalba是Microsoft商业软件工程部门的软件工程师，专注于开源云和Kubernetes。他帮助许多用户将Kubernetes用于他们的应用程序。DaveStrebel是MicrosoftAzure的全球云原生架构师，专注于开源云和Kubernetes。他深度参与Kubernetes开源项目，帮助Kubernetes发布团队并领导SIG-Azure工作组。MicrosoftAzure容器计算团队首席开发经理LachlanEvenson通过实践教学和会议演示帮助许多人了解Kubernetes。本文节选自《Kubernetes实战》，经发布者授权发布。（书号：9787111672128）
