理解Resource QoS

由问题进行展开

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值的比例分配。举例说明：