【DNS系列】k8s中kube-proxy与kube-dns的关系
参考
-
CoreDNS：Kubernetes内部域名解析原理、弊端及优化方式
-
coredns和kube-proxy简介和区别
-
K8s CoreDNS落地实践
-
【kubernetes/k8s源码分析】coredns 源码分析之一解读源码
-
k8s service的DNS名称解析之CoreDNS
-
一篇文章为你图解 Kubernetes 网络通信原理，运维请收藏~
基础
Kubernetes 早期的 DNS 组件叫 KubeDNS。CNCF 社区后来引入了更加成熟的开源项目 CoreDNS 替换了 KubeDNS。所以我们现在提到 KubeDNS，其实默认指代的是 CoreDNS 项目。在 Kubernetes 中部署 CoreDNS 作为集群内的 DNS 服务有很多种方式，例如可以使用官方 Helm Chart 库中的 Helm Chart 部署，具体可查看 CoreDNS Helm Chart。
1 | kube-proxy
kube-proxy 与 service 关系
在k8s中，提供相同服务的一组pod可以抽象成一个service，通过service提供的统一入口对外提供服务，每个service都有一个虚拟IP地址（VIP）和端口号供客户端访问。kube-proxy存在于各个node节点上，主要用于Service功能的实现，具体来说，就是实现集群内的客户端pod访问service，或者是集群外的主机通过NodePort等方式访问service。
service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP。kube-proxy的作用主要是负责service的实现，具体来说，就是实现了内部从pod到service和外部的从node port向service的访问。
在当前版本的k8s中，kube-proxy默认使用的是iptables模式，通过各个node节点上的iptables规则来实现service的负载均衡，但是随着service数量的增大，iptables模式由于线性查找匹配、全量更新等特点，其性能会显著下降。从k8s的1.8版本开始，kube-proxy引入了IPVS模式，IPVS模式与iptables同样基于Netfilter，但是采用的hash表，因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡，它运行在每个Node计算节点上，负责Pod网络代理, 它会定时从etcd服务获取到service信息来做相应的策略，维护网络规则和四层负载均衡工作。在K8s集群中微服务的负载均衡是由Kube-proxy实现的，它是K8s集群内部的负载均衡器，也是一个分布式代理服务器，在K8s的每个节点上都有一个，这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。
nodeport service 中 kube-proxy 的作用
kube-proxy功能主要是外部服务nodePort访问集群时转发到目标服务，即clusterIP到PodIP的转换。
举个例子：集群中有三个节点，node1（node1-ip），node2（node2-ip）。
微服务A部署以nodePort的形式部署在node2中，副本为3个，端口是9002。
外部客户端通过访问访问http://node1-ip:9002即可访问到微服务A。
kube-proxy在node1节点上也起了一个端口9002，在iptables的规则中，目标端口9002被指向指向目标POD的三个IP（中间还会有细节，这里就不展开了）。因此，当外部访问9002端口时，根据iptables的规则会将该消息分发给三个POD的IP:9002这三个个地址（概率33.33%）。
同理：多个节点的情况下，都可以通过访问node1的ip加上service的Port访问到任一节点的服务。
这也就是说，内网环境的k8s集群，只需要任一个节点挂载公网IP，所有以nodePort部署的服务都可以访问到。
三种模式
kube-proxy一共有三种运行模式、
1.用户空间代理模式—基本废除了。
2.iptables模式—中小规模的k8s集群。
3.ipyablesIPVS模式–大规模k8s集群
2 | kube-dns
kube-dns功能主要是处理Pod通过servicename访问服务，即服务名称(servicename)到clusterIP的解析。
以前是 kube-dns 负责 k8s 中的 DNS 解析，最新版 k8s kube-dns 变为了 NodeLocalDNS 和 CoreDNS，不过功能都是一致的【负责集群内DNS解析】
以前逻辑是：发给 kube-dns 进行解析
现在是：发给 NodeLocalDNS 查找本地的缓存 —> 上一步没找到，发给 CoreDNS 进行查询 —> 上一步没有找到，发给 /etc/resolv.conf 中的 nameserver 进行查询
Pod 中的 dns 解析服务
每一个POD中指向到DNS解析服务都是kube-dns的cluster-IP地址
Pod 中 DNS解析服务都是kube-dns的cluster-IP地址
DNS 策略
另外，DNS运行策略有：
“Default“: Pod继承所在宿主机的设置，也就是直接将宿主机的/etc/resolv.conf内容挂载到容器中。
“ClusterFirst“: 默认的配置，所有请求会优先在集群所在域查询，也就是kube-dns，如果没有才会转发到上游DNS。
“ClusterFirstWithHostNet“: 和ClusterFirst一样，不过是Pod运行在hostNetwork:true的情况下强制指定的。
“None“: 1.9版本引入的一个新值，这个配置忽略所有配置，以Pod的dnsConfig字段为准。
3 | 总结：
1.kube-proxy主要是处理集群外部通过nodePort访问集群内服务，通过iptables规则，解析cluterIP到PodIp的过程，并提供服务的负载均衡能力。
2.kube-proxy还可以提供集群内部服务间通过clusterIP访问，也会经过kube-proxy负责转发。
3.kube-dns主要处Pod内通过serviceName访问其他服务，找到服务对应的clusterIP的关系，和一些基本的域名解析功能。
4.kube-dns是和kube-proxy协同工作的，前者通过servicename找到指定clusterIP，后者完成通过clusterIP到PodIP的过程。