K8S Service 实战与原理初探
Service是一种暴露一组Pod网络的抽象方式，K8S Service提供了针对于一组Pod的负载均衡的暴露。通过这样的方式，可以避免不同的pod之间访问时需要知晓对应pod网络信息的痛苦。例如：前端->后端，由于前端POD IP随时变动，后端亦如此，如何处理前端POD和后端POD的通信，就需要Service这一抽象，来保证简单可靠。
Service的使用
1、典型服务配置方法
当配置了selector之后，Service Controller会自动查找匹配这个selector的pod，并且创建出一个同名的endpoint对象，负责具体service之后连接。
2、配置没有selector的服务
没有selector的service不会出现Endpoint的信息，需要手工创建Endpoint绑定，Endpoint可以是内部的pod，也可以是外部的服务。
Service的类型
1.CluserIP
2.LoadBalance
- 对于 ExternalName 类型的服务，查找其 CNAME 记录
- 对所有其他类型的服务，查找与 Service 名称相同的任何 Endpoints 的记录
Service的实现方式
1.用户态代理访问
即：当对于每个Service，Kube-Proxy会在本地Node上打开一个随机选择的端口，连接到代理端口的请求，都会被代理转发给Pod。那么通过Iptables规则，捕获到达Service:Port的请求都会被转发到代理端口，代理端口重新转为对Pod的访问
这种方式的缺点是存在内核态转为用户态，再有用户态转发的两次转换，性能较差，一般不再使用
2.Iptables模式
3.Ipvs模式
Service Iptables实现原理
Iptables表和链及处理过程
Service的Traffic流量将会通过prerouting和output重定向到kube-service链
- KUBE-SERVICES->KUBE-SVC-XXXXXXXXXXXXXXXX->KUBE-SEP-XXXXXXXXXXXXXXXX represents a ClusterIP service
- KUBE-NODEPORTS->KUBE-SVC-XXXXXXXXXXXXXXXX->KUBE-SEP-XXXXXXXXXXXXXXXX represents a NodePort service
几种不同类型的Service在Kube-Proxy启用Iptables模式下上的表现
- ClusterIP
- NodePort
同时，可以看到Service所申请的端口38081被Kube-proxy所代理和监听
-
LoadBalancer
不带有Endpoint的Service
带有外部endpoint的Service
直接通过iptable规则转发到对应的外部ep地址
总结
- ClusterIP类型，KubeProxy监听Service和Endpoint创建规则，采用DNAT将目标地址转换为Pod的ip和端口，当有多个ep时，按照策略进行转发，默认RR模式时，iptables采用：比如有4个实例，四条规则的概率分别为0.25, 0.33, 0.5和 1，按照顺序，一次匹配完成整个流量的分配。
- NodePort类型，将会在上述ClusterIP模式之后，再加上Kube-Proxy的监听（为了确保其他服务不会占用该端口）和KUBE-NODEPORT的iptable规则
参考文献
1、iptables https://en.wikipedia.org/wiki/Iptables
2、ipvs https://en.wikipedia.org/wiki/IP_Virtual_Server
3、K8S Service https://kubernetes.io/zh/docs/concepts/services-networking/service/
PS：过两天给大家搞个粉丝福利，Python【电子资料+视频教程+包邮纸质书籍】，全部免费送！可以期待一下~
文章转载： twt企业IT社区
（版权归原作者所有，侵删）