监控 Pod 时，我们在监控什么

应用 Kubernetes 化已经开始推进了一段时间，监控系统也提供了 Kubernetes Pod 相关的监控指标和警报规则。

由于 Kubernetes 和传统的物理机/虚拟机是完全不同的运行环境，因此监控系统提供的监控指标也存在一定的区别。虽然我们已经尽量统一不同平台的差异，但是日常工作中仍会收到用户对 Kubernetes 监控指标的反馈。

本文旨在从 CPU/内存/磁盘/网络四个角度阐述物理机/虚拟机（后续统一为 KVM）与 Kubernetes 的区别，帮助大家在使用监控产品时也能理解背后的原理。本文会一定程度上深入技术细节，但是也提供了监控产品使用指导，希望大家理解。

需要提前说明的是，监控平台所有的数据都是采集自 Kubernetes 原生暴露的指标，因此难免受限于 Kubernetes 原生接口的特点。

总体而言，Kubernetes 和 KVM 的区别在不同组件存在区别：

• CPU 区别最大，这是 Kubernetes 技术本质决定的
• 内存有一定区别，但是基本可以和 KVM 技术栈统一
• 网络、磁盘区别不大，基本没有额外的理解成本

CPU

长话短说，在 KVM 场景下，用户需要关注的指标是 CPU 使用率 和 CPU load：

• CPU load 高，CPU 使用率低，一般表明性能瓶颈出现在磁盘 I/O 上
• CPU 使用率高，CPU load 远高于 CPU 核数，表示当前 CPU 资源严重不足

在 Kubernetes 场景下，用户需要关注的指标是 CPU 使用率和 CPU 限流时间：

• CPU 使用率高（接近甚至稍微超过 100%），CPU 限流时间大，表示当前 CPU 资源严重不足，需要增加 request 或者 limit

出现这种差异的原因：

• Kubernetes 和 KVM 在 CPU 资源隔离机制上存在差别
• Linux 指标暴露 和 Kubernetes 指标暴露存在差别

监控提供了两个监控项，以及对应的指标项：

下图展示了一个被限流的应用，可以看到 CPU 使用率显示超过了 100%。

CPU 使用率

对于一个独立的 CPU core，它的时间被分成了三份：

• 执行用户代码时间
• 执行内核代码时间
• 空闲时间（对于 x86 体系而言，此时会执行 HLT 指令）

因此 KVM 环境下计算 CPU 使用率很直接：（执行用户代码时间 + 执行内核代码时间）/ 总时间。

因为对于 Kubernetes Pod 而言，它不再享有独立的 CPU core，因此这个公式不再成立。在 Kubernetes 语境下，CPU 的资源总量/使用量是通过时间表示的：

• 配置一个 CPU limit 为 4 的 POD，含义是 一秒钟内可以使用 4s 的 CPU 资源，这个当然需要多核/多线程的支持
• 一个 POD 每秒使用 0.5s 的 CPU 资源，可以理解为这个 POD 使用了一个 CPU core 的 50%

原生的 Kubernetes 并不关注”使用率“这个概念，但是为了降低用户的迁移成本，监控通过 使用量 / Limit 来衡量 POD 的 CPU 使用率。

由于 Kubernetes 对 CPU Limit 的实现粒度有限，同时考虑到统计的误差，因此在压测等极限场景中 CPU 使用率会出现高于 100% 的”毛刺“。

CPU Load

CPU load 用于衡量当前系统的负载情况， Linux 系统使用当前处于可运行状态的线程数来标识，包括：

• 处于 running 状态的线程，这个是最正常的情况，获得 CPU 分片，执行用户态或者内核态代码的线程
• 出入 uninterruptible sleep 状态的线程，这个是特殊的情况，表明这个线程在进行 I/O 操作

因此，当 CPU 使用率很低，但 load 很高时， 我们可以推断大量线程处于 I/O 操作状态，系统的性能瓶颈出现在磁盘或者网络 I/O。

Kubernetes 虽然也提供了 cpu_load 指标， 却只包含了处于 running 状态的线程，这个指标也失去了判断系统性能瓶颈是否出现在 I/O 的作用。

另一方面，虽然不知道具体原因， Kubernetes 默认关闭 CPU load 指标，我们决定尊重这一决定。

同时，由于 CPU 使用方式的不同，Kubernetes 提供了“CPU 限制时间”指标，通过这个指标覆盖了 “CPU 使用率和 load 都很高，CPU 资源严重不足” 的情况。

具体来说，Kubernetes 通过 Completely Fair Scheduler (CFS) Cgroup bandwidth control 限制 Pod 的 CPU 使用：

• 首先，我们将 1s 分成多个 period，每个 period 持续时间为 0.1s
• 在每个 peroid 中，Pod 需要向 CFS 申请时间片，CFS 通过 Limit 参数判断这个申请是否达到这个 Pod 的资源限制
• 如果达到了 Pod 的资源限制，”限流时间“ 指标会记录限流的时间

因此，当一个 Pod 的”限流时间“非常高时，意味着这个 Pod CPU 资源严重不足，需要增加更多的资源了。

内存

KVM 和 Kubernetes 都通过 内存使用率 这个指标衡量内存使用情况，但是 "哪些内存是使用内存" 两者有一定区别：

• 在KVM场景中，内存的具体使用量并没有一个非常清晰的标准，cache/buffer/slab 内存对于应用性能的影响和应用本身的特点有关，没有统一的计算方案，综合各种因素，监控使用 total - available 作为内存使用
• Kubernetes 没有提供 available 指标，我们主要使用 RSS 内存作为已用内存

监控针对内存提供的的监控项/指标项比较多：

目前报警/主机详情页/应用诊断报告都使用 RSS 内存使用占比作为内存使用衡量指标。

Linux free 命令一般包含这几列：

• used：系统使用的内存，包括进程分配使用的内存，也包括系统为了优化性能而针对磁盘缓存分配的部分（即 cache/buffer）
• cache/buffer：上述的缓存
• available：估算的系统可用内存，考虑的 cache/buffer 以及不可回收的 slab 等

我们不能简单地将实际使用内存等价位used - cache/buffer，对于不同的应用，cache/buffer内存很可能是影响性能的重要部分（特别是依赖大量磁盘写操作的应用，如 Kafka、ElasticSearch 等）。

监控系统当前使用 total - available 作为已用内存，并基于此计算内存使用率。

Kubernetes 对于内存使用暴露了不同的值：

• MemUsed：和 Linux 的 used 一样，包含了 cache 值
• WorkingSet：比 memUsed 小一些，移除了一些“冷数据”，即长期没有访问的 cache 内存
• RSS：移除了 cache 的内存

一般情况下，我们认为 WorkingSet 是比较合理的内存使用量指标，但是实践中发现，WorkingSet的值一般比较高，常规应用内存使用率基本在 90%，和 KVM 下相同应用差别较大。

考虑到常规 Web 应用一般不依赖磁盘 I/O，cache 内存基本用于日志系统，对系统性能影响不大，因此最终在监控系统中选择使用 RSS 衡量内存使用。 但是，我们依然建议当用户发现系统出现性能瓶颈时，使用不同的内存指标辅助判断，更好地理解当前系统的状态。

磁盘/网络

基于 LInux Cgroup 隔离机制，磁盘/网络相关指标 Kubernetes 和 KVM 区别不大。唯一需要注意的是， Web 应用一般只关注磁盘用量，但是 Kubernetes 环境默认是无盘系统（除非使用持久卷），因此并没有分配磁盘空间这一概念，用户也不需要再关心磁盘可用空间。

对于磁盘，我们主要关心磁盘写入性能相关指标：

对于网络，和KVM场景类似，主要关注流量、丢包率等指标：

作者：逸恒，酷家乐监控组成员，关注云原生时代监控系统的发展与挑战。

原文链接： https://tech.kujiale.com/jian- ... -yao/