作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。
我们在前面介绍svc的的时候，可以通过ping svc的而获取到svc的ClusterIP。而我们在linux进阶里面讲过从域名变成ip是dns的功能，在k8s的里面实现这个dns的功能是CoreDNS。
基本介绍
CoreDNS 是一个用于域名解析的开源软件。它是 Kubernetes 默认的 DNS 插件，并且也可以用作独立的 DNS 服务器。
以下是 CoreDNS 的一些主要特点和功能：
-
灵活的插件架构：CoreDNS 使用插件来实现各种功能，例如域名解析、缓存、负载均衡、反向代理等。这使得 CoreDNS 可以根据需求进行定制和扩展。
-
支持多种后端数据源：CoreDNS 可以从多种数据源获取域名解析信息，例如文件、etcd、Consul、Kubernetes API 等。这使得 CoreDNS 可以适应不同的部署环境和使用场景。
-
高性能和高可用性：CoreDNS 具有高性能和高可用性，可以处理大量的 DNS 查询请求，并且支持水平扩展和故障转移。
-
简化的配置文件：CoreDNS 使用简洁的配置文件语法，易于理解和维护。它还支持使用 YAML 配置文件，并且可以通过 API 进行动态配置更新。
-
支持插件链：CoreDNS 的插件可以按照特定的顺序链接起来，形成处理 DNS 查询的管道。这使得用户可以根据需求选择和配置所需的插件。
CoreDNS 在 Kubernetes 中扮演着重要的角色，为集群中的服务提供了域名解析功能。它可以解析 Kubernetes 中的服务和 Pod 的域名，实现内部服务之间的通信。同时，CoreDNS 也可以配置为将外部域名解析为集群中的服务，实现从集群内外的服务访问。
Pod解析流程
- Pod 内部解析:
-
应用程序或容器内的代码发起域名解析请求。
-
解析库（例如 glibc）读取
/etc/resolv.conf文件中的配置，该文件指定了用于 DNS 查询的名称服务器，我们在讲Docker-联合文件的时候讲过，这个文件是自动生成，k8s创建的普通pod这个文件都会指向coredns的ClusterIP。
- CoreDNS 解析:
- 如果本地解析不成功或者
/etc/resolv.conf中配置了集群内部的 DNS 服务地址，那么 Pod 将会向 CoreDNS 发送 DNS 请求。CoreDNS 是 Kubernetes 默认的 DNS 服务，通常通过名为kube-dns或coredns的 Service IP 地址被访问。早期的版本才会使用的是kube-dns。
- CoreDNS 插件链处理:
- CoreDNS 收到请求后，根据其配置文件中定义的插件链顺序处理请求。这可以包含缓存、转发到上游 DNS 服务器、健康检查等功能。
- Kubernetes Service 解析:
- 对于 Kubernetes Service 域名的请求，CoreDNS 会查询 Kubernetes API Server 来获取对应的服务 IP 地址，并将结果返回给 Pod。
简单来就是pod发起dns请求和普通服务器发起dns流程一样，先找hosts，然后向/etc/resolv.conf里面配置的dns进行请求（而这里默认配置的则是Coredns）参考下图，如果Coredns无法解析，则递归pod的/etc/resolv.conf,而这个文件的内容刚好就是pod所在主机的resolv.conf(以前我记得是通过hostpath挂载的，现在的版本好像看不到这个配置)。所以主机的这个文件也不能轻易修改。
普通容器这个文件和coredns这个文件，都是docker创建的时候生成的，暂时不清楚他是怎么实现的逻辑导致他们的dns文件不一样。但是可以记住，这个域名解析流程就行，也可以通过控制Coredns的配置文件来修改dns的解析流程和路径。
CoreDNS是这个pod是在k8s安装的时候就自动生成，是通过deployment控制的，默认2个副本，配置文件通过configmap方式注入到pod。
运维小路
一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！
关注微信公众号《运维小路》获取更多内容。
