Kubernetes中如何使用臨時容器進行故障排查
容器及其周圍的生態系統改變了工程師部署、維護和排查工作負載故障的方式。但是，在 Kubernetes 集群上調試應用程序有時可能會很困難，因為你可能在容器中找不到所需的調試工具。
許多工程師使用基于精簡、發行版構建無發行版的基礎鏡像，其中甚至沒有包管理器或shell。甚至一些團隊使用 scratch 作為基礎鏡像，并且只添加應用程序運行所需的文件。這種常見做法的一些原因是：
- 具有較小的攻擊區域。
- 為了獲得更快的掃描性能。
- 減小了鏡像大小。
- 為了有更快的構建和更短CD/CI周期。
- 減少依賴關系。
這些精簡的基礎鏡像不包括用于對應用程序或其依賴項進行故障排查的工具。這是 Kubernetes 臨時容器功能最大用途。臨時容器允許創建包含可能需要的所有調試工具的容器鏡像。一旦需要調試，就可以將臨時容器部署到所選的正在運行的 Pod 中。
我們不能將容器添加到已部署的容器;您需要更新spec，并重新創建資源。但是，可以將臨時容器添加到現有 Pod 中，以便對線上問題進行故障排查。
本文介紹如何使用臨時容器進行Kubernetes上工作負載的問題排查。
臨時容器的配置
臨時容器與常規容器共享相同的spec。但是，某些字段被禁用，并且某些行為被更改。下面列出了一些重大變化;檢查臨時容器規范以獲取完整列表。
- 它們不會重新啟動。
- 不允許定義資源。
- 不允許使用端口。
- 不允許使用啟動、活動和就緒探測。
啟動臨時容器
首先，檢查是否啟用了臨時容器功能。
kubectl debug -it --image=busybox
如果未啟用該功能，您將看到類似下面的消息。
Defaulting debug container name to debugger-wg54p. error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").
將 EphemeralContainers=true 附加到 kubelet、kube-apiserver、kube-controller-manager、kube-proxy、kube-scheduler 參數中的--feature-gates=后, 例如：
... --feature-gates=RemoveSelfLink=false,EphemeralContainers=true ...
使用臨時容器
現在，集群支持臨時容器功能，讓我們來試試吧。要創建臨時容器，使用 kubectl 命令行工具的 debug 子命令。首先，創建一個Deployment
kubectl create deployment nginx-deployment --image=nginx
獲取需要debug的Pod的名稱
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-66b6c48dd5-frsv9 1/1 Running 6 62d
以下命令將在 pod nginx-deployment-66b6c48dd5-frsv9 中創建一個新的臨時容器。臨時容器的鏡像是busybox。-i 和 -t 參數允許我們附加到新創建的容器。
$ kubectl debug -it pods/nginx-deployment-66b6c48dd5-frsv9 --image=busybox
現在我們可以debug了
/ # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=112 time=9.797 ms 64 bytes from 8.8.8.8: seq=1 ttl=112 time=9.809 ms ^C / # nc --help BusyBox v1.34.1 (2021-11-11 01:55:05 UTC) multi-call binary. Usage: nc [OPTIONS] HOST PORT - connect nc [OPTIONS] -l -p PORT [HOST] [PORT] - listen ...
當使用 kubectl describe pod 命令時，可以看到一個新字段 "Ephemeral Containers"，此部分包含臨時容器及其屬性。
$ kubectl describe pods ... ... Ephemeral Containers: debugger-thwrn: Container ID: containerd://eec23aa9ee63d96b82970bb947b29cbacc30685bbc3418ba840dee109f871bf0 Image: busybox Image ID: docker.io/library/busybox@sha256:e7157b6d7ebbe2cce5eaa8cfe8aa4fa82d173999b9f90a9ec42e57323546c353 Port: Host Port:
與臨時容器共享進程命名空間
進程命名空間共享一直是一個很好的故障排查選項，此功能可用于臨時容器。進程命名空間共享不能應用于現有容器，因此必須創建目標容器的副本。--share-processesflag 在與 --copy-to 一起使用時，可實現進程命名空間共享。這些標志將現有的 Pod spec定義復制到新定義中，并在spec中啟用了進程命名空間共享。
$ kubectl debug -it --image=busybox --share-processes --copy-to=debug-pod
運行 ps 命令以查看正在運行的進程。正如您所期望的那樣，您可以從 busybox 容器中看到 /pause，從 nginx-deployment 容器中看到 nginx 進程。
# ps aux PID USER TIME COMMAND 1 root 0:00 /pause 6 root 0:00 nginx: master process nginx -g daemon off; 11 101 0:00 nginx: worker process 12 root 0:00 sh 17 root 0:00 ps aux
使用進程命名空間，共享容器文件系統也是可訪問的，這對于調試非常有用。您可以使用 /proc//root 鏈接訪問容器。從上面的輸出中，我們知道nginx的PID為6。
# ls /proc/6/root/etc/nginx conf.d koi-utf mime.types nginx.conf uwsgi_params fastcgi_params koi-win modules scgi_params win-utf
在這里，我們可以看到目標容器上的Nginx目錄結構和配置文件。
結論
臨時容器功能無疑給調試排查問題帶來了很大便利，而進程命名空間共享允許高級調試功能。如果你也使用在 Kubernetes 集群中運行的應用程序，那么值得花時間嘗試這些功能。不難想象，一些團隊甚至使用這些工具自動執行工作流，例如在readiness probes探針失敗時自動修復其他容器。
