虽然用户可以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的管理策略，该配置项有两个可选值：
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的整数
网友评论