调用AKS关联Azure API Management时出现500内部服务器错误排查

针对你遇到的Azure API Management（APIM）连接AKS中Pod返回500内部服务器错误的问题，除了你已尝试的步骤外，还可以从以下几个方向排查：

• 直接验证AKS服务的可用性
  绕过APIM，直接用AKS LoadBalancer服务的外部IP访问应用（比如执行 curl http://<LoadBalancer-IP>）。如果这里也返回500，说明问题出在AKS侧的应用或服务配置；如果访问正常，则问题聚焦在APIM的转发配置上。

• 查看APIM的后端错误日志
  在Azure门户进入你的APIM资源，前往监控 > 日志，或启用诊断设置将日志导出到Log Analytics，查看具体的错误详情。日志会包含诸如后端连接超时、请求路径不匹配、权限限制等关键信息，帮助定位APIM转发请求时的问题。

• 确认Node.js应用的监听地址
  Node.js应用默认若只监听localhost（即app.listen(3000)），容器内部可以访问，但AKS服务的流量无法穿透到容器内。需确保应用监听0.0.0.0:3000（即app.listen(3000, '0.0.0.0')），检查代码中的启动配置。

• 检查AKS网络策略限制
  如果AKS集群配置了NetworkPolicy，可能会阻止APIM的出站IP访问你的my-app服务。查看集群中是否存在针对该服务的NetworkPolicy规则，确保APIM的IP范围被允许访问。

• 验证APIM后端转发配置
  确认APIM中设置的后端URL是否正确：是否使用了LoadBalancer的外部IP、端口是否为80、请求路径是否与应用的路由匹配。比如APIM的API若将请求转发到http://<LoadBalancer-IP>/api/v1/xxx，需确保应用存在对应的路由。

• 进入Pod内部测试应用状态
  执行 kubectl exec -it <你的Pod名称> -- /bin/bash 进入容器内部，然后用 curl localhost:3000 测试应用是否正常响应。有时容器日志无报错，但应用可能存在静默初始化失败或路由配置错误，内部请求能直接暴露问题。

• 检查AKS服务的端点状态
  执行 kubectl describe service my-app，查看Endpoints字段是否显示Pod的IP和端口。如果该字段为空，说明服务未正确匹配到Pod（即使标签一致，也可能存在大小写、空格等细节问题），或Pod未处于就绪状态。

• 添加Pod就绪探针
  如果Deployment未配置就绪探针，AKS服务可能会将流量转发到尚未完全启动的Pod，导致500错误。可以给Deployment添加就绪探针，示例配置如下：

  spec:
    containers:
    - name: my-app
      # 原有配置...
      readinessProbe:
        httpGet:
          path: /health # 替换为你的应用健康检查路径
          port: 3000
        initialDelaySeconds: 10
        periodSeconds: 5
  

  确保应用提供健康检查接口，或使用TCP探针替代。

• 检查APIM的订阅与产品配置
  如果APIM的API关联了产品，需确认请求是否携带了有效的订阅密钥，或API是否允许匿名访问。部分场景下，订阅密钥无效或未正确传递也可能触发500错误（通常为401，但特殊配置下可能出现500）。

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