Kubernetes集群内Python-Flask服务调用内部Service出现502 Bad Gateway问题排查求助

看起来你遇到了一个有点棘手的矛盾问题：同一个serv2 Pod里手动执行Python代码能正常调用my-service，但serv2应用自身发起调用却返回502，而PHP的Web应用调用内部服务却完全正常。我来帮你拆解下可能的原因和排查步骤：

核心矛盾点分析 #

首先可以确定的是：Pod间网络连通性、Service的DNS解析、目标服务my-service本身都是正常的（毕竟手动调用和PHP调用都成功了）。问题大概率出在serv2应用自身的运行环境或配置上，和Kubernetes基础网络配置关系不大。

可能的问题方向 #

1. 应用继承了不需要的代理环境变量 #

很多应用会默认继承容器或系统的代理设置，但Kubernetes内部服务调用根本不需要走代理。如果serv2应用启动时带有HTTP_PROXY/HTTPS_PROXY环境变量，就会把内部请求错误地转发到代理服务器，导致502——但你手动执行命令时，这些环境变量可能没被加载（比如应用用非root用户启动，而手动执行用的是root）。

排查&解决方法：

• 进入serv2的Pod，执行env | grep -i proxy，查看是否存在代理相关环境变量。
• 在serv2的Python代码中添加日志，打印os.getenv('HTTP_PROXY')和os.getenv('HTTPS_PROXY')的值，对比手动执行时的输出。
• 可以直接在serv2的Deployment中强制清空代理变量：

  spec:
    containers:
    - name: serv2
      image: serv2
      imagePullPolicy: Never
      env:
      - name: HTTP_PROXY
        value: ""
      - name: HTTPS_PROXY
        value: ""
      - name: NO_PROXY
        value: "cluster.local,svc,.default.svc.cluster.local"
  

  重启Deployment后再测试。

2. Python应用的DNS解析缓存 #

Python的socket模块默认会缓存DNS解析结果，如果my-service的Service是在serv2应用启动后才创建/更新的，应用可能还在使用旧的解析记录，导致请求发往错误地址。而手动执行时是实时解析的，所以能成功。

排查方法：

• 在serv2的Python代码中添加日志，用socket.gethostbyname('my-service')打印解析后的IP，和手动执行nslookup my-service的结果对比。
• 如果确实是缓存问题，可以在请求前强制刷新DNS（比如用socket.getaddrinfo替代，或者直接重启应用）。

3. 应用进程的权限或网络命名空间限制 #

如果serv2应用是用非root用户运行的，可能存在网络权限限制（比如SELinux/AppArmor规则），导致应用无法发起网络请求，但手动执行时用root用户，不受限制。

排查方法：

• 在serv2的Pod中执行ps aux，找到应用进程的运行用户（比如www-data）。
• 切换到该用户执行调用代码：su www-data -c "python your-script.py"，看是否会出现502错误。如果是，需要调整容器的权限配置。

4. Python requests库的特殊配置差异 #

应用里的requests库可能和你手动执行的版本不同，或者带有默认的超时、重试、请求头等配置，导致请求被中断或被目标服务拒绝。

排查方法：

• 在应用的调用代码中添加详细日志，打印请求参数、响应状态码和异常信息：

  import requests
  import traceback
  
  try:
      response = requests.post(
          'http://my-service',
          json=args,
          timeout=10,
          headers={'Host': 'my-service'}
      )
      print(f"请求状态码: {response.status_code}")
      print(f"响应头: {dict(response.headers)}")
      print(f"响应内容: {response.text}")
  except Exception as e:
      print(f"请求失败: {str(e)}")
      print(f"异常栈: {traceback.format_exc()}")
  

  对比手动执行的输出，找到差异点。

快速验证步骤 #

1. 直接调用Pod IP：在serv2应用里改成直接调用my-service的Pod IP（比如http://10.244.0.XX），如果成功，说明是DNS或Service的问题；如果失败，说明是应用本身的网络问题。
2. 检查Service端点：执行kubectl get endpoints my-service，确认列表里有my-service的Pod IP，且状态正常。
3. 对比环境变量：把手动执行时的环境变量全部导出，和应用运行时的环境变量对比，看是否有缺失或差异。

总结 #

根据你的场景，最可能的元凶是代理环境变量或DNS缓存。先从这两个方向入手排查，应该能快速定位问题。

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