[[408037]]

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

更好的方法

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

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

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

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

Configuring Feature Gates

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

apiVersion: kubeadm.k8s.io/v1beta2  
kind: ClusterConfiguration  
kubernetesVersion: v1.20.2  
apiServer:  
  extraArgs:  
    feature-gates: EphemeralContainers=true 

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

# File: config.yaml  
# Run:  kind create cluster --config ./config.yaml --name kind --image=kindest/node:v1.20.2  
kind: Cluster  
apiVersion: kind.x-k8s.io/v1alpha4  
featureGates:  
  EphemeralContainers: true  
nodes: 
 - role: control-plane 

隨著集群的運(yùn)行，我們需要驗(yàn)證其有效性。最簡單方法是檢查 Pod API，它現(xiàn)在應(yīng)該包含臨時容器部分以及通常容器： 

~ $ kubectl explain pod.spec.ephemeralContainers  
KIND:     Pod 
VERSION:  v1  
RESOURCE: ephemeralContainers <[]Object>  
DESCRIPTION: 
      List of ephemeral containers run in this pod.... 
 ... 

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

~ $ kubectl run some-app --image=k8s.gcr.io/pause:3.1 --restart=Never  
~ $ kubectl debug -it some-app --image=busybox --target=some-app  
Defaulting debug container name to debugger-tfqvh. 
If you don't see a command prompt, try pressing enter.  
/ #  
# From other terminal...  
~ $ kubectl describe pod some-app  
...  
Containers:  
  some-app:  
    Container ID:   containerd://60cc537eee843cb38a1ba295baaa172db8344eea59de4d75311400436d4a5083
    Image:          k8s.gcr.io/pause:3.1  
    Image ID:       k8s.gcr.io/pause@sha256:f78411e19d84a252e53bff71a4407a5686c46983a2c2eeed83929b888179acea 
...  
Ephemeral Containers:  
  debugger-tfqvh:  
    Container ID:   containerd://12efbbf2e46bb523ae0546b2369801b51a61e1367dda839ce0e02f0e5c1a49d6  
    Image:          busybox 
    Image ID:       docker.io/library/busybox@sha256:ce2360d5189a033012fbad1635e037be86f23b65cfd676b436d0931af390a2ac  
    Port:           <none>  
    Host Port:      <none>  
    State:          Running  
      Started:      Mon, 15 Mar 2021 20:33:51 +0100  
    Ready:          False  
    Restart Count:  0  
    Environment:    <none>  
    Mounts:         <none> 

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

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

Process Namespace Sharing

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

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

~ $ kubectl run some-app --image=nginx --restart=Never  
~ $ kubectl debug -it some-app --image=busybox --share-processes --copy-to=some-app-debug  
Defaulting debug container name to debugger-tkwst.  
If you don't see a command prompt, try pressing enter.  
/ # ps ax  
PID   USER     TIME  COMMAND  
    1 root      0:00 /pause  
    8 root      0:00 nginx: master process nginx -g daemon off;  
   38 101       0:00 nginx: worker process  
   39 root      0:00 sh  
   46 root      0:00 ps ax  
~ $ cat /proc/8/root/etc/nginx/conf.d/default.conf   
server {  
    listen       80;  
    listen  [::]:80;  
    server_name  localhost;  
... 

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

# From other terminal:  
~ $ kubectl get pods  
NAME             READY   STATUS    RESTARTS   AGE  
some-app         1/1     Running   0          23h  
some-app-debug   2/2     Running   0          20s 

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

~ $ kubectl get pod some-app-debug -o json  | jq .spec.shareProcessNamespace  
true 

好好使用

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

~ $ kubectl run distroless-python --image=martinheinz/distroless-python --restart=Never  
~ $ kubectl exec -it distroless-python -- /bin/sh  
# id  
/bin/sh: 1: id: not found  
# ls  
/bin/sh: 2: ls: not found  
# env  
/bin/sh: 3: env: not found  
#  
...  
kubectl debug -it distroless-python --image=praqma/network-multitool --target=distroless-python -- sh  
Defaulting debug container name to debugger-rvtd4.  
If you don't see a command prompt, try pressing enter.  
/ # ping localhost  
PING localhost(localhost (::1)) 56 data bytes  
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.025 ms  
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.044 ms  
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.027 ms 

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

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

~ $ kubectl run distroless-python --image=martinheinz/distroless-python --restart=Never  
~ $ kubectl debug -it distroless-python --image=busybox --share-processes --copy-to=distroless-python-debug  
Defaulting debug container name to debugger-l692h.  
If you don't see a command prompt, try pressing enter.  
/ # ps ax  
PID   USER     TIME  COMMAND  
    1 root      0:00 /pause  
    8 root      0:00 /usr/bin/python3.5 sleep.py  # Original container is just sleeping forever  
   14 root      0:00 sh  
   20 root      0:00 ps ax  
/ # cat /proc/8/root/app/sleep.py   
import time 
print("sleeping for 1 hour")  
time.sleep(3600) 

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

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

~ $ kubectl get pods  
NAME                READY   STATUS             RESTARTS   AGE  
crashing-app        0/1     CrashLoopBackOff   1          8s  
~ $ kubectl debug crashing-app -it --copy-to=crashing-app-debug --container=crashing-app -- sh  
If you don't see a command prompt, try pressing enter.  
# id  
uid=0(root) gid=0(root) groups=0(root)  
#  
...  
# From another terminal  
~ $ kubectl get pods  
NAME                READY   STATUS             RESTARTS   AGE  
crashing-app        0/1     CrashLoopBackOff   3          2m7s  
crashing-app-debug  1/1     Running            0          16s 

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

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

~ $ kubectl get nodes  
NAME                 STATUS   ROLES                  AGE   VERSION  
kind-control-plane   Ready    control-plane,master   25h   v1.20.2  
~ $ kubectl debug node/kind-control-plane -it --image=ubuntu 
 Creating debugging pod node-debugger-kind-control-plane-hvljt with container debugger on node kind-control-plane.  
If you don't see a command prompt, try pressing enter.  
root@kind-control-plane:/# chroot /host  
# head kind/kubeadm.conf  
apiServer:  
  certSANs:  
  - localhost  
  - 127.0.0.1  
  extraArgs:  
    feature-gates: EphemeralContainers=true  
    runtime-config: ""  
apiVersion: kubeadm.k8s.io/v1beta2  
clusterName: kind  
controlPlaneEndpoint: kind-control-plane:6443 

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

小結(jié)

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