本文解释如何为kubernetes集群配置及自定义DNS服务。从kubernetes1.11版本开始,coreDNS插件被包含在GA发行版中,并且被kubeadm默认安装。详情:Configuring CoreDNS and Using CoreDNS for Service Discovery。除特别说明,本文讨论的是默认dns插件。
Kubernetes的DNS功能以插件形式提供,是自动启动的系统内置服务。服务包含如下三个容器:
DNS服务拥有静态IP地址,将各节点kubeletr的–cluster-dns=
当kubelet启动容器时,除使用kubernetes内置的DNS服务,默认从节点继承其DNS配置。此特性使kubernetes系统中的容器DNS行为高度依赖低层节点,建议关闭,设置kubelet–resolv-conf选项为用户自定义配置文件,而非系统默认/etc/resolve.conf,这样容器继承的DNS配置由用户提供的配置文件决定,而非节点,降低耦合度。
集群管理员可通过为kubernetes中DNS服务kube-system:kube-dns提供ConfigMap对象,设置自定义存根域及上游DNS服务器。以下示例为DNS服务配置一个存根域及两个上游DNS服务器:
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{"acme.local": ["1.2.3.4"]}
upstreamNameservers: |
["8.8.8.8", "8.8.4.4"]
如果查询请求的前缀为”acme.local”则被直接转发到1.2.3.4。下表列出不同域名前缀与DNS服务器对应关系:
如果pod Spec之dnsPolicy设置为”Default”或者”Node”,则用户自定义存根服务器与上游服务器对pod没有影响。当值为”Default”时,pod之DNS配置完全从节点继承。如果为Node,则取决于pod Spec中的dnsConfig配置。
当dnsPolicy设置为”ClusterFirst”时,pod的DNS配置分成没无自定义存根域与上游服务器、有自定义存根域与上游服务器两种情况。
无自定义存根域与上游服务器:如果查询请求之域名前缀与集群默认域名匹配,则使用kubernetes内置DNS服务,如果不匹配则使用从节点继承之DNS服务。
有自定义存根域与上游服务器,域名解析流程如下:
在缓存层,检查请求的域名前缀并将请求转发到与之匹配的DNS服务器,流程如下:
与集群域名前缀匹配,如“.cluster.local”,则发往kube-dns。
如与存根域匹配,如“.acme.local”, 则发往匹配的存根域服务器。
否则,发往上游服务器。
从1.9版本开始,CoreDNS成为GA可选特性,将来可能会取代kube-dns成为默认集群默认DNS解决方案,CoreDNS具备kube-dns所有功能并更强大。在CoreDNS插件内部通过一种Corefile文件管理配置。可以直接将为kube-dns设置的ConfigMap直接指定给CoreDNS,CoreDNS自动将此ConfigMap转换成Corefile。示例如下:
apiVersion: v1
data:
federations: |
{"foo" : "foo.feddomain.com"}
stubDomains: |
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
upstreamNameservers: |
["8.8.8.8", "8.8.4.4"]
kind: ConfigMap
转换结果:
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
upstream 8.8.8.8 8.8.4.4
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
federation cluster.local {
foo foo.feddomain.com
}
prometheus :9153
proxy . 8.8.8.8 8.8.4.4
cache 30
}
abc.com:53 {
errors
cache 30
proxy . 1.2.3.4
}
my.cluster.local:53 {
errors
cache 30
proxy . 2.3.4.5
}