[[427887]]

本文轉(zhuǎn)載自微信公眾號「運(yùn)維開發(fā)故事」，作者沒有文案的夏老師。轉(zhuǎn)載本文請聯(lián)系運(yùn)維開發(fā)故事公眾號。

pod狀態(tài)為Terminating

在節(jié)點(diǎn)處于“NotReady”狀態(tài)時，deployment控制器會遷移節(jié)點(diǎn)上的容器實例，并將節(jié)點(diǎn)上運(yùn)行的pod置為“Terminating”狀態(tài)。待節(jié)點(diǎn)恢復(fù)后，處于“Terminating”狀態(tài)的pod會自動刪除。偶現(xiàn)部分pod(實例)一直處于“Terminating ”狀態(tài)，發(fā)現(xiàn)這部分的pod沒有得到重新調(diào)度，不能提供服務(wù)。

Terminating不是pod生命周期PodStatus中的phase字段。會不會導(dǎo)致一些問題呢?我們來了解一下pod的生命周期與驅(qū)逐相關(guān)的概念。

pod的生命周期

Pod對象自從其創(chuàng)建開始至其終止退出的時間范圍稱為其生命周期。在這段時間中，Pod會處于多種不同的狀態(tài)，并執(zhí)行一些操作;其中，創(chuàng)建主容器(main container)為必需的操作，其他可選的操作還包括運(yùn)行初始化容器(init container)、容器啟動后鉤子(post start hook)、容器的存活性探測(liveness probe)、就緒性探測(readiness probe)以及容器終止前鉤子(pre stop hook)等，這些操作是否執(zhí)行則取決于Pod的定義。如下圖所示：

Pod 的生命周期

Pod的status字段是一個PodStatus的對象，PodStatus中有一個phase字段。無論是手動創(chuàng)建還是通過Deployment等控制器創(chuàng)建，Pod對象總是應(yīng)該處于其生命進(jìn)程中以下幾個階段(phase)之一。

• 掛起(Pending)：API Server創(chuàng)建了pod資源對象已存入etcd中，但它尚未被調(diào)度完成，或者仍處于從倉庫下載鏡像的過程中。
• 運(yùn)行中(Running)：Pod已經(jīng)被調(diào)度至某節(jié)點(diǎn)，并且所有容器都已經(jīng)被kubelet創(chuàng)建完成。
• 成功(Succeeded)：Pod中的所有容器都已經(jīng)成功終止并且不會被重啟
• 失敗(Failed)：Pod中的所有容器都已終止了，并且至少有一個容器是因為失敗終止。即容器以非0狀態(tài)退出或者被系統(tǒng)禁止。
• 未知(Unknown)：Api Server無法正常獲取到Pod對象的狀態(tài)信息，通常是由于無法與所在工作節(jié)點(diǎn)的kubelet通信所致。

注意：當(dāng)一個 Pod 被刪除時，它會Terminating被一些 kubectl 命令顯示為。此Terminating狀態(tài)不是 Pod 階段之一。Pod 默認(rèn)的正常終止的期限，默認(rèn)為 30 秒。您可以使用該標(biāo)志--force來強(qiáng)行終止pod。

Pod是kubernetes的基礎(chǔ)單元，理解它的創(chuàng)建過程對于了解系統(tǒng)運(yùn)作大有裨益。如下圖描述了一個Pod資源對象的典型創(chuàng)建過程。

• 用戶通過kubectl或其他API客戶端提交了Pod Spec給API Server。
• API Server嘗試著將Pod對象的相關(guān)信息存入etcd中，待寫入操作執(zhí)行完成，API Server即會返回確認(rèn)信息至客戶端。
• API Server開始反映etcd中的狀態(tài)變化。
• 所有的kubernetes組件均使用“watch”機(jī)制來跟蹤檢查API Server上的相關(guān)的變動。
• kube-scheduler(調(diào)度器)通過其“watcher”覺察到API Server創(chuàng)建了新的Pod對象但尚未綁定至任何工作節(jié)點(diǎn)。
• kube-scheduler為Pod對象挑選一個工作節(jié)點(diǎn)并將結(jié)果信息更新至API Server。
• 調(diào)度結(jié)果信息由API Server更新至etcd存儲系統(tǒng)，而且API Server也開始反映此Pod對象的調(diào)度結(jié)果。
• Pod被調(diào)度到的目標(biāo)工作節(jié)點(diǎn)上的kubelet嘗試在當(dāng)前節(jié)點(diǎn)上調(diào)用Docker啟動容器，并將容器的結(jié)果狀態(tài)返回送至API Server。
• API Server將Pod狀態(tài)信息存入etcd系統(tǒng)中。
• 在etcd確認(rèn)寫入操作成功完成后，API Server將確認(rèn)信息發(fā)送至相關(guān)的kubelet，事件將通過它被接受。

刪除 Pod的邏輯

當(dāng)發(fā)起一個刪除 Pod 的指令時 Pod 的刪除邏輯是這樣的：

• 調(diào)用 kube-apiserver 發(fā)起刪除 Pod 請求，如果刪除 Pod 時沒有設(shè)置 grace period 參數(shù)那么就會使用 30 秒的默認(rèn)值，否則就會使用用戶指定的 grace period 進(jìn)行優(yōu)雅下線
• kube-apiserver 接受到這個請求以后給相應(yīng)的 Pod 標(biāo)記為“刪除狀態(tài)”。其實 Pod 沒有“刪除狀態(tài)”，此時 Pod 的 status 還是 Running 狀態(tài)，所謂的“刪除狀態(tài)”只是 deletionTimestamp 和 deletionGracePeriodSeconds 字段會被設(shè)置，這時候 kubelet 或者 kube-proxy 監(jiān)聽到這樣的 Pod 就會認(rèn)為此 Pod 已經(jīng)不能提供服務(wù)了，然后開始做相應(yīng)的清理操作。
• 此時如果通過 Dashbord 查看 Pod 的狀態(tài)是 Terminating ，其實 Terminating 也不是 Pod status 的字段的值。只是因為設(shè)置了 deletionTimestamp 和 deletionGracePeriodSeconds 字段所以 Dashbord 就會把 Pod 標(biāo)記為 Terminating 狀態(tài)。
• (和第三條同時發(fā)生)當(dāng) kube-proxy 監(jiān)聽到 Pod 處于 Terminatiing 狀態(tài)時就把 Pod 從 Service 的 EndPoint 中摘掉，這樣對外暴露的服務(wù)就摘掉了這個 Pod，防止新的請求發(fā)送到這個 Pod 上來
• kubelet 監(jiān)測到 Pod 處于 Terminating 狀態(tài)的話會下線 Pod，下線的過程分成兩個步驟。1. 執(zhí)行 PreStop 2. 殺死容器。第一步：如果 Pod 設(shè)置了 PreStop hook 的話 kubelet 監(jiān)測到 Pod 處于 Terminating 狀態(tài)后就會執(zhí)行 PreStop 操作，執(zhí)行 PreStop 設(shè)置的超時時間和刪除 Pod 時指定的 grace period 一致(如果沒設(shè)置默認(rèn)是 30 秒)
• PreStop 執(zhí)行完以后還有第二步殺死容器，第二部也有超時時間，這個超時時間是 grace period 減去 PreStop 耗時。如果執(zhí)行 PreStop 超時或者 grace period 減去 PreStop 耗時剩余的時間不夠兩秒(甚至可能是負(fù)數(shù)) kubelet 會強(qiáng)制設(shè)置成兩秒。第二部的超時時間暫且稱之為 tm2, kubelet 停止容器時執(zhí)行的是 docker stop -t tm2 命令。所以 tm2 的邏輯是：首先發(fā)送 term 信號到容器的一號進(jìn)程，如果容器在 tm2 時間內(nèi)沒有停止就強(qiáng)制發(fā)送 kill 信號殺死容器
• kubelet 執(zhí)行完 PreStop 和殺死容器兩步以后會回調(diào) kube-apiserver，把 Pod 從 kube-apiserver 中刪除，這次的刪除是真的刪除，這時候通過 API 就再也看不到這個 Pod 的信息了

Eviction介紹

Eviction，即驅(qū)逐的意思，意思是當(dāng)節(jié)點(diǎn)出現(xiàn)異常時，為了保證工作負(fù)載的可用性，kubernetes將有相應(yīng)的機(jī)制驅(qū)逐該節(jié)點(diǎn)上的Pod。目前kubernetes中存在兩種eviction機(jī)制，分別由kube-controller-manager和kubelet實現(xiàn)。

kube-controller-manager實現(xiàn)的eviction

kube-controller-manager主要由多個控制器構(gòu)成，而eviction的功能主要由node controller這個控制器實現(xiàn)。該Eviction會周期性檢查所有節(jié)點(diǎn)狀態(tài)，當(dāng)節(jié)點(diǎn)處于NotReady狀態(tài)超過一段時間后，驅(qū)逐該節(jié)點(diǎn)上所有pod。kube-controller-manager提供了以下啟動參數(shù)控制eviction：

• pod-eviction-timeout：即當(dāng)節(jié)點(diǎn)宕機(jī)該時間間隔后，開始eviction機(jī)制，驅(qū)趕宕機(jī)節(jié)點(diǎn)上的Pod，默認(rèn)為5min。
• node-eviction-rate：驅(qū)趕速率，即驅(qū)趕Node的速率，由令牌桶流控算法實現(xiàn)，默認(rèn)為0.1，即每秒驅(qū)趕0.1個節(jié)點(diǎn)，注意這里不是驅(qū)趕Pod的速率，而是驅(qū)趕節(jié)點(diǎn)的速率。相當(dāng)于每隔10s，清空一個節(jié)點(diǎn)。
• secondary-node-eviction-rate：二級驅(qū)趕速率，當(dāng)集群中宕機(jī)節(jié)點(diǎn)過多時，相應(yīng)的驅(qū)趕速率也降低，默認(rèn)為0.01。
• unhealthy-zone-threshold：不健康zone閾值，會影響什么時候開啟二級驅(qū)趕速率，默認(rèn)為0.55，即當(dāng)該zone中節(jié)點(diǎn)宕機(jī)數(shù)目超過55%，而認(rèn)為該zone不健康。
• large-cluster-size-threshold：大集群閾值，當(dāng)該zone的節(jié)點(diǎn)多余該閾值時，則認(rèn)為該zone是一個大集群。大集群節(jié)點(diǎn)宕機(jī)數(shù)目超過55%時，則將驅(qū)趕速率降為0.01，假如是小集群，則將速率直接降為0。

由kube-controller-manager觸發(fā)的驅(qū)逐，會留下一個狀態(tài)為Terminating的pod，想要刪除這些狀態(tài)的 Pod 有三種方法：

• 從集群中刪除該 Node。使用公有云時，kube-controller-manager 會在 VM 刪除后自動刪除對應(yīng)的 Node。而在物理機(jī)部署的集群中，需要管理員手動刪除 Node(如 kubectl delete node。
• Node 恢復(fù)正常。Kubelet 會重新跟 kube-apiserver 通信確認(rèn)這些 Pod 的期待狀態(tài)，進(jìn)而再決定刪除或者繼續(xù)運(yùn)行這些 Pod。
• 用戶強(qiáng)制刪除。用戶可以執(zhí)行 kubectl delete pods--grace-period=0 --force 強(qiáng)制刪除 Pod。除非明確知道 Pod 的確處于停止?fàn)顟B(tài)(比如 Node 所在 VM 或物理機(jī)已經(jīng)關(guān)機(jī))，否則不建議使用該方法。特別是 StatefulSet 管理的 Pod，強(qiáng)制刪除容易導(dǎo)致腦裂或者數(shù)據(jù)丟失等問題。

kubelet的eviction機(jī)制

如果節(jié)點(diǎn)處于資源壓力，那么kubelet就會執(zhí)行驅(qū)逐策略。驅(qū)逐Pod會考慮優(yōu)先級，資源使用和資源申請。當(dāng)優(yōu)先級相同時，資源使用/資源申請最大的Pod會被首先驅(qū)逐。kube-controller-manager的eviction機(jī)制是粗粒度的，即驅(qū)趕一個節(jié)點(diǎn)上的所有pod，而kubelet則是細(xì)粒度的，它驅(qū)趕的是節(jié)點(diǎn)上的某些Pod，驅(qū)趕哪些Pod與Pod的Qos機(jī)制有關(guān)。該Eviction會周期性檢查本節(jié)點(diǎn)內(nèi)存、磁盤等資源，當(dāng)資源不足時，按照優(yōu)先級驅(qū)逐部分pod。驅(qū)逐閾值分為軟驅(qū)逐閾值(Soft Eviction Thresholds)和強(qiáng)制驅(qū)逐(Hard Eviction Thresholds)兩種機(jī)制，如下：kubelet提供了以下參數(shù)控制eviction：

• 軟驅(qū)逐閾值：當(dāng)node的內(nèi)存/磁盤空間達(dá)到一定的閾值后，kubelet不會馬上回收資源，如果改善到低于閾值就不進(jìn)行驅(qū)逐，若這段時間一直高于閾值就進(jìn)行驅(qū)逐。
• 強(qiáng)制驅(qū)逐：強(qiáng)制驅(qū)逐機(jī)制則簡單的多，一旦達(dá)到閾值，直接把pod從本地驅(qū)逐。
• eviction-soft：軟驅(qū)逐閾值設(shè)置，具有一系列閾值，比如memory.available<1.5Gi時，它不會立即執(zhí)行pod eviction，而會等待eviction-soft-grace-period時間，假如該時間過后，依然還是達(dá)到了eviction-soft，則觸發(fā)一次pod eviction。
• eviction-soft-grace-period：默認(rèn)為90秒，當(dāng)eviction-soft時，終止Pod的grace的時間，即軟驅(qū)逐寬限期，軟驅(qū)逐信號與驅(qū)逐處理之間的時間差。
• eviction-max-pod-grace-period：最大驅(qū)逐pod寬限期，停止信號與kill之間的時間差。
• eviction-pressure-transition-period：默認(rèn)為5分鐘，脫離pressure condition的時間，超過閾值時，節(jié)點(diǎn)會被設(shè)置為memory pressure或者disk pressure，然后開啟pod eviction。
• eviction-minimum-reclaim：表示每一次eviction必須至少回收多少資源。
• eviction-hard：強(qiáng)制驅(qū)逐設(shè)置，也具有一系列的閾值，比如memory.available<1Gi，即當(dāng)節(jié)點(diǎn)可用內(nèi)存低于1Gi時，會立即觸發(fā)一次pod eviction。

由kubelet觸發(fā)的驅(qū)逐，會留下一個狀態(tài)為Evicted的pod，此pod只是方便后期定位的記錄，可以直接刪除。

總結(jié)：

偶現(xiàn)部分pod(實例)一直處于“Terminating ”狀態(tài)，發(fā)現(xiàn)這部分的pod沒有得到重新調(diào)度，不能提供服務(wù)。這一類deployment其發(fā)布策略是Recreate模式(先刪舊POD，再啟動新POD)。該問題對于rollout滾動發(fā)布的deployment沒有影響，僅對recreate的造成影響(類似statefulset也有影響)根據(jù)以上描述deployment最好使用rollout滾動發(fā)布策略。

部分pod(實例)一直處于“Terminating ”狀態(tài)，情況分為很多種，這里騰訊云做過一個總結(jié)：

《Pod 一直處于 Terminating 狀態(tài)》。

https://cloud.tencent.com/document/product/457/43238

有興趣的可以去了解一下。

想要刪除這些狀態(tài)的 Pod 有三種方法：

• 從集群中刪除該 Node。使用公有云時，kube-controller-manager 會在 VM 刪除后自動刪除對應(yīng)的 Node。而在物理機(jī)部署的集群中，需要管理員手動刪除 Node(如 kubectl delete node。
• Node 恢復(fù)正常。Kubelet 會重新跟 kube-apiserver 通信確認(rèn)這些 Pod 的期待狀態(tài)，進(jìn)而再決定刪除或者繼續(xù)運(yùn)行這些 Pod。
• 用戶強(qiáng)制刪除。用戶可以執(zhí)行 kubectl delete pods--grace-period=0 --force 強(qiáng)制刪除 Pod。除非明確知道 Pod 的確處于停止?fàn)顟B(tài)(比如 Node 所在 VM 或物理機(jī)已經(jīng)關(guān)機(jī))，否則不建議使用該方法。特別是 StatefulSet 管理的 Pod，強(qiáng)制刪除容易導(dǎo)致腦裂或者數(shù)據(jù)丟失等問題。

參考文章：

https://feisky.gitbooks.io/kubernetes/content/troubleshooting/pod.html

https://v1-20.docs.kubernetes.io/docs/concepts/workloads/pods/#

https://v1-20.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

https://cloud.tencent.com/document/product/457/43238