53 K8S 之资源监控与资源指标

Kubernetes 系统上的关键指标大体可以分为两个主要组成部分：集群系统本身的指标和容器应用相关的指标。对于集群系统本身相关的监控层面而言，监控整个 Kubernetes 集群的健康状况是最核心的需求，包括所有工作节点是否运行正常、系统资源容量大小、每个工作节点上运行的容器化应用的数量以及整个集群的资源利用率等，它们通常可分为如下一些可衡量的指标。

1）节点资源状态：多数指标都与节点上的系统资源利用状况有关，例如网络带宽、磁盘空间、CPU 和内存的利用率等，它们也是管理员能够评估集群规模合理性的重要标准。

2）节点数量：在公有云服务商以实例数量计费的场景中，根据集群整体应用的资源需求规模实时调整集群节点规模是常见的弹性伸缩应用场景之一，而实时了解集群中的可用节点数量也给了用户计算所需支付费用的参考标准。

3）活动 Pod 对象的数量：正在运行的 Pod 对象数量常用于评估可用节点的数量是否足够，以及在节点发生故障时它们是否能够承接整个工作负载等。

这些应用的监控需求通常可以大体分为 3 类：应用编排指标、容器指标和应用程序指标。

1）应用编排指标：用于监视特定应用程序相关的 Pod 对象的部署过程、当前副本数量、期望的副本数量、部署过程进展状态、健康状态监测及网络服务器的可用性等，这些指标数据需要经由 Kubernetes 系统接口获取。

2）容器指标：包括容器的资源需求、资源限制以及 CPU、内存、磁盘空间、网络带宽等资源的实际占用状况等。

3）应用程序指标：应用程序内置的指标，通常与其所处理的业务规则相关，例如，关系型数据库应用程序可能会内置用于暴露索引状态的指标，以及表和关系的统计指标等。监控集群所有节点的常用方法之一是通过 DaemonSet 控制器在各节点部署一个采集监控指标数据的代理程序，由代理程序将节点级采集的各种指标数据上报至监控服务端，以统一进行数据的处理、存储和展示。这种部署方式给了管理员很大的自主选择空间，但也必定难以形成统一之势。

监控集群所有节点的常用方法之一是通过 DaemonSet 控制器在各节点部署一个采集监控指标数据的代理程序，由代理程序将节点级采集的各种指标数据上报至监控服务端，以统一进行数据的处理、存储和展示。这种部署方式给了管理员很大的自主选择空间，但也必定难以形成统一之势。

新一代的 Kubernetes 监控系统架构主要由核心指标流水线和监控指标流水线共同组成。

（1）核心指标管道

由 kubelet、资源评估器、Metrics Server 以及提供关键指标 API 的 API Server 共同组成，它们为 Kubernetes 系统提供核心指标。Metrics Server 通过服务发现机制发现集群上的所有节点，而后自动采集每个节点上 kubelet 的 CPU 和内存使用状态。kubelet 完全能够基于容器运行时接口获取容器的统计信息，同时为了能够兼容较旧版本的 Docker，它也支持从内部集成的 cAdvisor 采集资源指标信息，这些指标数据经由 kubelet 守护进程监听 TCP 的 10250 端口，并以只读方式对外提供，最终由 Metrics Server 完成聚合后对外公开。

截至目前，核心指标管道中的指标主要包括 CPU 累计使用、内存即时利用率、Pod 资源占用率及容器的磁盘占用率等。这些度量标准的核心系统组件包括调度逻辑（基于指标数据的调度程序和应用规模的水平缩放），以及部分 UI 组件（例如 kubectl top 命令和 Dashboard）等。

（2）监控管道

监控指标相关的管道负责从系统收集各种指标数据，并提供给终端用户、存储系统以及 HPA 控制器等使用。事实上，监控管道会收集包含核心指标（未必是 Kubernetes 可解析的格式）在内的大多数指标，核心指标集合之外的其他指标通常称为非核心指标。Kubernetes 自定义指标 API 允许用户扩展任意数量的、特定于应用程序的指标，例如队列长度、每秒入站请求数等。Kubernetes 系统自身既不会提供这类组件，也不为这些指标提供相关的解释，它依赖于用户使用的第三方整体解决方案。

资源指标 API 的主流实现是 Metrics Service 项目，而自定义指标 API 则以构建在 Prometheus[1]之上的 k8s-prometheus-adapter 接受最为广泛。