第三部分：DNS 组件 CoreDNS 介绍

type

status

date

slug

summary

📝 前言

在 Kubernetes 集群中，服务发现是至关重要的基础能力。

用户通过 Service 名称 访问服务，而非直接依赖 Pod 的 IP 地址，这极大简化了服务访问与调用。

而要实现这种服务发现机制 DNS 组件就是核心。

在 Kubernetes 中，默认的 DNS 组件是 CoreDNS，它负责为集群内的 Service、Pod 提供域名解析，从而让应用能够以更直观、稳定的方式进行通信。

CoreDNS 也是集群不可或缺的组件之一，本篇就带领大家了解一下 CoreDNS。

本篇也是云原生之旅系列第三部分的最后一篇，下一篇将正式进入 Kubernetes 实战部分，围绕如何使用 Kubernetes 进行展开，感兴趣的同学可以持续关注~

🧠 本章知识卡片

🚀 本章小节

1️⃣ 什么是 CoreDNS？

CoreDNS 是一个用 Go 语言编写的 可扩展 DNS 服务器，从 Kubernetes v1.13 开始成为默认的 DNS 组件，用来替代 kube-dns。

它的核心定位是：

服务发现中枢：为 Kubernetes Service、Pod 提供域名解析。

插件化 DNS 平台：支持多种插件扩展，例如负载均衡、缓存、日志等。

轻量高效：性能优于 kube-dns，架构更清晰，配置灵活。

一句话通俗描述：CoreDNS 就像 Kubernetes 集群里的“电话簿”，帮你把服务名字翻译成地址，让应用能找到彼此。

CoreDNS 与其他传统 DNS 服务器如（BIND、PowerDNS）不同，因为它非常的灵活，几乎所有功能都可以通过插件来完成。

2️⃣ CoreDNS 的工作原理

在 Kubernetes 集群中，Service 和 Pod 的访问依赖 集群 DNS 服务 来实现域名解析。

CoreDNS 本身是一个通用的 DNS 服务器，但为了能够理解和解析 Kubernetes 内部的服务域名（例如 my-svc.my-namespace.svc.cluster.local），它必须通过插件机制对接 Kubernetes。

CoreDNS 的设计核心是 插件链（Plugin Chain）。

当 CoreDNS 接收到一个 DNS 请求时，请求会按照 Corefile 配置中的插件顺序依次处理，直到某个插件返回结果为止。

例如，常见插件链可能是：

3️⃣ CoreDNS 工作流程

通常在 kubernetes 集群中，CoreDNS 的工作流程如下：

Pod 发起 DNS 请求：Pod 内部应用通过 /etc/resolv.conf 把请求发到 CoreDNS。

CoreDNS 处理请求：CoreDNS 收到请求后，逐个插件处理。

kubernetes 插件解析域名：

CoreDNS 调用 kubernetes 插件，向 kube-apiserver 查询该 Service/Pod 是否存在。
如果匹配到，则返回 Service 的 ClusterIP 或 Pod 的 IP。

forward 插件兜底：如果 kubernetes 插件无法解析（例如外部域名 google.com），请求会交给 forward 插件，转发到宿主机 /etc/resolv.conf 指定的上游 DNS。

cache 插件优化：结果会被缓存，后续相同请求直接返回，提高性能。

4️⃣ CoreDNS 工作时序图

5️⃣ CoreDNS 默认配置介绍

通常在 kubernetes 集群中 CoreDNS 的默认配置文件是在kube-system命名空间下的coredns configmap内，可通过如下命令进行查看：

内容如下：

配置说明：

.:53 . 表示监听所有域名（根域）,:53 表示 CoreDNS 在 53 端口上监听 DNS 请求。53 是 DNS 协议的标准端口。

errors：打印错误日志，方便排查 CoreDNS 的问题。

health：提供健康检查接口，默认在 http://localhost:8080/health。K8s 会用它来判断 CoreDNS Pod 是否健康。

kubernetes cluster.local in-addr.arpa ip6.arpa { ... }

这是最核心的配置，启用 kubernetes 插件，用于处理集群内的 DNS 请求。

cluster.local：Kubernetes 内部默认域名后缀。

Service 解析：my-svc.my-ns.svc.cluster.local

Pod 解析：10-244-0-5.default.pod.cluster.local

in-addr.arpa / ip6.arpa：用于处理反向解析（IP → 主机名）。

pods insecure：允许直接解析 Pod IP 对应的 DNS 名（比如 10-244-0-5.default.pod.cluster.local）。

fallthrough in-addr.arpa ip6.arpa：如果 CoreDNS 在这些反向解析域名（IP→域名）中未找到匹配记录，就把请求“传递”给下一个插件。避免 CoreDNS 吞掉无法处理的请求。

prometheus :9153 暴露 CoreDNS 的 Prometheus 指标（监听在 9153 端口）。

forward . /etc/resolv.conf 当 CoreDNS 无法解析域名（例如外部域名 google.com），会使用 forward 插件把请求转发到上游 DNS。

cache 30 启用缓存，缓存 TTL 为 30 秒，避免频繁访问 kube-apiserver 或外部 DNS，提高性能。

loop：防止 DNS 请求在 CoreDNS 内部形成死循环（例如错误配置时 CoreDNS 反复查询自己）。

reload：支持热加载，当 ConfigMap 更新时，CoreDNS 自动重新加载配置，而不需要重启 Pod。

loadbalance：如果有多个解析结果（比如 Service 对应多个 Pod IP），loadbalance 会随机打散返回顺序，达到负载均衡效果。

6️⃣ CoreDNS 在生产环境的优化

在大规模集群或对解析性能要求较高的环境中，可以考虑以下优化：

开启缓存插件合理设置缓存 TTL，减少重复查询，减轻 apiserver 压力。

合理副本数根据集群规模（节点/Pod 数量）调整 CoreDNS 的副本数，避免成为性能瓶颈。

使用 NodeLocal DNSCache 在节点本地部署缓存代理，Pod 优先查询本地缓存，减少 CoreDNS 和网络压力。

监控与告警使用 Prometheus + Grafana 监控 CoreDNS 的查询延迟、错误率，及时发现异常。

✅ 总结

CoreDNS 是 Kubernetes 集群中不可或缺的组件，它不仅解决了 Pod 与 Service 的服务发现问题，还提供了灵活的插件化扩展能力。

在生产环境中，合理配置 CoreDNS 并结合缓存和监控机制，可以有效提升服务解析的稳定性和性能。

💡

有关文章的任何疑问，欢迎您在底部评论区留言，一起交流~

若文章对您有帮助，欢迎请我喝杯咖啡~