Kubernetes内部域名解析的那些事儿

专治不开心 發表於 2020-6-9 11:02:00

<h1>前言</h1>
    在kubernets环境中，服务发现大都是基于内部域名的方式。那么就涉及到内部域名的解析。从1.11版本开始，kubeadm已经使用第三方的CoreDNS替换官方的kubedns作为集群内部域名的解析组件。
<h1>kubernets中的4种DNS策略</h1>
<h2>None</h2>
表示空的DNS设置，这种方式一般用于想要自定义 DNS 配置的场景，往往需要和 dnsConfig 配合一起使用达到自定义 DNS 的目的。
<h2>Default</h2>
此种方式是让kubelet来决定使用何种DNS策略。而kubelet默认的方式，就是使用宿主机的/etc/resolv.conf文件。
同时，kubelet也可以配置指定的DNS策略文件，使用kubelet参数即可，如：–resolv-conf=/etc/resolv.conf
<h2>ClusterFirst</h2>
此种方式是使用kubernets集群内部中的kubedns或coredns服务进行域名解析。若解析不成功，才会使用宿主机的DNS配置来进行解析。
<h2>ClusterFistWithHostNet</h2>
在某些场景下，我们的 POD 是用 HOST 模式启动的（HOST模式，是共享宿主机网络的），一旦用 HOST 模式，表示这个 POD 中的所有容器，都要使用宿主机的 /etc/resolv.conf 配置进行DNS查询，但如果你想使用了 HOST 模式，还继续使用 Kubernetes 的DNS服务，那就将 dnsPolicy 设置为 ClusterFirstWithHostNet。
<h2>策略配置示例</h2>
DNS策略，需要在Pod，或者Deployment、RC等资源中，设置 dnsPolicy 即可，以 Pod 为例：
<div class="cnblogs_code">
<pre>apiVersion: v1
kind: Pod
metadata:
labels:
name: cadvisor-nodexxxx
hostip: 192.168.x.x
name: cadvisor-nodexxxx
namespace: monitoring
spec:
containers:
- args:
- --profiling
- --housekeeping_interval=10s
- --storage_duration=1m0s
image: google/cadvisor:latest
name: cadvisor-nodexxxx
ports:
- containerPort: 8080
 name: http
 protocol: TCP
resources: {}
securityContext:
 privileged: true
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
nodeName: nodexxxx</pre>
</div>
<h1>kubernets中域名解析流程</h1>
# Pod中的resolv.conf的解析配置
# kubectl exec -it nginx-deploy-5754944d6c-dtzpj cat /etc/resolv.conf
<div class="cnblogs_code">
<pre>nameserver 10.96.0.2
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5</pre>
</div>
# kubectl get svc -n kube-system |grep dns
<div class="cnblogs_code">
<pre>kube-dns ClusterIP10.96.0.2 <none> 53/UDP,53/TCP,9153/TCP 158d</pre>
</div>
a）文件中配置的 nameserver 一般是k8s集群内部的dns服务的ClusterIP，无法ping，但是可以访问。
b）意味着集群Pod内部的所有域名的解析，都要经过kubedns的虚拟ip 10.96.0.2 进行解析。
c）resolv.conf中search域分别是default.svc.cluster.local svc.cluster.local cluster.local，在kubernets中，域名的全称必须是 service-name.namespace.svc.cluster.local 。
d）假如集群中有一个svc（Service）名为a，在某个Pod中执行命令 curl a 时，在此Pod中会根据/etc/resolv.conf进行解析流程。选择nameserver 10.96.0.2进行解析，将字符串'a'带入到/etc/resolv.conf文件中不同的search域，依次进行查找，如下：
a.default.svc.cluster.local -> a.svc.cluster.local -> a.cluster.local
先查找 a.default.svc.cluster.local ，若找不到，则再查找 a.svc.cluster.local ，依次往下进行，直到找到为止。
<h1>curl效率分析</h1>
在集群中若存在一个名为a的svc，在Pod中curl a和curl a.default都能实现请求，那么两种方式哪个的效率高呢？
那肯定是curl a啦，因为发起此请求时，通过/etc/resolv.conf中第一列的search域就能直接找到 a.default.svc.cluster.local ，直接避免了下一级的查找。
<h1>容器中访问外部域名讲述</h1>
下文将通过示例说明Pod访问外部域名时发起的相应的请求信息。
以请求baidu.com为例，因为DNS容器一般不具备bash，所以无法通过docker exec的方式进入容器抓包，所以此处采用进入到DNS容器的网络中（不是发起DNS请求的容器）的姿势去抓包，抓包姿势准备好后，同时在某容器中访问baidu.com，即可看到在进行的DNS查找的过程中都产生了什么样的数据包。
 
### 实操 
# 进入dns容器网络，准备好抓包姿势 
# 查看Pod所在具体的node节点
# kubectl get pods -n kube-system -o wide|grep dns
<div class="cnblogs_code">
<pre>coredns-5c48579f88-8wprg1/1 Running16 30d 10.244.4.120 node1
coredns-5c48579f88-rsnpr 1/1 Running 0 30d 10.244.5.142 node2</pre>
</div>
# 这里以node1上的容器为操作对象，所以到node1节点上进行操作 
# 找到容器并打印对应的NS ID
# docker ps |grep dns
<div class="cnblogs_code">
<pre>a964bbb43534 c0f6e815079e "/coredns -conf /etc…" 2 days ago Up 2 days k8s_coredns_coredns-5c48579f88-8wprg_kube-system_b1e7f3c3-98eb-4843-b156-1d203f98bd74_16
fbd12d2f9c7c k8s.gcr.io/pause:3.1 "/pause" 5 days ago Up 5 days k8s_POD_coredns-5c48579f88-8wprg_kube-system_b1e7f3c3-98eb-4843-b156-1d203f98bd74_3</pre>
</div>
# docker inspect --format "{{.State.Pid}}"  a964bbb43534
<div class="cnblogs_code">
<pre>21617</pre>
</div>
# 进入此容器的网络Namespace
# nsenter -n -t 21617
# 抓包姿势就绪
# tcpdump -i eth0 udp dst port 53|grep 'baidu.com'
 
# 在另外的某容器中，进行域名查找操作 
说明：一般pod中没有nslookup命令，故需要手动安装，根据不同环境自选以下操作。
### Centos 
]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
]# yum -y install bind-utils
### Debian 
# cat /etc/issue
Debian GNU/Linux 9
# apt-get install dnsutils -y
root@jenkins-7d66bf7977-cm4x4:~# nslookup baidu.com 10.244.4.120
 
注意：10.244.4.120是node1上的dns pod在kubernets集群中的内部通信ip地址。因为环境中有两个dns pod，将其指定要单个具体的容器，能够使抓包数据完整。
 
# 随后，在前面就绪的抓包姿势窗口就能看到数据包的出现 
# tcpdump -i eth0 udp dst port 53|grep 'baidu.com'
<div class="cnblogs_code">
<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:57:50.791154 IP 10.244.4.127.51794 > node1.domain: 55406+ A? baidu.com.infra.svc.cluster.local. (51)
16:57:50.792540 IP 10.244.4.127.56306 > node1.domain: 27958+ A? baidu.com.svc.cluster.local. (45)
16:57:50.793439 IP 10.244.4.127.59799 > node1.domain: 27048+ A? baidu.com.cluster.local. (41)
16:57:50.799463 IP 10.244.4.127.39116 > node1.domain: 2303+ A? baidu.com. (27)</pre>
</div>
说明： 
a）数据包中显示的 infra 是执行nslookup的pod的NameSpace；
b）根据数据显示，在真正解析到 baidu.com 之前，经历了baidu.com.infra.svc.cluster.local. > baidu.com.svc.cluster.local. > baidu.com.cluster.local. 三次DNS请求。
<h1>请求浪费的原因</h1>
上文在正确请求到baidu.com之前，有过三次无效请求，即意味着请求浪费，那为什么会出现那种情况呢，请继续往下看。
 
# Pod中的resolv.conf的解析配置
<div class="cnblogs_code">
<pre>root@jenkins-7d66bf7977-cm4x4:/# cat /etc/resolv.conf
nameserver 10.96.0.2
search infra.svc.cluster.local svc.cluster.local cluster.local host.com
options ndots:5</pre>
</div>
 
# options ndots:5 解释 
如果查询的域名包含的点"."，不到5个，那么进行DNS查找，将使用非完全限定名称（或者叫绝对域名），如果你查询的域名包含点数大于等于5，那么DNS查询，默认会使用绝对域名进行查询。
如果我们请求的域名是，a.b.c.d.e，这个域名中有4个点，那么容器中进行DNS请求时，会使用非绝对域名进行查找，使用非绝对域名，会按照 /etc/resolv.conf 中的 search 域，走一遍追加匹配：
a.b.c.d.e.cicd.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查找。
 
说明： 
a）请求域名中点数少于5个时，先走search域，最后将其视为绝对域名进行查询；
b）请求域名中点数大于等于5个时，直接视为绝对域名进行查找，只有当查询不到的时候，才继续走 search 域。
<h1>优化请求浪费</h1>
<h2>使用全限定域名</h2>
当访问某域名时，以 '.' 为后缀，即使用完全限定域名（绝对域名），这样发起的域名请求时将不会走search域进行匹配，而是直接使用整个原始域名字符串为个体进行解析。
 
如：
nslookup baidu.com.
<h2>配置特定ndots</h2>
在kubernets中，ndots值默认是5。是因为，Kubernetes 认为，内部域名，最长为5，要保证内部域名的请求，优先走集群内部的DNS，而不是将内部域名的DNS解析请求，有打到外网的机会，Kubernetes 设置 ndots 为5是一个比较合理的行为。
如果有特定业务需求，也可配置ndots，如下：
<div class="cnblogs_code">
<pre>apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
 image: nginx
dnsConfig:
options:
 - name: ndots
 value: "1"</pre>
</div>

</div>
<div id="MySignature" role="contentinfo">
========================================
<div>
作者：罗穆瑞
</div>
<div>
出处：http://www.cnblogs.com/kazihuo/
</div>
转载请保留此段声明，且在文章页面明显位置给出原文链接，谢谢！
==============================================================================

^_^ 如果觉得这篇文章对你有小小的帮助的话，记得在右下角点个“推荐”哦，您的“推荐”将是我最大的写作动力 ^_^
============================================================================== 
来源：https://www.cnblogs.com/kazihuo/p/13071242.html

頁: [1]

琼殿技术论坛's Archiver

Kubernetes内部域名解析的那些事儿