看起来你遇到了K8s集群里跨Pod服务连通的典型问题，我来一步步帮你定位根因：

1. 先确认PostgreSQL Service的“有效性” #

首先得确保这个postgresql-k8s-service真的能正确关联到PostgreSQL Pod：

• 执行kubectl get service postgresql-k8s-service，重点看ClusterIP列（不能是<none>），以及PORTS列是否显示5432/TCP，确认端口映射正确
• 再执行kubectl describe service postgresql-k8s-service，找到Endpoints字段——这里必须显示PostgreSQL Pod的IP+5432端口，如果是空的，那就是Service的标签选择器和Pod的标签不匹配，这是最常见的坑！
• 验证标签匹配度：用kubectl get pods --show-labels查看PostgreSQL Pod的标签，对比Service的spec.selector配置（同样用kubectl describe service能看到），必须完全一致才行（比如Service选app=postgresql，Pod就得有这个标签）

2. 检查Artifactory Pod里的DNS解析是否正常 #

你已经试过ping，但先确认DNS能不能把Service名称转成ClusterIP：

• 进入Artifactory Pod：kubectl exec -it <你的Artifactory Pod名称> -- /bin/bash
• 执行nslookup postgresql-k8s-service，如果能返回Service的ClusterIP，说明DNS没问题；如果报错，要么是CoreDNS出故障了，要么是Pod的DNS配置异常（可以看cat /etc/resolv.conf确认DNS服务器）
• 要是镜像里没有nslookup，也可以直接ping Service的ClusterIP试试，如果能ping通，说明网络可达，问题出在DNS解析

3. 别只ping，测试端口连通性！ #

ping只能确认网络层可达，但PostgreSQL的5432端口可能被拦截：

• 在Artifactory Pod里，用telnet postgresql-k8s-service 5432或者nc -zv postgresql-k8s-service 5432测试端口是否开放
• 如果telnet/nc失败，先直接ping PostgreSQL Pod的IP：如果能ping通但端口不通，要么是PostgreSQL容器没监听5432（进入PostgreSQL Pod执行netstat -tulpn | grep 5432确认，要是只绑定127.0.0.1就会出问题），要么是集群里的NetworkPolicy限制了Artifactory到PostgreSQL的流量
• 还有个容易忽略的点：两个Pod是不是在同一个Namespace？如果不在，连接的时候要写全Service的FQDN：postgresql-k8s-service.<PostgreSQL所在命名空间>.svc.cluster.local

4. 检查Artifactory的连接配置 #

虽然你的报错是等待DB就绪，但也得确认配置没写错：

• 确认Artifactory的数据库连接字符串里，主机名确实是postgresql-k8s-service，端口是5432，没有拼写错误
• 暂时排除认证问题：进入PostgreSQL Pod，用psql -U <数据库用户名> -d <数据库名>登录，确认数据库本身能正常使用

5. 扒日志找细节 #

最后，从日志里挖更多线索：

• 看PostgreSQL Pod的日志：kubectl logs <你的PostgreSQL Pod名称>，确认数据库已经正常启动，没有绑定错误的IP
• 看Artifactory Pod的日志：kubectl logs <你的Artifactory Pod名称>，获取更详细的连接错误（是超时还是拒绝连接，这俩指向的问题完全不同）
• 看Service的事件：kubectl describe service postgresql-k8s-service，Events里可能会有绑定失败的提示

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