成都建站价格,wordpress打赏链接,副食店年报在哪个网站做,营销技巧视频讲座视频文章目录 资源模型QoS 模型GPU 管理 资源模型
在 Kubernetes 里#xff0c;Pod 是最小的原子调度单位。这也就意味着#xff0c;所有跟调度和资源管理相关的属性都应该是属于 Pod 对象的字段。而这其中最重要的部分#xff0c;就是 Pod 的 CPU 和内存配置#xff0c;如下所… 文章目录 资源模型QoS 模型GPU 管理 资源模型
在 Kubernetes 里Pod 是最小的原子调度单位。这也就意味着所有跟调度和资源管理相关的属性都应该是属于 Pod 对象的字段。而这其中最重要的部分就是 Pod 的 CPU 和内存配置如下所示
apiVersion: v1
kind: Pod
metadata:name: frontend
spec:containers:- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: passwordresources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500m- name: wpimage: wordpressresources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500m在 Kubernetes 中像 CPU 这样的资源被称作“可压缩资源”compressible resources。它的典型特点是当可压缩资源不足时Pod 只会“饥饿”但不会退出。而像内存这样的资源则被称作“不可压缩资源incompressible resources。当不可压缩资源不足时Pod 就会因为 OOMOut-Of-Memory被内核杀掉。Pod 可以由多个 Container 组成所以 CPU 和内存资源的限额是要配置在每个 Container 的定义上的。这样Pod 整体的资源配置就由这些 Container 的配置值累加得到。 Kubernetes 里为 CPU 设置的单位是“CPU 的个数”。比如cpu1 指的就是这个 Pod 的 CPU 限额是 1 个 CPU。当然具体“1 个 CPU”在宿主机上如何解释是 1 个 CPU 核心还是 1 个 vCPU还是 1 个 CPU 的超线程Hyperthread完全取决于宿主机的 CPU 实现方式。Kubernetes 只负责保证 Pod 能够使用到“1 个 CPU”的计算能力。Kubernetes 允许你将 CPU 限额设置为分数。当然你可以直接把这个配置写成 cpu0.5。但在实际使用时推荐使用 500m 的写法毕竟这才是 Kubernetes 内部通用的 CPU 表示方式。Kubernetes 里对于内存资源来说它的单位自然就是 bytes。Kubernetes 支持使用 Ei、Pi、Ti、Gi、Mi、Ki或者 E、P、T、G、M、K的方式来作为 bytes 的值。比如在上面的例子里Memory requests 的值就是 64MiB (2 的 26 次方 bytes) 。这里要注意区分 MiBmebibyte和 MBmegabyte的区别。备注1Mi1024*10241M1000*1000 Kubernetes 里 Pod 的 CPU 和内存资源实际上还要分为 limits 和 requests 两种情况如下所示
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory两者的区别在调度的时候kube-scheduler 只会按照 requests 的值进行计算。而在真正设置 Cgroups 限制的时候kubelet 则会按照 limits 的值来进行设置。
QoS 模型
Kubernetes 中不同的 requests 和 limits 的设置方式其实会将这个 Pod 划分到不同的 QoS 级别当中。 当 Pod 里的每一个 Container 都同时设置了 requests 和 limits并且 requests 和 limits 值相等的时候这个 Pod 就属于 Guaranteed 类别。当 Pod 不满足 Guaranteed 的条件但至少有一个 Container 设置了 requests。那么这个 Pod 就会被划分到 Burstable 类别。当一个 Pod 既没有设置 requests也没有设置 limits那么它的 QoS 类别就是 BestEffort。 QoS 划分的主要应用场景是当宿主机资源紧张的时候kubelet 对 Pod 进行 Eviction即资源回收时需要用到的。当 Kubernetes 所管理的宿主机上不可压缩资源短缺时就有可能触发 Eviction。比如可用内存memory.available、可用的宿主机磁盘空间nodefs.available以及容器运行时镜像存储空间imagefs.available等等。Eviction 在 Kubernetes 里其实分为 Soft 和 Hard 两种模式。 Soft Eviction 允许你为 Eviction 过程设置一段“优雅时间”比如 imagefs.available2m就意味着当 imagefs 不足的阈值达到 2 分钟之后kubelet 才会开始 Eviction 的过程。Hard Eviction 模式下Eviction 过程就会在阈值达到之后立刻开始。 当 Eviction 发生的时候kubelet 具体会挑选哪些 Pod 进行删除操作就需要参考这些 Pod 的 QoS 类别了。 首当其冲的自然是 BestEffort 类别的 Pod。其次是属于 Burstable 类别、并且发生“饥饿”的资源使用量已经超出了 requests 的 Pod。最后才是 Guaranteed 类别。并且Kubernetes 会保证只有当 Guaranteed 类别的 Pod 的资源使用量超过了其 limits 的限制或者宿主机本身正处于 Memory Pressure 状态时Guaranteed 的 Pod 才可能被选中进行 Eviction 操作。 当然对于同 QoS 类别的 Pod 来说Kubernetes 还会根据 Pod 的优先级来进行进一步地排序和选择。
cpuset 的设置
在使用容器的时候可以通过设置 cpuset 把容器绑定到某个 CPU 的核上而不是像 cpushare 那样共享 CPU 的计算能力。这种情况下由于操作系统在 CPU 之间进行上下文切换的次数大大减少容器里应用的性能会得到大幅提升。事实上cpuset 方式是生产环境里部署在线应用类型的 Pod 时非常常用的一种方式。在 Kubernetes 里又该如何实现呢首先你的 Pod 必须是 Guaranteed 的 QoS 类型然后你只需要将 Pod 的 CPU 资源的 requests 和 limits 设置为同一个相等的整数值即可。这时候该 Pod 就会被绑定在 独占的 CPU 核上。当然具体是哪个 CPU 核是由 kubelet 分配的。 在实际的使用中强烈建议你将 DaemonSet 的 Pod 都设置为 Guaranteed 的 QoS 类型。否则一旦 DaemonSet 的 Pod 被回收它又会立即在原宿主机上被重建出来这就使得前面资源回收的动作完全没有意义了。 GPU 管理
后续补充…
你知道的越多你不知道的越多。
