我即将使用 KubeSpray 部署一个新的 K8S 裸机集群。在我的代理上，我已经解决了运行不从 DNS 设置/etc/resolvd.conf而是从/etc/systemd/resolved.conf.
那么哪个是最好的 DNS 设置呢？核心DNS？库贝DNS ? 只是想确保我部署的 pod 使用与我的代理节点上配置的相同 DNS 服务器。
我应该选择什么
# Can be dnsmasq_kubedns, kubedns, coredns, coredns_dual, manual or none
dns_mode: kubedns
# Set manual server if using a custom cluster DNS server
#manual_dns_server: 10.x.x.x
# Can be docker_dns, host_resolvconf or none
resolvconf_mode: docker_dns
?
根据官方文档：
从 Kubernetes v1.12 开始，CoreDNS 是推荐的 DNS 服务器，取代 kube-dns。但是，kube-dns 可能仍会在某些 Kubernetes 安装程序工具中默认安装。请参阅安装程序提供的文档以了解默认安装的 DNS 服务器。
CoreDNS 部署公开为具有静态 IP 的 Kubernetes 服务。CoreDNS 和 kube-dns 服务都 kube-dns 在 metadata.name 字段中命名。这样做是为了与依赖旧 kube-dns 服务名称来解析集群内部地址的工作负载具有更大的互操作性。它抽象出哪个 DNS 提供商在该公共端点后面运行的实现细节。
如果 Pod dnsPolicy 设置为“<code>default”，它会从运行 Pod 的节点继承名称解析配置。Pod 的 DNS 解析应该与节点相同。但请参阅 已知问题。
如果你不想要这个，或者你想要一个不同的 pod 的 DNS 配置，你可以使用 kubelet 的 --resolv-conf 标志。将此标志设置为“”以防止 Pod 继承 DNS。/etc/resolv.conf 将其设置为有效的文件路径以指定DNS 继承以外的文件 。
已知问题：
一些 Linux 发行版（例如 Ubuntu）默认使用本地 DNS 解析器（systemd-resolved）。Systemd-resolved 移动并替换 /etc/resolv.conf 为存根文件，当解析上游服务器中的名称时，该存根文件可能会导致致命的转发循环。这可以通过使用 kubelet 的 --resolv-conf 标志指向正确的 resolv.conf（使用 systemd-resolved，this is /run/systemd/resolve/resolv.conf）手动修复。kubeadm 1.11 自动检测 systemd-resolved并相应地调整 kubelet 标志。
默认情况下， Kubernetes 安装不会将节点的 resolv.conf 文件配置为使用集群 DNS，因为该过程本质上是特定于分发的。这可能最终应该实施。
Linux 的 libc 不可能被卡住（参见 2005 年的这个错误），只有 3 个 DNS nameserver 记录和 6 个 DNS search 记录的限制。Kubernetes 需要消耗 1 条nameserver记录和 3 search 条记录。这意味着如果本地安装已经使用 3 nameservers 或使用超过 3 searches，其中一些设置将丢失。作为部分解决方法，节点可以运行 dnsmasq ，这将提供更多 nameserver 条目，但不会提供更多 search 条目。您也可以使用 kubelet 的 --resolv-conf 标志。
如果您使用 Alpine 3.3 或更早版本作为基础映像，由于 Alpine 的一个已知问题，DNS 可能无法正常工作。在这里查看 更多信息。