k8spod不能解析svc域名，k8s解析外部域名

kubernetes组件之CoreDNS及dns解析不通问题

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

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

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

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

5、CoreDNS的作用 DNS解析服务：CoreDNS是Kubernetes集群中默认的DNS解析服务。它负责将DNS查询转发到正确的后端服务，并返回解析结果。配置pod的DNS：kubelet会将每个Pod的/etc/resolv.conf文件配置为使用CoreDNS Pod作为名称服务器。这意味着Pod内的所有DNS查询都会通过CoreDNS进行处理。

K8S搭建hadoop集群,当nameNode无法解析journalnode的域名

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

重新格式化NameNode：如果NameNode在初次启动时未进行格式化，或者后续进行了不恰当的格式化操作，需要在确保数据安全的前提下重新对NameNode进行格式化。但请注意，此操作会删除HDFS上的所有数据，因此需谨慎执行。

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

当Hadoop HDFS High Availability （HA） 集群中的JournalNode （JN） edit log丢失时，可以通过以下步骤进行恢复。请注意，此过程可能会导致近期写入的数据丢失，因此在执行前务必确认数据备份和可接受的数据丢失范围。

自动故障切换：当主NameNode出现故障时，备用NameNode能够自动接管服务，确保文件系统的连续运行。数据一致性：通过同步机制，确保主备NameNode之间的元数据一致性，从而避免数据丢失或不一致的问题。高可用性：通过冗余配置和故障切换机制，提高了文件系统的整体可用性。

pod内部访问svc失败分析

始终是1/2的成功率，但是完全没有新的contrack记录。 pod访问svc 应该没走kube-Proxy。解决方式： 移除eth1的网卡上的ip，该情况完全消失。

Cluster IP访问不通：由于服务名称访问的核心机制是通过kube-dns解析为Cluster IP，再由kube-proxy将Cluster IP形成iptables的chain进行路由，因此尝试直接使用Cluster IP进行通信，但依然不通。Pod内部nslookup失败：进入一个正在运行的Pod内部，执行nslookup命令解析服务名称失败，但在主机上却可以成功解析。

原因：镜像问题导致容器重启失败。解决方法：更换镜像。Pod创建失败：原因：镜像问题导致容器无法启动。解决方法：更换镜像。Pod的ready状态未进入：原因：Pod的执行命令失败，无法获取资源。解决方法：进入容器内部，创建yaml定义的资源。Pod创建失败：原因：yml文件内容出错，如使用了中文字符。

若pod1需访问pod2，通常通过Service2的域名进行访问，直接访问pod较为罕见，因pod IP易变，而服务IP相对稳定。当pod1使用servicenamespacesvc.cluster.local发起域名解析请求时，NodeLocalDNS若缓存中未找到解析结果，则将请求转发至全局CoreDNS。全局CoreDNS解析后将IP返回给pod1，完成访问过程。

Service 的 DNS 解析 普通 Service 的 DNS 解析 当创建一个普通的 Service 时，Kubernetes 会为该 Service 分配一个 DNS A 记录，格式为 my-svc.my-nameSpace.svc.cluster.local。