Kubernetes下pod控制组管理解析

Posted 2023-04-11

参考技术A 在 Kubernetes 里面，将资源分成不同的 QoS 类别，并且通过 pod 里面的资源定义来区分 pod 对于平台提供的资源保障的 SLA 等级：

针对不同的优先级的业务，在资源紧张或者超出的时候会有不同的处理策略。
同时，针对 CPU 和内存两类不同类型的资源，一种是可压缩的，一种是不可压缩的，所以资源的分配和调控策略也会有很大区别。

CPU 资源紧缺时，如果节点处于超卖状态，则会根据各自的 requests 配置，按比例分配 CPU 时间片，而内存资源紧缺时需要内核的 oom killer 进行管控，
Kubernetes 负责为 OOM killer 提供管控依据：

OOM 得分主要根据 QoS 类和容器的 requests 内存占机器总内存比来计算：

OOM 得分越高，该进程的优先级越低，越容易被终止；根据公式， Burstable 优先级的 pod 中， requests 内存申请越多，越容易在 OOM 的时候被终止。

首先我们先看下 pod 的控制组层级

其中 kubepods-besteffort.slice 存放 besteffort 类型 pod 控制组配置， kubepods-burstable.slice 存放 burstable 类型 pod 控制组配置。

kubepods-pod934b0aa2_1d1b_4a81_bfcf_89c4beef899e.slice 、 kubepods-podca849e84_aa86_4402_bf31_e7e73faa77fe.slice 则为 Guaranteed 类型 pod

为了更好的解释说明，我们创建一个新的 Guaranteed 类型的 pod 用于测试:

kubepods-podf56bf66f_3efb_4c80_8818_37de69ee5b72.slice 这个名称是怎么命名的呢？

命名格式为： kubepods-pod<pod uid>.slice ，并且会将 uid 中 - 转换为 _

我们发现怎么有两个容器呢？（ docker-08974ffd61043b34e4cd5710d5446eb423c6371afb4c9d106e608f08cc1182a3.scope 、 docker-d33dc12340fd32b35148293c21f84dab14f2274046056bbeef9e9666d1d0dc2a.scope ）

其实是业务容器 + infra 沙箱容器，并且命名格式遵循： docker-<container id>.scope

我们可根据以下命令获取业务容器 id ：

我们上述对 pod 配额的定义为:

其实等同于以以下方式启动 docker 容器:

我们可以看下 docker 容器的配额：

.HostConfig.CpuShares 对应控制内的 cpu.shares 文件内容
.HostConfig.CpuPeriod 对应控制内的 cpu.cpu.cfs_period_us 文件内容
.HostConfig.CpuQuota 对应控制内的 cpu.cfs_quota_us 文件内容

并且我们发现 k8s 基于 pod 管理控制组（同一 pod 内的容器所属同一控制组）

我们可以得出记录： k8s 通过控制组的 cpu.shares 、 cpu.cpu.cfs_period_us 、 cpu.cfs_quota_us 配置，达到限制 CPU 的目的。

那么这三个文件是用来干嘛的？

当系统中有两个 cgroup ，分别是 A 和 B ， A 的 shares 值是 1024 ，B 的 shares 值是 512 ，
那么 A 将获得 1024/(1024+512)=66% 的 CPU 资源，而 B 将获得 33% 的 CPU 资源。 shares 有两个特点：

从上面两个特点可以看出：

在闲的时候， shares 基本上不起作用，只有在 CPU 忙的时候起作用，这是一个优点。

由于 shares 是一个绝对值，需要和其它 cgroup 的值进行比较才能得到自己的相对限额，而在一个部署很多容器的机器上， cgroup 的数量是变化的，所以这个限额也是变化的，自己设置了一个高的值，但别人可能设置了一个更高的值，所以这个功能没法精确的控制 CPU 使用率。

值对应关系为： resources.requests.cpu * 1024 = cpu.shares

如： resources.requests.cpu 为3的时候， cpu.shares 值为 3072 ； resources.requests.cpu 为 100m 的时候， cpu.shares 值为 102

并且 k8s 下容器控制组的 cpu.cpu.cfs_period_us 值固定为 100000 ，实际只设置 cpu.cfs_quota_us 值

例如：

cpu.cpu.cfs_period_us 为 100000 （单位微妙，即0.1秒）， cpu.cfs_quota_us 为 500000 （单位微妙，即 0.5 秒）时， resources.limits.cpu 为5，即5个 cpu 核心。
cpu.cpu.cfs_period_us 为 100000 （单位微妙，即0.1秒）， cpu.cfs_quota_us 为 10000 （单位微妙，即 0.01 秒）时， resources.limits.cpu 为0.1（或100m），即0.1个 cpu 核心。

与 cpu 不同， k8s 里 pod 容器的 requests.memory 在控制组内没有对应的属性，未起到限制作用，只是协助 k8s 调度计算。
而 pod 容器的 limits.memory 对应控制组里的 memory.limit_in_bytes 值。

Kubernetes 配置Pod和容器(五)应用资源配额和限制

参考技术A 演示使用了下面的资源： Namespace , ResourceQuota , 和 LimitRange 。

你必须有一个Kubernetes集群，并且kubectl命令行工具能够和你的集群沟通。如果你还没有集群，可以使用 Minikube 创建一个集群。

集群管理员操作多用户团队的集群，集群管理员希望可以控制特定集群中可以消耗资源的总量，以提升集群的共享和控制成本。

这个例子将在自定义的命名空间工作以演示相关的概念。

让我们新建一个名字为quota-example的命名空间：

集群管理员像控制下面的资源：

让我们新建一个简单的配额来控制命名空间中的对象计数。

配额系统观察到配额已经创建，并将计算命名空间中资源的消耗。很快就可以看到。

我们来观察配额，看看目前命名空间中消耗的是什么：

如果用户创建应用所需的资源多余每种资源指定的数量，配额系统将不允许创建。

限制命名空间可以消耗的计算资源量，让我们创建一个配额跟踪计算资源。

我们来观察配额，看看目前命名空间中消耗的是什么：

配额系统现在不允许命名空间中超过4个非终端pod。此外它将强制pod中的每个容器都要定义cpu和内存的request和limit。

Pod的发起者很少给他们的pod指定资源请求和限制。

由于我们对项目施行了配额，让我看看当最终用户创建了没有cpu和内存限制的pod发生了什么，这个pod包含一个nginx容器。

这个演示我们创建了一个运行了nginx的deployment：

让我们看看创建的pod：

可以看到没有创建pod！让我们看看deployment发生了什么。

deployment创建了一个相应的副本，并尝试创建一个pod。

看看replica set获取很多详细信息。

Kubernetes API服务拒绝replica set请求创建一个pod因为我们的pod没有指定requests或limits的cpu和内存。

所以我们可以指定pod可以消耗的cpu和内存资源量的默认值：

如果Kubernetes API服务观察到命名空间中创建pod的请求，并且pod中的容器没有设置任何计算资源请求，将会配置默认的资源request和limit作为控制的一部分被应用。

在这个例子中，创建的每个pod都包含等同于以下的计算资源：

现在我们已经为命名空间应用了默认的计算资源，我们的replica set能够创建他的pod。

如果打印命名空间的配额使用：

你可以看到，创建的pod正在消耗计算资源，并且Kubernetes可以比较明确的跟踪使用情况。

我们假设你不想在命名空间中指定默认的消耗资源。相反你希望让用户在他们的命名空间中运行特定数量的BestEffort pod，以利用松散的计算资源，然后要求用户对需要较高服务质量的pod进行明确的资源请求。

让我们创建一个命名空间并提供两个配额来演示这个行为：

在这种场景下，一个pod没有设置计算资源请求将被"best-effort"配额追踪。

让我们来创建两个deployments来演示：

即使没有指定默认限制，best-effort-nginx将创建所有的8个pod。这是因为它追踪best-effort配置，not-best-effort配置将忽略它。not-best-effort配置将追踪not-best-effort-nginx deployment因为它创建了具有Burstable服务质量的pod。

让我们看看命名空间的pod列表：

你可以看到10个pod已经被允许创建。

让我们看看现在命名空间配额的使用情况：

可以看到，best-effort配额追踪创建best-effort-nginx deployment中8个pod的使用，并且not-best-effort配置追踪我们在配额里面创建的not-best-effort-nginx的使用情况。

scope提供了一种机制细分资源集合来追踪配额说明，以便在管理者部署和跟踪资源消耗方面提供更大的灵活性。

除了BestEffort和NotBestEffort范围，有一些范围限制长时运行与时间限制的pod。Terminating范围将匹配spec.activeDeadlineSeconds不为nil的任何pod。NotTerminating范围将匹配spec.activeDeadlineSeconds为nil的任何pod。这些范围允许你根据集群中节点上的预期的运行周期来限定pod。

消耗节点cpu和内存资源的举措可能受命名空间定义的配额限制。

可以调整消耗这些资源的任何举措，或者可以选择默认命名空间级别的默认值来满足你的最终需求。

配额可以根据服务质量和集群节点上预期的持久性进行分配。