目录

本节实战

实战名称
💘 实战：coredns测试(测试成功)-2023.2.18
💘 实战：Pod的DNS策略-2023.2.18(测试成功)
💘 实战：Pod的DNS设置-2023.2.18(测试成功)

前言

上面我们讲解了 Service 的用法，我们可以通过 Service 生成的 ClusterIP(VIP) 来访问 Pod 提供的服务。但是在使用的时候还有一个问题：我们怎么知道某个应用的 VIP 呢？比如我们有两个应用，一个是 api 应用，一个是 db 应用，两个应用都是通过 Deployment 进行管理的，并且都通过 Service 暴露出了端口提供服务。api 需要连接到 db 这个应用，我们只知道 db 应用的名称和 db 对应的 Service 的名称，但是并不知道它的 VIP 地址，我们前面的 Service 课程中是不是学习到我们通过 ClusterIP 就可以访问到后面的 Pod 服务，如果我们知道了 VIP 的地址是不是就行了？

注意：在实际工作应用中，我们很少去把访问地址用ip固定下来。我们要解决这种问题，一般有2种方法。
第一种：环境变量。
第二种：DNS。

1、环境变量

为了解决上面的问题，在之前的版本中，Kubernetes 采用了环境变量的方法，每个 Pod 启动的时候，会通过环境变量设置所有服务的 IP 和 port 信息，这样 Pod 中的应用可以通过读取环境变量来获取依赖服务的地址信息，这种方法使用起来相对简单，但是有一个很大的问题就是依赖的服务必须在 Pod 启动之前就存在，不然是不会被注入到环境变量中的。

💘 实战：环境变量测试(测试成功)-2023.2.13

• 实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

• 实验软件（无）

• 比如我们首先创建一个 Nginx 服务

#test-nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    name: nginx-service
spec:
  ports:
    - port: 5000
      targetPort: 80
  selector:
    app: nginx

• 创建上面的服务并查看：

[root@master1 ~]#kubectl apply -f test-nginx.yaml 
deployment.apps/nginx-deploy created
service/nginx-service created

[root@master1 ~]#kubectl get po
NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-7759cfdc55-8wqjs   1/1     Running   0          87s
nginx-deploy-7759cfdc55-99ttd   1/1     Running   0          57s
[root@master1 ~]#kubectl get svc
NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
kubernetes      ClusterIP   10.96.0.1        <none>        443/TCP    70d
nginx-service   ClusterIP   10.107.211.179   <none>        5000/TCP   119s
[root@master1 ~]#kubectl get ep
NAME            ENDPOINTS                       AGE
kubernetes      172.29.9.61:6443                70d
nginx-service   10.244.1.60:80,10.244.2.56:80   2m28s

我们可以看到两个 Pod 和一个名为 nginx-service 的服务创建成功了，该 Service 监听的端口是 5000，同时它会把流量转发给它代理的所有 Pod（我们这里就是拥有 app: nginx 标签的两个 Pod）。

• 现在我们再来创建一个普通的 Pod，观察下该 Pod 中的环境变量是否包含上面的 nginx-service 的服务信息

#test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-service-pod
    image: busybox:1.28.3
    command: ["/bin/sh", "-c", "env"]

• 然后创建该测试的 Pod：

[root@master1 ~]#kubectl apply -f test-pod.yaml 
pod/test-pod created

• 等 Pod 创建完成后，我们查看日志信息：

[root@master1 ~]#kubectl get po
NAME                            READY   STATUS             RESTARTS      AGE
……
test-pod                        0/1     CrashLoopBackOff   2 (17s ago)   49s
[root@master1 ~]#kubectl logs test-pod
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=test-pod
SHLVL=1
HOME=/root
NGINX_SERVICE_PORT_5000_TCP_ADDR=10.107.211.179
NGINX_SERVICE_PORT_5000_TCP_PORT=5000
NGINX_SERVICE_PORT_5000_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NGINX_SERVICE_SERVICE_HOST=10.107.211.179 #Host
KUBERNETES_PORT_443_TCP_PORT=443
NGINX_SERVICE_PORT_5000_TCP=tcp://10.107.211.179:5000
KUBERNETES_PORT_443_TCP_PROTO=tcp
NGINX_SERVICE_PORT=tcp://10.107.211.179:5000
NGINX_SERVICE_SERVICE_PORT=5000 #Port
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/

我们可以看到打印了很多环境变量信息，其中就包括我们刚刚创建的 nginx-service 这个服务，有 HOST、PORT、PROTO、ADDR 等，也包括其他已经存在的 Service 的环境变量。现在如果我们需要在这个 Pod 里面访问 nginx-service 的服务，我们是不是可以直接通过 NGINX_SERVICE_SERVICE_HOST 和 NGINX_SERVICE_SERVICE_PORT 就可以了。但是如果这个 Pod 启动起来的时候 nginx-service 服务还没启动起来，在环境变量中我们是无法获取到这些信息的。**当然我们可以通过 **initContainer之类的方法来确保 nginx-service 启动后再启动 Pod，但是这种方法毕竟增加了 Pod 启动的复杂性，所以这不是最优的方法，局限性太多了。

实验结束。😘

2、DNS

DNS 其实就是一个分布式的树状命名系统，它就像一个去中心化的分布式数据库，存储着从域名到 IP 地址的映射。当一台主机想要通过域名访问某个服务的内容时，需要先通过当前域名获取对应的 IP 地址，这时就需要通过一个 DNS 解析器负责域名的解析。

1.DNS 解析过程

所有 DNS 服务器都属于以下四个类别之一：递归解析器、根域名服务器、顶级域名服务器和权威性域名服务器。在典型 DNS 查找中（当没有正在进行的高速缓存时），这四个 DNS 服务器协同工作来完成将指定域的 IP 地址提供给客户端的任务（客户端通常是一个存根解析器 - 内置于操作系统的简单解析器）。

• DNS 解析器 - 该解析器可被视为被要求去图书馆的某个地方查找特定图书的图书馆员。DNS 解析器是一种服务器，旨在通过 Web 浏览器等应用程序接收客户端计算机的查询。然后，解析器一般负责发出其他请求，以便满足客户端的DNS 查询。

• 根域名服务器 - 根域名服务器是将人类可读的主机名解析为 IP 地址的第一步，可将其视为指向不同书架的图书馆中的索引。

• TLD 域名服务器 - 顶级域服务器（TLD）可被视为图书馆中的特定书架，此域名服务器是搜索特定 IP 地址的下一步，其托管主机名的最后一部分（比如在 example.com 中，TLD 服务器为 com ）。

• 权威性域名服务器 - 可将这个最终域名服务器视为书架上的字典，其中特定名称可被转换成其定义。权威性域名服务器是域名服务器查询中的最后一站。如果权威性域名服务器能够访问请求的记录，则其会将已请求主机名的 IP 地址返回到发出初始请求的 DNS 解析器（图书管理员）。

下面我们简单介绍下 DNS 查找 IP 地址的步骤（不考虑缓存）。DNS 服务器根据域名的层级，进行分级查询，需要明确的是，每一级域名都有自己的 NS（Name Server 的缩写）记录，NS 记录指向该级域名的域名服务器。

1. 用户在 Web 浏览器中键入 example.com ，查询传输到 Internet 中，并被 DNS 解析器接收。
2. 接着，解析器向 DNS 根域名服务器（ . ）发起查询请求。
3. 然后，根服务器返回其域信息的顶级域 DNS 服务器（例如 .com 或 .net）的 NS 记录和 A 记录给该解析器。例
   如：在访问 example.com 时，我们的请求指向 .com TLD 服务器。
4. 然后，解析器向 .com TLD 服务器发出请求。
5. TLD 服务器随后返回域名 example.com 的权威性域名服务器 NS 记录和 A 记录。
6. 最后，解析器将查询发送到域的域名服务器。
7. example.com 的 IP 地址从权威性域名服务器返回到解析器。
8. 然后 DNS 解析器使用最初请求的域的 IP 地址响应 Web 浏览器。
9. 浏览器向该 IP 地址发出 HTTP 请求。
10. 位于该 IP 的服务器返回将在浏览器中呈现的网页。

DNS 查找经过前面 8 个步骤返回 example.com 的 IP 地址后，浏览器便能发出对该网页的请求。

2.根域名服务器

每个 DNS 解析器都知道 13 个 DNS 根域名服务器，它们是 DNS 解析器搜寻 DNS 记录的第一站，根服务器接受解析器的查询，根域名服务器根据该域的扩展名（.com、 .net 、.org 等），将解析器定向到 TLD 域名服务器进行响应。一个普遍的误解是，世界上只有 13 台根服务器。实际上根服务器有许多，但只有 13 个 IP 地址用于查询不同的根服务器网络。DNS 原始架构的限制要求根区域中最多只能有 13 个服务器地址。在 Internet 面世之初，这 13 个 IP 地址的每一个都只有一台服务器，其中大多数位于美国。如今，这 13 个 IP 地址中的每一个都有多个服务器，这些服务器使用Anycast 路由基于负荷和距离分发请求。目前，地球上每座有人生活的大陆上都分布着 600 多台 DNS 根服务器。

每个 DNS 解析器都在其软件中内置了 13 个 IP 根服务器地址的列表，每次发起 DNS 查找时，解析器的第一个通信就是与这 13 个 IP 地址之一进行的。

DNS 的管理通过使用不同的受管理分区或区域的层次结构构造，其根区域位于该层次结构的最顶部。根服务器是在根区域中运行的 DNS 域名服务器，这些服务器可以直接回答针对根区域内存储或缓存的记录的查询，还可以将其他请求引向相应的顶级域 (TLD) 服务器。TLD 服务器是 DNS 层次结构中比根服务器低一级的 DNS 服务器组，它们是解析 DNS 查询的必要部分。

需要注意的是其实每个域名后面都有一个根域名，因为对于所有域名都是一样的所以平时是省略的。如：www.baidu.com真正的域名是 www.baidu.com.root ，简写为 www.baidu.com. ，因为，根域名 .root 对于所有域名都是一样的，所以平时是省略的。

在未缓存的 DNS 查询期间，每当用户在浏览器中输入网址，该操作都会触发 DNS 查找，并且所有 DNS 查找都从根区域开始。查找到达根区域后，将沿 DNS 系统的层次结构向下移动，首先到达 TLD 服务器，然后到达特定域（可能还有子域）的服务器，直到最终到达权威性名服务器，以查到正确的域名，其中包含要搜索的网站的 IP 地址，然后，该 IP 地址被返回给客户端。

3.顶级域名服务器

顶级（TLD）域名服务器维护共享通用域扩展名的所有域名的信息，例如 .com 、.net 或 url 中最后一个点之后的任何内容。例如，.com 顶级域名服务器包含以 .com 结尾的每个网站的信息。如果用户正在搜索 google.com ，则在收到来自根域名服务器的响应后，递归解析器将向 .com 顶级域名服务器发送查询，后者将通过针对该域的权威权威性域名服务器 性域名服务器进行响应。

TLD 域名服务器的管理由 **Internet 编号分配机构（IANA）**加以处理，其为 ICANN 的一个分支机构，IANA 将 TLD 服务器分为两个主要组：

• 通用顶级域：这些是非特定国家/地区的域，一些最知名的通用 TLD 包括 .com 、.org 、.net、 .edu 和.gov 。
• 国家/地区代码顶级域：这些包括特定于某个国家/地区或州的任何域。例如， .uk、 .us 、.ru 等。

4.权威性域名服务器

当域名解析器收到来自 TLD 域名服务器的响应时，该响应会将解析器定向到权威性域名服务器，权威性域名服务器通常是解析器查找找 IP 地址过程中的最后一 地址过程中的最后一步。权威名称服务器包含特定于其服务域名的信息（例如 google.com），并且它可为解析器提供在 DNS A 记录中找到的服务器的 IP 地址，或者如果该域具有 CNAME 记录（别名），它将为解析器提供一个别名域，这时解析器将必须执行全新 DNS 查找，以便从权威性域名服务器获取记录（通常为包含 IP 地址的 A 记录）。

5.dig 域名

上面我们了解了用于处理域名解析的 DNS 服务器是树形的，只是在树的组织和每一层的职责上有一些不同。DNS 解析器从根域名服务器查找到顶级域名服务器的 IP 地址，又从顶级域名服务器查找到权威域名服务器的 IP 地址，最终从权威域名服务器查出了对应服务的 IP 地址。

我们可以使用 dig 命令来追踪下我们的网站 youdianzhishi.com 域名对应的 IP 地址是如何被解析出来的，可以看到首先会向预置的 13 个根域名服务器发出请求获取顶级域名的地址。

[root@master1 ~]#dig -t A youdianzhishi.com +trace

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13 <<>> -t A youdianzhishi.com +trace
;; global options: +cmd #13个
.                       1236    IN      NS      h.root-servers.net.
.                       1236    IN      NS      k.root-servers.net.
.                       1236    IN      NS      b.root-servers.net.
.                       1236    IN      NS      e.root-servers.net.
.                       1236    IN      NS      f.root-servers.net.
.                       1236    IN      NS      l.root-servers.net.
.                       1236    IN      NS      m.root-servers.net.
.                       1236    IN      NS      g.root-servers.net.
.                       1236    IN      NS      a.root-servers.net.
.                       1236    IN      NS      c.root-servers.net.
.                       1236    IN      NS      j.root-servers.net.
.                       1236    IN      NS      i.root-servers.net.
.                       1236    IN      NS      d.root-servers.net.
;; Received 239 bytes from 223.6.6.6#53(223.6.6.6) in 7 ms

根域名服务器是 DNS 中最高级别的域名服务器，域名的格式从上面返回的结果可以看到是 .root-servers.net ，每个根域名服务器中只存储了顶级域服务器的 IP 地址。在这里，我们获取到了以下的 13 条 NS 记录，也就是 13 台 com.顶级域名 DNS 服务器：
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20230226050000 20230213040000 951 . s0yeGeBN9LjndJ3ujWwwm6MyMmqkO0D686r+IFImHwssxgvkCLBIg4UR nerOWYVP8SwT9Gmlzzx2yKsXo8pm9ldXxk31pfZsW7lakQFH2gYh7K3X +nxVgnJzBDjfYuBvvwz8BvVuUf2CprlFFX2MxSbP3M1qjAcDYc/OuE6D 8QLEyPbV6mO5BZ5biBknsC/YBp3wSVpLOwrAJSi7cvbHEIYyMd5Y3f3f acaKEduQrjztO45rjq4vPQUeq4Qv2aTWs2RymCNT3nae0u8Ow3+VStW6 mg51C0KdWbgaQwz+9OlqDUX3KVfCZ1c45TJnA8uV1F/9SKtSn17tmy/x Zy51SQ==
;; Received 1177 bytes from 199.7.91.13#53(d.root-servers.net) in 187 ms

当 DNS 解析器从根域名服务器中查询到了顶级域名 .com 服务器的地址之后，就可以访问这些顶级域名服务器其中的一台g.gtld-servers.net 获取权威 DNS 的服务器的地址了：
youdianzhishi.com.      172800  IN      NS      dns21.hichina.com.
youdianzhishi.com.      172800  IN      NS      dns22.hichina.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230219052251 20230212041251 36739 com. LMcgMQFLQOrC5eZ8lT/w3zfy938o3HvnXbZ79glQ3tceud7s3FSaxbFl E6faNre/oHe273TfuUur69LMn456aELFsigub9aprgTzSVMLLR1uLo9S ikIpps4OSakJD/sxrIQR1KG+4gzfi0j6U+u1h8NZwbNJFBxEe2jnajl3 OSAQkcRYrubFQYXbxh0mmdur0UcZ0pl+NBsBltSbCf9MHw==
U5N4GVFN782MDPPH68294PMTF8CN0JN2.com. 86400 IN NSEC3 1 1 0 - U5N4UBHTCVO3DI2VRP6OTQOLFFDDKVBF NS DS RRSIG
U5N4GVFN782MDPPH68294PMTF8CN0JN2.com. 86400 IN RRSIG NSEC3 8 2 86400 20230219065636 20230212054636 36739 com. JVI8Vw3zv6ujeKX/oL6/co5sXE3SZuXVO4IlApPbEW5Ferq45HDl4nbn ZMzEliC4zOT97cQFp5fa32IWmV0VPKr/xjvYrX+1SL4GUKO2VSOUk7Bx MpQASWFCtCJwWvS9jcTRAgtAiLAp7rbFhPcsFdE4S2emftR76KksxDYJ UflGkVUy7nVPMfLA6pt86XjIJDkMojYPaGWddtalVyKfVA==
;; Received 955 bytes from 192.42.93.30#53(g.gtld-servers.net) in 267 ms
这里的权威 DNS 服务是我在域名提供商进行配置的，当有客户端请求 youdianzhishi.com 域名对应的 IP 地址时，其实会从我使用的 DNS 服务商（阿里云）处请求服务的 IP 地址：

youdianzhishi.com.      600     IN      A       39.106.22.102
;; Received 62 bytes from 39.96.153.38#53(dns22.hichina.com) in 32 ms
最终，DNS 解析器从 dns21.hichina.com 服务中获取了我们网站的 IP 地址，浏览器或者其他设备就能够通过该 IP向服务器获取请求的内容了。
[root@master1 ~]#

3、CoreDNS

到这里我们其实能够发现 DNS 就是一种最早的服务发现的手段，虽然服务器的 IP 地址可能会变动，但是通过相对不会变动的域名，我们总是可以找到提供对应服务的服务器。

在微服务架构中，服务注册的方式大体上有两种，一种是使用 Zookeeper 和 etcd 等配置管理中心，另一种就是使用DNS 服务。由于上面我们介绍的环境变量这种方式的局限性，我们需要一种更加智能的方案，其实我们可以自己思考一种比较理想的方案：那就是可以直接使用 Service 的名称，因为 Service 的名称不会变化，我们不需要去关心分配的ClusterIP 的地址，因为这个地址并不是固定不变的，所以如果我们直接使用 Service 的名字，然后对应的ClusterIP 地址的转换能够自动完成就很好了。我们知道名字和 IP 直接的转换是不是和我们平时访问的网站非常类似啊？他们之间的转换功能通过 DNS 就可以解决了，同样的，Kubernetes 也提供了 DNS 的方案来解决上面的服务发现的问题。

CoreDNS 其实就是一个 DNS 服务，而 DNS 作为一种常见的服务发现手段，所以很多开源项目以及工程师都会使用CoreDNS 为集群提供服务发现的功能，Kubernetes 就在集群中使用 CoreDNS 解决服务发现的问题。CoreDNS 是基于Go 编写的 HTTP/2 Web 服务器 Caddy 构建的，其大多数功能都是由插件来实现的，插件和服务本身都使用了 Caddy提供的一些功能。

DNS 服务不是一个独立的系统服务，而是作为一种 addon 插件而存在，现在比较推荐的两个插件：kube-dns 和 CoreDNS，实际上在比较新点的版本中已经默认是 CoreDNS 了，因为 kube-dns 默认一个 Pod 中需要3个容器配合使用，CoreDNS 只需要一个容器即可，我们在前面使用 kubeadm 搭建集群的时候直接安装的就是 CoreDNS 插件：

[root@master1 ~]# kubectl get pods -n kube-system -l k8s-app=kube-dns -owide
NAME                       READY   STATUS    RESTARTS      AGE   IP           NODE      NOMINATED NODE   READINESS GATES
coredns-7b884d5cb7-6jzn6   1/1     Running   1 (61d ago)   71d   10.244.0.6   master1   <none>           <none>
coredns-7b884d5cb7-gcszd   1/1     Running   1 (61d ago)   71d   10.244.0.7   master1   <none>           <none>

[root@master1 ~]#kubectl get po coredns-7b884d5cb7-6jzn6 -oyaml -nkube-system
……
containers:
  - args:
    - -conf
    - /etc/coredns/Corefile
    image: registry.aliyuncs.com/k8sxio/coredns:v1.9.3
……
    volumeMounts:
    - mountPath: /etc/coredns
      name: config-volume #注意
      readOnly: true
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-dvl9w
      readOnly: true
……
volumes:
  - configMap:
      defaultMode: 420
      items:
      - key: Corefile
        path: Corefile
      name: coredns #注意
    name: config-volume
  - name: kube-api-access-dvl9w
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
……

CoreDNS 内部采用插件机制，所有功能都是插件形式编写，用户也可以扩展自己的插件，以下是 Kubernetes 部署CoreDNS 时的默认配置：

➜  ~ kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
data:
  Corefile: | #注意：你可以认为，下面{}里的每一行相当于一个插件！！！
    .:53 {
        errors  # 启用错误记录
        health  # 启用健康检查检查端点，8080:health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {  # 处理 k8s 域名解析，提供集群内服务解析能力，基于服务和 Pod 的 IP 来应答 DNS 查询
           pods insecure ## 为了与 kube-dns 向后兼容，还可以使用 pods verified 选项，可以使得仅在相同名字空间中存在具有匹配 IP 的 Pod 时才返回 A 记录。
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153  # 启用 metrics 指标，9153:metrics
        forward . /etc/resolv.conf  # 默认情况下任何不属于 Kubernetes 集群内部的域名，其 DNS 请求都将指向 forward 指定的DNS 服务器地址，这里面第一个 “.” 代表所有域名，后面 “/etc/resolv.conf” 表示使用宿主机的域名解析服务器。
        cache 30  # 启用缓存，所有内容限制为 30s 的TTL (all的解析都有一个缓存的)
        loop  # 环路检测，如果检测到环路，则停止 CoreDNS。
        reload  # 允许自动重新加载已更改的 Corefile，编辑 ConfigMap 配置后，需要等待一段时间生效
        loadbalance  # 负载均衡，默认 round_robin
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-11-08T11:59:49Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "188"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 21966186-c2d9-467a-b87f-d061c5c9e4d7

• 每个 {} 代表一个 zone,格式是 “Zone:port{}”, 其中"."代表默认zone
• {} 内的每个名称代表插件的名称，只有配置的插件才会启用，当解析域名时，会先匹配 zone（都未匹配会执行默认 zone），然后 zone 内的插件从上到下依次执行(这个顺序并不是配置文件内谁在前面的顺序，而是core/dnsserver/zdirectives.go内的顺序)，匹配后返回处理（执行过的插件从下到上依次处理返回逻辑），不再执行下一个插件。

1.CoreDNS 扩展配置

我们可以根据自己的实际需求，针对不同场景来扩展 CoreDNS 的配置。

（1）开开启日志服务

如果需将 CoreDNS 每次域名解析的日志打印出来，我们可以开启 Log 插件，只需要在 Corefile 里加上 log 即可，示例配置如下：

  Corefile: | #注意：你可以认为，下面{}里的每一行相当于一个插件！！！
    .:53 {
        errors
        log #启用log插件
        health
        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
    }

（2）特定域名使用自定义 DNS 服务器

如果 example.com 类型后缀的域名需要使用自建 DNS 服务器（比如 10.10.0.10）进行解析的话，我们可为域名配置一个单独的服务块，示例配置如下：

Corefile: |
 .:53 {
   # 省略......
 }
   example.com:53 {
   errors
   cache 30
   forward . 10.10.0.10
   prefer_udp
 }

（3）自定义 Hosts

如果需要为特定域名指定 hosts 映射，如为 www.example.com 指定 IP 为 127.0.0.1 ，那么可以使用 Hosts 插件来配置，示例配置如下：

Corefile: |
  .:53 {
    errors
    health {
      lameduck 15s
  }
  ready
  hosts { # 使用 hosts 插件
    127.0.0.1 www.example.com
    fallthrough
  }
  kubernetes cluster.local in-addr.arpa ip6.arpa {
    pods insecure
    fallthrough in-addr.arpa ip6.arpa
    ttl 30
  }
  prometheus :9153
  forward . /etc/resolv.conf {
    prefer_udp
  }
  cache 30
  loop
  reload
  loadbalance
  }

（4）集群外部访问集群内服务

如果你希望在集群外的进程能够访问到集群内的服务，可以通过将节点的 /etc/resolv.conf 文件内 nameserver配置为集群 kube-dns 的 ClusterIP 地址来达到目的，但不推荐该方式。如果你使用的是云服务器，在内网场景下，可以将集群内的服务通过内网 SLB 进行暴露，然后通过云服务商提供的解析服务添加 A 记录到该 SLB 的内网 IP 进行解析，比如阿里云的 PrivateZone 服务。

（5）统一域名访问服务

我们可以实现在公网、内网和集群内部通过统一域名 foo.example.com 访问你的服务，原理如下：

• 集群内的服务 foo.default.svc.cluster.local 通过公网 SLB 进行了暴露，且有域名 foo.example.com解析到该公网 SLB 的 IP。
• 集群内服务 foo.default.svc.cluster.local 通过内网 SLB 进行了暴露，且通过云解析 PrivateZone（比如在阿里云）在 VPC 内网中将 foo.example.com 解析到该内网 SLB 的 IP。
• 在集群内部，可以通过 Rewrite 插件将 foo.example.com CNAME 到foo.default.svc.cluster.local。

Corefile: |
  .:53 {
    errors
    health {
      lameduck 15s
  }
  ready
  rewrite stop {
   name regex foo.example.com foo.default.svc.cluster.local
   answer name foo.default.svc.cluster.local foo.example.com
   }
  kubernetes cluster.local in-addr.arpa ip6.arpa {
    pods insecure
    fallthrough in-addr.arpa ip6.arpa
    ttl 30
  }
  prometheus :9153
  forward . /etc/resolv.conf {
    prefer_udp
  }
  cache 30
  loop
  reload
  loadbalance
  }

（6）禁止对对 IPv6类型的 AAAA 记录查询返回

如果 K8s 节点没有禁用 IPV6 的话，容器内进程请求 CoreDNS 时的默认行为是同时发起 IPV4 和 IPV6 解析，而通常我们只需要用到 IPV4，当容器请求某个域名时，CoreDNS 解析不到 IPV6 记录，就会 forward 到 upstream 去解析，如果到 upstream 需要经过较长时间(比如跨公网，跨机房专线)，就会拖慢整个解析流程的速度，业务层面就会感知DNS 解析慢。

CoreDNS 有一个 template 的插件，可以用它来禁用 IPV6 的解析，只需要给 CoreDNS 加上如下的配置:

Corefile: |
 .:53 {
   errors
   health {
   lameduck 15s
   }
 # 新增以下一行Template插件，其它数据请保持不变。
 template IN AAAA .
 # ......
 }

该配置的含义是在 CoreDNS 中将 AAAA 记录类型拦截，返回域名不存在，以减少不必要的网络通信。

2.使用

CoreDNS 的 Service 地址一般情况下是固定的，类似于 kubernetes 这个 Service 地址一般就是第一个 IP 地址 10.96.0.1，CoreDNS 的 Service 地址就是 10.96.0.10。该 IP 被分配后，kubelet 会将使用 --cluster-dns=<dns-service-ip> 参数配置的 DNS 传递给每个容器。DNS 名称也需要域名，本地域可以使用参数--cluster-domain = <default-local-domain> 在 kubelet 中配置：

➜  ~ cat /var/lib/kubelet/config.yaml
......
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local #当然，这个可以改，但一般是不会去修改的，是约定俗成的。
......

注意点1：

当我们去启动一个容器的时候，它会把这里的clusterDNS地址给写入到我们容器的nameserver里面去，那么当我们容器里面的namesrver是这个地址，然后去做域名解析的时候，是不是都会进入到这个10.96.0.10里面去，而这个地址刚好是我们core dns的地址。所以最终解析，还是进入到这个coredns里面来做的。

[root@master1 ~]#kubectl get svc -nkube-system
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
kube-dns         ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP   49d
metrics-server   ClusterIP   10.106.125.106   <none>        443/TCP                  27d

注意点2：

文件/var/lib/kubelet/config.yaml里的clusterDomain: cluster.local就相当于在我们k8s集群里面，就是我们service的一个域名后缀。all的以dns的形式访问service的时候，它的一个后缀都是cluster.local。

我们前面说了如果我们建立的 Service 如果支持域名形式进行解析，就可以解决我们的服务发现的功能，那么利用 kubedns 可以将 Service 生成怎样的 DNS 记录呢？

• 普通的 Service：会生成 servicename.namespace.svc.cluster.local 的域名，会解析到 Service 对应的 ClusterIP 上，在 Pod 之间的调用可以简写成 servicename.namespace，如果处于同一个命名空间下面，甚至可以只写成 servicename 即可访问。

假如说我们有个svc叫做nginx-service：

那么，该service在dns里的域名可以按如下来写：
	nginx-service.default.svc.cluster.local
	nginx-service.default.svc
	nginx-service.default
	
如果你的Pod和nigx-service在同一个namesapce，也可以写成nginx-service

• Headless Service：无头服务，就是把 clusterIP 设置为 None 的，会被解析为指定 Pod 的 IP 列表，同样还可以通过 podname.servicename.namespace.svc.cluster.local 访问到具体的某一个 Pod。

🍀 主服务

注意：kubernetes这个service这个是谁创建的？

[root@master1 ~]#kubectl get svc
NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
kubernetes      ClusterIP   10.96.0.1      <none>        443/TCP    42d
nginx-service   ClusterIP   10.98.166.23   <none>        5000/TCP   5m57s

这个kubernetes主服务(service)是系统自己创建的，这个service是必须要有的，不能随便被删除的。相当与是我们集群内部的一些应用，他们要通过这个service去访问apiserver，这个其实就是去关联到我们的apiserver而已。

我们可以去describe看下：

[root@master1 ~]#kubectl describe svc kubernetes 
Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.0.1
IPs:               10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         172.29.9.51:6443 #care
Session Affinity:  None
Events:            <none>

可以看到这里的Endpoints，其实就是到我们的apiserver那里去的。

其实就是给我们集群内部的一些pod去使用这个apiserver的，因为一般来说 我们不太可能在集群内部去写上这个172.29.9.51:6443地址。

💘 实战：coredns测试(测试成功)-2023.2.18

• 实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

• 实验软件（无）

• 接下来我们来使用一个简单 Pod 来测试下 CoreDNS 的使用。

# dns-utils.yaml
apiVersion: v1
kind: Pod
metadata:
  name: dnsutils
spec:
  containers:
    - name: dnsutils
      image: cnych/jessie-dnsutils:1.3 #当然，这里使用busybox镜像也是可以的。
      command:
        - sleep
        - "infinity"
      imagePullPolicy: IfNotPresent
  restartPolicy: Always

• 直接应用上面的资源清单即可：

[root@master1 ~]#kubectl apply -f dns-utils.yaml
[root@master1 ~]#kubectl get pods dnsutils
NAME       READY   STATUS    RESTARTS   AGE
dnsutils   1/1     Running   0          115s

• 一旦 Pod 处于运行状态，我们就可以在该环境里执行 nslookup 命令，如果你看到类似下列的内容，则表示 DNS 是正常运行的。```

[root@master1 ~]#kubectl exec -it dnsutils -- nslookup kubernetes.default
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   kubernetes.default.svc.cluster.local
Address: 10.96.0.1

[root@master1 ~]#

• 如果 nslookup 命令执行失败，可以先检查下本地的 DNS 配置，查看 resolv.conf 文件的内容：

正常该文件内容如下所示：

[root@master1 ~]#kubectl exec -it dnsutils -- cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

可以看到 nameserver 的地址 10.96.0.10，该 IP 地址即是在安装 CoreDNS 插件的时候集群分配的一个固定的IP 地址，我们可以通过下面的命令进行查看：

[root@master1 ~]# kubectl get svc kube-dns -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   75d

也就是说我们这个 Pod 现在默认的 nameserver 就是 kube-dns 的地址。

• 现在我们来访问下前面我们创建的nginx-service 服务，先在 Pod 中添加 wget 命令：

[root@master1 ~]# kubectl exec  -it  dnsutils  -- /bin/bash
root@dnsutils:/#  apt-get install wget -y

注意：这个debian镜像下载速度太慢了……不如使用busybox镜像。🤣

• 然后我们去访问下 nginx-service 服务：

root@dnsutils:/#  wget -q -O- nginx-service.default.svc.cluster.local
root@dnsutils:/#

但是上面我们使用 wget 命令去访问 nginx-service 服务域名的时候被 hang 住了，没有得到期望的结果，这是因为上面我们建立 Service 的时候暴露的端口是 5000：

root@dnsutils:/#  wget -q -O- nginx-service.default.svc.cluster.local:5000
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
root@dnsutils:/#

加上 5000 端口，就正常访问到服务。

需要注意的是：

我这里的测试现象有点不一样。

dnsutils镜像

busybox镜像

再试一试访问：nginx-service.default.svc、 nginxservice.default、 nginx-service ，不出意外这些域名都可以正常访问到期望的结果。

root@dnsutils:/#  wget -q -O- nginx-service.default.svc.cluster.local:5000
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
root@dnsutils:/#  wget -q -O- nginx-service.default.svc:5000
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
root@dnsutils:/#  wget -q -O- nginx-service.default:5000
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
root@dnsutils:/#  wget -q -O- nginx-service:5000
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
root@dnsutils:/#

到这里我们是不是就实现了在集群内部通过 Service 的域名形式进行互相通信了，大家下去试着看看访问不同namespace 下面的服务呢？

我们再来总结一下，在 Kubernetes 集群内部，域名的全称是 servicename.namespace.svc.cluster.local，服务名就是 K8s 的 Service 名称，比如当我们执行 curl s 的时候，必须就有一个名为 s 的 Service 对象，在容器内部，会根据 /etc/resolve.conf 进行解析，使用 nameserver 10.96.0.10 进行解析，然后用字符串 s 依次带入 search 域进行查找，分别是：s.default.svc.cluster.local --> s.svc.cluster.local -->s.cluster.local，直到找到为止。

所以，我们执行 curl s，或者执行 curl s.default，都可以完成 DNS 请求，这 2 个不同的操作，会分别进行不同的 DNS 查找步骤：

"// curl s，可以一次性找到（s + default.svc.cluster.local）
s.default.svc.cluster.local

"// curl s.default，第一次找不到（s.default + default.svc.cluster.local）
s.default.default.svc.cluster.local
"// 第二次查找可以找到（s.default + svc.cluster.local）
s.default.svc.cluster.local

那么问题来了， curl s 要比 curl s.default 效率高吗？

能简写就简写，能帮我们省略几次dns解析过程。

答案是肯定的，因为 curl s.default 多经过了一次 DNS 查询，当执行 curl s.default ，也就使用了带有命名空间的内部域名时，容器的第一个 DNS 请求是：

"// s.default + default.svc.cluster.local
s.default.default.svc.cluster.local

当请求不到 DNS 结果时，使用下面的搜索域

"// s.default + svc.cluster.local
s.default.svc.cluster.local

进行请求，此时才可以得到正确的 DNS 解析。

🍀 ndots测试

其实 /etc/resolv.conf 这个文件，并不止包含 nameserver 和 search 域，还包含了非常重要的一项： ndots ，上面我们没有提及这个配置项。

/ # cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5
/ #

ndots:5 表示如果查询的域名包含的点 . 不到 5 个，那么进行 DNS 查找，将使用非完全限定名称（或者叫非绝对域名），如果你查询的域名包含点数大于等于 5，那么 DNS 查询，默认会使用绝对域名进行查询。

比如我们请求的域名是 a.b.c.d.e，这个域名中有 4 个点，那么容器中进行 DNS 请求时，会使用非绝对域名进行查找，使用非绝对域名，会按照 /etc/resolv.conf 中的 search 域，走一遍追加匹配：

a.b.c.d.e.default.svc.cluster.local.
a.b.c.d.e.svc.cluster.local.
a.b.c.d.e.cluster.local.

直到找到为止，如果走完了 search 域还找不到，则使用 a.b.c.d.e. 作为绝对域名进行 DNS 查找。

我们通过抓包分析一个具体案例，由于 CoreDNS 容器往往不具备 bash，所以无法通过 kubectl exec 的方式进入容器内抓包，我们可以给 CoreDNS 添加上 log 插件来记录解析日志。

[root@master1 ~]#kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
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 {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2022-12-04T22:25:08Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "248"
  uid: 13ed16b1-cb31-492a-944c-a30a03e177e6
[root@master1 ~]#kubectl edit cm coredns -n kube-system
……
        log
……        
[root@master1 ~]#kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        log
        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 {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2022-12-04T22:25:08Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "938524"
  uid: 13ed16b1-cb31-492a-944c-a30a03e177e6

[root@master1 ~]# kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
NAME                       READY   STATUS    RESTARTS        AGE   IP            NODE      NOMINATED NODE   READINESS GATES
coredns-7b884d5cb7-6jzn6   1/1     Running   2 (3d21h ago)   75d   10.244.0.11   master1   <none>           <none>
coredns-7b884d5cb7-gcszd   1/1     Running   2 (3d21h ago)   75d   10.244.0.10   master1   <none>           <none>

由于 CoreDNS 的 Pod 存在多个，那么 DNS 请求，可能会均分到所有 DNS 服务的容器上，我们如果只查看单个 DNS服务容器抓到的包，可能就不全了，所以我们可以指定特定的一个 Pod 来进行 DNS 解析：

1.域名中点数少于 5 个的情况，比如对域名 a.b.c.d.ccccc 进行 DNS 解析请求：

root@dnsutils:/#  nslookup a.b.c.d.ccccc 10.244.0.11
Server:         10.244.0.11
Address:        10.244.0.11#53

** server can't find a.b.c.d.ccccc: NXDOMAIN

root@dnsutils:/#

对应 CoreDNS Pod（ 10.244.0.11 这个 Pod）的日志如下所示：

[root@master1 ~]#kubectl logs -f coredns-7b884d5cb7-6jzn6 -nkube-system
.:53
[INFO] plugin/reload: Running configuration SHA512 = 591cf328cccc12bc490481273e738df59329c62c0b729d94e8b61db9961c2fa5f046dd37f1cf888b953814040d180f52594972691cd6ff41be96639138a43908
CoreDNS-1.9.3
linux/amd64, go1.18.2, 45b0a11
[INFO] Reloading
[INFO] plugin/health: Going into lameduck mode for 5s
[INFO] plugin/reload: Running configuration SHA512 = f00fdccfaa4735680a8e1c1039784634259e55a73b0d1f92bb0bb09000f01852501d2fda805465f42467cb636637a06efa4674610b45b3d569a999ff1d701fb4
[INFO] Reloading complete
[INFO] 127.0.0.1:38447 - 39263 "HINFO IN 1756676467130346557.5690313054789561260. udp 57 false 512" NXDOMAIN qr,rd,ra 132 0.016539258s
[INFO] 10.244.2.57:48637 - 28949 "A IN a.b.c.d.ccccc.default.svc.cluster.local. udp 57 false 512" NXDOMAIN qr,aa,rd 150 0.000185532s
[INFO] 10.244.2.57:35202 - 14814 "A IN a.b.c.d.ccccc.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000130307s
[INFO] 10.244.2.57:48540 - 23439 "A IN a.b.c.d.ccccc.cluster.local. udp 45 false 512" NXDOMAIN qr,aa,rd 138 0.000111244s
[INFO] 10.244.2.57:49119 - 6131 "A IN a.b.c.d.ccccc. udp 31 false 512" NXDOMAIN qr,rd,ra 106 0.01328048s

从上面的日志可以看出当点数少于 5 个的时候，先加上搜索域去进行解析的，解析失败后切换到下一个搜索域继续，最后再加一个 . 进行解析 a.b.c.d.ccccc. 。

我们可以再请求一个正常的域名验证下：

root@dnsutils:/#  nslookup youdianzhishi.com 10.244.0.11
Server:         10.244.0.11
Address:        10.244.0.11#53

Non-authoritative answer:
Name:   youdianzhishi.com
Address: 39.106.22.102

root@dnsutils:/#

对应 CoreDNS 的日志为：

[INFO] 10.244.2.57:47078 - 53361 "A IN youdianzhishi.com.default.svc.cluster.local. udp 61 false 512" NXDOMAIN qr,aa,rd 154 0.00021077s
[INFO] 10.244.2.57:46364 - 24256 "A IN youdianzhishi.com.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000187543s
[INFO] 10.244.2.57:54366 - 41723 "A IN youdianzhishi.com.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.00014864s
[INFO] 10.244.2.57:50899 - 11617 "A IN youdianzhishi.com. udp 35 false 512" NOERROR qr,rd,ra 68 0.00974118s

可以看到仍然是先走 search 域最后再添加的一个 . 进行解析，也就是绝对域名，这样来看肯定就存在浪费请求的情况，当然我们在请求的时候直接手动在域名后面加上一个 . 直接变成绝对域名解析也是可以避免走 search 域的：

root@dnsutils:/#  nslookup youdianzhishi.com. 10.244.0.11
Server:         10.244.0.11
Address:        10.244.0.11#53

Non-authoritative answer:
Name:   youdianzhishi.com
Address: 39.106.22.102

root@dnsutils:/#

对应的 CoreDNS 日志：

2.域名中点数"/5 个的情况，比如对域名 a.b.c.d.e.ccccc 进行 DNS 解析请求：

root@dnsutils:/#  nslookup a.b.c.d.e.ccccc.10.244.0.11
Server:         10.96.0.10
Address:        10.96.0.10#53

** server can't find a.b.c.d.e.ccccc.10.244.0.11: NXDOMAIN

root@dnsutils:/#

对应 CoreDNS 的日志如下所示：

[INFO] 10.244.2.57:58995 - 3245 "A IN a.b.c.d.e.ccccc.10.244.0.11. udp 45 false 512" NXDOMAIN qr,rd,ra 120 0.145085181s

可以看到现在没有进行 search 域匹配了。

上面我们提到了可以在请求的域名末尾加一个 . 来对 DNS 请求进行优化，但是我们平时在使用的时候没有这种习惯，在Kubernetes 中，默认设置了 ndots 值为 5，是因为，Kubernetes 认为内部域名，最长为 5，要保证内部域名的请求，优先走集群内部的 DNS，而不是将内部域名的 DNS 解析请求，有打到外网的机会，所以 Kubernetes 设置 ndots为 5 是一个比较合理的行为。

但是我们也可以自己去定制这个长度，为自己的业务 Pod 单独配置 ndots 即可，如下所示：

# dns-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: dns-demo
spec:
  containers:
    - name: dnsutils
      image: cnych/jessie-dnsutils:1.3 #当然，这里使用busybox镜像也是可以的。
      command:
        - sleep
        - "infinity"
      imagePullPolicy: IfNotPresent
  restartPolicy: Always
  dnsConfig:
    options:
      - name: ndots
        value: "1"

创建该 Pod 后，我们可以查看下对应的 /etc/resolv.conf 文件：

[root@master1 ~]#kubectl apply -f dns-demo.yaml
[root@master1 ~]#kubectl exec -it dns-demo -- /bin/bash
root@dns-demo:/# cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:1
root@dns-demo:/#

可以看到对应的 ndots 值现在是 1 了。现在我们来做一次 dns 解析，再观察下对应的 CoreDNS 日志：

root@dns-demo:/# nslookup youdianzhishi.com 10.244.0.11
Server:         10.244.0.11
Address:        10.244.0.11#53

Non-authoritative answer:
Name:   youdianzhishi.com
Address: 39.106.22.102

root@dns-demo:/#

对应的 CoreDNS 日志：

[INFO] 10.244.2.59:45260 - 45830 "A IN youdianzhishi.com. udp 35 false 512" NOERROR qr,aa,rd,ra 68 0.000116046s

可以看到直接就是绝对域名的形式进行解析了，所以这种方法也是可以对解析过程进行优化的。

🍀 进入容器网络命名空间进行抓包

⚠️ 补充说明

我们这里是给 CoreDNS 添加的一个 log 插件来观察的解析日志，在实际的工作中可能我们可能也需要对一些应用进行抓包观察，可能单纯通过日志没办法获取相关信息，而该应用镜像中又不包含抓包需要的 tcpdump 命令，这个时候应该如何来进行抓包呢？

我们这里还是以 CoreDNS 为例，要抓去 DNS 容器的包，就需要先进入到该容器的网络中去。

[root@master1 ~]#kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
NAME                       READY   STATUS    RESTARTS        AGE   IP            NODE      NOMINATED NODE   READINESS GATES
coredns-7b884d5cb7-6jzn6   1/1     Running   2 (3d22h ago)   75d   10.244.0.11   master1   <none>           <none>
coredns-7b884d5cb7-gcszd   1/1     Running   2 (3d22h ago)   75d   10.244.0.10   master1   <none>           <none>

比如 coredns-7b884d5cb7-6jzn6 Pod 位于节点 master1，我们可以先进入该节点，使用 crictl命令找到该 Pod 对应的容器 ID：

[root@master1 ~]#crictl ps
CONTAINER           IMAGE               CREATED             STATE               NAME                      ATTEMPT             POD ID              POD
19ece1f877db4       5185b96f0becf       3 days ago          Running             coredns                   2                   55840d6e4467c       coredns-7b884d5cb7-6jzn6
……

我们这里对应的容器 ID 就是 19ece1f877db4 ，通过下面的命令找到它的 Pid：

[root@master1 ~]# crictl inspect -o go-template --template '{{.info.pid}}' 19ece1f877db4
15106

然后进入该容器的网络 Namespace 中去：

[root@master1 ~]# nsenter -n -t 15106
[root@master1 ~]#

然后使用 tcpdump 命令抓取 DNS 网络包：

[root@master1 ~]# nsenter -n -t 15106
[root@master1 ~]#tcpdump -i eth0 udp dst port 53
-bash: tcpdump: command not found
[root@master1 ~]#ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
    link/ether e2:9c:cd:3f:c9:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.244.0.11/24 brd 10.244.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e09c:cdff:fe3f:c9b9/64 scope link
       valid_lft forever preferred_lft forever
[root@master1 ~]#

注意这里有报错了的：

是因为自己宿主机上没有安装tcpdump命令：

[root@master1 ~]#yum install -y tcpdump
……
Installed:
  tcpdump.x86_64 14:4.9.2-4.el7_7.1

Dependency Installed:
  libpcap.x86_64 14:1.5.3-13.el7_9

Complete!
……

再次执行命令：

[root@master1 ~]# nsenter -n -t 15106
[root@master1 ~]#tcpdump -i eth0 udp dst port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

同样在上面的容器中进行 youdianzhishi.com 域名查找：

root@dnsutils:/#  nslookup youdianzhishi.com  10.244.0.11
Server:         10.244.0.11
Address:        10.244.0.11#53

Non-authoritative answer:
Name:   youdianzhishi.com
Address: 39.106.22.102

root@dnsutils:/#

此时就可以看到对应的数据包：

[root@master1 ~]#tcpdump -i eth0 udp dst port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:45:11.129972 IP 10.244.2.57.40860 > master1.domain: 33074+ A? youdianzhishi.com.default.svc.cluster.local. (61)
10:45:11.130457 IP master1.44571 > public2.alidns.com.domain: 48878+ PTR? 11.0.244.10.in-addr.arpa. (42)
10:45:11.131554 IP 10.244.2.57.40965 > master1.domain: 44300+ A? youdianzhishi.com.svc.cluster.local. (53)
10:45:11.133338 IP 10.244.2.57.34133 > master1.domain: 33419+ A? youdianzhishi.com.cluster.local. (49)
10:45:11.134212 IP 10.244.2.57.47873 > master1.domain: 17847+ A? youdianzhishi.com. (35)
10:45:11.134430 IP master1.41844 > public2.alidns.com.domain: 15306+ [1au] A? youdianzhishi.com. (46)
10:45:11.225248 IP master1.48344 > public2.alidns.com.domain: 30197+ PTR? 57.2.244.10.in-addr.arpa. (42)
10:45:11.294293 IP master1.39999 > public2.alidns.com.domain: 18521+ PTR? 6.6.6.223.in-addr.arpa. (40)

当然也可以利用 kubectl-debug 这样的工具进行辅助调试，但是进入容器网络命名空间进行抓包是最基本的知识点，需要我们掌握。

测试结束。😘

4、Pod 的 DNS 策略

DNS 策略可以单独对 Pod 进行设定，目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。这些策略可以在 Pod 规范中的 dnsPolicy 字段设置：

• Default: 有人说 Default 的方式，是使用宿主机的方式，这种说法并不准确。这种方式其实是让 kubelet 来决定使用何种 DNS 策略。而 kubelet 默认的方式，就是使用宿主机的 /etc/resolv.conf（可能这就是有人说使用宿主机的 DNS 策略的方式吧）。但是，kubelet 是可以灵活来配置使用什么文件来进行DNS策略的，我们完全可以使用 kubelet 的参数 –resolv-conf=/etc/resolv.conf 来决定你的 DNS 解析文件地址。

• ClusterFirst: 这种方式，表示 Pod 内的 DNS 使用集群中配置的 DNS 服务，简单来说，就是使用 Kubernetes 中 kubedns 或 coredns 服务进行域名解析。如果解析不成功，才会使用宿主机的 DNS 配置进行解析。

• ClusterFirstWithHostNet：在某些场景下，我们的 Pod 是用 HostNetwork 模式启动的，一旦用 HostNetwork 模式，表示这个 Pod 中的所有容器，都要使用宿主机的 /etc/resolv.conf 配置进行 DNS 查询，但如果你还想继续使用 Kubernetes 的DNS服务，那就将 dnsPolicy 设置为 ClusterFirstWithHostNet。

• None: 表示空的 DNS 设置，这种方式一般用于想要自定义 DNS 配置的场景，往往需要和 dnsConfig 配合一起使用达到自定义 DNS 的目的。(下面会讲到的)

注意：Default 并不是默认的 DNS 策略，如果未明确指定 dnsPolicy，则使用 ClusterFirst。

💘 实战：Pod的DNS策略-2023.2.18(测试成功)

• 实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

• 实验软件(无)

下面的示例显示了一个 Pod，其 DNS 策略设置为 ClusterFirstWithHostNet，因为它已将 hostNetwork 设置为 true。

• 编写资源清单文件：

#pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox:1.28.3
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet

• 部署并进入到pod查看nameserver：

[root@master1 ~]#kubectl apply -f pod.yaml
pod/busybox created
[root@master1 ~]#kubectl get po
NAME      READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          7s

[root@master1 ~]#kubectl exec busybox -- cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5
[root@master1 ~]#kubectl get svc kube-dns -nkube-system
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   51d

可以看到，当pod里使用了hostNetwork模式，且dnsPolicy配置为ClusterFirstWithHostNet的之后，此时容器里的nameserver使用的是Kubernetes 的DNS服务。

• 把dnsPolicy配置为ClusterFirst

但此时，若把dnsPolicy配置为ClusterFirst，按理说，此时的容器里的nameserver应该使用的是宿主机的/etc/resolv.conf 配置进行 DNS 查询，我们来测试下：

#pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox #这里改个名称！
  namespace: default
spec:
  containers:
  - image: busybox:1.28.3
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
    name: busybox
  restartPolicy: Always
  hostNetwork: true
  dnsPolicy: ClusterFirst #将上面的ClusterFirstWithHostNet修改为ClusterFirst。

修改完后，重新部署并观察现象：

[root@master1 ~]#kubectl apply -f pod.yaml
pod/busybox1 created
[root@master1 ~]#kubectl get po busybox
NAME       READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          7s
[root@master1 ~]#kubectl exec busybox -- cat /etc/resolv.conf
nameserver 223.6.6.6
[root@master1 ~]#

可以发现，此时的容器里的nameserver应该使用的是宿主机的/etc/resolv.conf 配置进行 DNS 查询，符合预期效果，测试结束。

⚠️ 注意：查看kube-proxy pod的DNS策略

我们的k8s集群的kube-proxy组件，它开启了hostNetwork:true，但是它的的dnsPolicy却是ClusterFirst，难道这里的kube-proxy pod不使用coredns服务吗？而是直接使用的宿主机的dns服务，这个自己有些疑问？—是的🤣

实验结束。😘

5、Pod 的 DNS 配置

Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。dnsConfig 字段是可选的，它可以与任何 dnsPolicy 设置一起使用。 但是，当 Pod 的 dnsPolicy 设置为 “None” 时，必须指定 dnsConfig 字段。

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

• nameservers：将用作于 Pod 的 DNS 服务器的 IP 地址列表。 最多可以指定 3 个 IP 地址。当 Pod 的 dnsPolicy 设置为 “None” 时，列表必须至少包含一个 IP 地址，否则此属性是可选的。所列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。
• searches：用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。 指定此属性时，所提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。重复的域名将被删除，Kubernetes 最多允许 6 个搜索域。
• options：可选的对象列表，其中每个对象可能具有 **name 属性（必需）**和 value 属性（可选）。此属性中的内容将合并到从指定的 DNS 策略生成的选项。重复的条目将被删除。

💘 实战：Pod的DNS设置-2023.2.18(测试成功)

• 实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

• 实验软件(无)

• 部署pod资源

以下是具有自定义 DNS 设置的 Pod 示例：

#dnsconfig.yaml 
apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 1.2.3.4
    searches:
      - ns1.svc.cluster-domain.example
      - my.dns.search.suffix
    options:
      - name: ndots
        value: "2"
      - name: edns0

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

[root@master1 ~]#kubectl apply -f dnsconfig.yaml 
pod/dns-example created
[root@master1 ~]#kubectl get po
]NAME          READY   STATUS    RESTARTS   AGE
dns-example   1/1     Running   0          40s
[root@master1 ~]#kubectl exec dns-example -- cat /etc/resolv.conf
search ns1.svc.cluster-domain.example my.dns.search.suffix
nameserver 1.2.3.4
options ndots:2 edns0
[root@master1 ~]#

实验结束。😘

关于我

我的博客主旨：

• 排版美观，语言精炼；
• 文档即手册，步骤明细，拒绝埋坑，提供源码；
• 本人实战文档都是亲测成功的，各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人帮您解决问题，让我们一起进步！

🍀 微信二维码
x2675263825 （舍得）， qq：2675263825。

🍀 微信公众号
《云原生架构师实战》

🍀 博客
www.onlyyou520.com

🍀 csdn
https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

🍀 知乎
https://www.zhihu.com/people/foryouone

最后

好了，关于本次就到这里了，感谢大家阅读，最后祝大家生活快乐，每天都过的有意义哦，我们下期见！