1 重啟策略

1.1 Always

Pod中的容器，不管因?yàn)槭裁丛蛲Ｖ?，都?huì)自動(dòng)重啟。

該為默認(rèn)策略，

沒(méi)有定義重啟策略時(shí)，默認(rèn)的就是always

1.2  OnFailure

Pod中的容器，非正常停止/異常退出時(shí)，會(huì)自動(dòng)重啟容器，如果是正常停止，則不會(huì)

1.3 Nerver

Pod中容器不管以什么原因退出，都不會(huì)自動(dòng)重啟容器

1.4 yaml示例 

其關(guān)鍵字為：restartPolicy 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-test
spec:
  restartPolicy: Always/OnFailure/Nerver # 重啟策略,根據(jù)需求選擇一種即可
  containers:
    - name: nginx-pod-test
      image: nginx

2 Pod常見(jiàn)異常狀態(tài)

• Pending狀態(tài)
• Waiting/ContainerCreating狀態(tài)
• CrashLoopBackOff狀態(tài)
• ImagePullBackOff狀態(tài)
• Error狀態(tài)
• 其他狀態(tài)說(shuō)明

2.1  Pending狀態(tài)

Pending狀態(tài):

• 說(shuō)明Pod的YAML文件已提交給Kubernetes
• API對(duì)象已經(jīng)被創(chuàng)建并保存在Etcd當(dāng)中

原因：這個(gè)Pod里有些容器因?yàn)槟撤N原因而不能被順利創(chuàng)建。

可能原因：

調(diào)度不成功

可以通過(guò)命令查看到當(dāng)前Pod的事件，進(jìn)而判斷為什么沒(méi)有調(diào)度。

kubectl describe pod {podname}

資源不足

• 原因：集群內(nèi)所有的Node都不滿足該P(yáng)od請(qǐng)求的CPU、內(nèi)存、GPU等資源
• 解決方法：增加資源配置/優(yōu)化容器資源使用方式

HostPort 已被占用

解決方法：使用Service對(duì)外開(kāi)放服務(wù)端口

2.2 Waiting/ContainerCreating狀態(tài)

首先通過(guò) 命令查看當(dāng)前Pod的事件

kubectl describe pod {podname}

可能的原因有:

• 鏡像拉取失敗：比如鏡像地址配置錯(cuò)誤、拉取不了國(guó)外鏡像源（gcr.io)、私有鏡像密鑰配置錯(cuò)誤、鏡像太大導(dǎo)致拉取超時(shí) (可以適當(dāng)調(diào)整kubelet的-image-pull-progress-deadline和-runtime-request-timeout選項(xiàng))等。
• CNI網(wǎng)絡(luò)錯(cuò)誤：檢查CNI網(wǎng)絡(luò)插件的配置，比如:無(wú)法配置Pod 網(wǎng)絡(luò)、無(wú)法分配IP地址。
• 容器無(wú)法啟動(dòng)：檢查是否打包了正確的鏡像或者是否配置了正確的容器參數(shù)
• Failed create pod sandbox：查看kubelet日志，原因可能是磁盤壞道（input/output error)。

2.3 CrashLoopBackOff狀態(tài)

處于CrashLoopBackOff狀態(tài)

說(shuō)明容器曾經(jīng)啟動(dòng)了，但又異常退出。

1.查看容器的日志，查看退出原因

kubectl logs {podname}
kubectl logs --previous {podname}

2.進(jìn)入容器查看

kubectl exec {mypodname} -c {containername} -it -- bash

3.ssh登錄Node查看

2.4 ImagePullBackOff狀態(tài)

處于ImagePullBackOff狀態(tài)

原因：是鏡像名稱配置錯(cuò)誤或者私有鏡像的密鑰配置錯(cuò)誤導(dǎo)致。

2.5 Error狀態(tài)

Pod處于Error狀態(tài)，說(shuō)明Pod啟動(dòng)過(guò)程中發(fā)生了錯(cuò)誤。

2.6 其他狀態(tài)說(shuō)明

CrashLoopBackOff：    #容器退出，kubelet正在將它重啟
InvalidImageName：    #無(wú)法解析鏡像名稱
ImageInspectError：   #無(wú)法校驗(yàn)鏡像
ErrImageNeverPull：   #策略禁止拉取鏡像
ImagePullBackOff：    #正在重試?yán)?
RegistryUnavailable： #連接不到鏡像中心
ErrImagePull：        #通用的拉取鏡像出錯(cuò)
CreateContainerConfigError： #不能創(chuàng)建kubelet使用的容器配置
CreateContainerError： #創(chuàng)建容器失敗
m.internalLifecycle.PreStartContainer #執(zhí)行hook報(bào)錯(cuò)
RunContainerError：   #啟動(dòng)容器失敗
PostStartHookError：  #執(zhí)行hook報(bào)錯(cuò)
ContainersNotInitialized： #容器沒(méi)有初始化完畢
ContainersNotReady：   #容器沒(méi)有準(zhǔn)備完畢
ContainerCreating：    #容器創(chuàng)建中
PodInitializing：pod   #初始化中
DockerDaemonNotReady：  #docker還沒(méi)有完全啟動(dòng)
NetworkPluginNotReady： #網(wǎng)絡(luò)插件還沒(méi)有完全啟動(dòng)
Evicte:     #pod被驅(qū)趕

tips: 

k8s中不支持重啟Pod資源，只有刪除重建！重建！

3.自動(dòng)重啟的可能原因：

•  Xms超出了k8s分配
• docker容器的內(nèi)存限制
• 出現(xiàn)OOMKilled事件

3.1  Xms超出了k8s分配 

在沒(méi)有給jvm指定內(nèi)存大小的情況下，機(jī)器物理內(nèi)存很大時(shí)，jvm默認(rèn)占用的內(nèi)存Xms超出了k8s分配給pod的內(nèi)存，導(dǎo)致pod內(nèi)存溢出，從而k8s不斷重啟pod。

或者：運(yùn)行過(guò)程中，jvm不斷申請(qǐng)內(nèi)存直到最大heap內(nèi)存Xmx，Xmx超出了k8s分配給pod的內(nèi)存，從而k8s自動(dòng)重啟pod。

解決方法：在啟動(dòng)的腳本中設(shè)置jvm內(nèi)存-Xms、-Xmx參數(shù)

例如：java -Xms1024m -Xmx1024m -jar test.jar

3.2 docker容器的內(nèi)存限制

設(shè)置了docker容器的內(nèi)存限制，制作的鏡像未對(duì)JVM進(jìn)行配置，

JVM 會(huì)默認(rèn)設(shè)置堆棧的大小。

這樣，當(dāng)jvm占用內(nèi)存超過(guò)docker容器限制時(shí)，就會(huì)出現(xiàn)container 被docker killed情況。

解決方法：一樣是設(shè)置jvm內(nèi)存-Xms、-Xmx參數(shù)

注意要小于docker容器的內(nèi)存限制。

3.3 出現(xiàn)OOMKilled事件

pod運(yùn)行過(guò)程中出現(xiàn)了OOMKilled事件

即pod運(yùn)行過(guò)程內(nèi)存需求持續(xù)增加，超過(guò)為pod設(shè)置的內(nèi)存大小時(shí)，pod會(huì)被重啟。

解決方法：將pod的內(nèi)存配置項(xiàng)的值修改大點(diǎn)。

例如之前是1/2，可改為2/4

總結(jié)

到此這篇關(guān)于K8S中Pod重啟策略及重啟可能原因的文章就介紹到這了,更多相關(guān)K8S Pod重啟策略及原因內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論