40 | Kubernetes的资源模型与资源管理

张磊



该思维导图由 AI 生成，仅供参考

你好，我是张磊。今天我和你分享的主题是：Kubernetes 的资源模型与资源管理。
作为一个容器集群编排与管理项目，Kubernetes 为用户提供的基础设施能力，不仅包括了我在前面为你讲述的应用定义和描述的部分，还包括了对应用的资源管理和调度的处理。那么，从今天这篇文章开始，我就来为你详细讲解一下后面这部分内容。
而作为 Kubernetes 的资源管理与调度部分的基础，我们要从它的资源模型开始说起。
我在前面的文章中已经提到过，在 Kubernetes 里，Pod 是最小的原子调度单位。这也就意味着，所有跟调度和资源管理相关的属性都应该是属于 Pod 对象的字段。而这其中最重要的部分，就是 Pod 的 CPU 和内存配置，如下所示：
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
备注：关于哪些属性属于 Pod 对象，而哪些属性属于 Container，你可以在回顾一下第 14 篇文章《深入解析 Pod 对象（一）：基本概念》中的相关内容。
在 Kubernetes 中，像 CPU 这样的资源被称作“可压缩资源”（compressible resources）。它的典型特点是，当可压缩资源不足时，Pod 只会“饥饿”，但不会退出。
而像内存这样的资源，则被称作“不可压缩资源（incompressible resources）。当不可压缩资源不足时，Pod 就会因为 OOM（Out-Of-Memory）被内核杀掉。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入探讨了Kubernetes资源管理与QoS模型，强调了Pod作为最小的原子调度单位，并详细解释了CPU和内存配置的设置方式及其影响。介绍了Kubernetes中的QoS模型，将Pod划分为Guaranteed、Burstable和BestEffort三种类别，并解释了它们在宿主机资源紧张时的作用。最后，提到了Kubernetes中cpuset的设置特性，通过设置cpuset将容器绑定到特定CPU核上，提升应用性能。对于想要深入了解Kubernetes资源管理的读者具有很高的参考价值。文章还提到了对Pod进行Eviction的具体策略和实践方式，以及建议将DaemonSet的Pod都设置为Guaranteed的QoS类型。文章内容丰富，对于Kubernetes资源管理感兴趣的读者具有很高的参考价值。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入剖析 Kubernetes》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(46)

最新
精选

DJH
“为什么宿主机进入 MemoryPressure 或者 Dis...“ 这是因为给宿主机打了污点标记吗？
作者回复: 对
2018-11-23
5
79
gogo
老师您好，cpu设置limit之后，容器的cpu使用率永远不会超过这个限制对吗？而mem设置limit之后，容器mem使用率有可能超过这个限制而被kill掉，也就是说设置了cpu limit之后，容器永远不会因为cpu超过限制而被kill对吗
作者回复: 是
2018-11-23
5
39
刘岚乔月
1、3、5都在追文章，一直都有一个疑问，请作者能解惑下。对于主java是其他语言（非运维）的同学来说，我们是否需要深入了解k8s和docker（还是停留在使用层面）我想一直跟着学的同学大部门还是冲着能找到更好的工作去的（有情怀的同学请忽略）目前更大公司的招聘对于要求掌握k8s和docker的基本上都是运维岗位。并没有招聘java要求掌握k8s和docker，面试中也不曾问到。感觉很尴尬 - -！毕竟时间成本在哪，请作者能阐述下自己的观点！
作者回复: kubernetes 是云时代的开发者工具。重要的事情只说一遍。
2018-11-25
3
20
虎虎❤️
在namespace limitRange 里面设置了default request 和 default limit之后，创建出来的pod即使不显式指定limit和request，是不是也是guaranteed？
作者回复: 是的
2018-11-27
4
10
unique
这时候，该 Pod 就会被绑定在 2 个独占的 CPU 核上。独占的意思就是其它pod 不能使用这两个CPU了么？
作者回复: 对
2018-11-23
5
9
beenchaos
请问张老师，cpuset是否只适用于nginx或者redis这类单线程的应用，为这类进程单独绑定一个CPU。而针对多线程的应用程序，设置cpuset反而会限制该应用程序的并发能力？这样理解准确么？
作者回复: 不能这么理解，首先，cpuset也可以绑定多个核的，其次，它的主要作用是让其他进程不能来到被独占的core上。
2019-05-28

3
初学者
老师，能不能讲一下kubernetes是如何划分和管理宿主机上的cgroups结构的？
作者回复: 这个非常简单，就是按qos划分成三种
2018-12-01

3
汪浩
被称作“不可压缩资源（compressible resources）应该是 uncompressible
作者回复: 对，得然后编辑改一下
2018-11-25

3
Pixar
如果某个Guaranted Pod 的 Mem 设定为了256，在宿主机资源不紧张但该Pod 的的 mem 使用量达到了256以后会出现什么情况？会被oom杀掉吗？
作者回复: 见QoS部分
2018-11-23
2
1
chenhz
Pod 是最小的原子调度单位，所有跟调度和资源管理相关的属性，都是 Pod 对象属性的字段。其中最重要的是 Pod 和 CPU 配置。其中，CPU 属于可压缩资源，内存属于不可压缩资源。当可压缩资源不足时，Pod 会饥饿；当不可压缩资源不足时，Pod 就会因为 OOM 被内核杀掉。 Pod ，即容器组，由多个容器组成，其 CPU 和内存配额在 Container 上定义，其 Container 配置的累加值即为 Pod 的配额。 ## limits 和 requests - requests：kube-scheduler 只会按照 requests 的值进行计算。 - limits：kubelet 则会按照 limits 的值来进行设置 Cgroups 限制. ## QoS 模型 - Guaranteed：同时设置 requests 和 limits，并且 requests 和 limit 值相等。优势一是在资源不足 Eviction 发生时，最后被删除；并且删除的是 Pod 资源用量超过 limits 时才会被删除；优势二是该模型与 docker cpuset 的方式绑定 CPU 核，避免频繁的上下午文切换，性能会得到大幅提升。 - Burstable：不满足 Guaranteed 条件，但至少有一个 Container 设置了 requests - BestEffort：没有设置 requests 和 limits。 ## Eviction ```bash kubelet --eviction-hard=imagefs.available<10%,memory.available<500Mi,nodefs.available<5%,nodefs.inodesFree<5% --eviction-soft=imagefs.available<30%,nodefs.available<10% \ --eviction-soft-grace-period=imagefs.available=2m,nodefs.available=2m \ --eviction-max-pod-grace-period=600 ``` 两种模式： - soft: 如 `eviction-soft-grace-period=imagefs.available=2m` eviction 会在阈值达到 2 分钟后才会开始 - hard：evivtion 会立即开始。 **eviction 计算原理**：将 Cgroups （limits属性）设置的值和 cAdvisor 监控的数据相比较。最佳实践：DaemonSet 的 Pod 都设置为 Guaranteed，避免进入“回收->创建->回收->创建”的“死循环”。
2020-03-19
2
42

收起评论