Kubernetes 部署錯誤常見，多因配置或資源。文章詳解 10 常見錯誤與故障排除，并強調(diào)自動化、資源限制及可觀測性，旨在預防問題。

譯自：Top 10 Kubernetes Deployment Errors: Causes and Fixes (And Tips)^[1]

作者：Sunny Yadav

當您的 Kubernetes^[2] 部署失敗時，可能會感覺像大海撈針。一個小小的錯誤——一個字段缺失、鏡像名稱拼寫錯誤或內(nèi)存不足——都可能使一切停滯。您可能會驚訝地發(fā)現(xiàn)，配置錯誤是高達 80% 的 Kubernetes 安全和穩(wěn)定性問題的根本原因。

了解 Kubernetes 部署錯誤發(fā)生的原因以及如何準確地排除故障。無論您是處理 CrashLoopBackOff、卡住的 Pod 還是 YAML 問題，我們都將深入探討 10 個常見問題，并提供簡單的方法來在未來預防它們。

接下來

? Kubernetes 部署錯誤為何發(fā)生：3 個主要原因

? 10 大 Kubernetes 部署錯誤及其故障排除方法

? 通用故障排除框架

? 預防未來錯誤的專業(yè)技巧

? 總結(jié)：在 Kubernetes 部署問題發(fā)生前做好準備

Kubernetes 部署錯誤為何發(fā)生：3 個主要原因

Kubernetes 幫助您在容器^[3]中運行應用程序，但即使是設置中的小錯誤也可能導致大問題。大多數(shù)問題發(fā)生是因為配置不正確或您的集群沒有足夠的資源。讓我們看看部署失敗的幾個常見原因。

聲明式配置出錯

Kubernetes 使用 YAML 文件^[4]來定義您的應用程序應有的樣子。這被稱為聲明式配置。但如果該文件中有哪怕一個小錯誤——例如拼寫錯誤、錯誤的縮進或字段缺失——您的應用程序?qū)o法正確部署。

此外，有時文件是有效的 YAML 但對 Kubernetes 無效。例如，您可能忘記設置副本數(shù)量或指向尚不存在的服務。這些小錯誤可能難以發(fā)現(xiàn)，但一旦發(fā)現(xiàn)就容易修復。

鏡像和資源限制

您的容器鏡像就是 Kubernetes 運行的應用程序。如果鏡像名稱錯誤或鏡像未推送到注冊表，Kubernetes 就無法拉取它，您的應用程序也無法啟動。另一個常見問題是沒有為您的 Pod^[5] 設置足夠的 CPU 或內(nèi)存。如果 Pod 請求的資源多于可用資源，Kubernetes 可能會延遲它或使其處于“Pending”狀態(tài)。

節(jié)點和集群級別問題

有時問題不在于您的應用程序——而在于集群本身。如果節(jié)點已滿、離線或出現(xiàn)問題，您的應用程序可能沒有地方運行。集群的網(wǎng)絡或存儲設置也可能存在問題。例如，Pod 可能無法連接到其他服務，或者如果存儲不可用，它可能會崩潰。

10 大 Kubernetes 部署錯誤及其故障排除方法

當 Kubernetes 部署^[6]出現(xiàn)問題時，一開始可能會感到困惑。但許多錯誤是常見的，并且有明確的原因。以下是您可能會遇到的 10 個最常見的錯誤以及如何修復它們。

1. CrashLoopBackOff

此錯誤意味著 Pod 啟動后立即崩潰，然后反復嘗試重新啟動。這通常發(fā)生在容器內(nèi)的應用程序啟動后立即失敗時。

故障排除方法：

? 運行 kubectl logs 查看應用程序崩潰的原因。

? 檢查您的啟動命令或環(huán)境變量。

? 確保任何所需的文件、服務或依賴項都可用。

2. ImagePullBackOff / ErrImagePull

當 Kubernetes 無法下載您的容器鏡像時，會顯示這些錯誤。這可能是因為鏡像名稱錯誤、注冊表需要登錄或鏡像不存在。

故障排除方法：

? 檢查 YAML 文件中的鏡像名稱和標簽。

? 確保鏡像已推送到容器注冊表。

? 如果是私有注冊表，請?zhí)砑佑行У溺R像拉取密鑰。

3. OOMKilled

OOM 代表內(nèi)存不足（out of memory）。此錯誤意味著您的容器使用的內(nèi)存超出允許范圍，并被系統(tǒng)終止。

故障排除方法：

? 增加部署文件中的內(nèi)存限制。

? 優(yōu)化您的應用程序以減少內(nèi)存使用。

? 使用 kubectl describe pod 檢查內(nèi)存限制和使用情況。

4. CreateContainerConfigError

此錯誤意味著 Pod 設置中的某些內(nèi)容有誤。這可能是一個錯誤的 Secret、ConfigMap 或 Volume。

故障排除方法：

? 使用 kubectl describe pod 查看詳細錯誤消息。

? 檢查 Secret、ConfigMap 或 Volume 是否在 YAML^[7] 中被引用。

? 確保路徑和鍵是正確的。

5. NodeNotReady

此錯誤意味著集群中的節(jié)點不可用于運行 Pod。它可能已關閉或斷開連接。

故障排除方法：

? 使用 kubectl get nodes 檢查節(jié)點狀態(tài)。

? 查看 kubectl describe node 獲取更多信息。

? 根據(jù)問題重啟或修復節(jié)點。

6. Pod Stuck in Pending

處于“Pending”狀態(tài)的 Pod 尚未啟動。這通常意味著資源不足（CPU 或內(nèi)存）或卷不可用。

故障排除方法：

? 運行 kubectl describe pod 找出它處于 Pending 狀態(tài)的原因。

? 檢查您的集群是否有足夠的可用資源。

? 確保存儲卷或節(jié)點選擇器是正確的。

7. FailedScheduling

此錯誤意味著 Kubernetes 找不到符合您的 Pod 要求的節(jié)點。這通常與資源限制或調(diào)度規(guī)則有關。

故障排除方法：

? 使用 kubectl describe pod 查看調(diào)度詳情。

? 減少 Pod 規(guī)格中的 CPU 或內(nèi)存請求。

? 檢查您是否使用了可能阻止調(diào)度的任何節(jié)點選擇器或污點。

8. ContainerCannotRun

這意味著容器根本未能啟動。這可能是因為入口點命令錯誤或容器沒有所需的權(quán)限。

故障排除方法：

? 使用 kubectl logs 或 describe pod 查看錯誤。

? 確保 YAML 中的命令和參數(shù)是正確的。

? 檢查是否存在文件缺失、權(quán)限損壞或所需的訪問權(quán)限。

9. Exit Code 1 / 125

這些退出代碼表示您的應用程序在啟動后立即失敗。代碼 1 通常表示一般錯誤。代碼 125 可能意味著容器命令在應用程序運行之前就失敗了。

故障排除方法：

? 使用 kubectl logs 查看錯誤輸出。

? 仔細檢查您的入口命令、環(huán)境變量和依賴項。

? 嘗試使用 docker run 在本地運行鏡像進行測試。

10. Pods in Init / Waiting Loop

有時 Pod 會長時間停留在“Init”或“Waiting”狀態(tài)。這發(fā)生在 Init 容器或主容器無法正常啟動時。

故障排除方法：

? 使用 kubectl describe pod 檢查是什么阻礙了進程。

? 確保 Init 容器成功完成。

? 檢查鏡像名稱、卷掛載和啟動腳本。

通用故障排除框架

當 Kubernetes 出現(xiàn)問題時，遵循按部就班的方法會有所幫助。不要猜測，而是使用 Kubernetes 內(nèi)置的工具來找出發(fā)生了什么。

這是一個簡單的框架，可以指導您進行故障排除：

從 kubectl describe 開始

kubectl describe 命令提供了 Pod、節(jié)點或其他資源正在發(fā)生的事情的完整細分。它顯示了當前狀態(tài)、任何錯誤消息和相關事件。這應該是您獲取問題線索的第一站。

檢查事件和日志

事件告訴您 Kubernetes 一直在嘗試做什么，例如調(diào)度 Pod 或拉取鏡像。日志顯示您的應用程序或容器實際在做什么。使用 kubectl get events 獲取全局視圖，使用 kubectl logs 查看容器內(nèi)部。

使用試運行 (Dry Run) 驗證 YAML

YAML 文件中的小拼寫錯誤或錯誤的格式可能會導致大問題。在應用配置之前，使用 kubectl apply –dry-run=client -f .yaml 來檢查您的配置。這有助于在不更改集群任何內(nèi)容的情況下盡早發(fā)現(xiàn)錯誤。

監(jiān)控資源使用情況

使用 kubectl top 或指標儀表板等工具檢查您的 Pod 正在使用的 CPU 和內(nèi)存^[8]量。如果 Pod 沒有足夠的資源——或者請求過多——它們可能會崩潰、卡住或被系統(tǒng)終止。

使用探針和健康檢查

存活探針和就緒探針幫助 Kubernetes 了解您的應用程序何時健康并準備好提供流量。如果這些探針缺失或設置不正確，Pod 可能會頻繁重啟或在準備好之前接收流量。添加適當?shù)慕】禉z查使您的應用程序更穩(wěn)定。

預防未來錯誤的專業(yè)技巧

一旦您修復了常見的 Kubernetes 問題，下一步就是阻止它們再次發(fā)生。一些聰明習慣對于保持部署順暢無憂大有裨益。

自動化靜態(tài)分析和驗證

在部署之前，使用工具檢查您的 YAML 文件是否存在錯誤。靜態(tài)分析器可以捕獲缺失的字段、錯誤的格式或無效的值。在您的 CI/CD 流水線^[9]中自動化此步驟有助于您在問題影響生產(chǎn)之前盡早發(fā)現(xiàn)它們。

YAML 靜態(tài)分析和驗證的有用工具：

? Kubeval

? kube-linter

? Datree

? kubectl –dry-run

明智地使用資源請求和限制

始終為您的容器設置 CPU 和內(nèi)存請求和限制。這有助于 Kubernetes 正確調(diào)度您的 Pod，并保護您的集群免受單個 Pod 使用過多資源的影響。但不要猜測——從小處著手，并根據(jù)實際使用情況進行調(diào)整。

設置資源請求和限制的技巧：

? 從小的默認值開始（例如，100m CPU，128Mi 內(nèi)存），并監(jiān)控使用情況。

? 使用 kubectl top pod 或指標儀表板查看實際資源消耗。

? 設置請求（最低需求）和限制（最大允許）。

? 避免將限制設置得過低，因為它可能導致您的應用程序崩潰或重啟。

實施可觀測性工具

添加工具，讓您實時查看集群中發(fā)生的事情。儀表板和監(jiān)控解決方案可以幫助您更快地發(fā)現(xiàn)問題，并更容易理解整體性能。

Kubernetes 流行的可觀測性工具：

? Prometheus^[10] + Grafana

? Kube-state-metrics

? 用于日志聚合的 Loki

? 用于追蹤的 Jaeger

? Datadog、New Relic^[11] 或 Dynatrace 用于一體化監(jiān)控