Kubernetes集群中要监控哪些组件？采集哪些指标？

hzbooks

于 2021-12-18 08:00:00 发布

阅读量433

点赞数

文章标签：内核大数据 java kubernetes 人工智能

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg5MDU5NTM1NQ==&mid=2247532231&idx=1&sn=31fb4b8476d50e380767e08a9a09df7c&chksm=cfd80fb3f8af86a5969ac7a789e2f2410926de9e264d661a6e781abcbabd3d7108975f3b82de&scene=126&&sessionid=0

版权

导读：让我们看一看在Kubernetes集群中应该监控哪些组件。

作者：Brendan Burns, Eddie Villalba, Dave Strebel, Lachlan Evenson

译者：陈亮王磊张扬

来源：大数据DT（ID：hzdashuju）

Kubernetes集群由控制平面和工作节点两类组件组成。控制平面包括API Server、etcd、Scheduler以及Controller Manager。工作节点则包括kubelet、Container Runtime、kube-proxy、kube-dns以及Pod。你需要监控所有这些组件以确保集群和应用程序的正常运行。

Kubernetes通过多种方式暴露这些组件的指标，让我们看看可以使用哪些不同的组件来采集集群的指标。

01 cAdvisor

Container Advisor（或者称为cAdvisor）是一个开源项目，用来采集节点上容器的资源使用情况和指标。cAdvisor内置在kubelet中，kubelet运行在集群中的每个节点上。它通过Linux cgroups（Control Group，控制组）来收集内存和CPU指标。

cgroups是Linux内核的一个功能，用来隔离诸如CPU、磁盘I/O或者网络I/O等资源。cAdvisor也会通过Linux内核内置的statfs来收集磁盘指标。你不需要关心这些技术的实现细节，但是应该理解这些指标是如何暴露的，以及你需要采集什么类型的信息。最后，你应该将cAdvisor视为所有容器指标的可信来源。

02 Metrics Server

Kubernetes Metrics Server和Metrics Server API替代了弃用的Heapster。Heapster在数据接收器的架构上存在一些缺陷，导致在Heapster的核心代码中引入了大量的供应商解决方案。

这个问题最终通过在Kubernetes中将Resource Metrics API（资源指标API）和Custom Metrics API（自定义指标API）实现成一个聚合API而得到解决。这样就可以在不改变API的情况下切换不同的实现。

Metrics Server API和Metrics Server有两个方面需要理解。

首先，Metrics Server是 Resource Metrics API的典型实现，它通过kubelet的API采集诸如CPU和内存这类资源的指标，并将其存储在内存中以供Kubernetes Scheduler、HPA（Horizontal Pod Autoscaler）以及VPA（Vertical Pod Autoscaler）使用。

其次，Custom Metrics API 允许监控系统收集任意指标，这将允许在监控方案中构建自定义的适配器，将监控范围扩展到核心资源指标之外。

例如，Prometheus构建了最早的自定义指标适配器之一，它可以让你基于自定义的指标来使用HPA。这样就可以根据场景提供更好的伸缩性，因为你可以引入诸如队列大小这样的指标，并且基于这类外部指标进行缩放。

Metrics API的标准化为扩展传统的CPU和内存指标提供了更多的可能。

03 kube-state-metrics

kube-state-metrics是Kubernetes的一个附加组件，用来监控存储在Kubernetes中的对象。cAdvisor和Metrics Server 用于提供资源使用的详细指标，而kube-state-metrics则关注识别集群中对象的状态。

以下是一些kube-state-metrics可以回答的问题：