Pod容器資源限制和探針

一、資源限制

1.Pod和容器的資源請求和限制

2.CPU 資源單位

案例一

案例二?

二、健康檢查，又稱為探針（Probe）

1.探針的三種規則

2.Probe支持三種檢查方法

3.探測獲得的三種結果

案例一：exec

案例二：httpget

案例三：tcpSocket

案例四：就緒檢測readinessProbe1

案例五：就緒檢測readinessProbe2

案例六：啟動、退出

一、資源限制

當定義Pod 時可以選擇性地為每個容器設定所需要的資源數量。最常見的可設定資源是CPU和內存大小，以及其他類型的資源。

當為 Pod 中的容器指定了request資源時，調度器就使用該信息來決定將Pod調度到哪個節點上。當還為容器指定了limit資源時，kubelet就會確保運行的容器不會使用超出所設的limit資源量。kubelet還會為容器預留所設的 request 資源量，供該容器使用。
如果 Pod運行所在的節點具有足夠的可用資源，容器且可以使用超出所設置的 request資源量。不過，容器不可以使用超出所設置的limit資源量。
如果給容器設置了內存的 limit值，但未設置內存的 request值，Kubernetes 會自動為其設置與內存 limit相匹配的 request值。類似的，如果給容器設置了CPU的 limit值但未設置cPU的 request值，則Kubernetes自動為其設置CPU 的request 值并使之與CPU 的limit 值匹配。

官網示例:
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

1.Pod和容器的資源請求和限制

spec .containers[].resources.requests.cpu		//定義創建容器時預分配的CPU資源
spec.containers[].resources.requests.memory		//定義創建容器時預分配的內存資源
spec.containers[].resources.imits.cpu			//定義cpu 的資源上限
spec.containers[].resources.1imits.memory		//定義內存的資源上限

2.CPU 資源單位

CPU資源的request和limit以cpu為單位。Kubernetes 中的一個cpu相當于1個VCPU (1個超線程)
Kubernetes也支持帶小數CPU 的請求。spec.containers[].resources.requests.cpu為0.5 的容器能夠獲得一個cpu的一半CPU資源(類似于Cgroup對CPU資源的時間分片)。表達式0.1 等價于表達式100m (毫核)，表示每1000 毫秒內容器可以使用的CPU時間總量為0.1*1000 亳秒。

案例一

OOMKilled：資源不足被殺死

apiVersion: v1
kind: Pod
metadata:name: ky-web-db
spec:containers:- name: webimage: nginxenv:- name: WEB_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: "abc123"resources:requests:memory: "64Mi"cpu: "0.25"limits:memory: "128Mi"cpu: "500m"

案例二?

給足資源

二、健康檢查，又稱為探針（Probe）

探針是由kubelet對容器執行的定期診斷。

1.探針的三種規則

●livenessProbe ：判斷容器是否正在運行。如果探測失敗，則kubelet會殺死容器，并且容器將根據 restartPolicy 來設置 Pod 狀態。如果容器不提供存活探針，則默認狀態為Success。
●readinessProbe ：判斷容器是否準備好接受請求。如果探測失敗，端點控制器將從與 Pod 匹配的所有 service endpoints 中剔除刪除該Pod的IP地址。初始延遲之前的就緒狀態默認為Failure。如果容器不提供就緒探針，則默認狀態為Success。
●startupProbe（這個1.17版本增加的）：判斷容器內的應用程序是否已啟動，主要針對于不能確定具體啟動時間的應用。如果配置了 startupProbe 探測，在則在 startupProbe 狀態為 Success 之前，其他所有探針都處于無效狀態，直到它成功后其他探針才起作用。如果 startupProbe 失敗，kubelet 將殺死容器，容器將根據 restartPolicy 來重啟。如果容器沒有配置 startupProbe，則默認狀態為 Success。
#注：以上規則可以同時定義。在readinessProbe檢測成功之前，Pod的running狀態是不會變成ready狀態的。

2.Probe支持三種檢查方法

●exec ：在容器內執行指定命令。如果命令退出時返回碼為0則認為診斷成功。
●tcpSocket ：對指定端口上的容器的IP地址進行TCP檢查（三次握手）。如果端口打開，則診斷被認為是成功的。
●==httpGet ==：對指定的端口和路徑上的容器的IP地址執行HTTPGet請求。如果響應的狀態碼大于等于200且小于400，則診斷被認為是成功的

3.探測獲得的三種結果

每次探測都將獲得以下三種結果之一
●成功：容器通過了診斷。
●失敗：容器未通過診斷。
●未知：診斷失敗，因此不會采取任何行動

官網示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

案例一：exec

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: busyboximagePullPolicy: IfNotPresentargs:  - /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60livenessProbe:exec:command:- cat- /tmp/healthyfailureThreshold: 1 initialDelaySeconds: 5periodSeconds: 5

??- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60

創建一個名為?/tmp/healthy?的文件，暫停執行腳本，等待 30 秒鐘，刪除后，再次暫停執行腳本，等待額外的 60 秒鐘

案例二：httpget

apiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1           #soscscs：nginx1.12imagePullPolicy: IfNotPresent      #拉取策略ports:- name: httpcontainerPort: 80livenessProbe:              #探針httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1     #延遲1秒開始探測periodSeconds: 3          #每3秒探測一次timeoutSeconds: 10         #超時時間10秒

刪除index.html頁面，報錯404，探針失敗

案例三：tcpSocket

apiVersion: v1
kind: Pod
metadata:name: xzq-tcp-live
spec:containers:- name: nginximage: soscscs/myapp:v1livenessProbe:initialDelaySeconds: 5  #第一次探測延遲5秒，第6秒開始timeoutSeconds: 1tcpSocket:port: 8080periodSeconds: 10     #每10秒探測一次failureThreshold: 2   #允許2次失敗

案例四：就緒檢測readinessProbe1

apiVersion: v1
kind: Pod
metadata:name: readiness-httpgetnamespace: default
spec:containers:- name: readiness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10

案例五：就緒檢測readinessProbe2

apiVersion: v1
kind: Pod
metadata:name: myapp1labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:name: myapp2labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10 
---
apiVersion: v1
kind: Pod
metadata:name: myapp3labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10 
---
apiVersion: v1
kind: Service
metadata:name: myapp
spec:selector:app: myapptype: ClusterIPports:- name: httpport: 80targetPort: 80

刪除頁面，看效果

//readiness探測失敗，Pod 無法進入READY狀態，且端點控制器將從 endpoints 中剔除刪除該 Pod 的 IP 地址?

案例六：啟動、退出

apiVersion: v1
kind: Pod
metadata:name: lifecycle-demo
spec:containers:- name: lifecycle-demo-containerimage: soscscs/myapp:v1lifecycle:   #此為關鍵字段postStart:exec:command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]      preStop:exec:command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falseinitContainers:- name: init-myserviceimage: soscscs/myapp:v1command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falsevolumes:- name: message-loghostPath:path: /data/volumes/nginx/log/type: DirectoryOrCreate