調試 Kubernetes 最簡單方法

調試容器化工作負載和 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（功能門）顯式啟用。

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

在以下示例中，為了簡單和測試目的，我們使用 KinD（Docker 中的 Kubernetes）叢集，這允許我們指定要啟用的功能門。建立我們的測試叢集：

随着叢集的運作，我們需要驗證其有效性。最簡單方法是檢查 Pod API，它現在應該包含臨時容器部分以及通常容器：

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

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

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

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/<PID>/... 目錄，這個例子中是 /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

（版權歸原作者所有，侵删）