Kubernetes监控手册01-体系介绍

Kubernetes 监控体系驳杂，涉及到的内容非常多，总是感觉摸不到头绪，网上虽然有很多资料，都略显凌乱，没有一个体系化的讲解，今天开始，我们准备撰写一系列文章，把 Kubernetes 监控说透，从如何采集数据，到重点关注哪些指标，怎么做监控大盘，怎么配告警规则，全部囊括其中，让大家彻底理解 Kubernetes 监控，解决你的工作问题，当然，鉴于我们的知识储备水平，有些地方可能难免会有疏漏和错误，如果您发现有不合理的内容，欢迎联系我一起探讨。

核心要点

Kubernetes 监控不是只监控 Pod，而是要覆盖底层宿主环境、控制面、工作负载节点、容器运行时和业务应用。
控制面重点关注 API Server、Scheduler、Controller-Manager、ETCD，它们决定集群能否接收请求、保存状态和完成调度。
工作负载节点重点关注 OS、Kubelet、Kube-Proxy、容器引擎以及节点上运行的 Pod。
公有云托管 Kubernetes 通常由云厂商维护控制面，用户侧更应优先把工作负载节点、Pod 和应用监控做好。

Kubernetes 监控概述

当我们谈及 Kubernetes 监控的时候，我们在谈论什么？显然是 Kubernetes 架构下的各个内容的监控，Kubernetes 所跑的环境、Kubernetes 本身、跑在 Kubernetes 上面的应用等等。Kubernetes 所跑的环境，可能是物理机、虚拟机，并且依赖底层的基础网络，Kubernetes 上面的应用，可能是业务应用程序，也可能是各类中间件、数据库，Kubernetes 本身，则包含很多组件，我们通过一张 Kubernetes 架构图来说明。

Kubernetes 架构

下面是一张 Kubernetes 架构图，画的很简单，不过主要组件都有说明，下面我们来一起看一下。

Kubernetes架构

最左侧是 UI 层，包括页面 UI 以及命令行工具 kubectl，中间部分是 Kubernetes 控制面组件，右侧部分是工作负载节点，包含两个工作覆盖节点。

Kubernetes 哪些组件要监控

从架构图可以看出，UI 层显然不是关键，kubectl 命令行工具无需监控，如果有自建 UI 展示系统，那是需要监控的，不过因为 UI 层面不承担太多逻辑，出问题的概率很小，所以不是我们关注的重点。重点是中间的控制面组件以及右侧的工作负载节点。

控制面组件包括 API Server、Scheduler、Controller-Manager、ETCD 四个组件，每个组件都很重要，需要黑盒、白盒监控并举。工作负载节点运行了 Pod 容器负载，以及容器引擎和 Kubernetes Node 组件，容器引擎图上是 Docker，不过不局限 Docker，也可能是别的容器引擎，Kubernetes Node 组件包括 Kubelet 和 Kube-Proxy，也都是需要监控的。

监控层次	典型对象	为什么要监控
宿主环境	物理机、虚拟机、CPU、内存、磁盘、网络	Kubernetes 自身和业务 Pod 都依赖这些基础资源
控制面	API Server、Scheduler、Controller-Manager、ETCD	决定集群 API、状态存储、调度和控制循环是否正常
工作负载节点	Kubelet、Kube-Proxy、容器运行时	决定 Pod 能否启动、上报状态、接入 Service 流量
Pod 与应用	容器资源、应用接口、业务指标、日志	最终影响用户体验和业务可用性

建议的落地顺序

先把宿主机 OS 指标采集起来，保证 CPU、内存、磁盘、IO、网络等基础信号可见。
再监控工作负载节点组件，重点是 Kubelet、Kube-Proxy 和容器运行时。
接着补齐控制面组件，尤其是 API Server 和 ETCD 的可用性、延迟和错误。
最后把 Pod、应用指标、日志和业务可用性接入同一套告警与大盘体系。

总结

本篇简单开个头，对 Kubernetes 监控相关的内容做了概述，下一节开始，我们就开始介绍具体如何落地了。因为使用公有云的企业大都在使用云厂商托管的 Kubernetes，对于控制面组件已经交给云厂商来运维了，所以我们重点关注工作负载节点，下一节开始，我们先来介绍如何监控工作负载节点的OS。敬请期待。