我打算使用KubeSpray部署新的K8S裸机集群。
在我的代理上,我运行的是resolvd,它不从/etc/resolvd.conf
获取DNS设置,而是从/etc/systemd/resolved.conf
获取DNS设置。
那么哪个是最好的DNS设置? CoreDNS? KubeDNS?只是要确保我部署的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
?
答案 0 :(得分:1)
从Kubernetes v1.12开始, CoreDNS是推荐的DNS服务器,代替了kube-dns 。但是,默认情况下,某些Kubernetes安装程序工具仍可能安装kube-dns。请参阅安装程序提供的文档,以了解默认情况下安装了哪个DNS服务器。
CoreDNS部署作为具有静态IP的Kubernetes服务公开。在kube-dns
字段中,CoreDNS和kube-dns服务都被命名为metadata.name
。这样做是为了与依靠旧版kube-dns
服务名称来解析群集内部地址的工作负载具有更大的互操作性。它抽象出了哪个DNS提供程序在该公共端点后面运行的实现细节。
如果Pod的dnsPolicy
设置为“ default
”,它将从Pod运行所在的节点继承名称解析配置。 Pod的DNS解析应与节点具有相同的行为。但是请参见Known issues。
如果您不想这样做,或者想要对Pod使用不同的DNS配置,则可以使用kubelet的--resolv-conf
标志。将此标志设置为“”可以防止Pod继承DNS。将其设置为有效的文件路径,以指定用于DNS继承的/etc/resolv.conf
以外的文件。
某些Linux发行版(例如Ubuntu),默认情况下使用本地DNS解析器(systemd-resolved)。 Systemd解决的问题将移动/etc/resolv.conf
并将其替换为存根文件,当在上游服务器中解析名称时,存根文件可能导致致命的转发循环。可以通过使用kubelet的--resolv-conf
标志来指向正确的resolv.conf
来手动解决此问题(对于systemd-resolved
,这是/run/systemd/resolve/resolv.conf
)。 kubeadm 1.11自动检测到systemd-resolved
,并相应地调整kubelet标志。
Kubernetes安装默认情况下不会将节点的resolv.conf
文件配置为使用群集DNS,因为该过程本质上是特定于发行版的。这可能最终应该实现。
Linux的libc不可能卡住(see this bug from 2005),限制为3个DNS nameserver
记录和6个DNS search
记录。 Kubernetes需要消耗1 nameserver
条记录和3 search
条记录。这意味着,如果本地安装已经使用了3 nameserver
或使用了3 search
个以上,则其中的某些设置将丢失。作为部分解决方法,节点可以运行dnsmasq
,这将提供更多nameserver
条目,但不会提供更多search
条目。您还可以使用kubelet的--resolv-conf
标志。
如果您使用Alpine 3.3或更早版本作为基本映像,则由于Alpine的已知问题,DNS可能无法正常工作。检查here了解更多信息。