pod异常或服务不可访问时，应依次检查pod状态与事件、容器日志、service/endpoint连通性、helm release渲染内容及底层依赖可用性，覆盖调度、启动、网络、配置和依赖全链路。

如果您使用Helm部署服务后，Pod未正常运行或服务无法访问，则可能是由于资源配置错误、依赖组件缺失、网络策略限制或镜像拉取失败等原因导致。以下是系统性排查此问题的步骤：

一、检查Pod状态与事件

该步骤用于快速识别Pod是否处于异常状态（如Pending、CrashLoopBackOff、ImagePullBackOff），并获取Kubernetes调度器和kubelet生成的关键事件信息。

1、执行命令查看目标命名空间下所有Pod状态：kubectl get pods -n

2、对状态异常的Pod执行详细描述：kubectl describe pod -n

3、在输出中重点检查Events字段下的最近几条事件，例如“FailedScheduling”、“FailedMount”、“ErrImagePull”等提示。

4、若事件中出现“node(s) had taints that the pod didn't tolerate”，需核查Pod的tolerations配置与节点taint是否匹配。

二、查看容器日志

该步骤用于确认容器启动后是否因应用自身错误（如配置缺失、端口冲突、数据库连接失败）而崩溃退出。

1、获取Pod内主容器名称（若未显式指定，通常为第一个容器）：kubectl get pod -n -o jsonpath='{.spec.containers[0].name}'

2、拉取容器最近一次崩溃前的日志：kubectl logs -n --previous

3、若容器仍在运行但功能异常，直接查看实时日志：kubectl logs -n

4、若日志为空且Pod反复重启，尝试进入容器内部手动验证启动脚本或二进制文件权限：kubectl exec -it -n -- /bin/sh

三、验证Service与Endpoint连通性

该步骤用于确认服务发现层是否正常工作，即Service是否正确关联到后端Pod IP，以及集群内DNS解析是否生效。

1、检查Service是否存在且ClusterIP非None：kubectl get service -n

2、检查对应Endpoint是否包含活跃Pod IP：kubectl get endpoints -n

3、在另一Pod中执行DNS解析测试：kubectl exec -n -- nslookup

4、在同一命名空间内尝试通过ClusterIP直连服务端口：kubectl exec -n -- curl -v http://:

四、检查Helm Release状态与渲染内容

该步骤用于确认Helm模板是否按预期生成资源对象，是否存在values.yaml配置错误或条件渲染失效问题。

1、列出当前命名空间中的Helm Release：helm list -n

2、检查Release部署状态是否为DEPLOYED：helm status -n

3、查看Helm实际渲染出的YAML内容（不含实际创建）：helm get manifest -n

4、将渲染结果保存为文件并与预期values.yaml比对，重点关注replicas、image、ports、env等关键字段是否被正确注入。

五、验证底层依赖组件可用性

该步骤用于排除因数据库、缓存、消息队列等外部依赖不可达而导致服务启动阻塞的问题。

1、检查依赖服务（如PostgreSQL、Redis、MySQL）Pod是否Running：kubectl get pods -n

2、确认依赖服务的Service和Endpoint已就绪：kubectl get svc,endpoint -n | grep

3、从应用Pod所在节点直连依赖服务端口（如5432）：kubectl exec -n -- telnet 5432

4、若使用自定义域名或外部服务，检查Secret中凭证是否正确挂载，且应用容器内环境变量是否成功读取：kubectl exec -n -- env | grep -i db