09-kubernetes中的域名解析流程

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了09-kubernetes中的域名解析流程相关的知识，希望对你有一定的参考价值。

参考技术A

从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）
https://blog.51cto.com/u_12965094/2641238
（2）自定义 DNS 服务
https://kubernetes.io/zh/docs/tasks/administer-cluster/dns-custom-nameservers/
（3）Kubernetes 服务发现之 coreDNS
https://juejin.cn/post/6844903965520297991
（4）Kubernetes 集群 DNS 服务发现原理
https://developer.aliyun.com/article/779121
（5）Kubernetes之服务发现和域名解析过程分析
https://www.jianshu.com/p/80ad7ff37744

kubernetes CoreDNS全解析

文章目录

一、前言

kubernetes CoreDNS 是 kube-system 命令空间里面的一个Pod，用于域名解析。

kubernetes自带三个命名空间（用kubeadm安装的Kubernetes集群）：
default kube-public kube-system
前两个不重要，kube-system命名空间很重要，静态Pod都在这个命名空间里面。

kube-system中，与网络相关的三个Pod
kube-proxy：
calico：解决的是node1与node2之间（不同节点之间）网络通不通的问题。
验证1：kubectl get pod -n kube-system 查看calico是否正常运行Running；
验证2：在node1 ping 另一个节点node2 上 serviceName.namespace ，验证通不通。
CoreDNS：解决的是 ping 内网ip 可以通，ping serviceName.namespace 不通，报错为 name server unknown；ping 外网ip 可以通，ping 外网域名 不通的问题，报错为 name server unknown。解决的是将 域名解析为ip 的问题。

二、调用流程

pod - service - deployment - replicaset - 两个pod - configmap - linux



kubectl get deployment coredns -o yaml -n kube-system

小结：调用流程

pod - service - deployment - replicaset - 两个pod - configmap - linux

所有命令：
kubectl get pod -n kube-system -o wide
kubectl exec -it nginx bash
cat /etc/resolv.conf 
kubectl get all -o wide -A | grep 10.96.0.10
kubectl get all -o wide -A | grep kube-dns
kubectl get all -o wide -A | grep coredns
kubectl get deployment coredns -o yaml -n kube-system
kubectl get configmap coredns -o yaml -n kube-system

三、CoreDNS

3.1 dnsPolicy的四个属性

Kubernetes 中 Pod 的 DNS 策略有四种类型，yaml 文件中通过 dnsPolicy 和 dnsConfig 两个属性来指定 Pod 的dns方式。

1.Default：Pod 继承所在主机上的 DNS 配置；

2.ClusterFirst：K8s 的默认设置；先在 K8s 集群配置的 coreDNS 中查询，查不到的再去继承自主机的上游 nameserver 中查询（就是通过 configmap 里面的 forward 属性来指定上游服务器）；

3.ClusterFirstWithHostNet：对于网络配置为 hostNetwork 的 Pod 而言，其 DNS 配置规则与 ClusterFirst 一致；

4.None：忽略 K8s 环境的 DNS 配置，只认 Pod 的 dnsConfig 设置。（当 dnsPolicy 指定为 none，dnsConfig 属性必须配置）

默认是 ClusterFirst ，表示 ping serviceName.namespace 可以，ping 外网域名 报错 name server unknown。

设置为 Default 表示 继承所在主机上的 DNS 配置，但是 ping serviceName.namespace 报错 name server unknown。

3.2 Corefile 各自字段什么意思

53 表示的 kube-dns Service 服务的端口，其他的如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 
        errors
        health 
            lameduck 5s
        
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa 
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance

Corefile 配置包括以下 CoreDNS 插件：

errors：错误记录到标准输出。

health：在 http://localhost:8080/health 处提供 CoreDNS 的健康报告。

ready：在端口 8181 上提供的一个 HTTP 末端，当所有能够 表达自身就绪的插件都已就绪时，在此末端返回 200 OK。

kubernetes：CoreDNS 将基于 Kubernetes 的服务和 Pod 的 IP 答复 DNS 查询。你可以在 CoreDNS 网站阅读更多细节。 你可以使用 ttl 来定制响应的 TTL。默认值是 5 秒钟。TTL 的最小值可以是 0 秒钟， 最大值为 3600 秒。将 TTL 设置为 0 可以禁止对 DNS 记录进行缓存。

pods insecure 选项是为了与 kube-dns 向后兼容。你可以使用 pods verified 选项，该选项使得 仅在相同名称空间中存在具有匹配 IP 的 Pod 时才返回 A 记录。如果你不使用 Pod 记录，则可以使用 pods disabled 选项。

prometheus：CoreDNS 的度量指标值以 Prometheus 格式在 http://localhost:9153/metrics 上提供。

forward: 不在 Kubernetes 集群域内的任何查询都将转发到 预定义的解析器 (/etc/resolv.conf).

cache：启用前端缓存。

loop：检测到简单的转发环，如果发现死循环，则中止 CoreDNS 进程。

reload：允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后，请等待两分钟，以使更改生效。

loadbalance：这是一个轮转式 DNS 负载均衡器， 它在应答中随机分配 A、AAAA 和 MX 记录的顺序。

参考资料（Corefile 各自字段什么意思）：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/

3.3 让container同时内网和外网（通过 forward 属性配置上游域名解析服务器来实现）

让container同时内网和外网，通过 forward 属性配置上游域名解析服务器来实现

[root@w1 ~]# kubectl get configmap coredns -o yaml -n kube-system
apiVersion: v1
data:
  Corefile: |
    .:53 
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa 
           pods insecure
           upstream
           fallthrough in-addr.arpa ip6.arpa
        
        prometheus :9153
        # 这里表示将使用本机linux的域名解析，可以配置为ip，表示其他的机器
        forward . /etc/resolv.conf  
        cache 30
        loop
        reload
        loadbalance
    
kind: ConfigMap
metadata:
  creationTimestamp: "2022-07-28T16:05:03Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "200"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 0a6711df-0e8f-11ed-a989-000c291867b4

yaml里面的指定 dnsPolicy 为 ClusterFirst 或者不指定，因为默认就是 ClusterFirst，只需要修改 configmap 里面的 forward . /etc/resolv.conf 配置上上游的域名解析服务器为本地。

查看本机使用的域名解析服务器

cat /etc/resolv.conf
nameserver 表示域名解析器

3.4 CoreDNS 配置等同于 kube-dns

在 Kubernetes 1.21 版本中，kubeadm 移除了对将 kube-dns 作为 DNS 应用的支持。 对于 kubeadm v1.24，所支持的唯一的集群 DNS 应用是 CoreDNS。

参考资料：https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/coredns/

四、尾声

kubernetes CoreDNS全解析，完成了。

以上是关于09-kubernetes中的域名解析流程的主要内容，如果未能解决你的问题，请参考以下文章

域名解析的原理是什么？域名解析的流程是怎样的？

建站必备知识：域名注册和域名解析流程有哪些？

域名解析

域名注册域名实名认证域名解析流程详解

DNS分层结构及DNS解析流程

DNS工作流程及原理 域名IP与DNS的关系