使用 kubectl exec 執行指令

如果您在 Kubernetes 上運行軟件，您會想要在某些時候去調試您所部署的軟件的一些方面。對于習慣于使用虛擬機 (VMs) 的人來說能自然使用的一種簡單的調試方法，就是連接到一個正在運行的 pod，然后進行解譯:

kubectl exec -it podname -c containername -- bash

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

不以 root 用戶身份運行。容器盡可能以最少的特權運行，甚至可能使用隨機的用戶標識符 (UID) 運行。

最小化鏡像。鏡像盡可能小，你甚至可以將二進制文件寫入到 distroless image。

當應用這些最佳實踐時，使用kubectl exec連接到您的容器要么不可行，要么進入到不適合進行調試的環境。

kubectl exec 指令不允許指定用戶標志或能力以啟動進程，而是會從目標容器的主指令中復制這些設置。

調試容器

在解決運行容器問題時，Kubernetes 提供了一種原生化調試策略，即使用kubectl debug。調試指令會在運行中的 pod 中啟動一個新的容器。這個新容器能夠以不同的用戶身份以及從您選擇的任何鏡像去運行。由于調試容器與目標容器位于同一個 pod 中運行(因此在同一個節點上)，兩者之間不需要絕對的隔離。調試容器可以與同一 pod 中運行的其他容器共享系統資源。

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

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

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

如果希望調試容器與postcont共享相同的進程命名空間，即使postcont是在postpod中運行的唯一容器，指定--target是不具備選擇性的 (non-optional)。

您可以按 CTRL+P CTRL+D 斷開與臨時容器/bash 會話 (session) 的連接，而無需退出 (終止) 它。再使用kubectl attach即可重新連接。

kubectl debug提供的功能比這里概述的更多，比如使用一個修改后的啟動指令復制 pods，或通過訪問節點文件系統的啟動一個 "節點 (node) " pod。

原理解釋

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

Pod 應該是一次性的、可替換的，并且 Pod 規范也是不可改變的。

當 Kubernetes 主要用于部署無狀態工作負載時，這一點更加合理——因為此時 pod 本身會被認為是臨時的。在這個 Kubernetes 中它可能會受到限制。Pod 規范保持不變，但 Kubernetes 會將臨時容器作為 Pod 的子資源建模。與“普通”容器不同，臨時容器不屬于 Pod 規范的一部分。

掛載卷 (volumes)

內置指令kubectl debug非常有用。它允許您在運行的 pod 中添加一個臨時容器，并可選擇與運行中的容器共享進程命名空間。不過，如果您希望使用kubectl debug來檢查或修改運行中容器文件系統的某個部分，那就不走運了——因為調試 pod 的文件系統與您將其連接到的容器的文件系統是分離的。幸運的是，我們可以做的更好。原理很簡單:

讀取正在運行的目標容器的規范。

將一個臨時容器填充到 pod 中。將其配置成與目標容器共享相同的進程命名空間，并包含相同的卷掛載。

因為沒有用于創建臨時容器的 kubectl 命令，所以我們需要構建一個 PATCH 請求到 K8s API 來創建它。kubectl proxy指令允許訪問 K8s API。這一過程對用戶來說并不太友好，因此將這一過程封裝到腳本或 kubectl 插件中是合理的。您可以在這里找到這樣一個腳本實現示例:

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

需要注意的是，這種方法和腳本可以很容易地擴展到從目標容器中復制環境變量的規范。如果您將此腳本保存為kubectl-superdebug，并將其放在您的路徑上，就可以在任何地方以kubectl superdebug的形式運行，如下所示:

還可以嘗試擴展此腳本，將目標容器的其他方面復制到調試容器中，例如環境變量引用。

至此，Kubernetes 本機調試運行中的容器的方法概述就完成了，應該能滿足大多數人的需求。

非 Kubernetes 原生方法

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

如果您使用的是 Docker 引擎，并且可以直接從節點或通過節點上運行的特權容器訪問您的引擎，那么您就可以運行docker exec --user，并以您選擇的用戶身份執行一個進程。

kubectl ssh和kubectl exec-user等插件實現了這種方法。但遺憾的是，containerd 和 CRI-O 等現代引擎不再提供--user這樣標志功能，這意味著這些插件無法在當下的 Kubernetes 安裝上運行。

不過，即使是這些現代引擎，通常也只是與 Linux 命名空間接口。通過輸入相應的 Linux 命名空間集，您可以在任何您想要的“容器”中運行指令。kpexec 工具實現了這種方法。它在與目標容器相同的節點上啟動一個有權限的 pod，然后確定要針對哪些 (Linux) 命名空間，在這些 (Linux) 命名 空間中執行命令，最后將其輸出流式傳輸到您的終端。作為額外的收獲，它還能在目標容器的文 件系統之上疊加一套用于調試的工具。

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

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

借助 Appilot 對話式診斷 K8s

Appilot 是一款面向 DevOps 場景的開源 AI 助手，它可以充分利用 AI 大語言模型的能力讓用戶直接輸入自然語言進一步簡化應用部署與管理體驗。用戶可以根據自身的需求和使用習慣，將 Appilot 集成到任意平臺，進而實現通過輸入自然語言即可調用后端平臺的能力，輕松完成 Kubernetes debug 工作。