乾貨！K8S之Pod資源控制+健康檢查（探針）

一、爲什麼要進行容器資源限制

• 在容器中不一定需要創建虛擬硬件，是以進程的方式進行管理，共享宿主機內核資源
• 在容器使用時，並沒有對其硬件做出限制和瓶頸，出於安全考慮，需要對容器資源進行限制
• 參考官方文檔：參考K8S官方文檔，點此跳～～～

二、pod的資源控制

• 在Docker中，主要是利用linux內核提供的Cgroup機制來管理CPU、內存和blkio
• 在k8s中可以在yaml中對其進行限制：

Pod的每個容器可以指定以下一項或多項：

'//resources表示資源限制字段'
'//requests表示基本資源'
'//limits表示資源上限，即這個pod最大能用到多少資源'

spec.containers[].resources.limits.cpu	'//CPU上限'
spec.containers[].resources.limits.memory	'//內存上限'
spec.containers[].resources.requests.cpu	'//創建時分配的基本CPU資源'
spec.containers[].resources.requests.memory	'//創建時分配的基本內存資源'
注意：requests<=limits  
儘管只能在單個容器上指定請求和限制，但是談論Pod資源請求和限制很方便。特定資源類型的 Pod資源請求/限制是Pod中每個Container的該類型資源請求/限制的總和。

示例：

以下Pod具有兩個容器。每個容器都有0.25 cpu的請求和64MiB的內存。每個容器的限制爲0.5 cpu和128MiB的內存。即該pod限制cpu爲1個核心數，內存爲256MiB。

[root@k8s_master ~]# vim pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
 - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:                       ##資源控制
      requests:
        memory: "64Mi"         
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
 - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

• 執行創建，並查看資源限制情況

##創建2個容器
[root@k8s_master ~]# kubectl apply -f pod1.yaml 

##查看容器分配到哪個節點
[root@k8s_master ~]# kubectl get pods -o wide
NAME       READY   STATUS             RESTARTS   AGE    IP            NODE           NOMINATED NODE
frontend   1/2     CrashLoopBackOff   5          8m7s   172.17.50.3   192.168.5.20   <none>

##查看資源限制
[root@k8s_master ~]# kubectl describe nodes 192.168.5.20

三、pod重啓策略

• Always：當容器終止退出後，總是重啓容器，默認策略
• OnFailure：當容器異常退出（退出狀態碼非0）時，重啓容器
• Never：當容器終止退出，從不重啓容器。
• （注意：k8s中不支持重啓Pod資源，只有刪除重建）

查看pod資源的重啓策略：

使用kubectl edit 命令可以輸出其資源的yaml文件，查看重啓策略restartPolicy。

[root@k8s_master ~]# kubectl edit pod frontend
##57行
    57   restartPolicy: Always

四、pod健康檢查又稱爲探針（Probe）

當後端pod資源出現問題時，採用一系列策略對其進行操作

4.1、兩種策略：

• livenessProbe: 如果檢查失敗，將殺死容器，根據Pod的restartPolicy來操作。
• ReadinessProbe :如果檢查失敗，kubernetes會把Pod從service endpoints中剔除。
  （注意：）規則可以同時定義

4.2、Probe支持三種檢查方法：

• httpGet: 發送http請求，返回200-400範圍狀態碼爲成功。
• exec: 執行Shell命令返回狀態碼是0爲成功。
• tcpSocket: 發起TCP Socket建立成功

參考官方文檔：參考K8S官方文檔，點此跳～～～～～～～～～

示例1：exec方式

• 創建一個pod資源，在配置文件中，您可以看到Pod具有單個Container。
• 該periodSeconds字段指定kubelet應該每5秒執行一次活動性探測。該initialDelaySeconds字段告訴kubelet在執行第一個探測之前應等待5秒鐘。爲了執行探測，kubelet cat /tmp/healthy在目標容器中執行命令
• 如果命令成功執行，則返回0，並且kubelet認爲該容器處於活動狀態且健康。如果命令返回非零值，則kubelet將殺死容器並重新啓動它。

##創建pod資源，定義yaml文件
[root@k8s_master ~]# vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
 - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
 ##生成資源
 [root@k8s_master ~]# kubectl apply -f pod2.yaml     

• 容器啓動時，它將執行以下命令

/bin/bash -c touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy

• 查看liveness-exec資源狀態，顯然根據策略重啓了5次

[root@k8s_master ~]# kubectl get pods 
NAME            READY   STATUS             RESTARTS   AGE
liveness-exec   0/1     CrashLoopBackOff   5          8m16s

示例2：httpGet方式

• 在配置文件中，您可以看到Pod具有單個容器。
• 該periodSeconds字段指定kubelet應該每3秒執行一次活動性探測。該initialDelaySeconds字段告訴kubelet在執行第一個探測之前應等待3秒。
• 爲了執行探測，kubelet將HTTP GET請求發送到在容器中運行並正在偵聽端口8080的服務器。
• 如果服務器/healthz路徑的處理程序返回成功代碼，則kubelet會認爲該容器處於活動狀態並且運行狀況良好。
• 如果處理程序返回失敗代碼，則kubelet將殺死容器並重新啓動它。
• 任何大於或等於200且小於400的代碼均表示成功。其他任何代碼均指示失敗。
• 在容器/healthz處於活動狀態的前10秒鐘中，處理程序返回狀態200。此後，處理程序返回狀態500。
  
• 容器啓動後三秒鐘，kubelet將開始執行運行狀況檢查。因此，前幾次健康檢查將成功。
• 但是10秒鐘後，運行狀況檢查將失敗，並且kubelet將終止並重新啓動容器

示例3：tcpSocket方式

• 第三種類型的活動性探針使用TCP套接字。

• 使用此配置，kubelet將嘗試在指定端口上打開容器的套接字。

• 如果可以建立連接，則認爲該容器運行狀況良好，如果不能建立連接，則視爲故障。
  

• 如您所見，TCP檢查的配置與HTTP檢查非常相似。此示例同時使用了就緒和活躍度探針

• 容器啓動後5秒鐘內，kubelet將發送第一個就緒探測器。這將嘗試連接到goproxy端口8080上的容器。

• 如果探測成功，則Pod將標記爲就緒。kubelet將繼續每10秒運行一次此檢查。

• 除了就緒探針之外，此配置還包括活動探針。容器啓動後15秒鐘，kubelet將運行第一個活動探針

• 就像就緒探針一樣，這將嘗試goproxy在端口8080上連接到 容器。如果活動探針失敗，則將重新啓動容器。

4.3、探針使用總結

• 在現網中esec方式用的多但是佔資源
• tcpsocket和http在使用時會產生訪問流量，統計日誌流量會有誤差