譯者 | 晶顏

審校 | 重樓

隨著Kubernetes不斷革新我們管理和部署應用程序的方式，理解它的復雜性對開發人員和運營團隊都變得至關重要。如果您沒有一個專門的DevOps團隊，在使用Kubernetes的過程中可能很容易陷入誤區。

本指南探討了常見的Kubernetes錯誤，并提供了故障排除技巧，以幫助開發人員在容器編排的復雜環境中避坑。

1.識別配置問題

當您在Kubernetes中遇到配置問題時，首先要使用“kubectl get pods”命令檢查狀態列。這里會顯示一些常見的錯誤，然后，您需要使用“kubectl description pod”進行進一步檢查。

常見原因及解決方法

1）資源不足（注意，這里指POD本身的資源，而不是容器內的資源。這意味著硬件或周圍的VM達到了極限）

• 癥狀描述：資源限制導致Pod無法調度。
• 解決方案：通過添加更多節點來擴展集群以滿足資源需求。

2）卷掛載失敗

• 癥狀描述：Pod無法正常掛載卷。
• 解決方案：確保Pod規范中準確定義了存儲，并檢查存儲類和持久卷（Persistent Volume，PV）配置。

詳細調查步驟

我們可以使用kubectl describe pod：該命令提供Pod的詳細描述，包括已發生的事件。通過檢查這些事件，我們可以查明問題的確切原因。

另一個重要步驟是資源配額分析。有時，資源約束是由于名稱空間級別的資源配額造成的。使用“kubectl get resourcequotas”來檢查配額是否限制了Pod的創建。

2.處理映像提取錯誤

ErrImagePull或Imagepulbackoff之類的錯誤表示獲取容器映像的問題。這些錯誤通常與映像可用性或訪問權限有關。

故障排除步驟

第一步是檢查映像名稱，我們可以使用以下命令：

docker pull <image-name>

然后，我們需要驗證圖像名稱是否有拼寫錯誤或無效字符。我們可以通過grep對命令進行管道輸入，以驗證名稱是否100%相同，有些拼寫錯誤非常難以發現。

憑據也可能是一個主要的陷阱。例如，從私有存儲庫中提取映像時授權失敗。我們必須確保在Kubernetes secrets中正確配置了Docker注冊憑據。

還應該檢查網絡配置。確保Kubernetes節點能夠通過網絡訪問Docker注冊表。網絡策略或防火墻規則可能會阻止訪問。

還有一些額外的陷阱，比如圖像標記的問題。確保您使用了正確的圖像標簽。請注意，最新標簽可能并不總是指向預期的圖像版本。

如果您使用的是私有注冊表，則可能會遇到訪問問題。確保您的憑據是最新的，并且可以從所有區域的所有節點訪問注冊中心。

3.處理節點問題

與節點相關的錯誤通常指向物理或虛擬機問題。這些問題可能會中斷Kubernetes集群的正常運行，需要及時注意。

我們可以使用下述命令查詢節點狀態：

kubectl get nodes

然后，我們可以在結果輸出中識別出有問題的節點。但有時重新啟動節點是解決某些問題的優選方案。我們可以重新啟動受影響的機器或虛擬機。Kubernetes應該嘗試“自我修復”并在幾分鐘內恢復。

為了調查節點的情況，我們可以使用下面的命令：

kubectl describe node <node-name>

我們還應該查找MemoryPressure、DiskPressure或NetworkUnavailable等條件。這些條件為我們應該在節點中解決的潛在問題提供了線索。

預防措施

節點監控應該與Prometheus和Grafana等工具一起使用，以監視節點的運行狀況和性能。它們可以很好地解決與Kubernetes相關的低級問題，我們也可以使用它們來解決高級應用程序問題。

我們還可以利用一些自動修復工具（如Kubernetes Cluster Autoscaler）來根據工作負載需求自動管理集群中的節點數量。需要注意的是，如此一來所導致的級聯失敗可能會觸發額外的資源消耗。

4.管理丟失的配置密鑰或秘密

丟失配置密鑰或秘密是破壞Kubernetes部署的常見問題。妥善管理這些因素對順利運作至關重要。

我們需要使用ConfigMaps和secrets。這讓我們可以安全地存儲配置值和敏感信息。為了避免這種情況，我們需要確保ConfigMaps和Secrets在您的Pod規范中被正確引用。

我們可以使用下述命令檢查Pod描述：

kubectl describe pod <pod-name>

該命令能夠檢查輸出并查找丟失的配置細節，以糾正任何錯誤配置。

ConfigMap和secret的創建可以通過下面的命令來驗證：

kubectl get configmaps

以及：

kubectl get secrets

確保所需的ConfigMaps和Secrets存在于名稱空間中，并包含預期的數據。最好將ConfigMaps的非敏感部分保留在版本控制中，同時出于安全考慮排除秘密。此外，您應該為不同的環境（開發、生產）使用不同的Configmap和Secrets，以避免配置泄漏。

5.利用Buildg進行交互式調試

Buildg是一個相對較新的工具，它通過允許交互式調試來增強Docker配置的調試過程。

它以類似于標準調試的方式為配置問題提供交互式調試。它允許我們逐步執行Dockerfile的各個階段并設置斷點。Buildg通過調試適配器協議（Debug Adapter Protocol，DAP）與VSCode和其他IDE兼容。

Buildg允許我們在構建過程的每個階段檢查容器狀態，以便及早發現問題。

您可以按照Buildg GitHub頁面上的說明安裝build。

結語

調試Kubernetes極具挑戰性，但有了正確的知識和工具，開發人員可以有效地識別和解決常見問題。通過了解配置問題、映像提取錯誤、節點問題以及ConfigMaps和secrets的重要性，開發人員可以為更健壯、更可靠的Kubernetes部署做出貢獻。像build這樣的工具在交互式調試方面提供了有效支持，進一步彌合了開發和操作之間的差距。

隨著Kubernetes的不斷發展，了解新工具和最佳實踐對于成功的應用程序管理和部署至關重要。通過主動解決這些常見問題，開發人員可以確保Kubernetes運行更順暢、更高效，最終實現更具彈性和可擴展性的應用程序。

原文鏈接：

原文標題：Common Kubernetes Errors and How to Fix Them，作者：Shai Almog