關(guān)于K8S的服務(wù)質(zhì)量QoS你知道多少？

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

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

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

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

二、QoS級別

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

對于 QoS 類為 Guaranteed 的 Pod：

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

Pod 中的每個容器，包含初始化容器，必須指定 CPU 請求和 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"

驗證：

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

注意點：

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

2.2、Burstable

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

Pod 不符合 Guaranteed QoS 類的標準；

Pod 中至少一個容器具有內(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"

驗證：

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

2.3、BestEffort

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

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

三、QoS優(yōu)先級

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

BestEffort pods -> Burstable pods -> Guaranteed pods

四、驅(qū)逐原理

可壓縮資源：CPU

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

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

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

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

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

對于 “BestEffort” Pod中的容器，其為“ 1000”；

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

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

五、最佳實踐

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

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

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

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

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

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

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

審核編輯：劉清