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

一、重啟策略：Pod在遇到故障之后重啟的動(dòng)作

1：Always：當(dāng)容器終止退出后，總是重啟容器，默認(rèn)策略
2：OnFailure：當(dāng)容器異常退出（退出狀態(tài)碼非0）時(shí)，重啟容器
3：Never：當(dāng)容器終止退出，從不重啟容器。
（注意：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

創(chuàng)建中

運(yùn)行中

出錯(cuò)了

立即重啟

證明重啟策略默認(rèn)是always，總是自動(dòng)拉取

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

這時(shí)pod故障后就一直不重啟了

3、onfailure

3.1 非0狀態(tài)

[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狀態(tài)

[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

退出后顯示的完成，說(shuō)明正常退出，只是完成了這個(gè)動(dòng)作，并不是錯(cuò)誤。

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

二、探針

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

Probe支持三種檢查方法：
httpGet發(fā)送http(的GET)請(qǐng)求，返回200-400范圍狀態(tài)碼為成功。
exec執(zhí)行 shell命令返回狀態(tài)碼是0為成功（例如:/bin/sh -c cat /var/run/nginx.pid）。
tcpSocket 發(fā)起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具有單個(gè)Container ,該period9econds 字段指定Kucaeet應(yīng)該每5秒執(zhí)行一次活動(dòng)性探測(cè)。該initialle1sy$conda字股告訴知cbee在執(zhí)行第一個(gè)保影之前應(yīng)等待5秒。為了執(zhí)行探測(cè)，kubet cat /try/heolthy在容器中執(zhí)行命令。如果命令成功執(zhí)行，則返回，并且lubelet認(rèn)l為Container仍然健康。如果命令返回非零值，則妙火ubelet將殺死Container并重新啟動(dòng)它。

附：pod各種狀態(tài)解釋：

1、Pod一直處于Pending狀態(tài)

Pending狀態(tài)意味著Pod的YAML文件已經(jīng)提交給Kubernetes，API對(duì)象已經(jīng)被創(chuàng)建并保存在Etcd當(dāng)中。但是，這個(gè)Pod里有些容器因?yàn)槟撤N原因而不能被順利創(chuàng)建。比如，調(diào)度不成功(可以通過(guò)kubectl describe pod命令查看到當(dāng)前Pod的事件，進(jìn)而判斷為什么沒(méi)有調(diào)度)。可能原因:資源不足（集群內(nèi)所有的Node都不滿足該P(yáng)od請(qǐng)求的CPU、內(nèi)存、GPU等資源);HostPort.已被占用(通常推薦使用Service對(duì)外開(kāi)放服務(wù)端口)。

2、Pod一直處于Waiting 或 ContainerCreating狀態(tài)

首先還是通過(guò) kubectl describe pod命令查看當(dāng)前Pod的事件。可能的原因有:
1、鏡像拉取失敗，比如鏡像地址配置錯(cuò)誤、拉取不了國(guó)外鏡像源（gcr.io)、私有鏡像密鑰配置錯(cuò)誤、鏡像太大導(dǎo)致拉取超E(可以適當(dāng)調(diào)整kubelet的-image-pull-progress-deadline和-runtime-request-timeout選項(xiàng))等。
2、CNI網(wǎng)絡(luò)錯(cuò)誤，一般需要檢查CNI網(wǎng)絡(luò)插件的配置，比如:無(wú)法配置Pod 網(wǎng)絡(luò)、無(wú)法分配IP地址。
3、容器無(wú)法啟動(dòng)，需要檢查是否打包了正確的鏡像或者是否配置了正確的容器參數(shù)
4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盤(pán)壞道（input/output error)。
Pod 一直處于ImagePullBackOff狀態(tài)
通常是鏡像名稱配置錯(cuò)誤或者私有鏡像的密鑰配置錯(cuò)誤導(dǎo)致。

3、Pod 一直處于CrashLoopBackOff狀態(tài)

此狀態(tài)說(shuō)明容器曾經(jīng)啟動(dòng)了，但又異常退出。這時(shí)可以先查看一下容器的日志。
通過(guò)命令kubectl logs 和kubectl logs --previous 可以發(fā)下一些容器退出的原因，比如:容器進(jìn)程退出、健康檢查失敗退出;此時(shí)如果還未發(fā)現(xiàn)線索，還而已到容器內(nèi)執(zhí)行命令(kubectl exec cassandra - cat /var.log/cassandra/system.loq)來(lái)進(jìn)一步查看退出原因;如果還是沒(méi)有線索，那就需要SSH登錄該P(yáng)od所在的Node上，查看Kubelet或者Docker的日志進(jìn)一步排查。

4、Pod處于Error狀態(tài)

通常處于Error狀態(tài)說(shuō)明Pod啟動(dòng)過(guò)程中發(fā)生了錯(cuò)誤。常見(jiàn)的原因:依賴的ConfigMap、Secret或PV等不存在;請(qǐng)求的資源超過(guò)了管理員設(shè)置的限制，比如超過(guò)了LimitRange等;違反集群的安全策略，比如違反了PodSecurityPolicy.等;容器無(wú)法操作集群內(nèi)的資源，比如開(kāi)啟RDAC后，需要為ServiceAccount配置角色綁定。

5、Pod 處于Terminating或 Unknown狀態(tài)

從v1.5開(kāi)始,Kubernetes,不會(huì)因?yàn)镹ode失聯(lián)而刪除其上正在運(yùn)行的Pod，而是將其標(biāo)記為T(mén)erminating或 Unknown 狀態(tài)。想要?jiǎng)h除這些狀態(tài)的Pod有三種方法:
1、從集群中刪除Node。使用公有云時(shí)，kube-controller-manager會(huì)在VM刪除后自動(dòng)刪除對(duì)應(yīng)的Node
而在物理機(jī)部署的集群中，需要管理員手動(dòng)刪除Node (kubectl delete node)。
2、Node恢復(fù)正常。,kubelet會(huì)重新跟kube-apiserver通信確認(rèn)這些Pod的期待狀態(tài),進(jìn)而再?zèng)Q定刪除或者繼續(xù)運(yùn)行這些Pod,用戶強(qiáng)制刪除，用戶可以執(zhí)行(kubectl delete pods pod-name --grace-period=0 --force）強(qiáng)制刪除Pod。除非明確知道pod的確處于停止?fàn)顟B(tài)）比如node所在VM或物理機(jī)已經(jīng)關(guān)機(jī)，否則不建議使用該方法，特別時(shí)statefulset管理的POD

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。