说透 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监控讲解系列文章，会重度依赖这两个开源项目：
本文由mdnice多平台发布
