[[427887]]

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

pod狀態(tài)為Terminating

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

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

pod的生命周期

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

Pod 的生命周期

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

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

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

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

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

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

Eviction介紹

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

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

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

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

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

• 從集群中刪除該 Node。使用公有云時(shí)，kube-controller-manager 會(huì)在 VM 刪除后自動(dòng)刪除對(duì)應(yīng)的 Node。而在物理機(jī)部署的集群中，需要管理員手動(dòng)刪除 Node(如 kubectl delete node。
• 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--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就會(huì)執(zhí)行驅(qū)逐策略。驅(qū)逐Pod會(huì)考慮優(yōu)先級(jí)，資源使用和資源申請(qǐng)。當(dāng)優(yōu)先級(jí)相同時(shí)，資源使用/資源申請(qǐng)最大的Pod會(huì)被首先驅(qū)逐。kube-controller-manager的eviction機(jī)制是粗粒度的，即驅(qū)趕一個(gè)節(jié)點(diǎn)上的所有pod，而kubelet則是細(xì)粒度的，它驅(qū)趕的是節(jié)點(diǎn)上的某些Pod，驅(qū)趕哪些Pod與Pod的Qos機(jī)制有關(guān)。該Eviction會(huì)周期性檢查本節(jié)點(diǎn)內(nèi)存、磁盤等資源，當(dāng)資源不足時(shí)，按照優(yōu)先級(jí)驅(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不會(huì)馬上回收資源，如果改善到低于閾值就不進(jìn)行驅(qū)逐，若這段時(shí)間一直高于閾值就進(jìn)行驅(qū)逐。
• 強(qiáng)制驅(qū)逐：強(qiáng)制驅(qū)逐機(jī)制則簡(jiǎn)單的多，一旦達(dá)到閾值，直接把pod從本地驅(qū)逐。
• eviction-soft：軟驅(qū)逐閾值設(shè)置，具有一系列閾值，比如memory.available<1.5Gi時(shí)，它不會(huì)立即執(zhí)行pod eviction，而會(huì)等待eviction-soft-grace-period時(shí)間，假如該時(shí)間過后，依然還是達(dá)到了eviction-soft，則觸發(fā)一次pod eviction。
• eviction-soft-grace-period：默認(rèn)為90秒，當(dāng)eviction-soft時(shí)，終止Pod的grace的時(shí)間，即軟驅(qū)逐寬限期，軟驅(qū)逐信號(hào)與驅(qū)逐處理之間的時(shí)間差。
• eviction-max-pod-grace-period：最大驅(qū)逐pod寬限期，停止信號(hào)與kill之間的時(shí)間差。
• eviction-pressure-transition-period：默認(rèn)為5分鐘，脫離pressure condition的時(shí)間，超過閾值時(shí)，節(jié)點(diǎn)會(huì)被設(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時(shí)，會(huì)立即觸發(fā)一次pod eviction。

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

總結(jié)：

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

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

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

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

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

想要?jiǎng)h除這些狀態(tài)的 Pod 有三種方法：

• 從集群中刪除該 Node。使用公有云時(shí)，kube-controller-manager 會(huì)在 VM 刪除后自動(dòng)刪除對(duì)應(yīng)的 Node。而在物理機(jī)部署的集群中，需要管理員手動(dòng)刪除 Node(如 kubectl delete node。
• 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--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