*作者：風敬*

> 本文篇幅超過 7 千字，通讀全文大概需要 20 分鐘。文章內容源自大量真實場景的沉澱和分析，建議收藏，以供查閱。

在 K8s 中，Pod 作為工作負載的執行載體，是最為核心的一個資源物件。Pod 具有複雜的生命週期，在其生命週期的每一個階段，可能發生多種不同的異常情況。K8s 作為一個複雜系統，異常診斷往往要求強大的知識和經驗儲備。結合實戰經歷以及 EDAS 使用者真實場景的歸納，我們總結了 K8s Pod 的 13 種常見異常場景，給出各個場景的常見錯誤狀態，分析其原因和排查思路。

## Pod 生命週期

在整個生命週期中，Pod 會出現 5 種階段（Phase）。

-   Pending：Pod 被 K8s 建立出來後，起始於 Pending 階段。在 Pending 階段，Pod 將經過排程，被分配至目標節點開始拉取映象、載入依賴項、建立容器。

-   Running：當 Pod 所有容器都已被建立，且至少一個容器已經在執行中，Pod 將進入 Running 階段。

-   Succeeded：當 Pod 中的所有容器都執行完成後終止，並且不會再重啟，Pod 將進入 Succeeded 階段。

-   Failed：若 Pod 中的所有容器都已終止，並且至少有一個容器是因為失敗終止，也就是說容器以非 0 狀態異常退出或被系統終止，Pod 將進入 Failed 階段。

-   Unkonwn：因為某些原因無法取得 Pod 狀態，這種情況 Pod 將被置為 Unkonwn 狀態。

一般來說，對於 Job 型別的負載，Pod 在成功執行完任務之後將會以 Succeeded 狀態為終態。而對於 Deployment 等負載，一般期望 Pod 能夠持續提供服務，直到 Pod 因刪除消失，或者因異常退出/被系統終止而進入 Failed 階段。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9d641c29b0b44b17b49066bf362f8638~tplv-k3u1fbpfcp-zoom-1.image "1.png")

Pod 的 5 個階段是 Pod 在其生命週期中所處位置的簡單宏觀概述，並不是對容器或 Pod 狀態的綜合彙總。Pod 有一些細分狀態（ PodConditions ），例如 Ready/NotReady、Initialized、 PodScheduled/Unschedulable 等。這些細分狀態描述造成 Pod 所處階段的具體成因是什麼。比如，Pod 當前階段是 Pending，對應的細分狀態是 Unschedulable，這就意味著 Pod 排程出現了問題。

容器也有其生命週期狀態（State）：Waiting、Running 和 Terminated。並且也有其對應的狀態原因（Reason），例如 ContainerCreating、Error、OOMKilled、CrashLoopBackOff、Completed 等。而對於發生過重啟或終止的容器，上一個狀態（LastState）欄位不僅包含狀態原因，還包含上一次退出的狀態碼（Exit Code）。例如容器上一次退出狀態碼是 137，狀態原因是 OOMKilled，說明容器是因為 OOM 被系統強行終止。在異常診斷過程中，容器的退出狀態是至關重要的資訊。

除了必要的叢集和應用監控，一般還需要透過 kubectl 命令蒐集異常狀態資訊。

```
// 獲取Pod當前物件描述檔案
kubectl get po <podname> -n <namespace> -o yaml

// 獲取Pod資訊和事件（Events）
kubectl describe pod <podname> -n <namespace>

// 獲取Pod容器日誌
kubectl logs <podname> <containername> -n <namespace>

// 在容器中執行命令
kubectl exec <podname> -n <namespace> -c <containername> -- <cmd> <args>
```

## Pod 異常場景

Pod 在其生命週期的許多時間點可能發生不同的異常，按照 Pod 容器是否執行為標誌點，我們將異常場景大致分為兩類：

1.  在 Pod 進行排程並建立容器過程中發生異常，此時 Pod 將卡在 Pending 階段。

1.  Pod 容器執行中發生異常，此時 Pod 按照具體場景處在不同階段。

下文將對這具體的 13 種場景進行描述和分析。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6094fc1b3431459e9689d753945014cf~tplv-k3u1fbpfcp-zoom-1.image "2.png")

### 排程失敗

> 常見錯誤狀態：Unschedulable

Pod 被建立後進入排程階段，K8s 排程器依據 Pod 宣告的資源請求量和排程規則，為 Pod 挑選一個適合執行的節點。當叢集節點均不滿足 Pod 排程需求時，Pod 將會處於 Pending 狀態。造成排程失敗的典型原因如下：

-   **節點資源不足**

K8s 將節點資源（CPU、記憶體、磁碟等）進行數值量化，定義出節點資源容量（Capacity）和節點資源可分配額（Allocatable）。資源容量是指 Kubelet 獲取的計算節點當前的資源資訊，而資源可分配額是 Pod 可用的資源。Pod 容器有兩種資源額度概念：請求值 Request 和限制值 Limit，容器至少能獲取請求值大小、至多能獲取限制值的資源量。Pod 的資源請求量是 Pod 中所有容器的資源請求之和，Pod 的資源限制量是 Pod 中所有容器的資源限制之和。K8s 預設排程器按照較小的請求值作為排程依據，保障可排程節點的資源可分配額一定不小於 Pod 資源請求值。當叢集沒有一個節點滿足 Pod 的資源請求量，則 Pod 將卡在 Pending 狀態。

Pod 因為無法滿足資源需求而被 Pending，可能是因為叢集資源不足，需要進行擴容，也有可能是叢集碎片導致。以一個典型場景為例，使用者叢集有 10 幾個 4c8g 的節點，整個叢集資源使用率在 60%左右，每個節點都有碎片，但因為碎片太小導致擴不出來一個 2c4g 的 Pod。一般來說，小節點叢集會更容易產生資源碎片，而碎片資源無法供 Pod 排程使用。如果想最大限度地減少資源浪費，使用更大的節點可能會帶來更好的結果。

-   **超過 Namespace 資源配額**

K8s 使用者可以透過資源配額（Resource Quota）對 Namespace 進行資源使用量限制，包括兩個維度：

1. 限定某個物件型別（如 Pod）可建立物件的總數。

2. 限定某個物件型別可消耗的資源總數。

如果在建立或更新 Pod 時申請的資源超過了資源配額，則 Pod 將排程失敗。此時需要檢查 Namespace 資源配額狀態，做出適當調整。

-   **不滿足 NodeSelector 節點選擇器**

Pod 透過 NodeSelector 節點選擇器指定排程到帶有特定 Label 的節點，若不存在滿足 NodeSelector 的可用節點，Pod 將無法被排程，需要對 NodeSelector 或節點 Label 進行合理調整。

-   **不滿足親和性**

節點親和性（Affinity）和反親和性（Anti-Affinity）用於約束 Pod 排程到哪些節點，而親和性又細分為軟親和（Preferred）和硬親和（Required）。對於軟親和規則，K8s 排程器會嘗試尋找滿足對應規則的節點，如果找不到匹配的節點，排程器仍然會排程該 Pod。而當硬親和規則不被滿足時，Pod 將無法被排程，需要檢查 Pod 排程規則和目標節點狀態，對排程規則或節點進行合理調整。

-   **節點存在汙點**

K8s 提供汙點（Taints）和容忍（Tolerations）機制，用於避免 Pod 被分配到不合適的節點上。假如節點上存在汙點，而 Pod 沒有設定相應的容忍，Pod 將不會排程到該 節點。此時需要確認節點是否有攜帶汙點的必要，如果不必要的話可以移除汙點；若 Pod 可以分配到帶有汙點的節點，則可以給 Pod 增加汙點容忍。

-   **沒有可用節點**

節點可能會因為資源不足、網路不通、Kubelet 未就緒等原因導致不可用（NotReady）。當叢集中沒有可排程的節點，也會導致 Pod 卡在 Pending 狀態。此時需要檢視節點狀態，排查不可用節點問題並修復，或進行叢集擴容。

### 映象拉取失敗

> 常見錯誤狀態：ImagePullBackOff

Pod 經過排程後分配到目標節點，節點需要拉取 Pod 所需的映象為建立容器做準備。拉取映象階段可能存在以下幾種原因導致失敗：

-   **映象名字拼寫錯誤或配置了錯誤的映象**

出現映象拉取失敗後首先要確認映象地址是否配置錯誤。

-   **私有倉庫的免密配置錯誤**

叢集需要進行免密配置才能拉取私有映象。自建映象倉庫時需要在叢集建立免密憑證 Secret，在 Pod 指定 ImagePullSecrets，或者將 Secret 嵌入 ServicAccount，讓 Pod 使用對應的 ServiceAccount。而對於 acr 等映象服務雲產品一般會提供免密外掛，需要在叢集中正確安裝免密外掛才能拉取倉庫內的映象。免密外掛的異常包括：叢集免密外掛未安裝、免密外掛 Pod 異常、免密外掛配置錯誤，需要檢視相關資訊進行進一步排查。

-   **網路不通**

網路不通的常見場景有三個：

1. 叢集透過公網訪問映象倉庫，而映象倉庫未配置公網的訪問策略。對於自建倉庫，可能是埠未開放，或是映象服務未監聽公網 IP；對於 acr 等映象服務雲產品，需要確認開啟公網的訪問入口，配置白名單等訪問控制策略。

2. 叢集位於專有網路，需要為映象服務配置專有網路的訪問控制，才能建立叢集節點與映象服務之間的連線。

3. 拉取海外映象例如 gcr.io 倉庫映象，需配置映象加速服務。

-   **映象拉取超時**

常見於頻寬不足或映象體積太大，導致拉取超時。可以嘗試在節點上手動拉取映象，觀察傳輸速率和傳輸時間，必要時可以對叢集頻寬進行升配，或者適當調整 Kubelet 的 --image-pull-progress-deadline 和 --runtime-request-timeout 選項。

-   **同時拉取多個映象，觸發並行度控制**

常見於使用者彈性擴容出一個節點，大量待排程 Pod 被同時排程上去，導致一個節點同時有大量 Pod 啟動，同時從映象倉庫拉取多個映象。而受限於叢集頻寬、映象倉庫服務穩定性、容器執行時映象拉取並行度控制等因素，映象拉取並不支援大量並行。這種情況可以手動打斷一些映象的拉取，按照優先順序讓映象分批拉取。

### 依賴項錯誤

> 常見錯誤狀態：Error

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f82f3180e714409f9515c8cd9a64439f~tplv-k3u1fbpfcp-zoom-1.image "3.png")

在 Pod 啟動之前，Kubelet 將嘗試檢查與其他 K8s 元素的所有依賴關係。主要存在的依賴項有三種：PersistentVolume、ConfigMap 和 Secret。當這些依賴項不存在或者無法讀取時，Pod 容器將無法正常建立，Pod 會處於 Pending 狀態直到滿足依賴性。當這些依賴項能被正確讀取，但出現配置錯誤時，也會出現無法建立容器的情況。比如將一個只讀的持久化儲存卷 PersistentVolume 以可讀寫的形式掛載到容器，或者將儲存卷掛載到/proc 等非法路徑，也會導致容器建立失敗。

### 容器建立失敗

> 常見錯誤狀態：Error

Pod 容器建立過程中出現了錯誤。常見原因包括：

-   違反叢集的安全策略，比如違反了 PodSecurityPolicy 等。

-   容器無權操作叢集內的資源，比如開啟 RBAC 後，需要為 ServiceAccount 配置角色繫結。

-   缺少啟動命令，Pod 描述檔案和映象 Dockerfile 中均未指定啟動命令。

-   啟動命令配置錯誤。Pod 配置檔案可以透過 command 欄位定義命令列，透過 args 欄位給命令列定義引數。啟動命令配置錯誤的情況非常多見，要格外注意命令及引數的格式。正確的填寫方式可參考：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b1012868654146639e5094285d963cc8~tplv-k3u1fbpfcp-zoom-1.image "4.png")

### 初始化失敗

> 常見錯誤狀態：CrashLoopBackOff

K8s 提供 Init Container 特性，用於在啟動應用容器之前啟動一個或多個初始化容器，完成應用程式所需的預置條件。Init container 與應用容器本質上是一樣的，但它們是僅執行一次就結束的任務，並且必須在執行完成後，系統才能繼續執行下一個容器。如果 Pod 的 Init Container 執行失敗，將會 block 業務容器的啟動。透過檢視 Pod 狀態和事件定位到 Init Container 故障後，需要檢視 Init Container 日誌進一步排查故障點。

### 回撥失敗

> 常見錯誤狀態：FailedPostStartHook 或 FailedPreStopHook 事件

K8s 提供 PostStart 和 PreStop 兩種容器生命週期回撥，分別在容器中的程式啟動前或者容器中的程式終止之前執行。PostStart 在容器建立之後立即執行，但由於是非同步執行，無法保證和容器啟動命令的執行順序相關聯。如果 PostStart 或者 PreStop 回撥程式執行失敗，常用於在容器結束前優雅地釋放資源。如果 PostStart 或者 PreStop 回撥程式執行失敗失敗，容器將被終止，按照重啟策略決定是否重啟。當出現回撥失敗，會出現 FailedPostStartHook 或 FailedPreStopHook 事件，進一步結合容器打出的日誌進行故障排查。

### 就緒探針失敗

> 常見錯誤狀態：容器已經全部啟動，但是 Pod 處於 NotReady 狀態，服務流量無法從 Service 達到 Pod

K8s 使用 Readiness Probe（就緒探針）來確定容器是否已經就緒可以接受流量。只有當 Pod 中的容器都處於就緒狀態時，K8s 才認定該 Pod 處於就緒狀態，才會將服務流量轉發到該容器。一般就緒探針失敗分為幾種情況：

-   容器內應用原因：健康檢查所配置規則對應的埠或者指令碼，無法成功探測，如容器內應用沒正常啟動等。

-   探針配置不當：寫錯檢查埠導致探測失敗；檢測間隔和失敗閾值設定不合理，例如每次檢查間隔 1s，一次不透過即失敗；啟動延遲設定太短，例如應用正常啟動需要 15s，而設定容器啟動 10s 後啟用探針。

-   系統層問題：節點負載高，導致容器程式 hang 住。

-   CPU 資源不足：CPU 資源限制值過低，導致容器程式響應慢。

需要特別說明的是，對於微服務應用，服務的註冊和發現由註冊中心管理，流量不會經過 Service，直接從上游 Pod 流到下游 Pod。然而註冊中心並沒有如 K8s 就緒探針的檢查機制，對於啟動較慢的 JAVA 應用來說，服務註冊成功後所需資源仍然可能在初始化中，導致出現上線後流量有損的情況。對於這一類場景，EDAS 提供延遲註冊和服務預熱等解決方案，解決 K8s 微服務應用上線有損的問題。

### 存活探針失敗

> 常見錯誤狀態：CrashLoopBackOff

K8s 使用 Liveness Probe（存活探針）來確定容器是否正在執行。如果存活態探測失敗，則容器會被殺死，隨之按照重啟策略決定是否重啟。存活探針失敗的原因與就緒探針類似，然而存活探針失敗後容器會被 kill 消失，所以排障過程要棘手得多。一個典型的使用者場景是，使用者在壓測期間透過 HPA 彈性擴容出多個新 Pod，然而新 Pod 一啟動就被大流量阻塞，無法響應存活探針，導致 Pod 被 kill。kill 後又重啟，重啟完又掛掉，一直在 Running 和 CrashLoopBackOff 狀態中振盪。微服務場景下可以使用延遲註冊和服務預熱等手段，避免瞬時流量打掛容器。如果是程式本身問題導致執行阻塞，建議先將 Liveness 探針移除，透過 Pod 啟動後的監控和程式堆疊資訊，找出流量湧入後程式阻塞的根因。

### 容器退出

> 常見錯誤狀態：CrashLoopBackOff

容器退出分為兩種場景：

-   啟動後立即退出，可能原因是：

1. 啟動命令的路徑未包含在環境變數PATH中。

2. 啟動命令引用了不存在的檔案或目錄。

3. 啟動命令執行失敗，可能因為執行環境缺少依賴，也可能是程式本身原因。

4. 啟動命令沒有執行許可權。

5. 容器中沒有前臺程式。容器應該至少包含一個 long-running 的前臺程式，不能後臺執行，比如透過nohup這種方式去啟動程式，或是用 tomcat 的 startup.sh 指令碼。

對於容器啟動後立即退出的情況，通常因為容器直接消失，無法獲取其輸出流日誌，很難直接透過現場定位問題。一個簡易的排查方式是，透過設定特殊的啟動命令卡住容器（比如使用 tail -f /dev/null），然後進到容器中手動執行命令看看結果，確認問題原因。

-   執行一段時間後退出，這種情況一般是容器內 1 程式 Crash 或者被系統終止導致退出。此時首先檢視容器退出狀態碼，然後進一步檢視上下文資訊進行錯誤定位。這種情況發生時容器已經刪除消失，無法進入容器中檢視日誌和堆疊等現場資訊，所以一般推薦使用者對日誌、錯誤記錄等檔案配置持久化儲存，留存更多現場資訊。幾種常見的狀態碼如下：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9113fb9724404b0c94856e172134603f~tplv-k3u1fbpfcp-zoom-1.image "5.png")

### OOMKilled

> 常見錯誤狀態：OOMKilled

K8s 中有兩種資源概念：可壓縮資源（CPU）和不可壓縮資源（記憶體，磁碟 ）。當 CPU 這種可壓縮資源不足時，Pod 只會“飢餓”，但不會退出；而當記憶體和磁碟 IO 這種不可壓縮資源不足時，Pod 會被 kill 或者驅逐。因為記憶體資源不足/超限所導致的 Pod 異常退出的現象被稱為 Pod OOMKilled。K8s 存在兩種導致 Pod OOMKilled 的場景：

-   **Container Limit Reached，容器記憶體用量超限**

Pod 內的每一個容器都可以配置其記憶體資源限額，當容器實際佔用的記憶體超額，該容器將被 OOMKilled 並以狀態碼 137 退出。OOMKilled 往往發生在 Pod 已經正常執行一段時間後，可能是由於流量增加或是長期執行累積的記憶體逐漸增加。這種情況需要檢視程式日誌以瞭解為什麼 Pod 使用的記憶體超出了預期，是否出現異常行為。如果發現程式只是按照預期執行就發生了 OOM，就需要適當提高 Pod 記憶體限制值。一個很常見的錯誤場景是，JAVA 容器設定了記憶體資源限制值 Limit，然而 JVM 堆大小限制值比記憶體 Limit 更大，導致程式在執行期間堆空間越開越大，最終因為 OOM 被終止。對於 JAVA 容器來說，一般建議容器記憶體限制值 Limit 需要比 JVM 最大堆記憶體稍大一些。

-   **Limit Overcommit，節點記憶體耗盡**

K8s 有兩種資源額度概念：請求值 Request 和限制值 Limit，預設排程器按照較小的請求值作為排程依據，保障節點的所有 Pod 資源請求值總和不超過節點容量，而限制值總和允許超過節點容量，這就是 K8s 資源設計中的 Overcommit（超賣）現象。超賣設計在一定程度上能提高吞吐量和資源利用率，但會出現節點資源被耗盡的情況。當節點上的 Pod 實際使用的記憶體總和超過某個閾值，K8s 將會終止其中的一個或多個 Pod。為了儘量避免這種情況，建議在建立 Pod 時選擇大小相等或相近的記憶體請求值和限制值，也可以利用排程規則將記憶體敏感型 Pod 打散到不同節點。

### Pod 驅逐

> 常見錯誤狀態：Pod Evicted

當節點記憶體、磁碟這種不可壓縮資源不足時，K8s 會按照 QoS 等級對節點上的某些 Pod 進行驅逐，釋放資源保證節點可用性。當 Pod 發生驅逐後，上層控制器例如 Deployment 會新建 Pod 以維持副本數，新 Pod 會經過排程分配到其他節點建立執行。對於記憶體資源，前文已經分析過可以透過設定合理的請求值和限制值，避免節點記憶體耗盡。而對於磁碟資源，Pod 在執行期間會產生臨時檔案、日誌，所以必須對 Pod 磁碟容量進行限制，否則某些 Pod 可能很快將磁碟寫滿。類似限制記憶體、CPU 用量的方式，在建立 Pod 時可以對本地臨時儲存用量（ephemeral-storage）進行限制。同時，Kubelet 驅逐條件預設磁碟可用空間在 10%以下，可以調整雲監控磁碟告警閾值以提前告警。

### Pod 失聯

> 常見錯誤狀態：Unkonwn

Pod 處於 Unkonwn 狀態，無法獲取其詳細資訊，一般是因為所在節點 Kubelet 異常，無法向 APIServer 上報 Pod 資訊。首先檢查節點狀態，透過 Kubelet 和容器執行時的日誌資訊定位錯誤，進行修復。如果無法及時修復節點，可以先將該節點從叢集中刪除。

### 無法被刪除

> 常見錯誤狀態：卡在 Terminating

當一個 Pod 被執行刪除操作後，卻長時間處於 Terminating 狀態，這種情況的原因有幾種：

-   Pod 關聯的 finalizer 未完成。首先檢視 Pod 的 metadata 欄位是否包含 finalizer，透過一些特定上下文資訊確認 finalizer 任務具體是什麼，通常 finalizer 的任務未完成可能是因為與 Volume 相關。如果 finalizer 已經無法被完成，可以透過 patch 操作移除對應的 Pod 上的 finalizer 完成刪除操作。

-   Pod 對中斷訊號沒有響應。Pod 沒有被終止可能是程式對訊號沒有響應，可以嘗試強制刪除 Pod。

-   節點故障。透過檢視相同節點上的其他 Pod 狀態確認是否節點故障，嘗試重啟 Kubelet 和容器執行時。如果無法修復，先將該節點從叢集中刪除。

## EDAS排障工具鏈

EDAS 對應用全生命週期的大部分異常都有沉澱和分析，降低使用者學習成本，縮短排障時間。EDAS 提供一系列解決方案和工具幫助使用者解決應用生命週期中的異常問題，包括應用變更前的變更預檢、應用變更和執行的事件追蹤可觀測、應用異常時的診斷工具。

### 應用變更預檢

EDAS 在應用變更任務下發前將經過預檢環節，應用變更預檢可以在應用部署前檢查叢集狀態及變更引數是否有效，能夠有效避免應用變更過程出錯，降低變更風險。當前應用變更預檢提供叢集可用資源檢查、叢集健康檢查、各項依賴配置檢查等專案，對於非預期的預檢結果給出分析和處置建議。例如對於叢集資源餘量不滿足 Pod 排程需求的異常場景，變更預檢結果將顯示資源檢查不透過，使用者能夠第一時間做出針對性調整。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f5fa78ff97a94ce39b31be4fb3bb335c~tplv-k3u1fbpfcp-zoom-1.image "6.png")

### 應用事件觀測

EDAS 對應用生命週期中的事件進行追蹤提供可觀測能力。對於應用變更過程提供完整的事項展示，讓使用者能夠白屏觀測到變更中的每一個步驟和相關上下文資訊。當出現異常變更情況時，將具體的事件和相關資源資訊在白屏透出，並對異常事件進行分析解讀並給出操作建議。例如給 Pod 配置了容器服務倉庫映象，但並未正確配置叢集免密外掛，EDAS 將映象拉取失敗事件丟擲，並引導使用者檢查映象拉取許可權。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8ffbf709a4e84b6d933149f554fd25d9~tplv-k3u1fbpfcp-zoom-1.image "7.png")

### 診斷工具箱

對於異常 Pod，通常需要連線到 Pod 容器，對業務程式進行診斷，必要時候還需要對異常進行復現。EDAS 提供雲原生工具箱，讓使用者在網頁上連線 Pod 容器 Shell，並且提供 Arthas、Tcpdump 等工具，彌補映象軟體工具包的缺失。對於 Pod 已經消失、不適合在業務 Pod 進行診斷等場景，雲原生工具箱提供 Pod 複製能力，根據診斷場景不同，使用者可以按需選擇開啟診斷 Pod。

對於上文中提到的容器程式被大流量阻塞，導致 Pod 被 Liveness 打掛的場景，使用者可以透過雲原生工具箱，開啟一個移除 Liveness 的診斷 Pod，設定全鏈路流量控制規則，打入一些測試流量，使用 Arthas 提供的 trace、stack、watch 等工具精準定位問題

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/65c0e0d374fa4b6f883e3663967e8c62~tplv-k3u1fbpfcp-zoom-1.image "8.png")

## *參考文件*

-   *<https:></https:>*
-   *Managing Compute Resources for Containers*
-   *Configure Quality of Service for Pods - Kubernetes*
-   *<https:>*
-   *<https:>*
-   *<https:>*</https:></https:></https:></args></cmd></containername></namespace></podname></namespace></containername></podname></namespace></podname></namespace></podname>

解讀 K8s Pod 的 13 種異常

相關文章