Kubernetes(k8s)-CoreDNS介绍(一)

我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。

我们在前面介绍svc的的时候，可以通过ping svc的而获取到svc的ClusterIP。而我们在linux进阶里面讲过从域名变成ip是dns的功能，在k8s的里面实现这个dns的功能是CoreDNS。

基本介绍

CoreDNS 是一个用于域名解析的开源软件。它是 Kubernetes 默认的 DNS 插件，并且也可以用作独立的 DNS 服务器。

以下是 CoreDNS 的一些主要特点和功能：

1. 灵活的插件架构：CoreDNS 使用插件来实现各种功能，例如域名解析、缓存、负载均衡、反向代理等。这使得 CoreDNS 可以根据需求进行定制和扩展。
2. 支持多种后端数据源：CoreDNS 可以从多种数据源获取域名解析信息，例如文件、etcd、Consul、Kubernetes API 等。这使得 CoreDNS 可以适应不同的部署环境和使用场景。
3. 高性能和高可用性：CoreDNS 具有高性能和高可用性，可以处理大量的 DNS 查询请求，并且支持水平扩展和故障转移。
4. 简化的配置文件：CoreDNS 使用简洁的配置文件语法，易于理解和维护。它还支持使用 YAML 配置文件，并且可以通过 API 进行动态配置更新。
5. 支持插件链：CoreDNS 的插件可以按照特定的顺序链接起来，形成处理 DNS 查询的管道。这使得用户可以根据需求选择和配置所需的插件。

CoreDNS 在 Kubernetes 中扮演着重要的角色，为集群中的服务提供了域名解析功能。它可以解析 Kubernetes 中的服务和 Pod 的域名，实现内部服务之间的通信。同时，CoreDNS 也可以配置为将外部域名解析为集群中的服务，实现从集群内外的服务访问。

Pod解析流程

1. Pod 内部解析:
   • 应用程序或容器内的代码发起域名解析请求。
   • 解析库（例如 glibc）读取 /etc/resolv.conf 文件中的配置，该文件指定了用于 DNS 查询的名称服务器，我们在讲Docker-联合文件的时候讲过，这个文件是自动生成，k8s创建的普通pod这个文件都会指向coredns的ClusterIP。
2. CoreDNS 解析:
   • 如果本地解析不成功或者 /etc/resolv.conf 中配置了集群内部的 DNS 服务地址，那么 Pod 将会向 CoreDNS 发送 DNS 请求。CoreDNS 是 Kubernetes 默认的 DNS 服务，通常通过名为 kube-dns 或 coredns 的 Service IP 地址被访问。早期的版本才会使用的是kube-dns。
3. CoreDNS 插件链处理:
   • CoreDNS 收到请求后，根据其配置文件中定义的插件链顺序处理请求。这可以包含缓存、转发到上游 DNS 服务器、健康检查等功能。
4. 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。