1 重啟策略

1.1 Always

Pod中的容器，不管因為什么原因停止，都會自動重啟。

該為默認策略，

沒有定義重啟策略時，默認的就是always

1.2  OnFailure

Pod中的容器，非正常停止/異常退出時，會自動重啟容器，如果是正常停止，則不會

1.3 Nerver

Pod中容器不管以什么原因退出，都不會自動重啟容器

1.4 yaml示例 

其關鍵字為：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常見異常狀態(tài)

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

2.1  Pending狀態(tài)

Pending狀態(tài):

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

原因：這個Pod里有些容器因為某種原因而不能被順利創(chuàng)建。

可能原因：

調度不成功

可以通過命令查看到當前Pod的事件，進而判斷為什么沒有調度。

kubectl describe pod {podname}

資源不足

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

HostPort 已被占用

解決方法：使用Service對外開放服務端口

2.2 Waiting/ContainerCreating狀態(tài)

首先通過 命令查看當前Pod的事件

kubectl describe pod {podname}

可能的原因有:

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

2.3 CrashLoopBackOff狀態(tài)

處于CrashLoopBackOff狀態(tài)

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

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

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

2.進入容器查看

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

3.ssh登錄Node查看

2.4 ImagePullBackOff狀態(tài)

處于ImagePullBackOff狀態(tài)

原因：是鏡像名稱配置錯誤或者私有鏡像的密鑰配置錯誤導致。

2.5 Error狀態(tài)

Pod處于Error狀態(tài)，說明Pod啟動過程中發(fā)生了錯誤。

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

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

tips: 

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

3.自動重啟的可能原因：

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

3.1  Xms超出了k8s分配 

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

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

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

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

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

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

JVM 會默認設置堆棧的大小。

這樣，當jvm占用內(nèi)存超過docker容器限制時，就會出現(xiàn)container 被docker killed情況。

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

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

3.3 出現(xiàn)OOMKilled事件

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

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

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

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

總結

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

最新評論