排解已部署工作負載的問題

自動駕駛 標準

本頁面說明如何解決 Google Kubernetes Engine (GKE) 中已部署工作負載的錯誤。

如需有關排解應用程式問題的一般建議，請參閱 Kubernetes 說明文件中的「Troubleshooting Applications」(排解應用程式問題)。

所有錯誤：檢查 Pod 狀態

如果工作負載的 Pod 發生問題，Kubernetes 會更新 Pod 狀態，並顯示錯誤訊息。如要查看這些錯誤，請使用 Google Cloud 控制台或 kubectl 指令列工具檢查 Pod 的狀態。

控制台

請執行下列步驟：

1. 前往 Google Cloud 控制台的「Workloads」(工作負載) 頁面。

   前往「Workloads」(工作負載)

2. 選取要調查的工作負載。「總覽」分頁標籤會顯示工作負載的狀態。

3. 在「受管理的 Pod」區段，按一下任何錯誤狀態訊息。

kubectl

如要查看在叢集中執行的所有 Pod，請執行以下指令：

kubectl get pods

輸出結果會與下列內容相似：

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

「Status」欄會列出潛在錯誤。

如要取得特定 Pod 的詳細資訊，請執行下列指令：

kubectl describe pod POD_NAME

將 POD_NAME 替換為要調查的 Pod 名稱。

在輸出內容中，Events 欄位會顯示更多錯誤資訊。

如要瞭解詳情，請查看容器記錄：

kubectl logs POD_NAME

這些記錄有助於判斷容器中的指令或程式碼是否導致 Pod 當機。

找出錯誤後，請參閱下列章節，嘗試解決問題。

錯誤：CrashLoopBackOff

CrashLoopBackOff 狀態不代表發生特定錯誤，而是表示容器在重新啟動後一直當機。

詳情請參閱「排解 CrashLoopBackOff 事件」。

錯誤：ImagePullBackOff 和 ErrImagePull

ImagePullBackOff 或 ErrImagePull 狀態表示無法從映像檔登錄檔載入容器使用的映像檔。

如需排解這些狀態的指引，請參閱「排解映像檔提取問題」。

發生錯誤：OutOfPods

OutOfPods 狀態表示節點已達 Pod 容量上限，因此無法執行 Pod。

問題

Pod 的事件中可能會顯示類似下方的訊息：

Node didn't have enough resource: pods, requested: 1, used: 32, capacity: 32

原因

如果要求在容量已滿的節點上排程 Pod，就會發生這個錯誤。舉例來說，節點啟動期間通常會發生這種情況，因為 kube-scheduler 元件會在 kubelet 代理程式回報靜態 Pod (例如 kube-proxy 元件) 的存在之前，將 Pod 指派給新節點，而這些 Pod 需要自己的 Pod 容量。

解析度

如要解決這個問題，請嘗試下列其中一種方法：

• 提高每個節點的 Pod 數量上限。如果節點經常達到 Pod 數量上限，請提高節點集區的 --max-pods-per-node 設定。增加 Pod 數量可能需要較大的節點，才能處理增加的資源需求。

• 啟用叢集自動調度資源和自動佈建節點功能。如果 Pod 容量經常不足，啟用叢集自動配置器和節點自動佈建功能，有助於確保叢集有足夠的節點，可滿足工作負載的需求。

• 變更自動調度資源設定檔。如果您已使用叢集自動配置器，請嘗試將自動調整資源配置設定檔變更為 balanced 設定檔，而非 optimize-utilization 設定檔。optimize-utilization 設定檔會嘗試將 Pod 放置在最常使用的節點上，因此可能會增加發生 OutOfPods 錯誤的機率。

錯誤：Pod 無法排程

PodUnschedulable 狀態表示您的 Pod 因為資源不足或一些設定上的錯誤而無法排程。

如果您已設定控制層指標，可以在排程器指標和 API 伺服器指標中找到這些錯誤的詳細資訊。

使用無法排程的 Pod 互動式應對手冊

您可以使用 Google Cloud 控制台中的互動式劇本，排解 PodUnschedulable 錯誤：

1. 前往無法排程 Pod 的互動式應對手冊：

   前往 Playbook

2. 在「叢集」下拉式清單中，選取要排解問題的叢集。如果找不到叢集，請在「篩選」欄位中輸入叢集名稱。

3. 在「命名空間」下拉式選單中，選取要排解問題的命名空間。如果找不到命名空間，請在「篩選」欄位中輸入命名空間。

4. 為協助您找出原因，請逐步完成劇本中的每個章節：

   1. 調查 CPU 和記憶體問題
   2. 調查每個節點的 Pod 數量上限問題
   3. 調查自動配置器行為問題
   4. 調查其他失敗模式
   5. 找出變更事件的關聯性

5. 選用步驟：如要接收日後發生PodUnschedulable錯誤的通知，請在「Future Mitigation Tips」(日後補救提示) 部分選取「Create an Alert」(建立快訊)。

錯誤：資源不足

如果 CPU、記憶體或其他資源不足，無法滿足 Pod 的要求，就會出現 PodUnschedulable 狀態。

問題

您遇到的錯誤指出缺少 CPU、記憶體或其他資源。例如：No nodes are available that match all of the predicates: Insufficient cpu (2)。這則訊息表示兩個節點上沒有足夠的 CPU 可完成 Pod 要求。

原因

如果 Pod 資源要求超過任何符合資格的節點集區中單一節點的資源要求，GKE 不會排定 Pod，也不會觸發擴充作業來新增節點。

叢集會在 kube-system 命名空間中執行系統容器。這些容器也會使用叢集資源。

解析度

請嘗試下列解決方法：

• 在 spec: containers: resources: requests 欄位中指定較低的值，即可調整 Pod 的資源要求。預設的 CPU 要求為 100m 或 CPU (或一個核心) 的 10%。

• 建立新的節點集區，內含資源充足的節點，可滿足 Pod 的要求。

• 啟用自動佈建節點功能，讓 GKE 自動建立節點集區，並在節點中執行未排程的 Pod。

錯誤：MatchNodeSelector

MatchNodeSelector 錯誤表示沒有任何符合 Pod 標籤選取器的節點。

問題

Pod 狀態或事件顯示 MatchNodeSelector 錯誤。

原因

Pod 資訊清單的 nodeSelector 欄位中指定的標籤，在叢集中的任何節點上都不存在。

解析度

如要解決這項錯誤，請確保 Pod 的 nodeSelector 欄位中指定的標籤，與叢集中至少一個節點上的標籤相符：

1. 檢查 Pod 的 spec: nodeSelector 欄位，找出 Pod 尋找的標籤需求。

2. 如要查看是否有任何標籤符合 Pod 的規定，請查看指派給叢集節點的實際標籤：

   kubectl get nodes --show-labels
   

3. 如果節點要執行這個 Pod，請附加必要的標籤：

   kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE
   

   更改下列內容：

   • NODE_NAME：要新增標籤的節點。
   • LABEL_KEY：標籤的鍵。
   • LABEL_VALUE：標籤的值。

詳情請參閱 Kubernetes 說明文件的「將 Pod 指派給節點」一節。

錯誤：PodToleratesNodeTaints

PodToleratesNodeTaints 錯誤表示 Pod 無法排入任何節點，因為 Pod 沒有對應現有節點 taint 的容許條件。

問題

Pod 狀態或事件顯示 PodToleratesNodeTaints 錯誤。

原因

Pod 沒有對應現有節點 taint 的容忍度，因此無法排入任何節點。

解析度

1. 檢查節點上的汙點：

   kubectl describe nodes NODE_NAME
   

   在輸出結果中，檢查 Taints 欄位。這個欄位會列出鍵/值組合和排程效果。若排程效果為「NoSchedule」，表示除非 Pod 有相對應的容許條件，否則系統將無法在該節點上排程任何 Pod。

2. 從節點中移除汙點。舉例來說，如要移除 NoSchedule 汙點，請執行下列指令：

   kubectl taint nodes NODE_NAME key:NoSchedule-
   

錯誤：PodFitsHostPorts

PodFitsHostPorts 錯誤表示節點嘗試使用的通訊埠已在使用中。

問題

Pod 狀態顯示 PodFitsHostPorts 錯誤。

原因

Pod 要求的主機通訊埠已由目標節點上的其他 Pod 或程序使用。

解析度

如要解決這個問題，請考慮遵循 Kubernetes 最佳做法，並使用 NodePort Service，而非 hostPort 設定。

如果必須使用主機通訊埠，請檢查 Pod 的資訊清單，並確保相同節點上的所有 Pod 都為 hostPort 設定定義了專屬值。

錯誤：未達最低可用性

如果節點有足夠的資源，但無法用於排程，就可能發生這個錯誤。

問題

• 您看到 Does not have minimum availability 錯誤。

• 節點狀態會顯示 SchedulingDisabled 狀態或 Cordoned 狀態。

原因

節點的封鎖狀態會阻止系統將新 Pod 排程至該節點。

解析度

如要讓節點再次可供排定 Pod，請取消封鎖：

控制台

請執行下列步驟：

1. 前往 Google Cloud 控制台的「Google Kubernetes Engine」頁面。

   前往「Google Kubernetes Engine」

2. 選取要調查的叢集。「節點」分頁標籤會顯示節點及其狀態。

如要在節點上啟用排程，請執行下列步驟：

1. 在清單中，按一下要調查的節點。

2. 在「節點詳細資料」部分，按一下「取消限制」。

kubectl

如要取得節點的狀態，請執行下列指令：

kubectl get nodes

如要在節點上啟用排程，請執行下列指令：

kubectl uncordon NODE_NAME

錯誤：已達每個節點的 Pod 數上限

Too many pods 錯誤表示 Pod 無法排程，因為目標節點已達到設定的 Pod 容量上限。

問題

• Pod 處於 Unschedulable 狀態。
• 畫面上顯示包含「Too many pods」的訊息。

原因

叢集中所有節點都已達到「每個節點的 Pod 數上限」。

解析度

如要解決這項錯誤，請完成下列步驟：

1. 在 Google Cloud 控制台的 GKE 叢集詳細資料中，查看「Nodes」(節點) 分頁的 Maximum pods per node 設定。

2. 取得節點清單：

   kubectl get nodes
   

3. 針對每個節點，確認節點上執行的 Pod 數量：

   kubectl get pods -o wide | grep NODE_NAME | wc -l
   

4. 如果達到上限，請新增節點集區，或在現有節點集區中新增節點。

問題：啟用叢集自動調度器後，節點集區大小達到上限

如果節點集區已達到叢集自動調度資源設定的大小上限，就會發生這項問題。

問題

GKE 不會為原本會排定使用這個節點集區的 Pod 觸發擴充作業。Pod 會改為停留在 Pending 狀態。

原因

節點集區已達到大小上限，這是根據叢集自動調度資源設定而定。

解析度

變更叢集自動調度資源設定，調升節點集區的大小上限。

問題：停用叢集自動調度器後，節點集區大小達到上限

如果節點集區已達上限，且叢集自動調度器已停用，就會發生這個問題。

問題

GKE 無法使用節點集區排定 Pod。

原因

節點集區的節點數量已達上限，且叢集自動調度程式已停用。

解析度

如要解決這個問題，請嘗試下列其中一種方法：

• 增加節點集區的大小。
• 啟用叢集自動配置器，自動調整叢集大小。

錯誤：未繫結的 PersistentVolumeClaim

Unbound PersistentVolumeClaims 錯誤表示 Pod 參照的 PersistentVolumeClaim 未繫結。

問題

Pod 狀態或事件顯示 Unbound PersistentVolumeClaims 錯誤。

原因

發生這項錯誤的原因如下：

• 您的 PersistentVolume 佈建失敗。
• 手動預先佈建 PersistentVolume 並繫結至 PersistentVolumeClaim 時，發生設定錯誤。

解析度

1. 取得 PersistentVolumeClaim 的事件，確認佈建是否失敗：

   kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0
   

   更改下列內容：

   • STATEFULSET_NAME：StatefulSet 物件的名稱。
   • PVC_NAME：PersistentVolumeClaim 物件的名稱。

2. 再次嘗試預先佈建磁碟區。

錯誤：配額不足

如果 GKE 嘗試擴充叢集來排定 Pod，但遇到配額限制，擴充作業就會失敗。

問題

Pod 的事件中顯示 scale.up.error.quota.exceeded 錯誤訊息。

原因

擴大叢集會超出專案的可用配額。

解析度

確認專案的 Compute Engine 配額充足，可供 GKE 擴充叢集。詳情請參閱「ScaleUp 錯誤」。

問題：已淘汰的 API

如果資訊清單中使用的 API 已不受支援，工作負載可能無法部署。

問題

由於使用已淘汰的 API，工作負載無法部署或執行。

原因

您的資訊清單使用已淘汰的 API，這些 API 會在叢集的小版本中移除。

解析度

確認您未使用已淘汰的 API。更新資訊清單，改用支援的 API。詳情請參閱「功能和 API 淘汰」。

錯誤：沒有可用的連接埠，無法提供要求的 Pod 連接埠

將 Pod 繫結至主機通訊埠會限制 GKE 可排程 Pod 的位置，因為每個 hostIP 位址、hostPort 設定和protocol 值組合都不得重複。

問題

您會看到類似以下的錯誤：

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

原因

同一節點上的多個 Pod 指定了 hostPort 欄位中定義的相同值。

解析度

如要解決這個問題，請嘗試下列其中一種方法：

• 請遵循 Kubernetes 最佳做法，並使用 NodePort Service，而非主機連接埠。
• 如果必須使用主機通訊埠，請檢查 Pod 的資訊清單，並確保相同節點上的所有 Pod 都為 hostPort 欄位定義了專屬值。

問題：Pod 中的應用程式和探針失敗

如果您執行的應用程式使用 HTTPS 與伺服器通訊，就會發生這個問題。

問題

這類應用程式的故障情形如下：

• Pod 無法啟動，且容器會因結束代碼 137 而當機。

• 有效性或就緒探測失敗，並顯示類似下列內容的錯誤訊息：

  probeResult="failure" output="Get "https://example.com/healthy": EOF"
  

• Pod 可正常執行，但應用程式記錄顯示連線失敗。

原因

Kubernetes 1.30 以上版本使用的 Golang 版本會停用下列 TLS 密碼編譯套件：

• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA

解析度

使用傳輸層安全標準 (TLS) 1.2 以上版本支援的加密套件。

後續步驟

• 如果無法在文件中找到問題的解決方案，請參閱「取得支援」一文，瞭解如何取得進一步協助， 包括下列主題的建議：

  • 與 Cloud 客戶服務聯絡，建立支援案件。
  • 在 StackOverflow 上提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。你也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
  • 使用公開 Issue Tracker 開啟問題或功能要求。