[云原生] K8s之pod進階

一、pod的狀態說明

（1）Pod 一直處于Pending狀態

Pending狀態意味著Pod的YAML文件已經提交給Kubernetes，API對象已經被創建并保存在Etcd當中。但是，這個Pod里有些容器因為某種原因而不能被順利創建。比如，調度不成功(可以通過kubectl describe pod命令查看到當前Pod的事件，進而判斷為什么沒有調度)。

可能原因:資源不足（集群內所有的Node都不滿足該Pod請求的CPU、內存、GPU等資源); ? ? ?HostPort ?已被占用(通常推薦使用Service對外開放服務端口)。

（2）Pod一直處于Waiting 或 ContainerCreating狀態

首先還是通過 kubectl describe pod命令查看當前Pod的事件。可能的原因有:
1）鏡像拉取失敗，比如鏡像地址配置錯誤、拉取不了國外鏡像源（gcr.io)、私有鏡像密鑰配置錯誤、鏡像太大導致拉取超時 (可以適當調整kubelet的-image-pull-progress-deadline和-runtime-request-timeout選項)等。
2）CNI網絡錯誤，一般需要檢查CNI網絡插件的配置，比如:無法配置Pod 網絡、無法分配IP地址。
3）容器無法啟動，需要檢查是否打包了正確的鏡像或者是否配置了正確的容器參數
4）Failed create pod sandbox，查看kubelet日志，原因可能是磁盤壞道（input/output error)。

（3）Pod 一直處于ImagePullBackOff狀態

通常是鏡像名稱配置錯誤或者私有鏡像的密鑰配置錯誤導致。

（4）Pod 一直處于CrashLoopBackOff狀態

?
此狀態說明容器曾經啟動了，但又異常退出。這時可以先查看一下容器的日志。
通過命令kubectl logs 和kubectl logs --previous 可以發下一些容器退出的原因，比如:容器進程退出、健康檢查失敗退出;此時如果還未發現線索，還而已到容器內執行命令(kubectl exec cassandra - cat /var.log/cassandra/system.loq)來進一步查看退出原因;如果還是沒有線索，那就需要SSH登錄該Pod所在的Node上，查看Kubelet或者Docker的日志進一步排查。

（5）? Pod處于Error狀態

通常處于Error狀態說明Pod啟動過程中發生了錯誤。

常見的原因:依賴的ConfigMap、Secret或PV等不存在;請求的資源超過了管理員設置的限制，比如超過了LimitRange等;違反集群的安全策略，比如違反了PodSecurityPolicy.等;容器無法操作集群內的資源，比如開啟RDAC后，需要為ServiceAccount配置角色綁定。

（6）? Pod 處于Terminating或 Unknown狀態

?從v1.5開始，Kubernetes不會因為Node失聯而刪除其上正在運行的Pod，而是將其標記為Terminating 或 Unknown 狀態。想要刪除這些狀態的Pod有三種方法：

1）從集群中刪除Node。使用公有云時，kube-controller-manager會在VM刪除后自動刪除對應的Node。而在物理機部署的集群中，需要管理員手動刪除Node（kubectl delete node）。

2）Node恢復正常。kubelet會重新跟kube-apiserver通信確認這些Pod的期待狀態，進而再決定刪除或者繼續運行這些Pod。用戶強制刪除，用戶可以執行（kubectl delete pods pod-name --grace-period=0 --force）強制刪除Pod。除非明確知道Pod的確處于停止狀態（比如Node所在VM或物理機已經關機），否則不建議使用該方法。特別是StatefulSet 管理的Pod，強制刪除容易導致腦裂或數據丟失等問題。

3）Pod行為異常，這里所說的行為異常是指Pod沒有按預期的行為執行，比如沒有運行podSpec 里面設置的命令行參數。這一般是podSpec yaml文件內容有誤，可以嘗試使用 --validate 參數重建容器，比如（kubectl delete pod mypod 和 kubectl create --validate -f mypod.yaml）；也可以查看創建后的podSpec是否是對的，比如（kubectl get pod mypod -o yaml）；修改靜態Pod的Manifest后未自動重建，kubelet 使用inotify 機制檢測 /etc/kubernetes/manifests 目錄（可通過 kubelet 的 -pod-manifest-path 選項指定）中靜態Pod的變化，并在文件發生變化后重新創建相應的 Pod。但有時也會發現修改靜態Pod的 Manifest后未自動創建新 Pod的情景，此時已過簡單的修復方法是重啟 Kubelet。

Unknown 這個異常狀態意味著Pod的狀態不能持續地被 kubelet匯報給 kube-apiserver，這很有可能是主從節點（Master 和 Kubelet）間的通信出現了問題。

（7）pod從創建到成功或失敗的事件

PodScheduled
pod正處于調度中，剛開始調度的時候，hostip還沒綁定上，持續調度之后，有合適的節點就會綁定hostip，然后更新etcd數據

Initialized
pod中的所有初始化容器已經初啟動完畢

Ready
pod中的容器可以提供服務了

Unschedulable
不能調度，沒有合適的節點

?
CrashLoopBackOff： ? ?容器退出，kubelet正在將它重啟
InvalidImageName： ? ?無法解析鏡像名稱
ImageInspectError： ? 無法校驗鏡像
ErrImageNeverPull： ? 策略禁止拉取鏡像
ImagePullBackOff： ? ?正在重試拉取
RegistryUnavailable：連接不到鏡像中心
ErrImagePull： ? ? ? ?通用的拉取鏡像出錯
CreateContainerConfigError：不能創建kubelet使用的容器配置
CreateContainerError：創建容器失敗
m.internalLifecycle.PreStartContainer 執行hook報錯
RunContainerError： ? 啟動容器失敗
PostStartHookError： ? 執行hook報錯
ContainersNotInitialized：容器沒有初始化完畢
ContainersNotReady： ? 容器沒有準備完畢
ContainerCreating： ? ?容器創建中
PodInitializing：pod ? 初始化中
DockerDaemonNotReady： ?docker還沒有完全啟動
NetworkPluginNotReady：網絡插件還沒有完全啟動
Evicte: ? ? pod被驅趕

二、Pod 容器資源限制?

2.1 資源限制的了解?

? 在我前面Docker的Cgroup文章中，就提到過，為什么我們對容器進行資源限制。同理：首先K8s中pod使用宿主機的資源默認情況下是無節制的，但是當一個集群搭建成功后并投入生產環境中。如果其中的某一個pod因為不明原因出現了bug，瘋狂占用宿主機資源，搶占其他pod的資源。勢必會導致整個集群的癱瘓，所以pod資源的限制是非常有必要的

?在資源控制器中我們也可以準確的找到相應的資源控制字段：

kubectl explain deployment.spec.template.spec.containers.resources
kubectl explain  statefulset.spec.template.spec.containers.resources

在官方文檔中（資源配額 | Kubernetes）我們可以得知：pod控制的資源總共為三大類：

cpu，memory，hugepages（巨頁）。其中我們運用最多的限制還是cpu和memory。

?（1）cpu限制的參數了解

?pod對于cpu限制的參數有兩種表達形式：

第一種是指定個數的表達形式，例如：1 ，2， 0.5 ，0.2 ，0.3 指定cpu的個數（該個數可以為整數，也可以為小數點后一位的小數）

第二種是以毫核為單位的表達形式：100m ?500m ? 1000m ? 2000m （這里1000m等價于一個cpu，該方式來自于cpu時間分片原理得來）?

（2）memory的表達形式?

pod對內存參數的要求十分嚴謹。對硬件有過研究的朋友，應該會了解到,我們常常提到的GB，MB,TB其實是于實際字節總數是有誤差的（原因是GB是以10為底數計量，而真正的換算是以2為底數計量。導致了總量的誤差。）而真正沒有此誤差的單位是Ki ?Mi ?Gi ?Ti?

所以k8s中pod資源限制為了對pod的內存限制更為精準，采用的單位是?Ki ?Mi ?Gi ?Ti?

2.2 實例運用?

需求：創建一個deployment資源，鏡像使用nginx:latest，創建3個pod副本，鏡像拉取策略使用IfNotPresent，重啟策略使用Always，容器資源預留cpu 0.25個，內存128MiB，上限最多1個cpu，1g內存

kubectl create deployement nginx-test --images=nginx:latest  --dry-run=client -o yaml >test.yaml
vim test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: nulllabels:app: nginx-testname: nginx-test
spec:replicas: 3selector:matchLabels:app: nginx-testtemplate:metadata:labels:app: nginx-testspec:containers:- image: nginx:latestname: nginxresources:requests:memory: "128Mi"cpu: "250m"limits:memory: "1Gi"cpu: "1"imagePullPolicy: IfNotPresentrestartPolicy: Alwayskubectl apply -f test.yaml

#查看pod的資源使用情況
kubectl describe pod nginx-test

#查看node節點pod資源使用詳情
kubectl describe node node02

三、Pod 容器的探針?

3.1?探針的概念及其作用?

?探針是由 kubelet 對容器執行的定期診斷（pod中探針又分為三類）:

?存活探針（livenessProbe）探測容器是否運行正常。如果探測失敗則kubelet殺掉容器（不是Pod），容器會根據重啟策略決定是否重啟

就緒探針（readinessProbe）探測Pod是否能夠進入READY狀態，并做好接收請求的準備。如果探測失敗Pod則會進入NOTREADY狀態（READY為0/1）并且從所關聯的service資源的端點（endpoints）中踢出，service將不會再把訪問請求轉發給這個Pod

啟動探針（startupProbe）探測容器內的應用是否啟動成功，在啟動探針探測成功之前，其它類型的探針都會暫時處于禁用狀態?

?注意：啟動探針只是在容器啟動后按照配置滿足一次后就不再進行后續的探測了。存活探針和就緒探針會一直探測到Pod生命周期結束為止

kubectl explain pod.spec.containers

3.2?探針的探測方式??

exec : 通過command字段設置在容器內執行的Linux命令來進行探測，如果命令返回碼為0，則認為探測成功，返回碼非0則探測失敗

httpGet : 通過向容器的指定端口和uri路徑發起HTTP GET請求，如果HTTP返回狀態碼為 >=200且<400的（2XX,3XX），則認為探測成功，返回狀態碼為4XX,5XX則探測失敗

tcpSocket1 : 通過向容器的指定端口發送tcp三次握手連接，如果端口正確卻tcp連接成功，則認為探測成功，tcp連接失敗則探測失敗?

探針探測結果有以下值：
Success：表示通過檢測。
Failure：表示未通過檢測。
Unknown：表示檢測沒有正常進行。?

3.3?探針字段?

探針(Probe)有許多可選字段，可以用來更加精確的控制Liveness和Readiness兩種探針的行為(Probe)：

initialDelaySeconds：容器啟動后要等待多少秒后就探針開始工作，單位“秒”，默認是 0s，最小值是 0s;
periodSeconds：執行探測的時間間隔（單位是秒），默認為 10s，最小值是 1s，
timeoutSeconds：探針執行檢測請求后，等待響應的超時時間，默認為 1s，最小值是 1s，
successThreshold：探針檢測失敗后認為成功的最小連接成功次數，默認為 1，在 Liveness和startup探針中必須為 1，最小值為 1。
failureThreshold：探測失敗的重試次數，重試一定次數后將認為失敗，默認為 3，最小值為 1

3.4 探針實驗測試?

?（1）LivenessProbe 探針使用

1)?通過exec方式做健康探測?

apiVersion: v1
kind: Pod
metadata:name: demo-livelabels:app: demo-live
spec:containers:- name: demo-liveimage: centos:7args:                       #創建測試探針探測的文件- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:initialDelaySeconds: 10   #延遲檢測時間periodSeconds: 5          #檢測時間間隔exec:                     #使用命令檢查command:                #指令，類似于運行命令sh- cat                   #sh 后的第一個內容，直到需要輸入空格，變成下一行- /tmp/healthy          #由于不能輸入空格，需要另外聲明，結果為sh cat"空格"/tmp/healthy容器在初始化后，執行（/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"）首先創建一個 /tmp/healthy 文件，然后執行睡眠命令，睡眠 30 秒，到時間后執行刪除 /tmp/healthy 文件命令。而設置的存活探針檢檢測方式為執行 shell 命令，用 cat 命令輸出 healthy 文件的內容，如果能成功執行這條命令一次(默認successThreshold:1)，存活探針就認為探測成功，由于沒有配置(failureThreshold、timeoutSeconds)，所以執行（cat /tmp/healthy）并只等待1s，如果1s內執行后返回失敗，探測失敗。在前 30 秒內，由于文件存在，所以存活探針探測時執行 cat /tmp/healthy 命令成功執行。30 秒后 healthy 文件被刪除，所以執行命令失敗，Kubernetes 會根據 Pod 設置的重啟策略來判斷，是否重啟 Pod。

2)通過HTTP方式做健康探測??

vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10kubectl create -f httpget.yamlkubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods在這個配置文件中，可以看到 Pod 也只有一個容器。initialDelaySeconds 字段告訴 kubelet 在執行第一次探測前應該等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒執行一次存活探測。kubelet 會向容器內運行的服務（服務會監聽 8080 端口）發送一個 HTTP GET 請求來執行探測。如果服務器上 /healthz 路徑下的處理程序返回成功代碼，則 kubelet 認為容器是健康存活的。如果處理程序返回失敗代碼，則 kubelet 會殺死這個容器并且重新啟動它。任何大于或等于 200 并且小于 400 的返回代碼標示成功，其它返回代碼都標示失敗。

3）通過TCP方式做健康探測?

vim tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:name: probe-tcp
spec:containers:- name: nginximage: soscscs/myapp:v1livenessProbe:initialDelaySeconds: 5timeoutSeconds: 1tcpSocket:port: 8080periodSeconds: 10failureThreshold: 2kubectl create -f tcpsocket.yamlkubectl exec -it probe-tcp  -- netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1/nginx: master prokubectl get pods -w
NAME        READY   STATUS    RESTARTS   AGE
probe-tcp   1/1     Running             0          1s
probe-tcp   1/1     Running             1          25s       #第一次是 init(5秒) + period(10秒) * 2
probe-tcp   1/1     Running             2          45s       #第二次是 period(10秒) + period(10秒)  重試了兩次
probe-tcp   1/1     Running這個例子同時使用 readinessProbe 和 livenessProbe 探測。kubelet 會在容器啟動 5 秒后發送第一個 readinessProbe 探測。這會嘗試連接 goproxy 容器的 8080 端口。如果探測成功，kubelet 將繼續每隔 10 秒運行一次檢測。除了 readinessProbe 探測，這個配置包括了一個 livenessProbe 探測。kubelet 會在容器啟動 15 秒后進行第一次 livenessProbe 探測。就像 readinessProbe 探測一樣，會嘗試連接 goproxy 容器的 8080 端口。如果 livenessProbe 探測失敗，這個容器會被重新啟動。

（2）就緒檢測(ReadinessProbe) 探針使用?

vim readiness-httpget.yaml
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: 10kubectl create -f readiness-httpget.yaml//readiness探測失敗，無法進入READY狀態
kubectl get pods kubectl exec -it readiness-httpget sh# cd /usr/share/nginx/html/# ls
50x.html    index.html# echo 123 > index1.html # exitkubectl get pods kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods -w

vim readiness-myapp.yaml
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: 80kubectl create -f readiness-myapp.yamlkubectl get pods,svc,endpoints -o wide
NAME         READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod/myapp1   1/1     Running   0          3m42s   10.244.2.13   node02   <none>           <none>
pod/myapp2   1/1     Running   0          3m42s   10.244.1.15   node01   <none>           <none>
pod/myapp3   1/1     Running   0          3m42s   10.244.2.14   node02   <none>           <none>NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
......
service/myapp        ClusterIP   10.96.138.13   <none>        80/TCP    3m42s   app=myappNAME                   ENDPOINTS                                      AGE
......
endpoints/myapp        10.244.1.15:80,10.244.2.13:80,10.244.2.14:80   3m42skubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html//readiness探測失敗，Pod 無法進入READY狀態，且端點控制器將從 endpoints 中剔除刪除該 Pod 的 IP 地址
kubectl get pods,svc,endpoints -o wide
NAME         READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
pod/myapp1   0/1     Running   0          5m17s   10.244.2.13   node02   <none>           <none>
pod/myapp2   1/1     Running   0          5m17s   10.244.1.15   node01   <none>           <none>
pod/myapp3   1/1     Running   0          5m17s   10.244.2.14   node02   <none>           <none>NAME                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
......
service/myapp        ClusterIP   10.96.138.13   <none>        80/TCP    5m17s   app=myappNAME                   ENDPOINTS                       AGE
......
endpoints/myapp        10.244.1.15:80,10.244.2.14:80   5m17s

（3）啟動探針的使用??

啟動探針存在的必要：

有時候，會有一些現有的應用在啟動時需要較長的初始化時間。要這種情況下，若要不影響對死鎖作出快速響應的探測，設置存活探測參數是要技巧的。技巧就是使用相同的命令來設置啟動探測，針對 HTTP 或 TCP 檢測，可以通過將?failureThreshold * periodSeconds?參數設置為足夠長的時間來應對糟糕情況下的啟動時間。（因為啟動探針在啟動后，其他的兩種探針就會進入短暫的禁用裝態，于是給容器啟動預留了充足的時間，保證容器中業務啟動的順利進行。而且啟動探針只會啟動一次，后續工作就完全交給其他兩個探針，直到容器的生命周期結束）。

ports:
- name: liveness-portcontainerPort: 8080hostPort: 8080livenessProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 1periodSeconds: 10startupProbe:httpGet:path: /healthzport: liveness-portfailureThreshold: 30periodSeconds: 10

在這里，幸虧有了啟動探測，應用程序將會有最多 5 分鐘（30 * 10 = 300s）的時間來完成其啟動過程。一旦啟動探測成功一次，存活探測任務就會接管對容器的探測，對容器死鎖作出快速響應。如果啟動探測一直沒有成功，容器會在 300 秒后被殺死，并且根據?restartPolicy?來執行進一步處置。?

四、Pod 容器的啟動和退出動作?

postStart ? ?配置 exec.command 字段設置 Linux 命令，實現當應用容器啟動時，會執行的額外操作

preStop ? ? ?配置 exec.command 字段設置 Linux 命令，實現當應用容器退出時，會執行的最后一個操作

實例運用

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 prestop 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

kubectl create -f post.yamlkubectl get pods -o wide
NAME             READY   STATUS    RESTARTS   AGE    IP            NODE     NOMINATED NODE   READINESS GATES
lifecycle-demo   1/1     Running   0          2m8s   10.244.2.28   node02   <none>           <none>kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
Hello initContainers
Hello from the postStart handler//在 node02 節點上查看
[root@node02 ~]# cd /data/volumes/nginx/log/
[root@node02 log]# ls
access.log  error.log  message
[root@node02 log]# cat message 
Hello initContainers
Hello from the postStart handler
#由上可知，init Container先執行，然后當一個主容器啟動后，Kubernetes 將立即發送 postStart 事件。//刪除 pod 后，再在 node02 節點上查看
kubectl delete pod lifecycle-demo[root@node02 log]# cat message 
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，當在容器被終結之前， Kubernetes 將發送一個 preStop 事件。