調試容器化工作負載和 Pod 是每位使用 Kubernetes 的開發人員和 DevOps 工程師的日常任務。通常情況下，我們簡單地使用 kubectl logs 或者 kubectl describe pod 便足以找到問題所在，但有時候，一些問題會特別難查。這種情況下，大家可能會嘗試使用 kubectl exec，但有時候這樣也還不行，因為 Distroless 等容器甚至不允許通過 SSH 進入 shell。那么，如果以上所有方法都失敗了，我們要怎么辦？

更好的方法

其實我們只需要使用更合適的工具。如果在 Kubernetes 上調試工作負載，那么合適的工具就是 kubectl debug。這是不久前添加的一個新命令（v1.18），允許調試正在運行的 pod。它會將名為 EphemeralContainer（臨時容器）的特殊容器注入到問題 Pod 中，讓我們查看并排除故障。kubectl debug 看起來非常不錯，但要使用它需要臨時容器，臨時容器到底是什么？

臨時容器其實是 Pod 中的子資源，類似普通 container。但與普通容器不同的是，臨時容器不用于構建應用程序，而是用于檢查。我們不會在創建 Pod 時定義它們，而使用特殊的 API 將其注入到運的行 Pod 中，來運行命令并檢查 Pod 環境。除了這些不同，臨時容器還缺少一些基本容器的字段，例如 ports、resources。

那么我們為什么不直接使用基本容器？這是因為我們不能向 Pod 添加基本容器，它們應該是一次性的（需要隨時刪除或重新創建），這會導致難以重現問題 Pod 的錯誤，排除故障也會很麻煩。這就是將臨時容器添加到 API 的原因——它們允許我們將臨時容器添加到現有 Pod，從而檢查正在運行的 Pod。

雖然臨時容器是作為 Kubernetes 核心的 Pod 規范的一部分，但很多人可能還沒有聽說過。這是因為臨時容器處于早期 Alpha 階段，這意味著默認情況下不啟用。Alpha 階段的資源和功能可能會出現重大變化，或者在 Kubernetes 的某個未來版本中被完全刪除。因此，要使用它們必須在 kubelet 中使用Feature Gate（功能門）顯式啟用。

Configuring Feature Gates

現在如果確定要試用 kubectl debug，那么如何啟用臨時容器的功能門？這取決于集群設置。例如，現在使用kubeadm啟動創建集群，那么可以使用以下集群配置來啟用臨時容器：

在以下示例中，為了簡單和測試目的，我們使用 KinD（Docker 中的 Kubernetes）集群，這允許我們指定要啟用的功能門。創建我們的測試集群：
隨著集群的運行，我們需要驗證其有效性。最簡單方法是檢查 Pod API，它現在應該包含臨時容器部分以及通常容器：

現在都有了，可以開始使用 kubectl debug。從簡單的例子開始：

我們首先啟動一個名為 some-app 的 Pod 來進行“調試”。然后針對這個 Pod 運行 kubectl debug，指定 busybox 為臨時容器的鏡像，并作為原始容器的目標。此外，還需要包括 -it 參數，以便我們立即附加到容器獲得 shell 會話。

在上面的代碼中可以看到，如果我們在 Pod 上運行 kubectl debug 后對其進行描述，那么它的描述將包括具有之前指定為命令選項值的臨時容器部分。

Process Namespace Sharing

kubectl debug 是非常強大的工具，但有時向 Pod 添加一個容器還不足以獲取 Pod 的另一個容器中運行的應用程序相關信息。當故障容器不包括必要的調試工具甚至 shell 時，可能就是這種情況。在這種情況下，我們可以使用 Process Sharing（進程共享）來使用注入的臨時容器檢查 Pod 的原有容器。

進程共享的一個問題是它不能應用于現有的 Pod，因此我們必須創建一個新 Pod，將其 spec.shareProcessNamespace 設置為 true，并將一個臨時容器注入其中。這樣有點麻煩，尤其是需要調試多個 Pod 或容器，亦或者需要重復執行該操作時。幸運的是，kubectl debug 可以使用 --share-processes 做到：

上面的代碼表明，通過進程共享，我們可以看到 Pod 中另一個容器內的所有內容，包括其進程和文件，這對于調試來說非常方便。另外，除了 --share-processes 還包括了 --copy-to=new-pod-name，這是因為我們需要創建一個新的 Pod，其名稱由該 flag 指定。如果我們從另一個終端列出正在運行的 Pod，我們將看到以下內容：

這就是我們在原始應用程序 Pod 上的新調試 Pod。與原始容器相比，它有 2 個容器，因為它還包括臨時容器。此外，如果想在任何時候驗證 Pod 中是否允許進程共享，那么可以運行：

好好使用

既然我們已經啟用了功能并且知道命令是如何工作的，那就試著使用它并調試一些應用程序。想象這樣一個場景——我們有一個問題應用程序，我們需要在它的容器中對網絡相關的問題進行故障排除。該應用程序沒有我們可以使用的必要的網絡 CLI 工具。為了解決這個問題，我們通過以下方式使用 kubectl debug：

在啟動一個 Pod 之后，我們首先嘗試將 shell 會話放入它的容器中，這看起來有效，但是實際上我們嘗試運行一些基本命令時，將看到那里什么都沒有。所以，我們要使用 praqma/network-multitool 將臨時容器注入到 Pod 中，該鏡像包含了 curl、ping、telnet 等工具，現在我們可以進行所有必要的故障排除。

在上面的例子中，我們進入 Pod 的另一個容器中就足夠了。但有時可能需要直接查看有問題的容器。這種情況下，我們可以像這樣使用進程共享：

在這里，我們再次運行使用 Distroless 鏡像的容器。我們無法在它的 shell 中做任何事情。我們運行 kubectl debug 以及 --share-processes --copy-to=...，它創建了一個新的 Pod，帶有額外的臨時容器，可以訪問所有進程。當我們列出正在運行的進程時，能看到應用程序容器的進程有 PID 8，可以用它來探索文件和環境。為此，我們需要通過 /proc//... 目錄，這個例子中是 /proc/8/root/app/...

另一種常見情況是應用程序在容器啟動時不斷崩潰，這讓調試非常困難，因為沒有足夠的時間將 shell 會話導入容器并運行故障排除命令。在這種情況下，解決方案是創建具有不同入口點、命令的容器，這可以阻止應用程序立即崩潰并允許我們調試：

調試集群節點

本文主要關注 Pod 及其容器的調試，但任何集群管理員都知道常常需要調試的是節點而不是 Pod。幸運的是，kubectl debug 允許通過創建 Pod 來調試節點，該 Pod 將在指定節點上運行，節點的根文件系統安裝在 /root 目錄中。我們甚至可以用 chroot 訪問主機二進制文件，這本質上充當了節點的 SSH 連接：

在上面的代碼中，我們首先確定了想要調試的節點，然后使用 node/... 作為參數顯式運行 kubectl debug 以訪問我們集群的節點。在那之后，當連接到Pod后，我們使用 chroot /host 突破 chroot，并完全進入主機。最后，為了驗證是否真的可以看到主機上的所有內容，我們了查看一部分的 kubeadm.conf，最終看到我們在文章開頭配置的內容 feature-gates: EphemeralContainers=true。

小結

能夠快速有效地調試應用程序和服務可以節省大量時間，但更重要的是，它能極大地幫助解決那些如果不立即解決可能最終會花費大量資金的問題。這就是為什么 kubectl debug 之類的工具能隨意使用非常重要，即使它們尚未正式發布或默認啟用。如果啟用臨時容器不是一種選擇，那么嘗試替代調試方法可能是一個好主意，例如使用包含故障排除工具的應用程序鏡像的調試版本；或臨時更改 Pod 的容器命令以阻止其崩潰。

原文鏈接：https://towardsdatascience.com/the-easiest-way-to-debug-kubernetes-workloads-ff2ff5e3cc75

文章轉載：?K8S中文社區
（版權歸原作者所有，侵刪）