Kubernetes DNS解析实战过程
作者:CN-FuWei
Kubernetes中,Pod需Ready状态才会被CoreDNS解析,而Service创建时即添加记录,当服务依赖Pod解析时易引发启动死循环,通过设置Service的publishNotReadyAddresses为true,可解决此问题,允许未就绪Pod的IP立即被解析
一、前言
Pod 的解析记录
只有当 Pod 通过就绪探针(Readiness Probe)并成为 Ready 状态时,它才会被加入到对应的 Endpoint 对象中,CoreDNS 才会提供该 Pod 的 DNS 记录(仅限于 hostname.subdomain.namespace.svc.cluster.local 这种格式)。
Service 的解析记录
Service 的解析记录在 Service 对象本身被创建 时就会立刻添加到 CoreDNS 中,完全不依赖 其后端是否有任何就绪的 Pod。
二、场景
由于k8s原生机制受限,当我们某些服务在启动时就依赖pod域名解析,才能完成启动,这时就陷入死循环。
比如etcd集群的启动配置:

三、解决方案
service新增配置
apiVersion: v1
kind: Service
metadata:
name: kuboard-etcd
spec:
clusterIP: None
publishNotReadyAddresses: true # 核心配置:发布未就绪地址
selector:
app: kuboard-etcd
ports:
- name: client
port: 2379
protocol: TCP
targetPort: 2379
- name: peer
port: 2380
protocol: TCP
targetPort: 2380
sessionAffinity: Node
type: ClusterIP 当你为 Service 设置 publishNotReadyAddresses: true 时,无论 Pod 是否就绪,只要它匹配 Service 的 Selector,其 IP 地址就会被加入到 Endpoint 的 addresses 列表中。
这意味着 CoreDNS 会立即为这些未就绪的 Pod 创建对应的 DNS 解析记录。
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
