关于kubernetes与DNS，你必须知道的微服务架构的服务管理

Posted 2021-04-14 苏研大云人

应用场景

在kubernetes中每一个service都会被分配一个虚拟IP（kube-proxy生成访问规则，其虚拟IP可在创建service时直接指定），每一个Service在正常情况下都会长时间不会改变，所属该service的pod的IP因各种原因会有所变化，如pod实例因为业务流量过大，触发HPA规则，致使pod数量动态增长，但是对于该集群来说，使用该service进行通信是相对稳定的。但是如果其他应用需要与该Service进行通信，只有将service的信息注入到pod环境变量的方式，且严格规定了pod和service的启动顺序（当然可以使用init container方式来进行服务监测，这使得Kuberntees集群的使用不是太优雅。

基于上述一些原因，kubernetes以插件的方式引入了DNS 系统，利用DNS对Service进行一个映射，这样我们在应用中直接使用域名进行访问，避免了之前的变量配置问题，也解决了创建顺序的强依赖问题，cncf为产品化发展给出了如下的分层架构图。

服务注册

服务注册中心是服务发现机制中的核心部分。它是一个包含服务实例弟子的数据库(如etcd)。服务注册中心需要实现高可用并实时更新。客户端可以缓存从服务注册中心获取的网络位置。但是，信息最终会过期，导致客户端不能发现服务实例。于是，服务注册中心可以使用K/V存储的一致性来解决服务器集群的一致性问题。

kubernetes中以插件的方式使用dnsmasq作为DNS服务器。并且引入了一个另外一个组件kube-dns用来创建和删除域名解析记录及提供自身的健康检查。它目前仅支持两种解析A记录、SRV记录，在集群中对于域名的创建遵循一个规则：

对于A记录：

每一个Service都会对应一个A记录，命名规则为：

SERVICENAME.NAMESPACENAME.svc.CLUSTERDOMAIN

SERVICENAME：每个Service的名字

NAMESPACENAME：Service所属的namespace的名字

svc：固定值

CLUSTERDOMAIN：集群内部的域名

对于SRV记录：

每一个服务端口和服务协议会对应一个SRV记录，命名规则为：

_PORTNAME._PORTPROTOCOL.SERVICENAME.NAMESPACENAME.svc.CLUSTERDOMAIN

_PORTNAME：服务端口名字

PORTPROTOCOL：服务端口的协议类型

SERVICENAME：每个Service的名字

NAMESPACENAME：Service所属的namespace的名字

svc：固定值

CLUSTERDOMAIN：集群内部的域名

其中，

SRV记录: 是服务器资源记录的缩写，SRV记录的作用是用于描述一个服务器能够提供什么样的服务。

基于云的微服务架构，因为自动（手动）伸缩、故障、升级等，服务实例（pods）动态生成IP集合,kub-proxy将它的IP添加进iptables，kube-proxy监听kubernetes事件，当该pod实例终止的时候，该IP将会从iptables删除。其他方式的服务访问，以后做深入介绍。

组件分析

kubernetes推荐使用的dns组件有以下两种：

1

coredns

2

kube-dns

其中，CoreDNS基于Caddy实现域名服务器，CoreDNS同样具备中间件序列功能，类似openstack中的middleware，CoreDNS被作为SkyDNS的下一代产品，其依靠etcd存储服务信息，提供域名访问服务。

CoreDNS支持多种查询请求方式：UDP/TCP，TLS以及gRPC。主要功能有：域名安全、缓存、健康检查、pprof、rewrite、支持kubernetes、whoami、日志管理、metrics（prometheus）、服务代理等。

再来看看kube-dns，主要有三大组件sidecar、dnsmasq、kube-dns，其中sidecar负责对外暴露监控指标（prometheus类型）以及提供域名系统的健康检查功能，kube-dns负责监听apiserver事件，生成／删除域名记录，dnsmasq使用开业dnsmasq工具提供域名访问服务,原理如下图所示。

性能测试

首先准备查询域名目标，如下操作：

    [root@ys-2 ~]# for i in `kubectl get svc -n kube-system|awk '{ print $1}'`;do echo $i".kube-system.svc.cluster.local" >> ns.txt;done
    [root@ys-2 ~]# touch nq.txt
    [root@ys-2 ~]# for i in `seq 1 10000`;do cat ns.txt >> nq.txt;done

生产10w+查询目标，使用queryperf测试工具

社区结果如下：

启用缓存：

Kube-DNS (cache enabled): 15k qps

CoreDNS (cache enabled): 8k qps

未用缓存：

Kube-DNS (cache disabled): 7k qps

CoreDNS (cache disabled): 5k qps

实际结果：

未用缓存：

Kube-DNS (cache disabled): 3.8k qps

CoreDNS (cache disabled): 4.2k qps

结论

通过对dnsmasq的性能调优，如开启缓存功能等，Kube-DNS满足绝大多数应用场景，若需实现多集群的服务管理，使用Kubernetes(Federation多集群功能)，社区推荐使用CoreDNS，当然，可以采用第三方技术实现多集群的服务管理，如hashicorp开源工具(consul)等。

1

END

1

更

多

精

彩

请猛戳右边二维码

苏研大云人