kubeasz 集群 DNS 部署实战CoreDNS 与 NodeLocal DNSCache 架构解析【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz导读DNS 是 Kubernetes 集群中必须最先部署的基础组件它为集群中的 Pod 提供集群服务名SVC与 Pod hostname 的域名解析能力。本文以 kubeasz 项目为实践载体系统讲解其内置的 CoreDNS 与 NodeLocal DNSCache 两级 DNS 架构先说明组件在集群中的作用与选型背景再给出集成安装、手动部署与验证的完整命令随后结合仓库中的配置模板与 Ansible 任务源码逐层剖析 Corefile 配置、关键变量与 ipvs/iptables 两种模式的差异最后列出实战中常见的排错案例帮助读者在 kubeasz 安装的集群中快速落地并排查集群 DNS 问题。一、集群 DNS 的角色与选型在 kubeasz 集群中DNS 承担两个核心解析任务集群服务名 SVC 解析如nginx.default.svc.cluster.local解析为对应 Service 的 ClusterIPPod hostname 解析通过 headless service 场景下的 pod 记录或pods insecure模式下的 hostname 解析。kubeasz 目前推荐并默认部署CoreDNS作为集群 DNS 的实现历史版本曾基于 kube-dns dnsmasq sidecar 三容器方案对应模板保留在 kubedns.yaml.j2 中作为兼容与迁移参考。同时kubeasz 默认启用NodeLocal DNSCache在集群每个节点上运行一个 DNS 缓存 DaemonSet以提升 clusterDNS 的查询性能与可靠性。官方测试表明相比纯 CoreDNS 方案nodelocaldns coredns组合能够大幅降低 DNS 查询 timeout 的频次提升服务稳定性。说明原文档中引用的官方 nodelocaldns 说明链接kubernetes.io 官方文档可在阅读本文后按需自行检索本文后续内容均以仓库内实际模板与变量为准。二、安装集群 DNS三种方式kubeasz 已将 CoreDNS 与 NodeLocal DNSCache 自动集成进安装流程无需单独手工部署。配置模板位于roles/cluster-addon/templates/dns/目录coredns.yaml.j2、nodelocaldns-ipvs.yaml.j2、nodelocaldns-iptables.yaml.j2、kubedns.yaml.j2。1. 随集群一键安装推荐假设集群名为xxxx在执行ezctl setup全流程安装时DNS 组件会在第 07 步集群插件安装自动完成部署# 一键安装整个集群含 DNS ezctl setup xxxx all2. 分步安装如果集群已就绪只想单独执行插件安装步骤# 只执行第 07 步安装集群插件含 coredns、nodelocaldns ezctl setup xxxx 073. 手动安装kubeasz 在渲染阶段会把模板生成到集群目录{{ cluster_dir }}/yml/下默认/etc/kubeasz/clusters/xxxx/yml/。可手动应用生成好的清单文件kubectl apply -f /etc/kubeasz/clusters/xxxx/yml/coredns.yaml kubectl apply -f /etc/kubeasz/clusters/xxxx/yml/nodelocaldns.yaml4. 安装背后的自动化逻辑源码视角从 roles/cluster-addon/tasks/main.yml 可以看到插件的幂等控制方式先执行kubectl get pod --all-namespaces并注册变量pod_info只有当pod_info中未出现corednsPod 时才import_tasks: coredns.yml只有当未出现node-local-dnsPod 时才import_tasks: nodelocaldns.yml。而在 coredns.yml 与 nodelocaldns.yml 中实际执行的是# coredns.yml 核心动作 template: srcdns/coredns.yaml.j2 dest{{ cluster_dir }}/yml/coredns.yaml shell: {{ base_dir }}/bin/kubectl apply -f {{ cluster_dir }}/yml/coredns.yaml两个任务都用when:条件分别受控于配置项dns_install yes是否安装 CoreDNS默认开启见 example/config.yml 中dns_install: yesENABLE_LOCAL_DNS_CACHE|bool是否启用 NodeLocal DNSCache默认true。此外nodelocaldns 模板会依据PROXY_MODE自动二选一PROXY_MODE ipvs→ 渲染nodelocaldns-ipvs.yaml.j2PROXY_MODE in [iptables, nftables]→ 渲染nodelocaldns-iptables.yaml.j2。两者差异详见下文“四、NodeLocal DNSCache 部署解析”。三、CoreDNS 部署解析1. 关键变量与 DNS 服务地址kubeasz 的 DNS 服务 ClusterIP 并非手工指定而是由 roles/cluster-addon/vars/main.yml 依据SERVICE_CIDR自动推导取 Service 网段内第二个可用地址CLUSTER_DNS_SVC_IP: {{ SERVICE_CIDR.split(.)[0] }}.{{ SERVICE_CIDR.split(.)[1] }}.{{ SERVICE_CIDR.split(.)[2] }}.{{ SERVICE_CIDR.split(.)[3]|regex_replace(/.*, )|int 2 }}以默认配置SERVICE_CIDR10.68.0.0/16为例计算得到CLUSTER_DNS_SVC_IP10.68.0.2——这也解释了后文验证中 Pod 的resolv.conf里nameserver 10.68.0.2的来源。其余相关默认值定义在 example/config.yml配置项默认值说明dns_installyes是否安装 CoreDNScorednsVer__coredns__CoreDNS 镜像版本ezdown 渲染时替换为实际版本号ENABLE_LOCAL_DNS_CACHEtrue是否启用 NodeLocal DNSCachednsNodeCacheVer__dns_node_cache__NodeLocal DNSCache 镜像版本LOCAL_DNS_CACHE169.254.20.10节点本地 DNS 监听地址链路本地地址CLUSTER_DNS_DOMAINcluster.local集群 DNS 域名后缀见 hosts.allinone版本号占位符__coredns__、__dns_node_cache__会在ezdown -D离线下载镜像时被替换为真实版本这是 kubeasz 离线安装机制的一部分详见 07-install_cluster_addon.md。2. Corefile 核心配置解读coredns.yaml.j2 中的 ConfigMap 定义了 CoreDNS 的核心行为.:53 { errors health { lameduck 5s } ready kubernetes {{ CLUSTER_DNS_DOMAIN }} in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 } cache 30 reload loadbalance }逐项说明kubernetes cluster.local in-addr.arpa ip6.arpa接入 Kubernetes API负责集群域与反向域解析pods insecure启用 Pod 记录解析不做 IP 校验fallthrough in-addr.arpa ip6.arpa反向解析不命中时放行给下一插件ttl 30集群内记录 TTL 30 秒。forward . /etc/resolv.conf集群域之外的请求转发给节点/etc/resolv.conf中的上游 DNS即“默认集成节点 DNS 解析”的实现max_concurrent 1000限制并发转发数cache 30普通记录缓存 30 秒prometheus :9153暴露 Prometheus 指标health/ready就绪与健康检查端点loadbalance对多 A 记录做随机负载均衡。3. Deployment 与 Service 关键点Service 名称为kube-dnsclusterIP: {{ CLUSTER_DNS_SVC_IP }}即 10.68.0.2端口 53 UDP/TCP 与 9153 metrics。命名沿用kube-dns是为了兼容旧式 Pod 中写死的kube-dns.kube-system.svc服务名。Pod 标签k8s-app: kube-dns被 Service selector 选中这也是 nodelocaldns 中kube-dns-upstreamService 依赖的标签。Deployment 关键配置replicas: 1、RollingUpdate 策略priorityClassName: system-cluster-critical保证在资源紧张时优先调度podAntiAffinity尽量将副本分散到不同节点容器镜像为easzlab.io.local:5000/easzlab/coredns:{{ corednsVer }}离线仓库地址IfNotPresent资源请求cpu: 100m / memory: 70Mi上限memory: 500Mi健康检查liveness 探测/health8080、readiness 探测/ready8181安全加固seccompProfile: RuntimeDefault、allowPrivilegeEscalation: false、仅保留NET_BIND_SERVICE能力、readOnlyRootFilesystem: true。四、NodeLocal DNSCache 部署解析NodeLocal DNSCache 以 DaemonSet 方式在每个节点运行k8s-dns-node-cache监听链路本地地址169.254.20.10作为 Pod 侧 DNS 请求的第一跳缓存只有未命中的请求才通过force_tcp转发给 CoreDNS从而显著减少 DNS timeout。1. 两种模板的差异ipvs vs iptables/nftables从 nodelocaldns-ipvs.yaml.j2 与 nodelocaldns-iptables.yaml.j2 对比可见对比项ipvs 模式iptables/nftables 模式Corefilebind仅{{ LOCAL_DNS_CACHE }}{{ LOCAL_DNS_CACHE }} {{ CLUSTER_DNS_SVC_IP }}同时绑定 DNS Service IP集群域转发目标forward . {{ CLUSTER_DNS_SVC_IP }}显式指定forward . __PILLAR__CLUSTER__DNS__占位符由启动参数注入启动参数-localip{{ LOCAL_DNS_CACHE }}{{ LOCAL_DNS_CACHE }},{{ CLUSTER_DNS_SVC_IP }}原因iptables/nftables 模式下nodelocaldns 需要同时劫持bind原kube-dnsService 的 ClusterIP才能把原本发往10.68.0.2的请求接管到本地缓存而 ipvs 模式则通过 ipvs 规则天然实现因此只需绑定本地地址。2. Corefile 缓存策略以 ipvs 模板为例{{ CLUSTER_DNS_DOMAIN }}:53 { errors cache { success 9984 30 denial 9984 10 } reload loop bind {{ LOCAL_DNS_CACHE }} forward . {{ CLUSTER_DNS_SVC_IP }} { force_tcp } prometheus :9253 health {{ LOCAL_DNS_CACHE }}:8099 }集群域请求命中缓存则直接返回成功记录缓存 9984 条/30 秒否定记录 9984 条/10 秒未命中则force_tcp用TCP转发给 CoreDNS避免 UDP 大包分片与超时问题in-addr.arpa/ip6.arpa反向域同样走本地缓存与 TCP 转发.根域转发给上游 DNS__PILLAR__UPSTREAM__SERVERS__即节点上游metrics 端口9253health 端口8099。3. DaemonSet 关键配置hostNetwork: truednsPolicy: Default直连节点网络不依赖集群 DNSpriorityClassName: system-node-criticaltolerations 容忍CriticalAddonsOnly、NoExecute、NoSchedule保证所有节点含控制面都能调度需要NET_ADMIN能力以写入 iptables/ipvs 规则挂载宿主机/run/xtables.lock以避免并发修改 iptables 时锁冲突提供 headless Servicenode-local-dnsclusterIP: None暴露 9253 端口给 Prometheus 抓取指标。4. 与 kubelet 的衔接重要前提NodeLocal DNSCache 要真正生效还需将 kubelet 的--cluster-dns指向169.254.20.10并配置--cluster-domain为cluster.local。在 kubeasz 中这一衔接由 kubelet-config.yaml.j2 完成验证时 Pod 内resolv.conf的nameserver即应指向169.254.20.10见下文验证章节若仍为10.68.0.2则说明 kubelet 未配置 local dns 地址或配置未生效。五、验证 DNS 服务1. 创建测试服务kubectl run nginx --imagenginx --expose --port80确认服务已就绪kubectl get pod | grep nginx nginx-7cbc4b4d9c-fl46v 1/1 Running 0 1m kubectl get svc | grep nginx nginx ClusterIP 10.68.33.167 none 80/TCP 1m2. 在测试 Pod 内验证解析kubectl run test --rm -it --imagealpine /bin/sh If you dont see a command prompt, try pressing enter. / # cat /etc/resolv.conf nameserver 10.68.0.2 search default.svc.cluster.local. svc.cluster.local. cluster.local. options ndots:5 # 测试集群内部服务解析 / # nslookup nginx.default.svc.cluster.local Server: 10.68.0.2 Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local Name: nginx Address 1: 10.68.33.167 nginx.default.svc.cluster.local / # nslookup kubernetes.default.svc.cluster.local Server: 10.68.0.2 Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local Name: kubernetes Address 1: 10.68.0.1 kubernetes.default.svc.cluster.local # 测试外部域名的解析默认集成node的dns解析 / # nslookup www.baidu.com Server: 10.68.0.2 Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local Name: www.baidu.com Address 1: 180.97.33.108 Address 2: 180.97.33.107 / #输出要点解读resolv.conf中nameserver 10.68.0.2为集群 DNS Service IPsearch域与ndots:5由 kubelet 注入集群内部名解析返回 ClusterIPnginx → 10.68.33.167、kubernetes → 10.68.0.1apiserver 集群 IP外部域名www.baidu.com由 CoreDNS 的forward . /etc/resolv.conf转发至节点上游 DNS 完成解析多个 A 记录经loadbalance插件随机返回。若集群启用了 NodeLocal DNSCache 且 kubelet 正确指向169.254.20.10上述测试中的nameserver应显示为169.254.20.10解析结果不变。六、实战排错案例案例 1calico 网络下 DNS Pod CrashLoopBackOff原文档 Note1使用 calico 作为网络插件时安装集群后直接安装 DNS 组件可能出现如下故障calico 分配 Pod 地址时会从网段的第一个地址网络地址开始分配导致kube-dnsPod 恰好拿到与网络地址冲突的 IP出现CrashLoopBackOff。故障现象$ kubectl get pod --all-namespaces -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE default busy-5cc98488d4-s894w 1/1 Running 0 28m 172.20.24.193 192.168.97.24 kube-system calico-kube-controllers-6597d9c664-nq9hn 1/1 Running 0 1h 192.168.97.24 192.168.97.24 kube-system calico-node-f8gnf 2/2 Running 0 1h 192.168.97.24 192.168.97.24 kube-system kube-dns-69bf9d5cc9-c68mw 0/3 CrashLoopBackOff 27 31m 172.20.24.192 192.168.97.24解决办法临时删除该 Pod让其自动重建并获取后续可用 IP$ kubectl delete pod -n kube-system kube-dns-69bf9d5cc9-c68mw案例 2busybox 内 nslookup 解析异常原文档 Note2使用kubectl run test -it --rm --imagebusybox /bin/sh进行解析测试可能会失败——busybox 内置的 nslookup 程序存在已知 bug例如对SRV记录、搜索域拼接等处理不正确。因此推荐使用 alpine 镜像如上文验证章节所示进行 DNS 解析验证或改用nslookup之外的dig、getent hosts等方式交叉确认。案例 3Pod 无法解析排查路径当业务 Pod 报 “could not resolve host” 时按以下顺序排查kubectl get pod -n kube-system -o wide | grep -E coredns|node-local-dns确认两组 Pod 均 Running查看 Podresolv.confnameserver是否为169.254.20.10启用 nodelocaldns或10.68.0.2纯 corednssearch域是否包含cluster.local在集群内直接用nslookup测试集群域与外部域判断是 CoreDNS 不可达还是上游转发失败若为 CoreDNS 异常kubectl logs -n kube-system coredns-pod查看forward错误日志并确认kube-dnsService 的clusterIP与CLUSTER_DNS_SVC_IP一致。七、小结在 kubeasz 集群中DNS 采用“CoreDNS集群级解析 NodeLocal DNSCache节点级缓存”两级架构CoreDNS 通过kubernetes插件解析集群服务与 Pod 记录通过forward插件代理外部域名NodeLocal DNSCache 以 DaemonSet 在每个节点缓存并 TCP 转发请求显著降低 DNS timeout 频次提升稳定性部署完全融入ezctl setup自动化流程由dns_install与ENABLE_LOCAL_DNS_CACHE两个开关控制模板按PROXY_MODE自动选择 ipvs 或 iptables/nftables 变体关键配置点集中在 roles/cluster-addon/templates/dns/、roles/cluster-addon/vars/main.yml 与 example/config.ymlKubelet 侧衔接见 kubelet-config.yaml.j2。掌握上述部署与验证方法后即可在 kubeasz 集群中快速交付一个稳定、可观测、可排障的集群 DNS 服务。【免费下载链接】kubeasz使用Ansible脚本安装K8S集群介绍组件交互原理方便直接不受国内网络环境影响项目地址: https://gitcode.com/GitHub_Trending/ku/kubeasz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考