由问题进行展开
Kubernetes如何根据Pod的Requests和Limits配置,来实现针对Pod的不同级别的资源服务质量控制(QoS)
的呢?
什么是Requests和Limits
在Kubernetes的QoS体系中,需要保证高可靠的Pod可以申请可靠资源,而一些非高可靠行的Pod可以申请可靠性较低或不可靠的资源。
Pod容器资源的配置分为Requests和Limits,其中Requests是Kubernetes调度时能为容器提供的完全、可保证的资源量(一定可以拿到的最低保障资源),而Limits是系统允许容器运行时可能使用的资源量的上限(最高上限)。Pod级别的资源配置是通过计算Pod内所有容器的资源配置的总和得出来的。
超售机制
Kubernetes中Pod的Requests和Limits资源配置有如下特点:
-
如果Pod配置的Requests值等于Limits值,那么该Pod可以获得的资源是完全可靠的。
-
如果Pod的Requests值小于Limits值,那么该Pod获得资源可以分为两个部分:
-
完全可靠的资源,资源量的大小等于Requests值;
-
不可靠的资源,资源量最大等于Limits与Requests的差额,这份不可靠的资源能够申请多少,取决于当时主机上容器可用资源的余量。
-
通过这种机制,Kubernetes可以实现节点资源的超售(Over Subscription),比如:
- 在CPU完全充足的情况下,某机器共有32GiB内存可供容器使用。
- 容器配置为Requests值为1GiB、Limits值为2GiB。
- 那么在该机器上最多可以同时运行32个容器,每个容器最多可以使用2GiB内存。
- 如果这些容器的
内存使用峰值
能错开,那么所有容器都可以正常运行。
超售机制能有效提高资源的利用率,也不会影响容器申请的完全可靠资源
的可靠性.
限制机制
Requests和Limits对不同计算资源类型的限制机制
根据上文的内容可知,容器的资源配置满足以下两个条件:
- Requests <= 节点可用资源;
- Requests <= Limits
Kubernetes根据Pod配置的Requests值来调度Pod,Pod在成功调度之后会得到Requests值定义的资源来运行;如果Pod所在机器上的资源有空余,则Pod可以申请更多的资源,最多不能超过Limits的值。
下面看一下Requests和Limits针对不同计算资源类型的限制机制的诧异,这种诧异主要取决于计算资源类型是可压缩资源
还是不可压缩资源
。
可压缩资源
-
Kubernetes目前支持的可压缩资源是CPU。
-
Pod可以得到Requests配置的CPU使用量,而能否使用查过Requests值的部分取决于系统的负载和调度。不过由于目前Kubernetes和Docker的CPU隔离机制都是在容器级别起作用的,所以Pod级别的资源配置并不能完全得到保障;Pod级别的cgroup正在紧锣密鼓的开发中,如果将来引入,就可以确保Pod级别的资源配置准确运行。
-
空闲的CPU资源按照容器Requests值的比例分配。举例说明: