如何查看GKE容器与Cloud SQL之间的网络请求？

这种启动时一次性的连接错误确实挺挠头的，尤其是后续请求都正常的情况下。既然你怀疑错误请求没到达Cloud SQL，咱们可以从Pod内部、GKE网络层和Cloud SQL侧三个层面逐步排查网络请求的流向：

因为错误是Pod启动初期触发的，优先捕获这个阶段的网络流量最直接：

• 手动临时抓包（测试环境适用）：先进入目标Pod，安装抓包工具后定向捕获Cloud SQL的流量：

  # 进入Pod
  kubectl exec -it <你的Pod名称> -- /bin/bash
  # 安装tcpdump（Debian/Ubuntu系镜像示例，其他系统替换对应包管理命令）
  apt-get update && apt-get install -y tcpdump
  # 捕获指向Cloud SQL私有IP、5432端口的流量，保存为文件
  tcpdump -i any host <Cloud_SQL私有IP> and port 5432 -w init-connection.pcap
  

  等待错误触发后，按Ctrl+C停止抓包，再把文件拷到本地用Wireshark分析：

  kubectl cp <你的Pod名称>:/init-connection.pcap ./init-connection.pcap
  

  重点看启动时那10次错误对应的时间窗口里，有没有发出TCP连接请求，有没有收到Cloud SQL的响应。
• 自动抓包（生产/自动扩容场景适用）：修改Deployment的Pod模板，让主容器启动时先后台启动抓包，再启动Django进程：

  command:
    - /bin/sh
    - -c
    - "tcpdump -i any host <Cloud_SQL私有IP> and port 5432 -w /tmp/init-traffic.pcap & python manage.py runserver 0.0.0.0:8000"
  

  后续可以通过kubectl cp把抓包文件导出分析。

既然怀疑问题出在Django侧，先把日志拉满看细节：

• 调整Django的LOGGING配置，把django.db.backends的日志级别设为DEBUG，这样能看到数据库连接建立的完整过程，包括连接超时、认证失败等细节，确认错误是发生在连接初始化阶段，还是请求发送阶段。
• 检查数据库连接池配置（比如用了django-db-connection-pool或Django默认的连接管理）：Pod启动时10个进程同时建立连接，会不会是连接超时设置过短，刚好撞上Pod启动时的网络初始化延迟？或者连接池的初始化逻辑有竞争导致第一次连接失败？

确认Pod到Cloud SQL的网络路径全程通畅：

• 临时Pod测试连通性：在同一个Namespace下启动一个测试Pod，用psql或nc直接测试连接：

  kubectl run -it --rm test-connect --image=postgres:latest -- psql -h <Cloud_SQL私有IP> -U <数据库用户名> -d <数据库名>
  

  同时可以用mtr检查网络路径的丢包情况：

  kubectl exec -it test-connect -- mtr <Cloud_SQL私有IP> --port 5432
  

• 检查网络策略与VPC配置：确认有没有NetworkPolicy阻止了Pod到Cloud SQL的流量；如果用了VPC Peering连接Cloud SQL，检查Peering连接状态是否正常，路由表中是否存在指向Cloud SQL私有IP段的路由。

虽然你怀疑请求没到，但还是可以验证下：

• 查看Cloud SQL的连接日志：在Cloud Console中打开目标SQL实例的日志，筛选postgres.log里的connection received或connection authorized条目，看看Pod启动时有没有对应的连接记录。如果没有，说明请求确实没到达Cloud SQL；如果有，那可能是Postgres端的错误被Django捕获了。
• 检查连接数配额：Pod启动时10个进程同时连接，会不会触发了Cloud SQL的临时连接数限制？不过后续请求正常的话这个概率不高，但可以确认下当前连接数是否在配额范围内。

把这些步骤串起来排查，大概率能定位到问题——比如Django连接初始化时的超时设置过短，或者Pod启动时网络还未完全就绪导致第一次连接失败。

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