从KubectlTop说起，浅谈Kubernetes是如何进行资源监控的？

公众号关注 「奇妙的 Linux 世界」

设为「星标」&＃xff0c;每天带你玩转 Linux &＃xff01;

一. 前言

kubectl top 可以很方便地查看node、pod 的实时资源使用情况&＃xff1a;如CPU、内存。这篇文章会介绍其数据链路和实现原理&＃xff0c;同时借 kubectl top 阐述 k8s 中的监控体系&＃xff0c;窥一斑而知全豹。最后会解释常见的一些问题&＃xff1a;

• kubectl top 为什么会报错&＃xff1f;

• kubectl top node 怎么计算&＃xff0c;和节点上直接 top 有什么区别&＃xff1f;

• kubectl top pod 怎么计算&＃xff0c;包含 pause 吗&＃xff1f;

• kubectl top pod 和exec 进入 pod 后看到的 top 不一样&＃xff1f;

• kubectl top pod 和 docker stats得到的值为什么不同&＃xff1f;

以下命令的运行环境为&＃xff1a;

• k8s 1.8

• k8s 1.13

二. 使用

kubectl top 是基础命令&＃xff0c;但是需要部署配套的组件才能获取到监控值

• 1.8以下&＃xff1a;部署 heapter

• 1.8以上&＃xff1a;部署 metric-server

kubectl top node: 查看node的使用情况


kubectl top pod: 查看 pod 的使用情况


不指定pod 名称&＃xff0c;则显示命名空间下所有 pod&＃xff0c;–containers可以显示 pod 内所有的container


指标含义&＃xff1a;

• 和 k8s中 的 request、limit 一致&＃xff0c;CPU单位100m&＃61;0.1 内存单位1Mi&＃61;1024Ki

• pod 的内存值是其实际使用量&＃xff0c;也是做 limit 限制时判断 oom 的依据。pod的使用量等于其所有业务容器的总和&＃xff0c;不包括 pause 容器&＃xff0c;值等于 cadvisr中的 container_memory_working_set_bytes 指标

• node 的值并不等于该 node 上所有 pod 值的总和&＃xff0c;也不等于直接在机器上运行 top 或 free 看到的值

三. 实现原理

3.1 数据链路

kubectl top 、 k8s dashboard 以及 HPA 等调度组件使用的数据是一样&＃xff0c;数据链路如下&＃xff1a;

使用 heapster 时&＃xff1a;apiserver 会直接将 metric 请求通过 proxy 的方式转发给集群内的 hepaster 服务。

而使用 metrics-server 时&＃xff1a;apiserver 是通过 /apis/metrics.k8s.io/ 的地址访问 metric

这里可以对比下 kubect get pod 时的日志&＃xff1a;

3.2 metric api

可以发现&＃xff0c;heapster 使用的是 proxy 转发&＃xff0c;而 metric-server 和普通 pod都是使用 api/xx 的资源接口&＃xff0c;heapster采用的这种 proxy 方式是有问题的&＃xff1a;

• proxy 只是代理请求&＃xff0c;一般用于问题排查&＃xff0c;不够稳定&＃xff0c;且版本不可控

• heapster 的接口不能像 apiserver 一样有完整的鉴权以及 client 集成&＃xff0c;两边都维护的话代价高&＃xff0c;如 generic apiserver

• pod 的监控数据是核心指标&＃xff08;HPA调度&＃xff09;&＃xff0c;应该和 pod 本身拥有同等地位&＃xff0c;即 metric 应该作为一种资源存在&＃xff0c;如 metrics.k8s.io 的形式&＃xff0c;称之为 Metric Api

于是官方从 1.8 版本开始逐步废弃 heapster&＃xff0c;并提出了上边 Metric api 的概念&＃xff0c;而 metrics-server 就是这种概念下官方的一种实现&＃xff0c;用于从 kubelet获取指标&＃xff0c;替换掉之前的 heapster

3.3 kube-aggregator

有了 metrics-server 组件&＃xff0c;采集到了需要的数据&＃xff0c;也暴露了接口&＃xff0c;但走到这一步和 heapster 其实没有区别&＃xff0c;最关键的一步就是如何将打到 apiserver的 /apis/metrics.k8s.io 请求转发给 metrics-server 组件&＃xff1f;解决方案就是&＃xff1a;kube-aggregator。kube-aggregator 是对 apiserver 的有力扩展&＃xff0c;它允许 k8s 的开发人员编写一个自己的服务&＃xff0c;并把这个服务注册到 k8s 的 api 里面&＃xff0c;即扩展 API&＃xff0c;metric-server 其实在 1.7版本就已经完成了&＃xff0c;只是在等 kube-aggregator 的出现。kube-aggregator 是 apiserver 中的实现&＃xff0c;有些 k8s 版本默认没开启&＃xff0c;你可以加上这些配置来开启&＃xff0c;他的核心功能是动态注册、发现汇总、安全代理。

如 metric-server 注册 pod 和 node 时:

3.4 监控体系

在提出 metric api 的概念时&＃xff0c;官方也提出了新的监控体系&＃xff0c;监控资源被分为了2种&＃xff1a;

• Core metrics(核心指标)&＃xff1a;从 Kubelet、cAdvisor 等获取度量数据&＃xff0c;再由metrics-server 提供给 Dashboard、HPA 控制器等使用。

• Custom Metrics(自定义指标)&＃xff1a;由 Prometheus Adapter 提供 API custom.metrics.k8s.io&＃xff0c;由此可支持任意Prometheus采集到的指标。

核心指标只包含 node 和 pod 的 cpu、内存等&＃xff0c;一般来说&＃xff0c;核心指标作 HPA 已经足够&＃xff0c;但如果想根据自定义指标&＃xff1a;如请求 qps/5xx 错误数来实现 HPA&＃xff0c;就需要使用自定义指标了。目前 Kubernetes 中自定义指标一般由 Prometheus 来提供&＃xff0c;再利用 k8s-prometheus-adpater 聚合到 apiserver&＃xff0c;实现和核心指标同样的效果。

3.5 kubelet

前面提到&＃xff0c;无论是 heapster 还是 metric-server&＃xff0c;都只是数据的中转和聚合&＃xff0c;两者都是调用的 kubelet 的 api 接口获取的数据&＃xff0c;而 kubelet 代码中实际采集指标的是 cadvisor 模块&＃xff0c;你可以在 node 节点访问 10255 端口&＃xff08;1.11版本过后是10250端口&＃xff09;获取监控数据&＃xff1a;

• Kubelet Summary metrics: 127.0.0.1:10255/metrics&＃xff0c;暴露 node、pod 汇总数据

• Cadvisor metrics: 127.0.0.1:10255/metrics/cadvisor&＃xff0c;暴露 container 维度数据

示例&＃xff0c;容器的内存使用量&＃xff1a;

Kubelet 虽然提供了 metric 接口&＃xff0c;但实际监控逻辑由内置的 cAdvisor 模块负责&＃xff0c;演变过程如下&＃xff1a;

• 从k8s 1.6开始&＃xff0c;kubernetes 将 cAdvisor 开始集成在kubelet中&＃xff0c;不需要单独配置

• 从k8s 1.7开始&＃xff0c;Kubelet metrics API 不再包含 cadvisor metrics&＃xff0c;而是提供了一个独立的 API 接口来做汇总

• 从 k8s 1.12 开始&＃xff0c;cadvisor 监听的端口在k8s中被删除&＃xff0c;所有监控数据统一由 Kubelet 的 API 提供

到这里为止&＃xff0c;k8s 范围内的监控体系就结束了。

3.6 cadvisor

cadvisor 由谷歌开源&＃xff0c;使用 Go 开发&＃xff0c;cadvisor 不仅可以搜集一台机器上所有运行的容器信息&＃xff0c;包括 CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况&＃xff0c;还提供基础查询界面和 http 接口&＃xff0c;方便其他组件进行数据抓取。在K8S 中集成在 Kubelet 里作为默认启动项&＃xff0c;k8s 官方标配。cadvisor 拿到的数据结构示例&＃xff1a;

核心逻辑是通过 new 出来的 memoryStorage 以及 sysfs 实例&＃xff0c;创建一个manager 实例&＃xff0c;manager 的 interface 中定义了许多用于获取容器和 machine 信息的函数

cadvisor的指标解读&＃xff1a;cgroup-v1(https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt)

cadvisor 获取指标时实际调用的是 runc/libcontainer 库&＃xff0c;而 libcontainer 是对 cgroup 文件 的封装&＃xff0c;即 cadvsior 也只是个转发者&＃xff0c;它的数据来自于cgroup 文件。

3.7 cgroup

cgroup 文件中的值是监控数据的最终来源&＃xff0c;如

• mem usage 的值&＃xff0c;来自于
  /sys/fs/cgroup/memory/docker/[containerId]/memory.usage_in_bytes

• 如果没限制内存&＃xff0c;Limit&＃61;machine_mem&＃xff0c;否则来自于
  /sys/fs/cgroup/memory/docker/[id]/memory.limit_in_bytes

• 内存使用率&＃61;memory.usage_in_bytes/memory.limit_in_bytes

一般情况下&＃xff0c;cgroup文件夹下的内容包括CPU、内存、磁盘、网络等信息&＃xff1a;

如 memory 下的几个常用的指标含义&＃xff1a;

memory.stat 中的信息是最全的&＃xff1a;

原理到这里结束&＃xff0c;这里解释下最开始的 kubectl top 的几个问题&＃xff1a;

四. 问题

4.1 kubectl top 为什么会报错

一般情况下 top 报错有以下几种&＃xff0c;可以 kubectl top pod -v&＃61;10看到具体的调用日志:

• 没有部署 heapster 或者 metric-server&＃xff0c;或者 pod 运行异常&＃xff0c;可以排查对应 pod 日志

• 要看的 pod 刚刚建出来&＃xff0c;还没来得及采集指标&＃xff0c;报 not found 错误&＃xff0c;默认 1 分钟

• 以上两种都不是&＃xff0c;可以检查下 kubelet 的 10255 端口是否开放&＃xff0c;默认情况下会使用这个只读端口获取指标&＃xff0c;也可以在 heapster 或 metric-server 的配置中增加证书&＃xff0c;换成 10250 认证端口

4.2 kubectl top pod 内存怎么计算&＃xff0c;包含 pause容器吗

每次启动 pod&＃xff0c;都会有一个 pause 容器&＃xff0c;既然是容器就一定有资源消耗&＃xff08;一般在 2-3M 的内存&＃xff09;&＃xff0c;cgroup 文件中&＃xff0c;业务容器和 pause 容器都在同一个 pod的文件夹下。

但 cadvisor 在查询 pod 的内存使用量时&＃xff0c;是先获取了 pod 下的container列表&＃xff0c;再逐个获取container的内存占用&＃xff0c;不过这里的 container 列表并没有包含 pause&＃xff0c;因此最终 top pod 的结果也不包含 pause 容器pod 的内存使用量计算kubectl top pod 得到的内存使用量&＃xff0c;并不是 cadvisor 中的 container_memory_usage_bytes&＃xff0c;而是 container_memory_working_set_bytes&＃xff0c;计算方式为&＃xff1a;

• container_memory_usage_bytes &＃61; container_memory_rss &＃43; container_memory_cache &＃43; kernel memory

• container_memory_working_set_bytes &＃61; container_memory_usage_bytes – total_inactive_file&＃xff08;未激活的匿名缓存页&＃xff09;

container_memory_working_set_bytes 是容器真实使用的内存量&＃xff0c;也是 limit限制时的 oom 判断依据。cadvisor 中的 container_memory_usage_bytes 对应 cgroup 中的 memory.usage_in_bytes 文件&＃xff0c;但 container_memory_working_set_bytes 并没有具体的文件&＃xff0c;他的计算逻辑在 cadvisor 的代码中&＃xff0c;如下&＃xff1a;


同理&＃xff0c;node 的内存使用量也是 container_memory_working_set_bytes。

4.3 kubectl top node 怎么计算&＃xff0c;和节点上直接 top 有什么区别

kubectl top node 得到的 cpu 和内存值&＃xff0c;并不是节点上所有 pod 的总和&＃xff0c;不要直接相加。top node 是机器上 cgroup 根目录下的汇总统计

在机器上直接 top 命令看到的值和 kubectl top node 不能直接对比&＃xff0c;因为计算逻辑不同&＃xff0c;如内存&＃xff0c;大致的对应关系是(前者是机器上 top&＃xff0c;后者是 kubectl top):

rss &＃43; cache &＃61; (in)active_anon &＃43; (in)active_file

4.4 kubectl top pod 和 exec 进入 pod 后看到的 top 不一样

top 命令的差异和上边一致&＃xff0c;无法直接对比&＃xff0c;同时&＃xff0c;就算你对 pod 做了 limit 限制&＃xff0c;pod 内的 top 看到的内存和 cpu 总量仍然是机器总量&＃xff0c;并不是pod 可分配量

• 进程的RSS为进程使用的所有物理内存&＃xff08;file_rss&＃xff0b;anon_rss&＃xff09;&＃xff0c;即Anonymous pages&＃xff0b;Mapped apges&＃xff08;包含共享内存&＃xff09;

• cgroup RSS为&＃xff08;anonymous and swap cache memory&＃xff09;&＃xff0c;不包含共享内存。两者都不包含file cache

4.5 kubectl top pod 和 docker stats得到的值为什么不同&＃xff1f;

docker stats dockerID 可以看到容器当前的使用量&＃xff1a;

如果你的 pod 中只有一个 container&＃xff0c;你会发现 docker stats 值不等于kubectl top 的值&＃xff0c;既不等于 container_memory_usage_bytes&＃xff0c;也不等于container_memory_working_set_bytes。因为docker stats 和 cadvisor 的计算方式不同&＃xff0c;总体值会小于 kubectl top&＃xff1a;计算逻辑是&＃xff1a;

docker stats &＃61; container_memory_usage_bytes - container_memory_cache

五. 后记

一般情况下&＃xff0c;我们并不需要时刻关心 node 或 pod 的使用量&＃xff0c;因为有集群自动扩缩容(cluster-autoscaler)和 pod 水平扩缩容&＃xff08;HPA&＃xff09;来应对这两种资源变化&＃xff0c;资源指标的意义更适合使用 prometheus 来持久化 cadvisor 的数据&＃xff0c;用于回溯历史或者发送报警。其他补充&＃xff1a;

• 虽然 kubectl top help 中显示支持 Storage&＃xff0c;但直到 1.16 版本仍然不支持

• 1.13 之前需要 heapster&＃xff0c;1.13 以后需要 metric-server&＃xff0c;这部分 kubectl top help 的输出 有误&＃xff0c;里面只提到了heapster

• k8s dashboard 中的监控图默认使用的是 heapster&＃xff0c;切换为 metric-server后数据会异常&＃xff0c;需要多部署一个metric-server-scraper 的 pod 来做接口转换&＃xff0c;具体参考 pr&＃xff1a;https://github.com/kubernetes/dashboard/pull/3504

六. 参考资料

• https://github.com/kubernetes-sigs/metrics-server/issues/193

• https://github.com/kubernetes/kubernetes/pull/83247

• https://www.cnblogs.com/liuhongru/p/11215447.html

• https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/docs/walkthrough.md#quantity-values

• https://github.com/fabric8io/kansible/blob/master/vendor/k8s.io/kubernetes/docs/design/resources.md

• https://erdong.site/linux/system/computer-unit-conversion.html

• https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu

• https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/6/html/resource_management_guide/sec-memory

• https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

• https://www.cnblogs.com/liuhongru/p/11215447.html

• https://github.com/moby/moby/issues/10824

• https://github.com/docker/cli/pull/80

本文转载自&＃xff1a;「Vermouth 的博客」&＃xff0c;原文&＃xff1a;https://url.hi-linux.com/r06US&＃xff0c;版权归原作者所有。欢迎投稿&＃xff0c;投稿邮箱: editor&＃64;hi-linux.com。

最近&＃xff0c;我们建立了一个技术交流微信群。目前群里已加入了不少行业内的大神&＃xff0c;有兴趣的同学可以加入和我们一起交流技术&＃xff0c;在 「奇妙的 Linux 世界」 公众号直接回复 「加群」 邀请你入群。

你可能还喜欢

点击下方图片即可阅读

Umbrel: 一款超高颜值的自托管个人服务系统&＃xff0c;支持 Raspberry Pi、Linux 等多种硬件


点击上方图片&＃xff0c;『美团|饿了么』外卖红包天天免费领

更多有趣的互联网新鲜事&＃xff0c;关注「奇妙的互联网」视频号全了解&＃xff01;