虚拟主机只能静态网站,防蚊手环移动网站建设,广州google推广,电商网站模板html文章目录 概要基础知识Kubernetes 集群中对对象名称的 DNS 流量解析 Kubernetes 集群外的名称的 DNS 流量CoreDNS 如何确定向哪个本地 DNS 请求解析#xff1f;修改 CoreDNS 的配置 概要
CoreDNS 是 Kubernetes 的核心组件之一。只有在 Kubernetes 集群中安装了 容器网络接口… 文章目录 概要基础知识Kubernetes 集群中对对象名称的 DNS 流量解析 Kubernetes 集群外的名称的 DNS 流量CoreDNS 如何确定向哪个本地 DNS 请求解析修改 CoreDNS 的配置 概要
CoreDNS 是 Kubernetes 的核心组件之一。只有在 Kubernetes 集群中安装了 容器网络接口CNI 后CoreDNS 的 Pod 才会启动并运行。CoreDNS 的作用是为 Kubernetes 集群中的对象将名称解析为 IP 地址。
基础知识
CoreDNS 是 Kubernetes 集群中的核心组件作为一个 Pod 运行在集群中的某个节点上。这个节点可以是主节点也可以是工作节点。默认情况下有两个 CoreDNS Pod 分布在两个不同的节点上。这种设置为集群中的名称到 IP 的功能提供了冗余和负载均衡。CoreDNS 是通过一个 Deployment 对象部署的因此可以根据需要进行扩展或缩减。CoreDNS Pod 是通过一个服务(Service)访问的这个服务拥有一个虚拟 IP 地址用于在这些 Pod 之间平衡流量负载。
CoreDNS Pod 属于 kube-system 命名空间其配置存储在同一命名空间中的一个名为 coredns 的 ConfigMap 中。默认配置类似于以下内容
kubeuserk8smaster:~$ kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
data:Corefile: |.:53 {log #注意默认的configMap中没有log记得加上以便于后面的调试errorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153forward . /etc/resolv.conf {max_concurrent 1000}cache 30loopreloadloadbalance}
kind: ConfigMap
metadata:creationTimestamp: 2024-11-18T09:56:27Zname: corednsnamespace: kube-systemresourceVersion: 255uid: 38653b7a-05c2-4f83-bbc4-b7b1e4397f17为了更好地理解 CoreDNS 的行为并便于故障排查可以在配置中添加 log 选项。这样CoreDNS 进行的所有解析操作都会被记录到日志中。随后通过执行 kubectl logs 命令可以查看这些记录从而更直观地分析和排查问题。
Kubernetes 集群中对对象名称的 DNS 流量
CoreDNS 是 Kubernetes 集群的默认 DNS 解析器其服务通常监听在 UDP 端口 53。如果需要捕获 CoreDNS Pod 的所有流入和流出流量建议将 CoreDNS 的副本数缩减为 1 个 Pod从而确保所有流量都通过该实例。
接下来我们通过一个示例来演示如何捕获 DNS 流量。在示例中一个 Pod 将发送 DNS 请求同时我们利用 Cilium 捕获相关流量以便更好地分析和理解。这里使用的 Pod 是 netshoot它集成了多种网络工具在本例中我们将使用 nslookup 工具
kubeuserk8smaster:~$ kubectl run netshoot --imagenicolaka/netshoot -it -- bash
netshoot:~# nslookup nginx-service.default.svc.cluster.local
Server: 10.96.0.10
Address: 10.96.0.10#53Name: nginx-service.default.svc.cluster.local
Address: 10.98.167.203在 netshoot Pod 中我们将集群中某个服务nginx-service的名称解析为其对应的 IP 地址10.98.167.203而 CoreDNS 服务的 IP 地址为 10.96.0.10。
与此同时在另一个终端中我们通过 Cilium 捕获了这段流量。为了监控该流量需要确保使用运行在与 CoreDNS Pod 同一节点上的 Cilium 代理。捕获结果如下所示
kubeuserk8smaster:~$ kubectl exec -it cilium-kbwq7 -n kube-system -- cilium monitor |grep :53
Defaulted container cilium-agent out of: cilium-agent, config (init), mount-cgroup (init), apply-sysctl-overwrites (init), mount-bpf-fs (init), clean-cilium-state (init), install-cni-binaries (init)
- endpoint 118 flow 0x5a3b1331 , identity 27258-53291 state new ifindex lxc29d980acbf33 orig-ip 10.0.1.127: 10.0.1.127:51805 - 10.0.1.47:53 udp
- endpoint 139 flow 0x0 , identity 53291-27258 state reply ifindex lxc78a71191cd5e orig-ip 10.0.1.47: 10.96.0.10:53 - 10.0.1.127:51805 udp
netshoot Pod 的 IP 地址为 10.0.1.127而 CoreDNS Pod 的 IP 地址为 10.0.1.47。我们可以观察到DNS 请求通过端口 53 发送到 CoreDNS Pod随后 CoreDNS 将解析结果返回给 netshoot Pod。
需要注意的是即使该服务名称不存在数据流看起来依然相同。这是因为 CoreDNS 不会进一步尝试解析此类 DNS 请求其原因在于 CoreDNS 对域名 svc.cluster.local 具有权威性。如果 CoreDNS 无法解析那么其他任何 DNS 解析器也无法解析。此外执行 nslookup nginx-service.default 时CoreDNS 会自动尝试解析其管理范围内的多个后缀。
为了完整地展示整个过程以下是与该 DNS 流量相关的 CoreDNS 日志内容
kubectl logs --namespacekube-system -l k8s-appkube-dns
...
[INFO] 10.0.1.127:54548 - 57210 A IN nginx-service.default.svc.cluster.local. udp 57 false 512 NOERROR qr,aa,rd 112 0.000152805s
...我们可以看到 netshoot Pod 的 IP 地址、需要解析的名称以及解析结果。NOERROR 表示解析成功完成最后还显示了解析所花费的时间。如果解析失败将看到 NXDOMAIN 替代 NOERROR。
解析 Kubernetes 集群外的名称的 DNS 流量
当一个 Pod 尝试解析 CoreDNS 无权限管理的域名时会发生不同的处理方式。这些域名可能包括 Ingress 规则中指定的任意 URL或者集群的 API Server 名称。这类名称通常需要通过集群外的 DNS 服务器进行解析以便流量能够正确路由到 Kubernetes 集群外。
在某些架构中可能存在类似场景例如一个 Pod 尝试连接到 Kubernetes 集群外的 Oracle 数据库。在这种情况下数据库的名称解析将由位于本地网络中的外部 DNS 服务器完成而非 CoreDNS。
接下来让我们再次使用 netshoot Pod 来进一步探索这种情况并观察具体行为
netshoot:~# nslookup pcicvs.mydomain.com
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: pcicvs.mydomain.com
Address: 172.19.2.5名称已经被解析但从 Pod 的视角看不到太多有关解析过程的细节。Pod 只知道 CoreDNS 服务的 IP 地址是 10.96.0.10。如果查看该 netshoot Pod 内部的 DNS 配置会看到如下内容
netshoot:~# cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local pci.co.id
nameserver 10.96.0.10
options ndots:5你可以看到 CoreDNS 有权管理的域名和 CoreDNS 服务的 IP 地址仅此而已接下来我们来看看 Cilium 能够看到的关于这类流量的信息
kubectl exec -it -n kube-system cilium-kbwq7 -- cilium monitor|grep :53
- endpoint 1202 flow 0x226176d0 , identity 27258-53291 state new ifindex lxc0c634b736227 orig-ip 10.0.1.127: 10.0.1.127:39445 - 10.0.1.47:53 udp
- stack flow 0x350dacf7 , identity 53291-world state new ifindex 0 orig-ip 0.0.0.0: 10.0.1.47:60021 - 172.19.5.5:53 udp
- endpoint 1202 flow 0x0 , identity world-53291 state reply ifindex lxc0c634b736227 orig-ip 172.19.5.5: 172.19.5.5:53 - 10.0.1.47:60021 udp
- endpoint 1320 flow 0x0 , identity 53291-27258 state reply ifindex lxc15973d8c3d02 orig-ip 10.0.1.47: 10.96.0.10:53 - 10.0.1.127:39445 udp在这个案例中你可以看到由于 CoreDNS 并没有管理 mydomain.com 的权限它会向它已知的 DNS 请求解析操作。在这个例子中它使用了 kubernetes cluster外部的LAN DNS172.19.5.5来完成解析同时为了匿名化我们本地网络中的真实 DNS IP 地址使用了这个公共 DNS。因此DNS 流量的路径如下所示 Netshoot Pod (10.0.1.127) - CoreDNS Pod (10.0.1.47) - 本地 DNS (172.19.5.5)然后沿同一路径返回。 需要注意的是这是 Kubernetes 集群中 Cilium 代理所观察到的流量路径但实际上我们的本地 DNS 可能还会向其他 DNS 请求解析操作这就是标准的 DNS 递归解析机制。 在 CoreDNS 的日志中可以看到这个名称解析操作已经成功完成并且解析所花费的时间比集群内部解析稍长。这是因为流量需要经过本地 DNS多了一些处理步骤。 kubectl logs --namespacekube-system -l k8s-appkube-dns -f
...
[INFO] 10.0.1.127:45895 - 16502 A IN pcicvs.mydomain.com. udp 34 false 512 NOERROR qr,aa,rd,ra 66 0.000089403s
...CoreDNS 如何确定向哪个本地 DNS 请求解析
CoreDNS 知道向哪个本地 DNS 请求解析的答案来自其配置文件中的 ConfigMap例如其中的 forward 插件配置forward . /etc/resolv.conf。这是本文开头提到的配置。 你是否可以查看 /etc/resolv.conf 文件的内容及其来源 Pods 的设计初衷是提供特定功能因此其容器镜像通常仅包含实现该功能所需的最小工具集。这意味着容器中可能没有像 shell 这样的工具从而减少了潜在攻击面。例如CoreDNS 镜像就不包含 shell。尽管如此你仍可以通过一些方法“模拟”出一个 shell 来探索容器中的文件
kubectl debug -it coredns-58f6d65b75-zgfw6 -n kube-system --imagenicolaka/netshoot --targetcoredns --image-pull-policyIfNotPresent
coredns-58f6d65b75-zgfw6 ~ cat /proc/1/root/etc/resolv.conf
通过 kubectl debug你可以使用你选择的其他镜像进入 Pod同时仍然可以访问原始 CoreDNS 容器的内容。在目标 Pod coredns-58f6d65b75-zgfw6中CoreDNS 容器的名称是 coredns。然后你可以查看 /proc/1/root/etc/resolv.conf 的内容这正是我们要找的文件。 顺便说一下CoreDNS 的 ConfigMap 也作为文件存储在这个容器中路径是 /proc/1/root/etc/coredns/Corefile。 问题是这个 resolv.conf 文件是从哪里来的其实很简单它来自于托管 CoreDNS Pod 的节点的 /etc/resolv.conf 文件我做了一个测试往节点的 /etc/resolv.conf 文件中添加了一条记录然后重新部署了 CoreDNS结果确实如预期那样添加的记录也出现在了 CoreDNS 容器的 /etc/resolv.conf 中记住CoreDNS Pod 可以托管在集群中的任何节点上。因此如果你想做这个测试你可以强制 Pod 调度到特定的节点或者修改所有节点的 /etc/resolv.conf 文件。在实验室中使用几台节点来测试应该会非常容易。
修改 CoreDNS 的配置
到目前为止已经了解了 CoreDNS 的工作原理但有没有办法可以从集群内部控制名称解析呢 可能的架构中Pod 需要使用由集群的 Ingress 控制器管理的 URL。在这种情况下如前所述名称解析将不会由 CoreDNS 完成而是由你的本地 DNS 处理。在你的组织中这些本地 DNS可能由其他团队管理你无法对它们进行控制。如果由于某些原因这些本地 DNS 无法访问那么集群中的应用程序将无法正常工作。 如果希望集群中的 Pod 能够独立解析这些 URL 名称那么你可以通过使用 CoreDNS 的 hosts 插件在 CoreDNS 中静态映射这些名称。 只需编辑 CoreDNS 的 ConfigMap将 hosts 插件添加到 forward 插件之前即可在 CoreDNS 的术语中这些块或指令被称为插件如下所示 hosts插件示范内容 hosts {172.19.2.5 pcicvs.mydomain.comfallthrough}coredns congfigMap完整内容
kubeuserk8smaster:/etc$ kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
data:Corefile: |.:53 {logerrorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153hosts {172.19.2.5 pcicvs.mydomain.comfallthrough}forward . /etc/resolv.conf {max_concurrent 1000}cache 30loopreloadloadbalance}
kind: ConfigMap
metadata:creationTimestamp: 2024-11-18T09:56:27Zname: corednsnamespace: kube-systemresourceVersion: 5271081uid: 38653b7a-05c2-4f83-bbc4-b7b1e4397f17
不久后如果你从 netshoot Pod 再次尝试解析pcicvs.mydomain.com 的名称会发现它返回在 hosts 插件中设置的 IP 地址。 因此CoreDNS 能够直接解析该 URL而无需向 /etc/resolv.conf 中配置的本地 DNS 发送请求。参数 fallthrough 的作用是如果 hosts 插件中没有静态映射则会像之前一样将 DNS 请求转发给本地 DNS 进行解析。
这一更改是动态生效的无需重启并且通过 fallthrough 参数如果没有找到匹配的映射解析仍然会交由本地 DNS 处理从而能够解析外部名称或 URL。通过这种方式你可以根据需求逐步添加由 CoreDNS 处理的域名映射。这不仅能够加快名称解析的速度还可以让你对解析过程保持更好的控制。然而这样做的缺点是当新的应用例如使用 Ingress 规则的应用部署到集群时你需要及时更新这些映射。
需要注意的是在 CoreDNS 配置中fallthrough 参数用于决定当一个插件无法处理 DNS 请求时是否将请求传递给下一个插件。 因此将 hosts 插件放在 forward 插件之后没有意义因为 forward 插件没有 fallthrough 参数无法将请求传递回 hosts 插件。因此hosts 插件的映射就永远不会被访问到。为了确保 hosts 插件能够生效它应该放在 forward 插件之前。
