一、K8S中的應(yīng)用服務(wù)質(zhì)量（QoS）

服務(wù)質(zhì)量（QoS）類是Kubernetes的概念，它確定Pod的調(diào)度和驅(qū)逐優(yōu)先級(jí)

Kubelet使用它來管理驅(qū)逐pod的順序，以及使用高級(jí)CPU管理策略允許更復(fù)雜的pod調(diào)度決策。

QoS由Kubernetes本身分配給Pod。但是，DevOps可以通過處理Pod內(nèi)各個(gè)容器的資源請(qǐng)求和限制來控制分配給容器的QoS類。

二、QoS級(jí)別

Guaranteed：POD中所有容器（包含初始化容器）都必須統(tǒng)一設(shè)置了limits，并且設(shè)置參數(shù)都一致；

Burstable：POD中有容器設(shè)置了 內(nèi)存 或 CPU request；

BestEffort：POD中的所有容器都沒有指定CPU和內(nèi)存的requests和limits；

2.1、Guaranteed

對(duì)于 QoS 類為 Guaranteed 的 Pod：

Pod 中的每個(gè)容器，包含初始化容器，必須指定內(nèi)存 請(qǐng)求和 內(nèi)存 限制，并且兩者要相等。

Pod 中的每個(gè)容器，包含初始化容器，必須指定 CPU 請(qǐng)求和 CPU 限制，并且兩者要相等。

apiVersion: v1
kind: Pod
metadata:
name: qos-demo
spec:
containers:
- name: qos-demo
 image: nginx
 resources:
  limits:
   memory: "500Mi"
   cpu: "700m"
  requests:
   memory: "500Mi"
   cpu: "700m"

驗(yàn)證：

# kubectl describe po qos-demo
···
QoS Class:          Guaranteed

注意點(diǎn)：

如果容器指定了自己的內(nèi)存limits，但沒有指定內(nèi)存requests，Kubernetes 會(huì)自動(dòng)為它指定與內(nèi)存limits匹配的內(nèi)存requests。同樣，如果容器指定了自己的 CPU limits，但沒有指定 CPU requests，Kubernetes 會(huì)自動(dòng)為它指定與 CPU limits匹配的 CPU requests；

2.2、Burstable

如果滿足下面條件，將會(huì)指定 Pod 的 QoS 類為 Burstable：

Pod 不符合 Guaranteed QoS 類的標(biāo)準(zhǔn)；

Pod 中至少一個(gè)容器具有內(nèi)存 或 CPU requests；

apiVersion: v1
kind: Pod
metadata:
name: qos-demo2
spec:
containers:
- name: qos-demo2
 image: nginx
 resources:
  limits:
   memory: "500Mi"
  requests:
   memory: "200Mi"

驗(yàn)證：

# kubectl describe po qos-demo2
···
QoS Class:          Burstable

2.3、BestEffort

對(duì)于 QoS 類為 BestEffort 的 Pod，Pod 中的容器必須沒有設(shè)置內(nèi)存和 CPU 限制或請(qǐng)求。

apiVersion: v1
kind: Pod
metadata:
name: qos-demo3
spec:
containers:
- name: qos-demo3
 image: nginx

三、QoS優(yōu)先級(jí)

3種QoS優(yōu)先級(jí)從有低到高（從左向右）：

BestEffort pods -> Burstable pods -> Guaranteed pods

四、驅(qū)逐原理

可壓縮資源：CPU

在壓縮資源部分已經(jīng)提到CPU屬于可壓縮資源，當(dāng)pod使用超過設(shè)置的limits值，pod中進(jìn)程使用cpu會(huì)被限制，但不會(huì)被kill。

不可壓縮資源：內(nèi)存

4.1、節(jié)點(diǎn)OOM時(shí)如何處理Guaranteed, Burstable 和 BestEffort Pods？

如果節(jié)點(diǎn)在Kubelet可以回收之前耗盡了內(nèi)存，即節(jié)點(diǎn)發(fā)生了oom，則oom_killer會(huì)根據(jù)其oom_score終止容器。

對(duì)于 “Guaranteed” Pod中的容器，oom_score_adj 為 “ -998”；

對(duì)于 “BestEffort” Pod中的容器，其為“ 1000”；

Burstable Pod中的容器，值為“ min（max（2，1000-（1000 * memoryRequestBytes）/ machineMemoryCapacityBytes），999” ）”。

oom_killer首先終止QoS等級(jí)最低，且超過請(qǐng)求資源最多的容器。這意味著會(huì)優(yōu)先從Burstable中選擇占用資源請(qǐng)求過多的容器進(jìn)行驅(qū)逐；

五、最佳實(shí)踐

1、按照應(yīng)用類型進(jìn)行分類：核心應(yīng)用（core）/ 常規(guī)應(yīng)用（nomarl）/ 附加應(yīng)用（extral）

2、核心應(yīng)用：Guaranteed / 常規(guī)應(yīng)用：Burstable / 附加應(yīng)用：BestEffort

3、集群節(jié)點(diǎn)分為：核心應(yīng)用節(jié)點(diǎn) / 常規(guī)應(yīng)用節(jié)點(diǎn) / 附加應(yīng)用節(jié)點(diǎn)

4、調(diào)度策略：

核心應(yīng)用：可以采用nodeAffinity的prefer調(diào)度策略調(diào)度到核心節(jié)點(diǎn)；

常規(guī)應(yīng)用：可以采用nodeAffinity的硬親和調(diào)度策略調(diào)度到常規(guī)節(jié)點(diǎn)；

附加應(yīng)用：可以采用nodeAffinity的硬親和調(diào)度策略調(diào)度到附加節(jié)點(diǎn)；

審核編輯：劉清