或者如何将CPU时间分配给我的容器？

测量CPU

Pod可用的CPU总量是节点的可分配CPU。 CPU资源以cpu单位度量：绝对数量，其分数单位为millicore（1 CPU = 1000m CPU）。

1个CPU的含义取决于所使用的云提供商。 在亚马逊上，它是一个虚拟CPU（vCPU）-" CPU核心的一个线程，T2实例除外"。 根据定义，除非禁用超线程，否则vCPU是逻辑核心。

可以通过请求（所需的最小数量）和限制（允许的最大数量）定义容器的资源需求。 例如，一个容器的最小CPU需求量为200m，允许的最大CPU量为500m。

Kubernetes上的CPU调度（Linux）

在操作系统中，CPU是有限的资源，在多个工作单元（任务）之间共享。 计划是将工作分配给完成工作的（共享）资源的方法。

Kubernetes使用cgroup来控制CPU调度并在容器级别隔离CPU使用率。 kubernetes CRI委托容器运行时为Linux容器配置资源约束。

"完全公平调度程序"（CFS）是Linux内核中的默认任务调度程序（自2.6.23开始）。 它根据任务的优先级/权重或分配给cgroup的份额，在任务组（cgroup）之间按比例划分CPU时间（CPU带宽）。 可以通过cpu子系统配置CFS。

根据请求进行CPU调度

Pod的总请求用作在节点上调度它的过滤标准。 只能在具有足够可分配资源的节点上调度Pod，以适应Pod的请求-即，可分配≤请求总数。

尽管以绝对单位（" millicore"）指定，但是容器的请求定义了其访问CPU周期的相对优先级（以CPU份额表示）。

这意味着优先级为请求500m的容器在该节点上接收的CPU周期至少是请求250m的容器的两倍。 容器的CPU份额越大，使用CPU周期的优先级越高。

需要注意的几点：

· 优先，但不能保证：例如，第一个容器的任务在大多数时间都可以处于空闲状态（阻塞）。 但是，当所有容器的任务都在争夺CPU周期时，第一个容器的任务至少具有两倍的优先级。

· 至少不完全是这样：当不使用容量时，任何容器都可能破裂以使用该备用容量。 如果每个其他容器的任务都处于空闲状态（阻塞），则第一个容器的任务可以使用的CPU周期尽可能多。

· CPU周期，而不是CPU时间：分配的数量可能会有所不同，因此，即使可以保证将一半的量子分配给特定的容器，也不会占用一半的CPU时间。

· CPU在节点而不是核心上循环：在多核系统上，CPU时间份额分配在所有CPU核心上。 即使将容器限制为少于100％的CPU周期，它也可以使用每个CPU内核的100％。

QoS类别得到保证的TK Pod被安排为单独的CPU（和CPU管理策略），也可以为某些Pod预留CPU。

设计注意事项

使用相对份额来指定CPU意味着，一个cgroup可用的CPU时间的实际量可以根据系统上存在的cgroup的数量而变化。 之所以会发生这种情况，是因为分配给给定cgroup的CPU时间就是份额数（容器的请求）除以可用份额总数（所有容器的请求）。

但是，节点总请求的上限（由节点可分配并由调度程序强制执行）使容器之间的相对优先级（和CPU时间的实际数量）保持稳定：第一个容器的优先级始终为的两倍。 第二个容器，只要它们位于同一节点上即可—不管同一节点上存在多少其他容器。

类似设计

Amazon ECS（在EC2上）的设计非常相似：CPU资源以" CPU单位"（1个vCPU = 1024单位）进行度量。 每个任务都使用许多cpu单元创建，这些cpu单元将用于定义其容器的CPU份额。 节点上容器的cpu单元的总和受EC2实例上的单元数（1024 * vCPU）约束，这也由调度程序强制执行。

但是，Fargate上的Amazon EKS允许在Amazon Fargate上调度Pod，同时保证CPU单元数量，并且在Pod级别对资源收费。

(本文翻译自Reinaldo "Kingnaldo" Junior的文章《Understanding Kubernetes CPU scheduling》，参考：https://medium.com/@
kingnaldo/understanding-cpu-scheduling-on-kubernetes-1695bf08cafc)