Linkerd 2.10(Step by Step)—使用 Debug Sidecar，注入调试容器来捕获网络数据包

Linkerd 2.10 系列

• 快速上手 Linkerd v2.10 Service Mesh
• 腾讯云 K8S 集群实战 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 应用
• 详细了解 Linkerd 2.10 基础功能，一起步入 Service Mesh 微服务架构时代
• 将您的服务添加到 Linkerd
• 自动化的金丝雀发布
• 自动轮换控制平面 TLS 与 Webhook TLS 凭证
• 如何配置外部 Prometheus 实例
• 配置代理并发
• 配置重试
• 配置超时
• 控制平面调试端点
• 使用 Kustomize 自定义 Linkerd 的配置
• 使用 Linkerd 进行分布式跟踪
• 调试 502s
• 使用每个路由指标调试 HTTP 应用程序
• 使用请求跟踪调试 gRPC 应用程序
• 导出指标
• 暴露 Dashboard
• 生成您自己的 mTLS 根证书
• 获取每条路由指标
• 混沌工程之注入故障
• 优雅的 Pod 关闭
• Ingress 流量
• 安装多集群组件
• 安装 Linkerd
• 使用 Helm 安装 Linkerd
• Linkerd 和 Pod 安全策略 (PSP)
• 手动轮换控制平面 TLS 凭证
• 修改代理日志级别
• 多集群通信
• 将 GitOps 与 Linkerd 和 Argo CD 结合使用

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。