java cpu亲和_kubernetes中的CPU亲和性设置-这一篇就够了

虽然用户可以Kubernetes随意创建和使用Pod，但是有些特殊的使用场景需要更高的性能和更短的访问延时。kubelet提供了一些方法来管理各种复杂的工作负载。

准备工作

具有一个部署好的Kubernetes集群，并且可以使用kubectl命令行工具与集群互通。如果您还没有集群，则可以使用Minikube创建一个集群，也可以使用以下两种工具进行部署：

可以通过命令kubectl version来核查kubernetes的版本。

kubernetes的CPU 管理策略

默认情况下，kubelet使用CFS quota 机制限制Pod 的CPU资源。当node上运行许多设置了CPU limit的Pod时，不同pod上的工作负载可能在不同的CPU 核心上来回切换，不同的Pod中的计算task运行在哪个CPU核心上具体取决于Pod是否设置了limit以及在被执行时哪个CPU核心时空闲可用的。许多业务的工作负载在不同的CPU核心之间进行不停切换的情况并不敏感，因此也感知不到不停地CPU切换核心带来的负面影响。

但是，在对CPU cache亲和性和调度延迟敏感的业务场景中，kubelet可以通过设置CPU管理策略来确定node上CPU核心调度的优先级，来达到较好的性能。

配置

通过kubelet的 --cpu-manager-policy 配置项来设置CPU的管理策略，该配置项有两个可选值：

none: 默认策略。

static: 允许node上具有特定资源特征的Pod被授予更高的CPU亲和力和排他性。

CPU manager会定期通过CRI对资源状态进行更新，以使内存、CPU实际使用数量与cgroupfs保持一致。可以通过Kubelet配置值--cpu-manager-reconcile-period设置资源状态更新频率。如果未指定，则默认为与--node-status-update-frequency的值相同。

None

none策略会显式的使用默认的CPU亲和性方案，CPU的亲和性完全依赖于操作系统的自动调度。对于Guaranteed pods 的CPU限制会强制POD使用CFS的配合。

Static

static 策略：若Guaranteed级别的Pod中的Container中的CPU限制是大于等于1的整数，那么Container就可以运行在node上特定的一个或者几个独享CPU核心上。这种CPU核心的独享是通过cpuset cgroup controller来保证的.

Note: 像container runtime和kubelet这样的系统服务也可以运行在独享CPU上。这种独享性是相对于其他的Pod而言的。

Note: CPU Manager不支持在运行时对CPU进行online和offline操作。若node上的CPU发生了改变，则必须对该node进行维护并且通过删除kubelet根目录下的cpu_manager_state状态文件对CPU manager进行手动重置。

该策略管理着一个CPU的共享池，该共享池初始包含了node上的所有CPU。可分配的独享CPU的数量等于node上CPU的总数减去kubelet通过--kube-reserved 或者 --system-reserved 选项指定的保留CPU的数目。通过这些选项指定的保留CPU的个数必须是整数，并且在初始的共享池中按照物理CPU的Core ID的升序顺序依次设置为保留状态。BestEffort 和 Burstable类型的Pod以及CPU核数设置为非整数的 Guaranteed类型的Pod会已共享的方式使用共享池中的剩余CPU。只有requests和limits的值为整数的 Guaranteed类型的Pod才会以独享的方式使用共享池中的CPU。

Note: 当启用static策略时，必须通过--kube-reserved和/或--system-reserved选项为kubelet保留一部分CPU，而保留的数量必须大于0。因为若为kubelet的保留CPU为零的话，共享池变就有变为空的可能性。

当node满足Guaranteed级别的Pod的资源需求且启用了static策略时，该pod将会被调度到该node上，进而从该node的共享池中移除pod所需要的数量的CPU核心并将这些CPU放置到容器的cpuset中。 static策略可以增加计算密集型工作负载的CPU亲和性并减少CPU上下文切换的次数。

假设有如下几种Pods，我们针对其进行分析：

spec:

containers:

- name: nginx

image: nginx

由于没有设置 requests 或 limits，因此该Pod是BestEffort级别的. 该Pod会运行在共享池中.

spec:

containers:

- name: nginx

image: nginx

resources:

limits:

memory: "200Mi"

requests:

memory: "100Mi"

由于该Pod的requests值与limits值是不同的，并且cpu的资源限制也没有指定，因此该Pod是Burstable级别的。该Pod运行在共享池中。

spec:

containers:

- name: nginx

image: nginx

resources:

limits:

memory: "200Mi"

cpu: "2"

requests:

memory: "100Mi"

cpu: "1"

由于该Pod的requests值与limits值是不同的，因此该Pod是Burstable级别的。该Pod运行在共享池中。

spec:

containers:

- name: nginx

image: nginx

resources:

limits:

memory: "200Mi"

cpu: "2"

requests:

memory: "200Mi"

cpu: "2"

由于该Pod同时指定了requests 和 limits的值并且两者相同，因此该Pod是Guaranteed级别的。除此之外，container的CPU限制是大于等于1的整数，因此nginx container会运行在两个独占的CPU上。

spec:

containers:

- name: nginx

image: nginx

resources:

limits:

memory: "200Mi"

cpu: "1.5"

requests:

memory: "200Mi"

cpu: "1.5"

由于该Pod同时指定了requests 和 limits的值并且两者相同，因此该Pod是Guaranteed级别的。但是由于container中对CPU的资源限制是非整数，因此该Pod运行在共享池中，无法独占CPU。

spec:

containers:

- name: nginx

image: nginx

resources:

limits:

memory: "200Mi"

cpu: "2"

该Pod由于只设置了limits的值，而requests 在没有明确指定的情况下，默认与limits的值相等，因此该Pod是 Guaranteed 级别。并且由于container的CPU的资源限制是一个大于等于1的整数。所以nginx container会运行在2个独享的CPU核心上。

总结

只有同时满足如下条件时，容器才可以运行在独享CPU上:

1 通过kubelet的 --cpu-manager-policy 配置项启用static策略

2 容器必须是Guaranteed的级别

3 容器的CPU限制必须是大于等于1的整数