Kubernetes 1.5.2环境下DNS解析失败怎么办？

在Kubernetes的演进历程中，1.5.2版本是一个重要的里程碑，它奠定了现代服务发现和网络自动化的基础，尽管这个版本已经相当古老，但其DNS（域名系统）的实现机制——kube-dns，对于理解Kubernetes网络核心原理依然具有极高的学习价值，本文将深入探讨Kubernetes 1.5.2中的DNS架构、工作原理及其关键配置。

kube-dns 的核心架构

在Kubernetes 1.5.2时代，集群的DNS功能并非由如今广泛使用的CoreDNS提供，而是通过一个名为kube-dns的系统组件来实现。kube-dns本身并非单一程序，而是一个由三个容器组成的Pod，协同工作以提供完整的DNS服务，这种设计体现了“单一职责，组合工作”的哲学。

下表清晰地展示了这三个容器的分工：

容器名称	主要职责	关键技术
skydns	DNS服务核心，负责解析Kubernetes集群内的服务（Service）和Pod的域名。	使用SkyDNS库，后端存储为etcd。
dnsmasq	DNS缓存和转发器，作为前端，缓存查询结果以提高性能，并将外部域名查询转发给上游DNS服务器。	轻量级DNS转发工具，配置灵活。
sidecar (healthz)	健康检查与报告，定期检查`skydns`和`dnsmasq`的健康状态，并通过HTTP端点向Kubernetes报告，确保服务发现的高可用性。	简单的HTTP服务器，用于Kubernetes健康检查探针。

这种架构的优势在于性能和稳定性。dnsmasq作为缓存层，可以显著减少对后端skydns的直接访问压力，从而加快域名解析速度，而sidecar容器则确保了当DNS服务出现问题时,Kubernetes能够及时感知并采取相应措施。

DNS 解析流程详解

当一个集群内的Pod需要访问另一个服务时,其域名解析过程如下：

发起查询：Pod内的应用（例如一个Nginx容器）尝试访问一个服务名，如my-service.database。
读取配置：Pod的/etc/resolv.conf文件被Kubelet自动配置，其nameserver指向kube-dns服务的ClusterIP,查询请求被发送到这个虚拟IP。
到达缓存层：请求首先到达kube-dns Pod中的dnsmasq容器。dnsmasq会检查其缓存中是否有该记录。
缓存未命中：如果缓存中没有，dnsmasq会将查询转发给本地的skydns容器。
后端查询：skydns接收到查询后，会向其数据源——etcd——查询与my-service.database.svc.cluster.local（完整的FQDN）对应的记录，etcd中存储了由Kubernetes API Server创建的所有服务和端点的信息。
返回结果：skydns从etcd获取到该服务的ClusterIP，并将其返回给dnsmasq。
缓存并响应：dnsmasq将结果缓存起来,然后最终将IP地址返回给最初发起查询的Pod。
建立连接：Pod获得服务的ClusterIP后,便可以通过集群内部的网络进行通信。

对于集群外部的域名（如www.google.com），dnsmasq会根据其配置，将查询转发给在节点上配置的上游DNS服务器（通常是/etc/resolv.conf中指定的地址）,从而实现外部域名解析。

关键配置文件

每个Pod的/etc/resolv.conf文件是DNS解析工作的起点，在Kubernetes 1.5.2中,它通常看起来像这样：

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

nameserver：指向kube-dns服务的ClusterIP。
search：定义了域名搜索路径，当查询一个不带后缀的名称（如my-service）时，系统会依次尝试my-service.default.svc.cluster.local、my-service.svc.cluster.local等。
options ndots:5：这个选项很重要，它规定，如果一个域名中包含的点（）数量少于5个，它将首先被视为一个相对域名，并应用search路径进行搜索，只有当点数大于等于5时，才会直接作为绝对域名（FQDN）进行查询。