设置ClusterIP的Kubernetes Service无法访问Pod内部域名的原因

这个问题的核心在于普通ClusterIP Service和Headless Service（clusterIP: None）在DNS解析上的本质区别，以及StatefulSet Pod的FQDN生成规则。

1. 普通ClusterIP Service的DNS行为 #

当你创建带有ClusterIP的Service时：

• Kubernetes会为这个Service分配一个虚拟的ClusterIP，同时在集群DNS中创建一条A记录，指向这个ClusterIP（比如mariadb.your-namespace.svc.cluster.local → ClusterIP）。
• 这个Service的作用是作为负载均衡入口，把请求转发到匹配selector的Pod上，但它不会为每个后端Pod生成单独的DNS记录。
• 你尝试访问的mariadb-0.mariadb.your-namespace.svc.cluster.local这个域名，在普通Service的场景下根本不存在于集群DNS中，自然无法解析，也就ping不通。

另外补充：即使你ping Service本身的域名（mariadb.your-namespace.svc.cluster.local），有些环境里也可能ping不通——因为ClusterIP是kube-proxy维护的虚拟IP，很多集群的网络插件默认不响应ICMP请求，但你应该能通过3306端口正常连接数据库（比如用telnet mariadb 3306或者mysql客户端测试）。

2. Headless Service的DNS行为 #

当你把Service设置为clusterIP: None（即Headless Service）时：

• 这个Service不会分配ClusterIP，Kubernetes会直接在DNS中为每个匹配selector的StatefulSet Pod生成单独的A记录，格式就是pod-name.service-name.namespace.svc.cluster.local，指向Pod的真实IP。
• 这也是StatefulSet的设计特性之一：稳定的网络标识，每个Pod都有固定的FQDN，而这个特性依赖Headless Service来实现。
• 所以此时你能ping通这个域名，因为它能正确解析到Pod的真实IP，而真实Pod的IP是会响应ICMP请求的。

总结一下 #

• 如果你只是想通过Service访问数据库（不关心具体是哪个Pod），普通ClusterIP Service完全可以正常工作，只是不能通过Pod的FQDN访问。
• 如果你需要直接访问StatefulSet的某个特定Pod（比如主从复制场景下连接主节点），必须使用Headless Service，这样才能利用StatefulSet提供的稳定Pod FQDN。

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