K8s DNS #

DNS 策略 #

Default
- The Pod inherits the name resolution configuration from the node that the pods run on
ClusterFirst
- Any DNS query that does not match the configured cluster domain suffix, such as “www.kubernetes.io”, is forwarded to the upstream nameserver inherited from the node.
ClusterFirstWithHostNet
- For Pods running with hostNetwork, you should explicitly set its DNS policy “ClusterFirstWithHostNet”
None
- It allows a Pod to ignore DNS settings from the Kubernetes environment.
- All DNS settings are supposed to be provided using the dnsConfig field in the Pod Spec.

“`Default`” is not the default DNS policy. If dnsPolicy is not explicitly specified, then “`ClusterFirst`” is used.

参考：

Pod’s DNS Policy

k8s 中域名是如何被解析的 #

在 k8s 中，一个 Pod 如果要访问相同 Namespace 下的 Service（比如 user-svc），那么只需要 curl user-svc。如果 Pod 和 Service 不在同一域名下，那么就需要在 Service Name 之后添加上 Service 所在的 Namespace（比如 beta），curl user-svc.beta。那么 k8s 是如何知道这些域名是内部域名并为他们做解析的呢？

无论是在宿主机或者是在 k8s 集群中，DNS 解析会依赖这个三个文件

/etc/host.conf
/etc/hosts
/etc/resolv.conf

/etc/resolv.conf #

resolv.conf 是 Pod 在 dnsPolicy: ClusterFirst 的情况下，k8s 为其自动生成的。在该 Pod 内请求的所有的域名解析都需要经过 DNS Service 进行解析，不管是集群内部域名还是外部域名。

每行都会以一个关键字开头，然后跟配置参数。

在集群中主要使用到的关键词有 3 个

nameserver 定义 DNS 服务器的 IP 地址（Kube-DNS 的 Service IP）
search 定义域名的搜索列表，当查询的域名中包含的 . 的数量少于 options.ndots 的值时，会依次匹配列表中的每个值
options 定义域名查找时的配置信息

nameserver、search 和 options 都是可以通过 dnsConfig 字段进行配置的，详细参考官方文档

例如

nameserver 10.250.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

nameserver #

nameserver 所对应的地址正是 DNS Service 的 Cluster IP（该值在启动 kubelet 的时候，通过 clusterDNS 指定）。

search 域 #

search 域默认包含了 namespace.svc.cluster.local、svc.cluster.local 和 cluster.local 三种。

当我们在 Pod 中访问 a Service 时（ curl a ），会选择 nameserver 10.250.0.10 进行解析，然后依次带入 search 域进行 DNS 查找，直到找到为止。

$ curl a
a.default.svc.cluster.local

显然因为 Pod 和 a Service 在同一 Namespace 下，所以第一次 lookup 就能找到。

如果 Pod 要访问不同 Namespace（例如： beta ）下的 Service b （ curl b.beta ），会经过两次 DNS 查找，分别是

$ curl b.beta
b.beta.default.svc.cluster.local # Not Found
b.beta.svc.cluster.local # Found

正是因为 search 的顺序性，所以访问同一 Namespace 下的 Service， curl a 是要比 curl a.default 的效率更高的，因为后者多经过了一次 DNS 解析。

$ curl a
a.default.svc.cluster.local # Found

$ curl a.default
b.default.default.svc.cluster.local # Not Found
b.default.svc.cluster.local # Found

options #

ndots #

ndots:5，表示：

如果需要 lookup 的 Domain 中包含少于 5 个 . ，那么将会被当做非绝对域名，
如果需要查询的 Domain 中包含大于或等于 5 个 . ，那么就会被当做绝对域名。

如果是绝对域名则不会走 search 域，

如果是非绝对域名，就会按照 search 域中进行逐一匹配查询，如果 search 走完了都没有找到，那么就会使用原域名进行查找。

优化外网域名解析 #

在真正解析 http://iftech.io 之前，经历了

iftech.io.default.svc.cluster.local
-> iftech.io.svc.cluster.local
-> iftech.io.cluster.local
-> iftech.io

这样也就意味着前 3 次 DNS 请求是浪费的，没有意义的。

直接使用绝对域名 #

这是最简单直接的优化方式，可以直接在要访问的域名后面加上 . 如：iftech.io. ，这样就可以避免走 search 域进行匹配。

配置 ndots #

比如配置 ndots:1，iftech.io. 就会使用原域名进行查找。

CoreDNS vs KubeDNS #

在 kube-dns 中，一个 pod 内使用了数个容器：kubedns、dnsmasq 和 sidecar。

kubedns 容器监视 Kubernetes API 并基于 Kubernetes DNS 规范提供 DNS 记录，
dnsmasq 提供缓存和存根域支持，
sidecar 提供指标和健康检查。

此设置会导致一些问题随着时间的推移而出现。首先，dnsmasq 中的安全漏洞导致过去需要发布 Kubernetes 安全补丁。此外，由于 dnsmasq 处理存根域，但 kubedns 处理 External Services，因此你无法在外部服务中使用存根域，这非常限制该功能（参阅 dns＃131）。

在 CoreDNS 中，所有这些功能都在一个容器中完成 —— 该容器运行用 Go 编写的进程。启用的不同插件来复制（并增强）kube-dns 中的功能。

为什么 pod 是 coredns，service 是 kube-dns？ #

其实是 CoreDNS

CoreDNS is default from K8S 1.11. For previous installations it’s kube-dns.

看 image，其他都是 metadata，不重要

$ k describe pod coredns-6967fb4995-76trs -n kube-system | grep -i "image"

Image:         registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.3.1

问题详情

$ k cluster-info
Kubernetes master is running at https://192.168.99.102:8443
KubeDNS is running at https://192.168.99.102:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

$ k get po -n kube-system
NAME                               READY   STATUS    RESTARTS   AGE
coredns-6967fb4995-76trs           1/1     Running   6          32d
coredns-6967fb4995-grnzj           1/1     Running   6          32d
etcd-minikube                      1/1     Running   3          32d
kube-addon-manager-minikube        1/1     Running   3          32d
kube-apiserver-minikube            1/1     Running   3          32d
kube-controller-manager-minikube   1/1     Running   3          32d
kube-proxy-z765q                   1/1     Running   3          32d
kube-scheduler-minikube            1/1     Running   3          32d
storage-provisioner                1/1     Running   5          32d

$ k get svc -n kube-system
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   32d

$ k describe svc/kube-dns -n kube-system
Name:              kube-dns
Namespace:         kube-system
Labels:            k8s-app=kube-dns
                   kubernetes.io/cluster-service=true
                   kubernetes.io/name=KubeDNS
Annotations:       prometheus.io/port: 9153
                   prometheus.io/scrape: true
Selector:          k8s-app=kube-dns
Type:              ClusterIP
IP:                10.96.0.10
Port:              dns  53/UDP
TargetPort:        53/UDP
Endpoints:         172.17.0.2:53,172.17.0.3:53
Port:              dns-tcp  53/TCP
TargetPort:        53/TCP
Endpoints:         172.17.0.2:53,172.17.0.3:53
Port:              metrics  9153/TCP
TargetPort:        9153/TCP
Endpoints:         172.17.0.2:9153,172.17.0.3:9153
Session Affinity:  None
Events:            <none>

参考：

Kubernetes: Kube-DNS vs CoreDNS