09-kubernetes中的域名解析流程

从Kubernetes 1.11版本开始，Kubernetes集群的DNS服务由CoreDNS提供。CoreDNS是CNCF基金会的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端。CoreDNS解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains设置，等等。

成都创新互联公司是一家朝气蓬勃的网站建设公司。公司专注于为企业提供信息化建设解决方案。从事网站开发，网站制作，网站设计，网站模板，微信公众号开发，软件开发，微信平台小程序开发，十余年建站对护栏打桩机等多个行业，拥有丰富的网站营销经验。

CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。

CoreDNS没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能。

从kubernetes官方提供的 coredns.yml 文件中，不难看出coredns服务配置至少需要一个ConfigMap、一个Deployment和一个Service共3个资源对象。ConfigMap coredns 主要配置文件Corefile的内容：

其中主要有二个地方来解析配置

1、这段配置的意思是cluster.local后缀的域名都是kubernetes内部域名，coredns会监控service的变化来修改域名的记录

2、如果coredns没有找到dns记录，则去找 /etc/resolv.conf 中的 nameserver 解析

接下来使用一个带有nslookup工具的Pod来验证DNS服务能否正常工作：

通过nslookup进行测试。

查找defaul命名空间存在的ng-deploy-80服务

如果某个Service属于不同的命名空间，那么在进行Service查找时，需要补充Namespace的名称，组合成完整的域名。下面以查找kubernetes-dashboard服务为例，

众所周知, DNS 服务器用于将域名转换为 IP (具体为啥要转换建议复习下 7 层网络模型). Linux 服务器中 DNS 解析配置位于 /etc/resolv.conf , 在 Pod 中也不例外,

DNS 策略可以逐个 Pod 来设定。当前kubernetes支持这4中DNS 策略

如果我们不填dnsPolicy, 默认策略就是 ClusterFirst 。

kubelet 在起 pause 容器的时候，会将其 DNS 解析配置初始化成集群内的配置。配置: 它的 nameserver 就是指向 coredns 的

k8s里面有4种DNS策略， 而coredns使用的DNS策略就是Default， 这个策略的意思就是继承宿主机上的/etc/resolve.conf, 所以coredns Pod 里面的/etc/resolve.conf 的内容就是宿主机上的内容。

在集群中 pod 之间互相用 svc name 访问的时候，会根据 resolv.conf 文件的 DNS 配置来解析域名，下面来分析具体的过程。

pod 的 resolv.conf 文件主要有三个部分，分别为 nameserver、search 和 option。而这三个部分可以由 K8s 指定，也可以通过 pod.spec.dnsConfig 字段自定义。

nameserver

resolv.conf 文件的第一行 nameserver 指定的是 DNS 服务的 IP，这里就是 coreDNS 的

clusterIP：

也就是说所有域名的解析，都要经过coreDNS的虚拟IP 10.100.0.2 进行解析， 不论是内部域还是外部域名。

search 域

resolv.conf 文件的第二行指定的是 DNS search 域。解析域名的时候，将要访问的域名依次带入 search 域，进行 DNS 查询。

比如我要在刚才那个 pod 中访问一个域名为 ng-deploy-80的服务，其进行的 DNS 域名查询的顺序是：

options

resolv.conf 文件的第三行指定的是其他项，最常见的是 dnots。dnots 指的是如果查询的域名包含的点 “.” 小于 5，则先走 search 域，再用绝对域名；如果查询的域名包含点数大于或等于 5，则先用绝对域名，再走 search 域。K8s 中默认的配置是 5。

也就是说，如果我访问的是 a.b.c.e.f.g ，那么域名查找的顺序如下：

通过 svc 访问

在 K8s 中，Pod 之间通过 svc 访问的时候，会经过 DNS 域名解析，再拿到 ip 通信。而 K8s 的域名全称为 "service-name.namespace.svc.cluster.local"，而我们通常只需将 svc name 当成域名就能访问到 pod，这一点通过上面的域名解析过程并不难理解。

参考

（1）K8S落地实践 之 服务发现（CoreDNS）

（2）自定义 DNS 服务

（3）Kubernetes 服务发现之 coreDNS

（4）Kubernetes 集群 DNS 服务发现原理

（5）Kubernetes之服务发现和域名解析过程分析

k8s ingress 外部域名（External Domains）

这里涉及两个知识点。第一个是ingress ，第二个是external domains。ingress 大家可能比较熟悉，比如下面的配置，访问hello-world.info的域名，请求”/“目录，将会把请求转发到web 这个服务。

external domains大家可能不经常使用，这个是k8s 提供的CNAME能力，比如下面通过外部域名的功能，为my-service 的域名增加一个 my.database.example点抗 的CNAME，这样当我们在容器里面访问 my-service域名的时候，域名解析到CNAME my.database.example点抗 ，从而将请求转发到 my.database.example点抗 。

但外部域名有个小问题，就是它只是重定向域名，并不会修改 HTTP header，这就导致一个问题：请求url 里面域名和header中的域名不一致。而ingress 大部分都是HTTP 请求。比如下面service 的定义。

当通过 my-sample点抗 请求ingress的时候，ingress转发请求的时候， HTTP HOST header 还是my-sample点抗 ，但上面设置的外部域名是 example点抗 ，这就导致不一致了，nginx无法转发流量。

但我们还可以通过 nginx.ingress.kubernetes.io/upstream-vhost 这个annotation修改我们的请求header，如上面例子，我们将请求header的HOST 修改成 example点抗 就可以成功请求了。

k8s coredns 外网域名解析问题

1. 问题描述

问题表面原因：

在coredns默认配置下，proxy . /etc/resolv.conf

在Poc部署环境中，经常出现在/etc/resolv.conf中没有配置域名的情况，会出现coredns报错的情况：

2. 原因分析

在coredns中，默认有fallthrough的配置

coredns默认配置会将反向地址解析传到配置外部DNS，默认外部DNS为8.8.8.8，会导致反向地址解析要经过超时才有返回。

当而有组件会自动进行反向地址解析，会导致访问超时。

平台组件存在进行反向地址解析的操作，所以导致平台访问变慢。

3. 解决方案(任选一个)

3.1. 注释掉fall through

3.2. 配置正确的外部DNS

问题2：

出现某个域名在某个节点上解析不通，排障思路，进去cordns pod中nslookup该域名，如果通说明pod解析没问题，如果不通则在集群svc ip层面进行nslookup，如果不通那么是svc层面问题，进入到节点，一般为kubelet dns解析出现问题

解决方法：

1、删除原先coredns的配置（随后重启即可）  2、部署coredns  3. 删除原先的pod、service、重新创建。

k8s网络配置DNS

Kubernetes支持Pod维度DNS策略设置，通过pod规约中dnsPolicy字段设置，最终配置落到 /etc/resolv.conf 文件中，也就说k8s最终还是通过设置Pod容器中/etc/resolv.conf 文件来做设置解析配置，跟普通的虚拟机或者实体机是一样，因为Pod容器本身就一个小的主机。

采用集群DNS，与配置的集群域后缀不匹配的任何 DNS 查询 都将转发到从节点继承的上游名称服务器。简单来说，就是使用 Kubernetes 中 kubedns 或 coredns 服务进行域名解析，如果解析不成功，才会使用宿主机的 DNS 配置进行解析。

example容器/etc/resolv.conf

options ndots:5 代表当待解析域名包含.大于等于5时就会先解析域名，只有域名解析不成功时才会继续匹配serach域或domain域

访问test名字空间下example-svc服务，可以直接通过 example-svc 访问，会与search域组合，最终组合成 example-svc.test.svc.cluster.local ，访问test1名字空间下example-svc1，通过 example-svc.test1 ，会与search域组合，最终组合成 example-svc.test1.svc.cluster.local

自定义DNS策略，设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置，Pod 会使用其 dnsConfig 字段 所提供的 DNS 设置。

用户可以在 dnsConfig 字段中指定以下属性：

创建上面的 Pod 后，容器 test 会在其 /etc/resolv.conf 文件中获取以下内容：

Pod 从运行所在的节点继承名称解析配置，即跟所在节点主机一致

对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 为"ClusterFirstWithHostNet"

k8s新版本集群DNS服务是默认采用CoreDNS组件实现，1.13版本之前是采用Kube-dns

当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目， 可以在 Pod 级别覆盖对主机名的解析。你可以通过 PodSpec 的 HostAliases 字段来添加这些自定义条目.

pod打印/etc/hosts文件，多了以下内容