使用 kubectl exec 執(zhí)行指令

如果您在 Kubernetes 上運(yùn)行軟件，您會(huì)想要在某些時(shí)候去調(diào)試您所部署的軟件的一些方面。對(duì)于習(xí)慣于使用虛擬機(jī) (VMs) 的人來說能自然使用的一種簡(jiǎn)單的調(diào)試方法，就是連接到一個(gè)正在運(yùn)行的 pod，然后進(jìn)行解譯:
?

kubectl exec -it podname -c containername -- bash

?
這通常行之有效，而且非常管用。然而，至少有兩種 Kubernetes "最佳實(shí)踐 "限制了 exec 的實(shí)用性:
?

• 不以 root 用戶身份運(yùn)行。容器盡可能以最少的特權(quán)運(yùn)行，甚至可能使用隨機(jī)的用戶標(biāo)識(shí)符 (UID) 運(yùn)行。
  ?
• 最小化鏡像。鏡像盡可能小，你甚至可以將二進(jìn)制文件寫入到 distroless image。
  ?

當(dāng)應(yīng)用這些最佳實(shí)踐時(shí)，使用 kubectl exec連接到您的容器要么不可行，要么進(jìn)入到不適合進(jìn)行調(diào)試的環(huán)境。
?

kubectl exec 指令不允許指定用戶標(biāo)志或能力以啟動(dòng)進(jìn)程，而是會(huì)從目標(biāo)容器的主指令中復(fù)制這些設(shè)置。

?

調(diào)試容器

在解決運(yùn)行容器問題時(shí)，Kubernetes 提供了一種原生化調(diào)試策略，即使用 kubectl debug。調(diào)試指令會(huì)在運(yùn)行中的 pod 中啟動(dòng)一個(gè)新的容器。這個(gè)新容器能夠以不同的用戶身份以及從您選擇的任何鏡像去運(yùn)行。由于調(diào)試容器與目標(biāo)容器位于同一個(gè) pod 中運(yùn)行(因此在同一個(gè)節(jié)點(diǎn)上)，兩者之間不需要絕對(duì)的隔離。調(diào)試容器可以與同一 pod 中運(yùn)行的其他容器共享系統(tǒng)資源。
?

考慮去檢查在 pod postpod 中的容器 postcont 里運(yùn)行的 PostgreSQL 數(shù)據(jù)庫的 CPU 使用情況。這個(gè) pod 并不以 root 用戶身份運(yùn)行，并且 Postgres 鏡像沒有安裝類似 top 或 htop 的工具，也就是說，kubectl exec 指令幾乎沒有作用。您可以按照以下的指令去運(yùn)行:
?

kubectl debug -it \ 
 --container=debug-container \ 
 --image=alpine \ 
 --target=postcont \ 
 postpod

?
您將以 root 身份登錄(這是 Alpine 鏡像的默認(rèn)設(shè)置)，并可以輕松安裝您最喜歡的交互式進(jìn)程查看器 htop (apt add htop)。您與 postcont 容器共享同一個(gè)進(jìn)程命名空間，可以查看并甚至終止在此運(yùn)行的所有進(jìn)程！當(dāng)您退出進(jìn)程時(shí)，臨時(shí)容器也會(huì)終止。
?

如果希望調(diào)試容器與 postcont 共享相同的進(jìn)程命名空間，即使 postcont 是在 postpod 中運(yùn)行的唯一容器，指定 --target 是不具備選擇性的 (non-optional)。
?
您可以按 CTRL+P CTRL+D 斷開與臨時(shí)容器/bash 會(huì)話 (session) 的連接，而無需退出 (終止) 它。再使用 kubectl attach 即可重新連接。
?
kubectl debug 提供的功能比這里概述的更多，比如使用一個(gè)修改后的啟動(dòng)指令復(fù)制 pods，或通過訪問節(jié)點(diǎn)文件系統(tǒng)的啟動(dòng)一個(gè) "節(jié)點(diǎn) (node) " pod。

?

原理解釋

以上的 kubectl debug 指令是通過創(chuàng)建臨時(shí)容器 (ephemeral container) 來實(shí)現(xiàn)。這些容器應(yīng)在現(xiàn)有 pod 中臨時(shí)運(yùn)行，以支持故障排除等操作。“普通”容器和臨時(shí)容器之間的區(qū)別很小。而查看 Kubernetes 在創(chuàng)立之初所做的基礎(chǔ)架構(gòu)選擇最能讓我們理解使用臨時(shí)容器的原因:
?

Pod 應(yīng)該是一次性的、可替換的，并且 Pod 規(guī)范也是不可改變的。

?
當(dāng) Kubernetes 主要用于部署無狀態(tài)工作負(fù)載時(shí)，這一點(diǎn)更加合理——因?yàn)榇藭r(shí) pod 本身會(huì)被認(rèn)為是臨時(shí)的。在這個(gè) Kubernetes 中它可能會(huì)受到限制。Pod 規(guī)范保持不變，但 Kubernetes 會(huì)將臨時(shí)容器作為 Pod 的子資源建模。與“普通”容器不同，臨時(shí)容器不屬于 Pod 規(guī)范的一部分。

?

掛載卷 (volumes)

內(nèi)置指令 kubectl debug 非常有用。它允許您在運(yùn)行的 pod 中添加一個(gè)臨時(shí)容器，并可選擇與運(yùn)行中的容器共享進(jìn)程命名空間。不過，如果您希望使用 kubectl debug 來檢查或修改運(yùn)行中容器文件系統(tǒng)的某個(gè)部分，那就不走運(yùn)了——因?yàn)檎{(diào)試 pod 的文件系統(tǒng)與您將其連接到的容器的文件系統(tǒng)是分離的。幸運(yùn)的是，我們可以做的更好。原理很簡(jiǎn)單:
?

• 讀取正在運(yùn)行的目標(biāo)容器的規(guī)范。
  ?
• 將一個(gè)臨時(shí)容器填充到 pod 中。將其配置成與目標(biāo)容器共享相同的進(jìn)程命名空間，并包含相同的卷掛載。

?

因?yàn)闆]有用于創(chuàng)建臨時(shí)容器的 kubectl 命令，所以我們需要構(gòu)建一個(gè) PATCH 請(qǐng)求到 K8s API 來創(chuàng)建它。kubectl proxy 指令允許訪問 K8s API。這一過程對(duì)用戶來說并不太友好，因此將這一過程封裝到腳本或 kubectl 插件中是合理的。您可以在這里找到這樣一個(gè)腳本實(shí)現(xiàn)示例:
?

https://github.com/JonMerlevede/kubectl-superdebug?source=post_page-----2ba160c47ef5------

?
需要注意的是，這種方法和腳本可以很容易地?cái)U(kuò)展到從目標(biāo)容器中復(fù)制環(huán)境變量的規(guī)范。如果您將此腳本保存為 kubectl-superdebug，并將其放在您的路徑上，就可以在任何地方以 kubectl superdebug 的形式運(yùn)行，如下所示:

?
還可以嘗試擴(kuò)展此腳本，將目標(biāo)容器的其他方面復(fù)制到調(diào)試容器中，例如環(huán)境變量引用。

?

至此，Kubernetes 本機(jī)調(diào)試運(yùn)行中的容器的方法概述就完成了，應(yīng)該能滿足大多數(shù)人的需求。
?

非 Kubernetes 原生方法

Kubernetes 不提供以 root 身份連接到正在運(yùn)行的容器的方法（除非主進(jìn)程以 root 身份運(yùn)行），也不提供從另一個(gè)容器訪問容器根文件系統(tǒng)的方法。但這并不意味著這些事情不可能做到。畢竟， Kubernetes 只是一個(gè)位于容器化引擎之上的容器編排器。如果出于某種原因，確實(shí)有必要的話，您通?？梢酝ㄟ^移除抽象層來做任何您想做的事。
?

如果您使用的是 Docker 引擎，并且可以直接從節(jié)點(diǎn)或通過節(jié)點(diǎn)上運(yùn)行的特權(quán)容器訪問您的引擎，那么您就可以運(yùn)行 docker exec --user，并以您選擇的用戶身份執(zhí)行一個(gè)進(jìn)程。

?

kubectl ssh 和 kubectl exec-user 等插件實(shí)現(xiàn)了這種方法。但遺憾的是，containerd 和 CRI-O 等現(xiàn)代引擎不再提供 --user 這樣標(biāo)志功能，這意味著這些插件無法在當(dāng)下的 Kubernetes 安裝上運(yùn)行。
?

不過，即使是這些現(xiàn)代引擎，通常也只是與 Linux 命名空間接口。通過輸入相應(yīng)的 Linux 命名空間集，您可以在任何您想要的“容器”中運(yùn)行指令。kpexec 工具實(shí)現(xiàn)了這種方法。它在與目標(biāo)容器相同的節(jié)點(diǎn)上啟動(dòng)一個(gè)有權(quán)限的 pod，然后確定要針對(duì)哪些 (Linux) 命名空間，在這些 (Linux) 命名 空間中執(zhí)行命令，最后將其輸出流式傳輸?shù)侥慕K端。作為額外的收獲，它還能在目標(biāo)容器的文 件系統(tǒng)之上疊加一套用于調(diào)試的工具。

?

與 kubectl exec 不同，kpexec 可以使用不同的 uid/gid 運(yùn)行指令，甚至可以使用與容器主進(jìn)程不同的功能。它與 containerd 和 cri-o 兼容。只是 kpexec 采用的方法有些笨重和脆弱，可能與集群的安全配置不兼容。但如果 kubectl (super) 調(diào)試無法滿足您的需求，則值得考慮它。
?

需要注意，kpexec 使用 nsenter 是直接在命名空間中執(zhí)行指令的。它與無處不在的容器運(yùn)行時(shí) runc 兼容，但與 Kata Containers 等運(yùn)行時(shí)不兼容。

?

借助 Appilot 對(duì)話式診斷 K8s

Appilot 是一款面向 DevOps 場(chǎng)景的開源 AI 助手，它可以充分利用 AI 大語言模型的能力讓用戶直接輸入自然語言進(jìn)一步簡(jiǎn)化應(yīng)用部署與管理體驗(yàn)。用戶可以根據(jù)自身的需求和使用習(xí)慣，將 Appilot 集成到任意平臺(tái)，進(jìn)而實(shí)現(xiàn)通過輸入自然語言即可調(diào)用后端平臺(tái)的能力，輕松完成 Kubernetes debug 工作。
?
Appilot 項(xiàng)目地址 https://github.com/seal-io/appilot

總結(jié)

以上是生活随笔為你收集整理的K8s容器debug高级技巧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。