本篇内容主要讲解“kubernetes资源QOS机制实现原理是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“kubernetes资源QOS机制实现原理是什么”吧!
创新互联服务项目包括兴业网站建设、兴业网站制作、兴业网页制作以及兴业网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，兴业网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到兴业省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
QOS是k8s中一种资源保护机制，其主要是针对不可压缩资源比如的内存的一种控制技术，比如在内存中其通过为不同的Pod和容器构造OOM评分，并且通过内核的策略的辅助，从而实现当节点内存资源不足的时候，内核可以按照策略的优先级，优先kill掉哪些优先级比较低(分值越高优先级越低)的Pod，今天来分析下背后的实现
在Linux中一切皆文件，控制CGroup本身也是通过配置文件进行的,这是我创建的一个内存Lmits为200M的Pod的容器的配置
# pwd /sys/fs/cgroup # cat ./memory/kubepods/pod8e172a5c-57f5-493d-a93d-b0b64bca26df/f2fe67dc90cbfd57d873cd8a81a972213822f3f146ec4458adbe54d868cf410c/memory.limit_in_bytes 209715200
这里我们重点关注内存相关的两个配置：VMOvercommitMemory其值为1，表示运行分配所有的物理内存资源，注意不包括SWAP资源VMPanicOnOOM其值为0：表示当内存不足的时候触发oom_killer进行选择部分进程进行kill，QOS也是通过影响其kill流程来实现的
func setupKernelTunables(option KernelTunableBehavior) error {
desiredState := map[string]int{
utilsysctl.VMOvercommitMemory: utilsysctl.VMOvercommitMemoryAlways,
utilsysctl.VMPanicOnOOM: utilsysctl.VMPanicOnOOMInvokeOOMKiller,
utilsysctl.KernelPanic: utilsysctl.KernelPanicRebootTimeout,
utilsysctl.KernelPanicOnOops: utilsysctl.KernelPanicOnOopsAlways,
utilsysctl.RootMaxKeys: utilsysctl.RootMaxKeysSetting,
utilsysctl.RootMaxBytes: utilsysctl.RootMaxBytesSetting,
}QOS打分机制主要是根据Requests和limits里面的资源限制来进行类型判定与打分的，我们就来快速看下这部分的实现
遍历所有的容器列表，注意这里会包含所有的初始化容器和业务容器
requests := v1.ResourceList{}
limits := v1.ResourceList{}
zeroQuantity := resource.MustParse("0")
isGuaranteed := true
allContainers := []v1.Container{}
allContainers = append(allContainers, pod.Spec.Containers...)
// 追加所有的初始化容器
allContainers = append(allContainers, pod.Spec.InitContainers...)这里遍历所有的Requests和Limits限制的资源，分别加入到不同的资源集合汇总，其中判定是不是Guaranteed主要是根据limits里面的资源是否包含CPU和内存两种资源，都包含才可能是Guaranteed
for _, container := range allContainers {
// process requests
for name, quantity := range container.Resources.Requests {
if !isSupportedQoSComputeResource(name) {
continue
}
if quantity.Cmp(zeroQuantity) == 1 {
delta := quantity.DeepCopy()
if _, exists := requests[name]; !exists {
requests[name] = delta
} else {
delta.Add(requests[name])
requests[name] = delta
}
}
}
// process limits
qosLimitsFound := sets.NewString()
for name, quantity := range container.Resources.Limits {
if !isSupportedQoSComputeResource(name) {
continue
}
if quantity.Cmp(zeroQuantity) == 1 {
qosLimitsFound.Insert(string(name))
delta := quantity.DeepCopy()
if _, exists := limits[name]; !exists {
limits[name] = delta
} else {
delta.Add(limits[name])
limits[name] = delta
}
}
}
if !qosLimitsFound.HasAll(string(v1.ResourceMemory), string(v1.ResourceCPU)) {
// 必须是全部包含cpu和内存限制
isGuaranteed = false
}
}如果Pod里面的容器没有任何requests和limits的限制则就是BestEffort
if len(requests) == 0 && len(limits) == 0 {
return v1.PodQOSBestEffort
}要是Guaranteed必须是资源相等，并且限定的数量相同
// Check is requests match limits for all resources.
if isGuaranteed {
for name, req := range requests {
if lim, exists := limits[name]; !exists || lim.Cmp(req) != 0 {
isGuaranteed = false
break
}
}
}
if isGuaranteed &&
len(requests) == len(limits) {
return v1.PodQOSGuaranteed
}如果不是上面两种就是最后一种burstable了
return v1.PodQOSBurstable
其中guaranteedOOMScoreAdj是-998其实这跟OOM实现有关系，一台node节点上主要是三部分组成：kubelet主进程、docker进程、业务容器进程，而OOM的打分里面-1000表示该进程不会被oom所kill, 那一个业务进程最少也就只能是-999因为你不能保证自己的业务永远不会出现问题，所以在QOS里面-999其实就是kubelet和docker进程所保留的，剩下的才能作为业务容器分配(分值越高越容易被kill)
// KubeletOOMScoreAdj is the OOM score adjustment for Kubelet KubeletOOMScoreAdj int = -999 // DockerOOMScoreAdj is the OOM score adjustment for Docker DockerOOMScoreAdj int = -999 // KubeProxyOOMScoreAdj is the OOM score adjustment for kube-proxy KubeProxyOOMScoreAdj int = -999 guaranteedOOMScoreAdj int = -998 besteffortOOMScoreAdj int = 1000
关键Pod是一种特殊的存在，它可以是Burstable或者BestEffort类型的Pod，但是OOM打分却可以跟Guaranteed一样，这种类型的Pod主要包含三种：静态Pod、镜像Pod和高优先级Pod
if types.IsCriticalPod(pod) {
return guaranteedOOMScoreAdj
}判定实现
func IsCriticalPod(pod *v1.Pod) bool {
if IsStaticPod(pod) {
return true
}
if IsMirrorPod(pod) {
return true
}
if pod.Spec.Priority != nil && IsCriticalPodBasedOnPriority(*pod.Spec.Priority) {
return true
}
return false
}这两种类型都有各自默认的值分别为Guaranteed(-998)和BestEffort(1000)
switch v1qos.GetPodQOS(pod) {
case v1.PodQOSGuaranteed:
// Guaranteed containers should be the last to get killed.
return guaranteedOOMScoreAdj
case v1.PodQOSBestEffort:
return besteffortOOMScoreAdj
}其中关键的一行就是：oomScoreAdjust := 1000 - (1000memoryRequest)/memoryCapacity，从这个计算里面可以看出，如果我们申请的资源越多，那么 (1000memoryRequest)/memoryCapacity这个里面计算出来的时机值就会越小，即最终结果就越大，其实也就表明如果我们占用的内存越少，则打分就越高，这类容器就相对比较容易被kill
memoryRequest := container.Resources.Requests.Memory().Value()
oomScoreAdjust := 1000 - (1000*memoryRequest)/memoryCapacity
// A guaranteed pod using 100% of memory can have an OOM score of 10.
Ensure that burstable pods have a higher OOM score adjustment.
if int(oomScoreAdjust) < (1000 + guaranteedOOMScoreAdj) {
return (1000 + guaranteedOOMScoreAdj)
}
// Give burstable pods a higher chance of survival over besteffort pods.
if int(oomScoreAdjust) == besteffortOOMScoreAdj {
return int(oomScoreAdjust - 1)
}
return int(oomScoreAdjust)到此，相信大家对“kubernetes资源QOS机制实现原理是什么”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
