本篇內(nèi)容主要講解“kubernetes資源QOS機(jī)制實(shí)現(xiàn)原理是什么”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“kubernetes資源QOS機(jī)制實(shí)現(xiàn)原理是什么”吧!
創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括興業(yè)網(wǎng)站建設(shè)、興業(yè)網(wǎng)站制作、興業(yè)網(wǎng)頁(yè)制作以及興業(yè)網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，興業(yè)網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到興業(yè)省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
QOS是k8s中一種資源保護(hù)機(jī)制，其主要是針對(duì)不可壓縮資源比如的內(nèi)存的一種控制技術(shù)，比如在內(nèi)存中其通過(guò)為不同的Pod和容器構(gòu)造OOM評(píng)分，并且通過(guò)內(nèi)核的策略的輔助，從而實(shí)現(xiàn)當(dāng)節(jié)點(diǎn)內(nèi)存資源不足的時(shí)候，內(nèi)核可以按照策略的優(yōu)先級(jí)，優(yōu)先kill掉哪些優(yōu)先級(jí)比較低(分值越高優(yōu)先級(jí)越低)的Pod，今天來(lái)分析下背后的實(shí)現(xiàn)
在Linux中一切皆文件，控制CGroup本身也是通過(guò)配置文件進(jìn)行的,這是我創(chuàng)建的一個(gè)內(nèi)存Lmits為200M的Pod的容器的配置
# pwd /sys/fs/cgroup # cat ./memory/kubepods/pod8e172a5c-57f5-493d-a93d-b0b64bca26df/f2fe67dc90cbfd57d873cd8a81a972213822f3f146ec4458adbe54d868cf410c/memory.limit_in_bytes 209715200
這里我們重點(diǎn)關(guān)注內(nèi)存相關(guān)的兩個(gè)配置：VMOvercommitMemory其值為1，表示運(yùn)行分配所有的物理內(nèi)存資源，注意不包括SWAP資源VMPanicOnOOM其值為0：表示當(dāng)內(nèi)存不足的時(shí)候觸發(fā)oom_killer進(jìn)行選擇部分進(jìn)程進(jìn)行kill，QOS也是通過(guò)影響其kill流程來(lái)實(shí)現(xiàn)的
重慶分公司
重慶分公司
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打分機(jī)制主要是根據(jù)Requests和limits里面的資源限制來(lái)進(jìn)行類型判定與打分的，我們就來(lái)快速看下這部分的實(shí)現(xiàn)
遍歷所有的容器列表，注意這里會(huì)包含所有的初始化容器和業(yè)務(wù)容器
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主要是根據(jù)limits里面的資源是否包含CPU和內(nèi)存兩種資源，都包含才可能是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和內(nèi)存限制
isGuaranteed = false
}
}如果Pod里面的容器沒有任何requests和limits的限制則就是BestEffort
if len(requests) == 0 && len(limits) == 0 {
return v1.PodQOSBestEffort
}要是Guaranteed必須是資源相等，并且限定的數(shù)量相同
// 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
其中g(shù)uaranteedOOMScoreAdj是-998其實(shí)這跟OOM實(shí)現(xiàn)有關(guān)系，一臺(tái)node節(jié)點(diǎn)上主要是三部分組成：kubelet主進(jìn)程、docker進(jìn)程、業(yè)務(wù)容器進(jìn)程，而OOM的打分里面-1000表示該進(jìn)程不會(huì)被oom所kill, 那一個(gè)業(yè)務(wù)進(jìn)程最少也就只能是-999因?yàn)槟悴荒鼙ＷC自己的業(yè)務(wù)永遠(yuǎn)不會(huì)出現(xiàn)問(wèn)題，所以在QOS里面-999其實(shí)就是kubelet和docker進(jìn)程所保留的，剩下的才能作為業(yè)務(wù)容器分配(分值越高越容易被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
關(guān)鍵Pod是一種特殊的存在，它可以是Burstable或者BestEffort類型的Pod，但是OOM打分卻可以跟Guaranteed一樣，這種類型的Pod主要包含三種：靜態(tài)Pod、鏡像Pod和高優(yōu)先級(jí)Pod
if types.IsCriticalPod(pod) {
return guaranteedOOMScoreAdj
}判定實(shí)現(xiàn)
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
}這兩種類型都有各自默認(rèn)的值分別為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
}其中關(guān)鍵的一行就是：oomScoreAdjust := 1000 - (1000memoryRequest)/memoryCapacity，從這個(gè)計(jì)算里面可以看出，如果我們申請(qǐng)的資源越多，那么 (1000memoryRequest)/memoryCapacity這個(gè)里面計(jì)算出來(lái)的時(shí)機(jī)值就會(huì)越小，即最終結(jié)果就越大，其實(shí)也就表明如果我們占用的內(nèi)存越少，則打分就越高，這類容器就相對(duì)比較容易被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)到此，相信大家對(duì)“kubernetes資源QOS機(jī)制實(shí)現(xiàn)原理是什么”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
