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

更好的方法

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

臨時(shí)容器其實(shí)是 Pod 中的子資源，類(lèi)似普通 container。但與普通容器不同的是，臨時(shí)容器不用于構(gòu)建應(yīng)用程序，而是用于檢查。我們不會(huì)在創(chuàng)建 Pod 時(shí)定義它們，而使用特殊的 API 將其注入到運(yùn)的行 Pod 中，來(lái)運(yùn)行命令并檢查 Pod 環(huán)境。除了這些不同，臨時(shí)容器還缺少一些基本容器的字段，例如 ports、resources。

那么我們?yōu)槭裁床恢苯邮褂没救萜?？這是因?yàn)槲覀儾荒芟?Pod 添加基本容器，它們應(yīng)該是一次性的（需要隨時(shí)刪除或重新創(chuàng)建），這會(huì)導(dǎo)致難以重現(xiàn)問(wèn)題 Pod 的錯(cuò)誤，排除故障也會(huì)很麻煩。這就是將臨時(shí)容器添加到 API 的原因——它們?cè)试S我們將臨時(shí)容器添加到現(xiàn)有 Pod，從而檢查正在運(yùn)行的 Pod。

雖然臨時(shí)容器是作為 Kubernetes 核心的 Pod 規(guī)范的一部分，但很多人可能還沒(méi)有聽(tīng)說(shuō)過(guò)。這是因?yàn)榕R時(shí)容器處于早期 Alpha 階段，這意味著默認(rèn)情況下不啟用。Alpha 階段的資源和功能可能會(huì)出現(xiàn)重大變化，或者在 Kubernetes 的某個(gè)未來(lái)版本中被完全刪除。因此，要使用它們必須在 kubelet 中使用Feature Gate（功能門(mén)）顯式啟用。

Configuring Feature Gates

現(xiàn)在如果確定要試用 kubectl debug，那么如何啟用臨時(shí)容器的功能門(mén)？這取決于集群設(shè)置。例如，現(xiàn)在使用kubeadm啟動(dòng)創(chuàng)建集群，那么可以使用以下集群配置來(lái)啟用臨時(shí)容器：

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

現(xiàn)在都有了，可以開(kāi)始使用 kubectl debug。從簡(jiǎn)單的例子開(kāi)始：

我們首先啟動(dòng)一個(gè)名為 some-app 的 Pod 來(lái)進(jìn)行“調(diào)試”。然后針對(duì)這個(gè) Pod 運(yùn)行 kubectl debug，指定 busybox 為臨時(shí)容器的鏡像，并作為原始容器的目標(biāo)。此外，還需要包括 -it 參數(shù)，以便我們立即附加到容器獲得 shell 會(huì)話(huà)。

在上面的代碼中可以看到，如果我們?cè)?Pod 上運(yùn)行 kubectl debug 后對(duì)其進(jìn)行描述，那么它的描述將包括具有之前指定為命令選項(xiàng)值的臨時(shí)容器部分。

Process Namespace Sharing

kubectl debug 是非常強(qiáng)大的工具，但有時(shí)向 Pod 添加一個(gè)容器還不足以獲取 Pod 的另一個(gè)容器中運(yùn)行的應(yīng)用程序相關(guān)信息。當(dāng)故障容器不包括必要的調(diào)試工具甚至 shell 時(shí)，可能就是這種情況。在這種情況下，我們可以使用 Process Sharing（進(jìn)程共享）來(lái)使用注入的臨時(shí)容器檢查 Pod 的原有容器。

進(jìn)程共享的一個(gè)問(wèn)題是它不能應(yīng)用于現(xiàn)有的 Pod，因此我們必須創(chuàng)建一個(gè)新 Pod，將其 spec.shareProcessNamespace 設(shè)置為 true，并將一個(gè)臨時(shí)容器注入其中。這樣有點(diǎn)麻煩，尤其是需要調(diào)試多個(gè) Pod 或容器，亦或者需要重復(fù)執(zhí)行該操作時(shí)。幸運(yùn)的是，kubectl debug 可以使用 --share-processes 做到：

上面的代碼表明，通過(guò)進(jìn)程共享，我們可以看到 Pod 中另一個(gè)容器內(nèi)的所有內(nèi)容，包括其進(jìn)程和文件，這對(duì)于調(diào)試來(lái)說(shuō)非常方便。另外，除了 --share-processes 還包括了 --copy-to=new-pod-name，這是因?yàn)槲覀冃枰獎(jiǎng)?chuàng)建一個(gè)新的 Pod，其名稱(chēng)由該 flag 指定。如果我們從另一個(gè)終端列出正在運(yùn)行的 Pod，我們將看到以下內(nèi)容：

這就是我們?cè)谠紤?yīng)用程序 Pod 上的新調(diào)試 Pod。與原始容器相比，它有 2 個(gè)容器，因?yàn)樗€包括臨時(shí)容器。此外，如果想在任何時(shí)候驗(yàn)證 Pod 中是否允許進(jìn)程共享，那么可以運(yùn)行：

好好使用

既然我們已經(jīng)啟用了功能并且知道命令是如何工作的，那就試著使用它并調(diào)試一些應(yīng)用程序。想象這樣一個(gè)場(chǎng)景——我們有一個(gè)問(wèn)題應(yīng)用程序，我們需要在它的容器中對(duì)網(wǎng)絡(luò)相關(guān)的問(wèn)題進(jìn)行故障排除。該應(yīng)用程序沒(méi)有我們可以使用的必要的網(wǎng)絡(luò) CLI 工具。為了解決這個(gè)問(wèn)題，我們通過(guò)以下方式使用 kubectl debug：

在啟動(dòng)一個(gè) Pod 之后，我們首先嘗試將 shell 會(huì)話(huà)放入它的容器中，這看起來(lái)有效，但是實(shí)際上我們嘗試運(yùn)行一些基本命令時(shí)，將看到那里什么都沒(méi)有。所以，我們要使用 praqma/network-multitool 將臨時(shí)容器注入到 Pod 中，該鏡像包含了 curl、ping、telnet 等工具，現(xiàn)在我們可以進(jìn)行所有必要的故障排除。

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

在這里，我們?cè)俅芜\(yùn)行使用 Distroless 鏡像的容器。我們無(wú)法在它的 shell 中做任何事情。我們運(yùn)行 kubectl debug 以及 --share-processes --copy-to=...，它創(chuàng)建了一個(gè)新的 Pod，帶有額外的臨時(shí)容器，可以訪(fǎng)問(wèn)所有進(jìn)程。當(dāng)我們列出正在運(yùn)行的進(jìn)程時(shí)，能看到應(yīng)用程序容器的進(jìn)程有 PID 8，可以用它來(lái)探索文件和環(huán)境。為此，我們需要通過(guò) /proc//... 目錄，這個(gè)例子中是 /proc/8/root/app/...

另一種常見(jiàn)情況是應(yīng)用程序在容器啟動(dòng)時(shí)不斷崩潰，這讓調(diào)試非常困難，因?yàn)闆](méi)有足夠的時(shí)間將 shell 會(huì)話(huà)導(dǎo)入容器并運(yùn)行故障排除命令。在這種情況下，解決方案是創(chuàng)建具有不同入口點(diǎn)、命令的容器，這可以阻止應(yīng)用程序立即崩潰并允許我們調(diào)試：

調(diào)試集群節(jié)點(diǎn)

本文主要關(guān)注 Pod 及其容器的調(diào)試，但任何集群管理員都知道常常需要調(diào)試的是節(jié)點(diǎn)而不是 Pod。幸運(yùn)的是，kubectl debug 允許通過(guò)創(chuàng)建 Pod 來(lái)調(diào)試節(jié)點(diǎn)，該 Pod 將在指定節(jié)點(diǎn)上運(yùn)行，節(jié)點(diǎn)的根文件系統(tǒng)安裝在 /root 目錄中。我們甚至可以用 chroot 訪(fǎng)問(wèn)主機(jī)二進(jìn)制文件，這本質(zhì)上充當(dāng)了節(jié)點(diǎn)的 SSH 連接：

在上面的代碼中，我們首先確定了想要調(diào)試的節(jié)點(diǎn)，然后使用 node/... 作為參數(shù)顯式運(yùn)行 kubectl debug 以訪(fǎng)問(wèn)我們集群的節(jié)點(diǎn)。在那之后，當(dāng)連接到Pod后，我們使用 chroot /host 突破 chroot，并完全進(jìn)入主機(jī)。最后，為了驗(yàn)證是否真的可以看到主機(jī)上的所有內(nèi)容，我們了查看一部分的 kubeadm.conf，最終看到我們?cè)谖恼麻_(kāi)頭配置的內(nèi)容 feature-gates: EphemeralContainers=true。

小結(jié)

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

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

文章轉(zhuǎn)載：?K8S中文社區(qū)
（版權(quán)歸原作者所有，侵刪）