42. 使用 Debug Sidecar

调试服务网格可能很困难。当某些东西不起作用时, 是代理有问题吗?与应用程序? 与客户端?与底层网络?有时, 没有什么比查看原始网络数据更好的了。

如果您需要对进入离开 应用程序的数据包进行网络级可见性Linkerd 提供了带有一些有用工具的 debug sidecar。 与 代理 sidecar 注入 的工作方式类似, 您可以通过在 pod 创建时设置 config.linkerd.io/enable-debug-sidecar: "true" annotation 来向 pod 添加 debug sidecar。 为方便起见,linkerd inject 命令提供了 一个 --enable-debug-sidecar 选项来为你做这个注解。

(请注意,Kubernetes pod 中的容器集不是可变的,因此简单地将此 annotation 添加到预先存在的 pod 中是行不通的。它必须在创建 pod 时存在。)

debug sidecar 镜像包含 tsharktcpdumplsofiproute2。 安装后,它会开始使用 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)

当然,这些示例仅在您能够 execKubernetes 集群中的任意容器时才有效。 有关此方法的替代方法,请参阅 linkerd tap