Linkerd 2.10(Step by Step)—使用 Debug Sidecar，注入除錯容器來捕獲網路資料包

Linkerd 2.10 系列

Linkerd 2.10 中文手冊持續修正更新中：

https://linkerd.hacker-linner.com

除錯服務網格(service mesh)可能很困難。當某些東西不起作用時，
是代理(proxy)有問題嗎？與應用程式(application)？
與客戶端(client)？與底層網路？(underlying network)有時，
沒有什麼比檢視原始網路資料更好的了。

如果您需要對進入(entering)和離開(leaving)應用程式的資料包進行
網路級可見性(network-level visibility)，
Linkerd 提供了帶有一些有用工具的 debug sidecar。
與 proxy sidecar injection 的工作方式類似，
您可以通過在 pod 建立時設定 config.linkerd.io/enable-debug-sidecar: "true" annotation
來向 pod 新增 debug sidecar。
為方便起見，linkerd inject 命令提供了
一個 --enable-debug-sidecar 選項來為你做這個註解。

（請注意，Kubernetes pod 中的容器集不是可變的，因此簡單地將此 annotation
新增到預先存在的 pod 中是行不通的。它必須在建立 pod 時存在。）

debug sidecar 映象包含
tshark、
tcpdump、lsof 和 iproute2。
安裝後，它會開始使用 tshark 自動記錄所有傳入和傳出的流量，
然後可以使用 kubectl logs 檢視這些流量。
或者，您可以使用 kubectl exec 訪問容器並直接執行命令。

例如，如果您已經閱讀了
Linkerd 入門指南
並安裝了 emojivoto 應用程式，並希望除錯 voting 服務的流量，您可以執行：

kubectl -n emojivoto get deploy/voting -o yaml \
  | linkerd inject --enable-debug-sidecar - \
  | kubectl apply -f -

將 debug sidecar 容器部署到 voting 服務中的所有 pod。
（請注意，此部署中只有一個 Pod，它將被重新建立以執行此
操作 - 請參閱上面有關 Pod 可變性的說明。）

您可以通過列出帶有 voting-svc 標籤的 pod 中的所有容器來確認除錯容器正在執行：

kubectl get pods -n emojivoto -l app=voting-svc \
  -o jsonpath='{.items[*].spec.containers[*].name}'

然後，您可以通過簡單地執行來檢視日誌中的實時 tshark 輸出：

kubectl -n emojivoto logs deploy/voting linkerd-debug -f

如果這還不夠，您可以 exec 到容器並在網路上下文中執行您自己的命令。
例如，如果您想檢查請求的 HTTP headers，您可以執行如下程式碼：

kubectl -n emojivoto exec -it \
  $(kubectl -n emojivoto get pod -l app=voting-svc \
    -o jsonpath='{.items[0].metadata.name}') \
  -c linkerd-debug -- tshark -i any -f "tcp" -V -Y "http.request"

由代理編寫的 debug sidecar 在故障排除中
有效的實際錯誤訊息是 Connection Refused 錯誤，如下所示：

ERR! [<time>] proxy={server=in listen=0.0.0.0:4143 remote=some.svc:50416}
linkerd2_proxy::app::errors unexpected error: error trying to connect:
Connection refused (os error 111) (address: 127.0.0.1:8080)

在這種情況下，可以修改 tshark 命令以偵聽錯誤中提到的特定埠之間的流量，如下所示：

kubectl -n emojivoto exec -it \
 $(kubectl -n emojivoto get pod -l app=voting-svc \
  -o jsonpath='{.items[0].metadata.name}') \
  -c linkerd-debug -- tshark -i any -f "tcp" -V \
  -Y "(tcp.srcport == 4143 and tcp.dstport == 50416) or tcp.port == 8080"

請注意，訊息 Connection reset by peer 也有類似的錯誤。
如果您在應用程式日誌輸出中沒有看到相關的錯誤或訊息，則此錯誤通常是良性的。
在這種情況下，除錯容器可能無法幫助解決錯誤訊息。

ERR! [<time>] proxy={server=in listen=0.0.0.0:4143 remote=some.svc:35314}
linkerd2_proxy::app::errors unexpected error: connection error:
Connection reset by peer (os error 104)

當然，這些示例僅在您能夠 exec 到 Kubernetes 叢集中的任意容器時才有效。
有關此方法的替代方法，請參閱 linkerd tap。

Linkerd 2.10(Step by Step)—使用 Debug Sidecar，注入除錯容器來捕獲網路資料包

Linkerd 2.10 系列

相關文章