说透 Kubernetes 监控系列 - 概述

本文作者孔飞，来自快猫星云团队，Kubernetes专家，Categraf 采集器核心研发工程师

云原生包含了开源软件、云计算和应用架构的元素。云计算解决开源软件的运行门槛问题，同时降低了运维成本和基础架构成本; 云原生给出了更多的应用架构规范, 更聚焦于能力和生态。随着 Kubernetes 在基础设施的大规模落地，监控的需求也发生了变化，建设一套更符合云原生规范的监控体系势在必行。

一 监控需求变化

• 指标周期变短: 相比物理机时代，基础设施动态化，Pod销毁重建非常频繁，监控指标跟随 Pod 的生命周期
• 指标数量增加: 随着微服务化流行，指标的数量也大幅增长，研发工程师也更愿意埋点，获取服务状态；各种采集器层出不穷，指标应采尽采
• 指标维度更加丰富：物理机时代监控多从资源视角出发，更关注机器、交换机、中间件的采集；新的监控维度更加丰富，维度标签动辄十几个几十个
• 基础设施复杂度变高，监控难度增加：Kubernetes 组件和应用架构模型都需要投入时间去了解学习。Kubernetes 本身组件都通过 /metrics 接口暴露了监控数据，但是缺少体系化的文档指导和最佳实践总结
• 自动发现更重要：相比物理机时代的静态采集，自动发现采集目标的能力变得更重要

这个系列的文章重点讲解 Kubernetes 云原生监控体系，讲解 Kubernetes 本身各个组件的监控，以及运行在 Kubernetes 上的业务应用的监控。

二 采集目标

2.1 从 Kubernetes 架构看采集目标

• 控制面组件监控，包括 kube-apiserver、kube-controller-manager、kube-scheduler、etcd 的监控
• node 组件监控，包括 kubelet、kube-proxy 等组件的监控
• Kubernetes对象监控（kube-state-metrics，后文简称KSM）
• 宿主节点资源监控
• 业务自身监控，业务自身的状态监控，白盒埋点监控

2.2 简单梳理监控指标

2.2.1 kube-apiserver

kube-apiserver 是 Kubernetes 的总入口，其他 Kubernetes 组件都是通过与kube-apiserver 交互实现各种功能

• 要处理各种 API 调用，需要重点关注吞吐、延迟、错误率这些指标
• 缓存对象数据，需要关注自身的 CPU 和内存使用率

2.2.2 kube-controller-manager

kube-controller-manager 负责监听对象状态，并与期望状态对比，如果状态不一致就进行调谐（reconcile)

• 主要关注各个 controller 的任务数、队列深度
• 与 kube-apiserver 交互的请求数、耗时、错误数

2.2.3 kube-scheduler

kube-scheduler 经过一些打分算法，给 Pod 选取合适的 Node

• 调度框架的各个扩展点、算法的耗时
• 调度队列的任务数、队列深度
• 与 kube-apiserver 交互的请求数、耗时、错误数

2.2.4 etcd

etcd 主要存储各种 Kubernetes 的对象数据，etcd 与 kube-apiserver 直接交互

• 关注 etcd 处理的请求量、请求耗时、cache 命中情况
• etcd 集群的状态，是否在做 snapshot、是否在做数据 defrag、leader/learner 以及切换次数
• etcd 的 db size ，wal 写入状态等
• etcd 各种操作的耗时、数量情况
• etcd 的 CPU、内存、fd 使用情况

2.2.5 Node节点

• Node本身的资源（cpu 内存 硬盘 网络 fd等）
• Node上容器资源（cpu 内存 硬盘 网络 fd等）
• Node上组件的监控，kubelet、kube-proxy、dockerd、containerd 等

2.2.6 KSM

• workloads（工作负载）指标，比如业务部署了多少个 deployment，部署了多少个pod，各个 pod 的状态如何
• 资源 quota 还剩多少

2.2.7 业务监控

• 业务本身提供的 metrics 接口，来暴露业务指标
• 业务进程自身的通用监控指标，比如进程的CPU、内存、IO、句柄等

三 采集方式

3.1 权限

监控对象明确后，就要确定如何收集指标。在收集具体指标前，首先要搞定的就是权限。Kubernetes 大部分指标的采集都是需要 kube-apiserver 授权的。关于 Kubernetes 的 authorization，主要包含RBAC、ABAC、Node Authorization、Webhook Authorization。

• RBAC：Role-based access control 是基于角色的访问控制
• ABAC：Atrribute-based access control 是基于属性的访问控制
• Node Authorization：节点鉴权，专门用于 kubelet 发出的 API 请求进行鉴权
• Webhook Authorization：webhook 是一种 HTTP 回调，kube-apiserver 配置webhook 时， 会设置回调 webhook 的规则，这些规则中包含了调用的 api group、version、operation、scope等信息。

Node Authorization 和 Webhook Authorization是两种专门的鉴权模型。ABAC 是用户和权限绑定；RBAC 是用户和角色绑定，角色和权限绑定。RBAC 比 ABAC 多了一个角色，更加灵活，后续我们主要是 RBAC 鉴权模式进行采集指标。

3.2 自动发现

搞定鉴权模式后，我们面临的下一个问题是自动发现。对于控制面组件，类似prometheus 的 static config 可以满足需求， 对于使用 pod 部署的组件，我们都可以利用 k8s 自身的特性来动态发现目标，进而采集数据。比如，创建 service，然后利用 service 动态发现对应 endpoint 的变化，这样 pod 的 ip 发生变化也不影响采集。如果 公司已经有其他成熟的服务发现机制，也可以直接利用，比如consul。

3.3 如何部署采集器

搞定了鉴权和自动发现，接下来要考虑采集器以何种方式采集了。

• 控制面组件，首先推荐使用 deployment方式 + 自动发现; 如果控制面组件是二进制方式部署, 可以用 deployment+ consul（或者静态抓取方式）；
• node节点，首先推荐使用 daemonset 方式采集 node 指标和容器基础指标；
• KSM，首先推荐使用单副本的 deployment 方式 + 自动发现；
• 业务监控，首先推荐使用 sidecar 模式来采集；其次使用集中式的 deployment方式采集；

部署yaml文件，我们已经放在k8s目录下:

• deployment.yaml 以deployment方式部署
• sidecar.yaml 以sidecar方式部署
• deamonset.yaml 以daemonset方式部署
• scrape_with_cafile.yaml 在pod内抓取指标
• scrape_with_cafile.yaml 用cafile方式抓取指标
• scrape_with_kubeconfig.yaml 用kube-config 文件方式抓取指标
• scrape_with_token.yaml 用token方式抓取指标

四 监控大盘与报警规则

按照梳理的指标，已经将k8s 部分组件的大盘梳理完了，具体可以参考https://github.com/flashcatcloud/categraf/tree/main/k8s目录下对应的文件。

• apiserver-dash.json
• cm-dash.json
• sheducler-dash.json
• etcd-dash.json
• coredns-dash.json

本文先将 Kubernetes 环境下的监控整体工作做了一个简单介绍，大家先有一个感性认识。后续我们会针对具体的步骤做详细的介绍，欢迎大家转发、点赞、关注和收藏。

最后，如果还没有关注夜莺和categraf开源项目的朋友，可以star收藏起来了，后续的Kubernetes监控讲解系列文章，会重度依赖这两个开源项目：

• https://github.com/ccfos/nightingale
• https://github.com/flashcatcloud/categraf

本文由 mdnice 多平台发布