Kubernetes中如何调试两个Pod之间的gRPC调用

你在本地终端执行export设置的环境变量仅对当前本地会话生效，不会自动注入到K8s集群运行的Pod容器内，因此容器内的gRPC进程根本读不到这两个变量，自然不会输出debug日志。

正确的环境变量注入方式：

• 临时调试场景：直接给对应工作负载注入环境变量触发滚动更新，执行命令：

kubectl set env deployment/<你的gRPC应用对应的Deployment名> -n <业务命名空间> GRPC_TRACE=all GRPC_VERBOSITY=DEBUG

等新Pod启动完成后，再执行kubectl logs查看即可。如果你的应用将gRPC日志输出到文件而非stdout/stderr，需要进入容器查看对应日志文件，或调整应用日志输出路径到标准输出。

• 注意不同语言gRPC库的兼容差异：Go语言版本的gRPC默认不会读取上述环境变量，需要在代码中显式导入grpclog初始化包才能让环境变量生效，部分二次封装的gRPC框架会默认屏蔽gRPC内部debug日志，需要同步调整框架本身的日志级别配置。

如果开启内置日志后仍无法定位问题，按网络层到应用层的顺序逐层排查：

• 第一层：TCP连通性校验
  进入客户端Pod容器内，测试到gRPC服务的连通性：

  kubectl exec -it <客户端Pod名称> -n <业务命名空间> -- sh
  # 容器内执行TCP连通性测试
  nc -zv <gRPC对应的Service域名> <gRPC服务端口>
  

  如果TCP连接失败，问题出在K8s网络层，和gRPC协议本身无关，依次排查：
  • Service标签选择器是否匹配后端Pod，执行kubectl get endpoints <gRPC服务名> -n <业务命名空间>确认是否存在正常的后端Pod IP+端口条目
  • 集群网络策略、节点安全组、CNI插件（Calico/Flannel等）是否放通对应端口的跨Pod访问
  • 若使用HostNetwork/hostPort暴露服务，检查节点对应端口是否被其他进程占用
• 第二层：报文抓包确认流量收发
  TCP连通正常但调用报错时，在Pod所在节点或容器内使用tcpdump抓对应端口的流量：

  tcpdump -i any port <gRPC服务端口> -w grpc_debug.pcap
  

  导出pcap文件后用Wireshark解析（Wireshark原生支持HTTP/2、gRPC协议解析），可以直接定位是TLS握手失败、HTTP/2帧格式异常、还是服务端返回了明确的gRPC错误状态码。如果是加密gRPC流量，需要加载服务端TLS私钥才能解密报文内容。
• 第三层：gRPC配置校验
  连通性正常但抓包看不到正常请求响应时，检查配置项：
  • 客户端配置的服务端地址是否正确，集群内访问Service的完整域名格式为<服务名>.<命名空间>.svc.cluster.local，注意不要写错端口、命名空间
  • 若开启TLS认证，检查证书SAN列表是否包含客户端访问的域名，确认证书未过期、客户端已配置正确的根证书完成服务端校验
  • 检查服务端配置的拦截器、鉴权、限流逻辑是否直接拒绝了跨Pod请求，查看服务端应用日志是否有请求进入的记录
• 可选：无侵入式观测
  不想修改应用代码或重启Pod的场景，可以在对应节点使用eBPF工具观测gRPC调用的状态码、延迟、错误信息，也可以临时注入gRPC调试边车转发流量，逐跳定位故障点。

• 所有需要容器内进程读取的环境变量，必须配置在Pod的spec.containers.env字段中，本地终端设置的变量不会同步到集群
• 部分旧版本gRPC库存在trace日志不生效的已知bug，若配置正确仍无日志输出，可尝试将gRPC依赖升级到稳定版本
• 如果集群配置了日志采集规则，会过滤掉DEBUG级别日志，需要同步调整日志采集端的级别配置，或直接进入容器查看原始日志

内容的提问来源于stack exchange，提问作者ratzip