如何排查Azure Kubernetes环境下应用的500 internal server error错误

1. 流量链路逐层校验 #

先沿着请求从外到内的路径定位错误发生的节点：

• 先验证APIM到AKS的链路是否符合预期：在AKS集群内进入对应业务Pod的网络命名空间，构造和APIM请求参数、Header完全一致的请求，用curl -v <目标接口地址>查看返回状态。如果直接请求Pod返回200，就依次向上排查Service、Ingress、APIM的策略配置；如果请求Pod直接返回500，直接定位到Pod内部问题。
• 校验APIM转发规则是否有变更：检查故障发生前后是否有APIM策略更新、限流规则调整、Header重写配置、证书过期问题，很多时候500错误是因为APIM转发的请求和本地测试的请求参数不一致，比如APIM默认添加了本地未传的特殊Header，触发了应用隐藏的边界异常。

2. Pod运行态差异校验 #

本地运行正常但集群异常，优先排查运行环境的差异：

• 对比本地和集群内的环境变量、ConfigMap/Secret配置差异：大部分集群独有的500错误都是因为数据库连接串、第三方依赖地址、特性开关等配置和本地不一致，触发了仅集群环境才会出现的异常逻辑。
• 检查Pod资源和事件：用kubectl top pod <pod名称> -n <命名空间>查看CPU、内存使用率，确认是否存在OOM前的内存飙升、CPU打满导致请求超时被反向代理返回500的情况；再用kubectl describe pod <pod名称>查看最近的事件，是否有镜像拉取异常、存储挂载失败、调度异常的记录。
• 校验集群内依赖连通性：确认Pod能不能正常访问依赖的数据库、中间件、第三方接口，很多时候本地网络能正常访问依赖，但集群内因为网络策略、NSG规则、出口IP白名单限制导致依赖调用失败，最终返回500错误。

3. 日志增强排查方案 #

默认日志无有效信息时，针对性补充日志采集维度：

• 临时调高应用日志级别：如果默认INFO级日志没有输出异常栈，在不影响核心业务的前提下临时开启DEBUG级日志，输出完整的请求参数、异常栈信息，很多隐藏的空指针、参数解析错误只会在DEBUG日志中体现。
• 采集全链路访问日志：开启Ingress、APIM的全量访问日志，确认错误请求的路径、参数、Header、响应时间、上游返回状态码，明确区分500是Ingress返回的还是应用本身返回的。
• 查看AKS原生监控指标：通过AKS控制台的洞察功能，查看错误请求发生的时间点，是否对应Pod重启、依赖服务调用失败、网络丢包的指标波动。

4. 根因复现验证 #

你本次通过重新部署镜像解决了问题，可通过以下方式定位根因避免后续复发：

• 如果重新部署使用的是同一个镜像，大概率是之前的Pod运行态出现了累积性故障，比如内存泄漏、连接池打满、临时文件占满磁盘，可以把出问题的镜像单独启动一个测试Pod，用压测工具模拟业务请求量，观察是否会逐步出现500错误，即可定位到具体的故障点。
• 如果重新部署使用了新的镜像，对比两个版本的代码差异、配置差异，即可找到引入故障的变更点。

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