Azure环境下Kotlin-Spring应用部署Pipeline失败排查求助

一、先解决MongoDB服务DNS解析失败的核心问题 #

• 核对Service的存在性与命名空间：你用的域名nl-dev-mongodb.nl-fe.svc.cluster.local遵循K8S Service域名规则，先执行kubectl get svc -n nl-fe，确认是否存在名为nl-dev-mongodb的Service，状态是否为正常的ClusterIP/NodePort。如果Service不存在，解析失败是必然的，得先确认MongoDB的Helm部署是否成功创建了该Service。
• 检查后端Pod的命名空间：如果后端Pod不在nl-fe命名空间，即便用全域名也可能因网络策略或DNS配置问题无法解析，先通过kubectl get pods -A | grep <后端Pod名>确认Pod所在命名空间，必要时调整应用配置里的MongoDB地址，或者检查跨命名空间的DNS访问权限。
• 直接在Pod内测试解析：进入后端Pod执行nslookup nl-dev-mongodb.nl-fe.svc.cluster.local，看能否返回有效IP。如果不行，检查集群DNS组件（比如CoreDNS）状态：kubectl get pods -n kube-system看CoreDNS Pod是否正常Running，再查看CoreDNS日志kubectl logs <coredns-pod名> -n kube-system排查DNS服务是否异常。

二、排查target目录jar包缺失的可能性 #

• 核查GitLab Pipeline构建日志：找到Pipeline里的构建步骤（比如Maven的mvn package或Gradle的./gradlew build），确认是否输出BUILD SUCCESS，以及是否有生成jar包的记录（比如Created target/your-app.jar）。如果构建阶段没生成jar，后续镜像肯定没有这个文件。
• 验证Docker镜像内容：拉取Pipeline构建的镜像，本地执行docker run --rm <镜像标签> ls target，看目录下是否存在jar文件；或者直接在后端Pod内执行ls target（如果Dockerfile里把jar放在这个目录）。如果确实缺失，哪怕没改Dockerfile，也可能是Pipeline构建步骤被误修改（比如跳过了打包命令），或者构建路径配置错误。

三、日志中“na”标识的排查方向 #

• 定位“na”的出现场景：把包含“na”的完整日志片段摘出来，看是在加载配置、初始化数据库连接、还是读取环境变量时出现的。如果是MongoDB连接地址被设为“na”，应用肯定无法正常连接数据库，进而启动失败。
• 检查Helm Values配置：打开用于helm upgrade的values.yaml文件，确认MongoDB相关的配置项（比如mongodb.host）是否正确设置为nl-dev-mongodb.nl-fe.svc.cluster.local，而不是“na”或空值——有可能是配置模板渲染时参数缺失，导致最终注入的配置无效。

四、Helm部署阶段的额外排查动作 #

• 查看Helm升级的详细日志：执行helm upgrade <release-name> <chart-name> -n <namespace> --debug，可以看到升级过程中的模板渲染、资源创建细节，能直接发现配置错误或资源创建失败的原因。
• 查看后端Pod的事件日志：执行kubectl describe pod <backend-pod-name> -n <namespace>，重点看Events栏，里面会记录Pod启动时的异常（比如镜像拉取失败、挂载卷错误、端口冲突等），这些都可能导致Pod启动异常。

内容的提问来源于stack exchange，提问作者Bilel-NEJI