当前位置：首页 > news >正文

Kubernetes相关的名词解释CoreDNS插件（2）

news 来源：原创 2025/4/20 17:17:20

为什么需要DNS服务？

service发现是k8s中的一个重要机制，其基本功能为：在集群内通过服务名对服务进行访问，即需要完成从服务名到ClusterIP的解析。
k8s主要有两种service发现机制：环境变量和DNS。没有DNS服务的时候，k8s会采用环境变量的形式，但一旦有多个service，环境变量会变复杂，为解决该问题，我们使用DNS服务。

什么是CoreDNS？

CoreDNS 是 Kubernetes 的核心组件之一，作为默认的 DNS 服务插件，用于提供集群内的服务发现和域名解析功能。

CoreDNS 不是“可选”插件，而是 Kubernetes 的核心基础设施组件，负责集群内 DNS 解析。它的设计轻量、模块化，完美契合 Kubernetes 的服务发现需求。

CoreDNS 在 Kubernetes 中的角色

替代 Kube-DNS：自 Kubernetes 1.13 起，CoreDNS 取代了早期的 kube-dns，成为默认的 DNS 服务。
服务发现：允许 Pod 通过服务名称（如 my-service.namespace.svc.cluster.local）访问其他服务，无需硬编码 IP。
集群域解析：处理 .svc.cluster.local、.pod.cluster.local 等集群内域名的解析。

coredns的架构是怎么样的？

通过下图可以很好的理解coredns的架构，CoreDNS 在 Kubernetes 中以 Pod 的形式运行，并作为一个（或多个）容器部署在集群内。

CoreDNS的部署方式

前面说了CoreDNS 在 Kubernetes 中以 Pod 的形式运行，在描述一下其部署方式：

Pod 中的容器：
CoreDNS 通常以 Deployment 或 ReplicaSet 的形式部署在 kube-system 命名空间下，每个 Pod 包含 1 个 CoreDNS 容器（镜像为 coredns/coredns）。
多副本高可用：
默认情况下会启动多个副本（例如 2 个），分布在不同的节点上，确保 DNS 服务的高可用性。

为什么以 Pod 形式运行？

隔离性：
作为独立 Pod 运行，避免与宿主或其他服务冲突。
动态管理：
可通过 Kubernetes 的机制（如滚动更新、健康检查）维护 CoreDNS 的可用性。
资源限制：
方便通过 requests/limits 控制 CPU/内存资源。

CoreDNS还有其他替代方案吗？

在 Kubernetes 中，CoreDNS 是默认的 DNS 和服务发现插件，但确实存在其他替代方案，类似于 containerd 和 Docker 在容器运行时领域的竞争关系。

主要替代方案

(1) kube-dns（已弃用）

历史地位：Kubernetes 早期默认的 DNS 服务（由 kube-dns Pod 提供）。
组件：整合了 skyDNS、dnsmasq 和 sidecar 健康检查。
现状：自 Kubernetes 1.13 起被 CoreDNS 取代，但仍可通过手动部署使用（不推荐）。

(2) Istio 的 DNS 代理

场景：在 Service Mesh 中，Istio 的 Sidecar（Envoy）可接管 DNS 解析，实现更细粒度的流量控制。
特点：依赖 Istio 的 istio-agent，支持多集群 DNS 和自定义规则。

(3) 其他自定义 DNS 方案

ExternalDNS：将 Kubernetes Service 记录同步到外部 DNS 系统（如 AWS Route53、Cloudflare）。
NodeLocal DNSCache：在节点级缓存 DNS 请求以提升性能（需配合 CoreDNS 使用）。

为什么 CoreDNS 是主流？

对比维度	CoreDNS	kube-dns（旧版）	Istio DNS
性能	更高（Go 编写，插件化）	较低（多组件协作）	依赖 Envoy 代理
灵活性	支持插件链（如缓存、转发、日志）	固定功能	深度集成 Service Mesh
维护性	活跃维护，Kubernetes 官方推荐	已弃用	需额外部署 Istio
适用场景	通用集群	旧版本兼容	需要高级流量管理的场景

虽然存在替代品（如 kube-dns 或 Istio 的方案），但 CoreDNS 凭借其性能、灵活性和官方支持 成为事实标准。替换 CoreDNS 需谨慎评估需求，通常仅在特殊场景（如深度集成 Service Mesh）时才有必要。

前面说的替代方案中的kube-dns其实也是coredns的发展进化的一个阶段。

DNS在kubernetes中的进化史

DNS服务在kubernetes中经历了三个阶段（SkyDNS-》KubeDNS-》CoreDNS）：

【第一阶段】在kubernetes 1.2版本时，dns服务使用的是由SkyDNS提供的，由4个容器组成：kube2sky、skydns、etcd和healthz。etcd存储dns记录；kube2sky监控service变化，生成dns记录；skydns读取服务，提供查询服务；healthz提供健康检查。
【第二阶段】在kubernetes 1.4版本开始使用KubeDNS，有3个容器组成：kubedns、dnsmasq和sidecar。kubedns监控service变化，并记录到内存（存到内存提高性能）中；dnsmasq获取dns记录，提供dns缓存，提供dns查询服务；sidecar提供健康检查。
【第三阶段】从kubernetes >=1.11版本开始，dns服务有CoreDNS提供，coredns支持自定义dns记录及配置upstream dns server，可以统一管理内部dns和物理dns。coredns只有一个coredns容器。