• 一、重啟策略：Pod在遇到故障之后重啟的動作
• • 1、always
  • 2、never
  • 3、onfailure
  • • 3.1 非0狀態
    • 3.2 為0狀態
• 二、探針
• 附：pod各種狀態解釋：
• • 1、Pod一直處于Pending狀態
  • 2、Pod一直處于Waiting 或 ContainerCreating狀態
  • 3、Pod 一直處于CrashLoopBackOff狀態
  • 4、Pod處于Error狀態
  • 5、Pod 處于Terminating或 Unknown狀態

一、重啟策略：Pod在遇到故障之后重啟的動作

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

1、always

[root@master test]# vim always.yaml apiVersion: v1 kind: Pod metadata:name: foo spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3

[root@master test]# kubectl apply -f always.yaml

創建中

運行中

出錯了

立即重啟

證明重啟策略默認是always，總是自動拉取

2、never

[root@master test]# vim never.yaml apiVersion: v1 kind: Pod metadata:name: foo01namespace: zy spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 30; exit 3restartPolicy: Never

[root@master test]# kubectl apply -f never.yaml

這時pod故障后就一直不重啟了

3、onfailure

3.1 非0狀態

[root@master test]# vim onfailure.yaml apiVersion: v1 kind: Pod metadata:name: foo02namespace: zy spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 20; exit 3restartPolicy: OnFailure

[root@master test]# kubectl apply -f onfailure.yaml

3.2 為0狀態

[root@master test]# mv onfailure.yaml onfailure0.yaml [root@master test]# vim onfailure0.yaml apiVersion: v1 kind: Pod metadata:name: foo03namespace: zy spec:containers:- name: busyboximage: busyboxargs:- /bin/sh- -c- sleep 20; exit 0restartPolicy: OnFailure

[root@master test]# kubectl apply -f onfailure0.yaml

退出后顯示的完成，說明正常退出，只是完成了這個動作，并不是錯誤。

[root@master test]# kubectl delete -f . pod "foo" deleted pod "foo01" deleted pod "foo03" deleted

二、探針

健康檢查：又稱為探針（Probe）
（注意：）規則可以同時定義
livenessProbe(存活性探針) 如果檢查失敗，將殺死容器，根據Pod的restartPolicy來操作。
ReadinessProbe(就緒性探針) 如果檢查失敗，kubernetes會把Pod的IP：port信息從service endpoints中剔除。

Probe支持三種檢查方法：
httpGet發送http(的GET)請求，返回200-400范圍狀態碼為成功。
exec執行 shell命令返回狀態碼是0為成功（例如:/bin/sh -c cat /var/run/nginx.pid）。
tcpSocket 發起TCP Socket建立成功(三次握手的方式建立連接，建立成功，則為健康、否則，則為失敗)

1、exec

[root@master test]# vim exec.yaml apiVersion: v1 kind: Pod metadata:labels:test: livenessname: liveness-execnamespace: zy spec:containers:- name: livenessimage: busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5

在配置文件中，您可以看到/Pod具有單個Container ,該period9econds 字段指定Kucaeet應該每5秒執行一次活動性探測。該initialle1sy$conda字股告訴知cbee在執行第一個保影之前應等待5秒。為了執行探測，kubet cat /try/heolthy在容器中執行命令。如果命令成功執行，則返回，并且lubelet認l為Container仍然健康。如果命令返回非零值，則妙火ubelet將殺死Container并重新啟動它。

附：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)、私有鏡像密鑰配置錯誤、鏡像太大導致拉取超E(可以適當調整kubelet的-image-pull-progress-deadline和-runtime-request-timeout選項)等。
2、CNI網絡錯誤，一般需要檢查CNI網絡插件的配置，比如:無法配置Pod 網絡、無法分配IP地址。
3、容器無法啟動，需要檢查是否打包了正確的鏡像或者是否配置了正確的容器參數
4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盤壞道（input/output error)。
Pod 一直處于ImagePullBackOff狀態
通常是鏡像名稱配置錯誤或者私有鏡像的密鑰配置錯誤導致。

3、Pod 一直處于CrashLoopBackOff狀態

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

4、Pod處于Error狀態

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

5、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

總結

以上是生活随笔為你收集整理的pod重启策略和状态解释的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。