k8s域名解析——k8s域名解析原理・

09-kubernetes中的域名解析流程

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

2、为了方便进行DNS排错，可以部署一个包含nslookup和curl等工具的容器，如busybox。通过访问这个容器，可以方便地测试DNS解析是否正常。总结 Kubernetes集群中的DNS解析是一个复杂的过程，涉及多个组件和配置。

3、在集群中，kubelet起着关键作用，它在拉起容器时，会根据Pod的dnsPolicy设置，自动修改容器的/etc/resolv.conf文件。kubelet将Kubernetes集群的coreDNS服务地址（默认2410）作为clusterip，配置到容器的DNS服务器列表中，这样容器就能通过这个地址进行域名解析。

抓包就明白CoreDNS域名解析

进行CoreDNS抓包前，需要理解一些基础概念。其中，完全限定名称（FQDN）指的是互联网上计算机或主机的完整域名，由主机名、域名、顶级域组成。例如，域名ayunw.cn实际上应为，通常会省略最后的点。

k8s中的dns默认使用的是coredns，通过以下命令查看。k8s中定义的service是有域名的，访问域名要通过dns解析，此时coredns就发挥它的作用了。 上面的试验时我们创建了一个my-service 的nodePort的service，此时查看一下此域名对应的ip，如下图所示，域名解析出来的ip与service对应的ip相同，大功告成。

Kubernetes组件之CoreDNS及DNS解析不通问题

如果CoreDNS也无法解析该请求，则可能会根据配置将请求转发给外部的DNS服务器。DNS解析不通问题分析及解决方案 问题描述：在某些情况下，Pod可能无法解析特定的域名，即使这些域名在CoreDNS中已正确配置。这个问题通常与NodeLocalDNS的配置有关，特别是与其转发DNS请求的方式有关。

解决方案是修改为直接使用全局DNS服务器的IP进行转发，即forward . 200.0.3。通过此方法解决了域名解析不通的问题。为了测试和调试DNS相关问题，提供了一个容器内的测试工具，该工具内置了nslookup工具、curl等常用工具，方便进行DNS排错。以下是用于测试的yaml脚本示例。

另一种情况下，服务器重启后仍遇到coredns异常，可能是由于/etc/resolv.conf文件丢失所致。检查pod的日志和dns配置文件，可以发现类似问题。此问题的解决方式与场景一相同，即重新配置/etc/resolv.conf文件。如果coredns部署后状态在CrashLoopBackOff和Error之间不断切换，查看日志会发现coredns无法启动的迹象。

为了彻底解决此问题，必须重新配置集群环境。先执行kubeadm reset命令，然后在master节点上运行新的kubeadm init命令，并正确指定CIDR网段。此操作需根据网络实际情况进行调整，以确保master节点和工作节点与Calico网络插件间的网络隔离。面对复杂的技术问题，耐心和持续的学习是关键。

默认情况下，Kubernetes集群内的容器要解析外部域名时，CoreDNS会将请求转发给/etc/resolv.conf文件里指定的上游DNS服务器。有时，我们可能需要在集群内全局劫持某个域名时，可以利用hosts插件来帮忙。hosts插件会每隔5s将需解析的信息重新加载到coredns当中，当你有任何变化时直接更新它的配置区块即可。

行为：当Pod使用hostNetwork模式时，如果指定此策略，Pod将使用CoreDNS服务进行DNS解析，而不是宿主机的DNS。适用场景：适用于Pod需要同时使用hostNetwork模式和集群内部DNS解析服务时。None：行为：Pod不依赖Kubernetes或宿主机的DNS，需要手动在Pod配置中提供DNS服务器地址。

k8s搭建hadoop集群,当namenode无法解析journalnode的域名

在K8s搭建Hadoop集群时，如果namenode无法解析journalnode的域名，可以通过以下步骤进行解决：检查Pod的DNS配置：确保namenode Pod的DNS配置正确。在Kubernetes中，Pod通过连接到kube-dns或CoreDNS服务来解析域名。

确认集群状态 检查集群配置：确认HDFS HA集群的配置，包括NameNode （NN）、JournalNode （JN） 和 DataNode （DN） 的数量和分布。在本例中，集群包含两个NameNode （test1， test2），三个JournalNode （test1， test2， test3），以及两个DataNode （test1， test2）。

生成一个集群的ID（ClusterID）。在HA中格式化之前要先启动journalNode，这是由于在格式化的时候最重要是生成一个集群的ID（ClusterID）。格式化命令执行的时候在NameNode结点上有一个verson，在journalNode中也有一个version。

在Hadoop集群中，主节点通常应该包含以下关键进程：NameNode：功能：Hadoop的核心组件，负责管理文件系统的命名空间和文件访问，维护着元数据信息。重要性：确保文件系统的完整性和高效访问。SecondaryNameNode：功能：提供周期性的检查点和清理任务，帮助NameNode合并编辑日志，以减少其启动时间。

DNS在Kubernetes中的高阶玩法(一)

1、node-local-dns通过添加iptables规则能够接收节点上所有发往162510的dns查询请求，把针对集群内部域名查询请求路由到coredns。把集群外部域名请求直接通过host网络发往本地/etc/resolv.conf记录的外部DNS服务器中。

2、在提供的配置中，NodeLocalDNS的Corefile配置了一个.：53段，用于处理所有未明确匹配的域名解析请求。该段中的forward . /etc/resolv.conf指令告诉NodeLocalDNS将未解析的请求转发给/etc/resolv.conf文件中列出的DNS服务器。

3、行为：Pod首先使用Kubernetes的CoreDNS服务进行DNS解析，若CoreDNS无法解析，则转交给宿主机进行解析。适用场景：适用于大多数情况，特别是当Pod需要解析集群内部服务时。Default：行为：Pod采用宿主机的DNS配置进行解析，即使用宿主机的DNS服务器。适用场景：适用于Pod需要解析宿主机所在网络的服务时。