当我们在监控 Kubernetes Pod 时,到底在监控什么

  1. 云栖社区>
  2. 云栖号资讯>
  3. 博客>
  4. 正文

当我们在监控 Kubernetes Pod 时,到底在监控什么

云栖号资讯小编 2020-06-04 12:24:06 浏览768
展开阅读全文

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

image

应用 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 指标暴露存在差别

监控提供了两个监控项,以及对应的指标项:

image

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

image

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 内存作为已用内存

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

image

目前报警/主机详情页/应用诊断报告都使用 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 环境默认是无盘系统(除非使用持久卷),因此并没有分配磁盘空间这一概念,用户也不需要再关心磁盘可用空间。

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

image

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

image

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-06-04
本文作者:高效运维
本文来自:“高效运维公众号”,了解相关信息可以关注“高效运维

网友评论

登录后评论
0/500
评论
云栖号资讯小编
+ 关注
所属团队号: 云栖号资讯