摘要:当通过访问应用时,流量经由表中的规则链处理后,跳转到子链,而此链包含了对具体处理的规则。再次防火墙规则,发现经由的模块,以方式均衡的分发流量,也即负载均衡模式为轮训。
前言
在K8S集群内部,应用常使用Service互访,那么,了解Service技术优缺点将有利于应用规划与部署,鉴于此,本文将通过简单案例以探索Cluster-Ip类型Service服务的利弊。
为便于讲解,我们先创建如下应用及Service服务:
# kubectl run --image=nginx nginx-web-1 --image-pull-policy="IfNotPresent" # kubectl expose deployment nginx-web-1 --port=80 --target-port=80Service探索
作者的K8S环境是1.9版本,其Service内部服务由Kube-Proxy1提供,且默认用iptables技术实现,故本文探索K8S集群Service技术,即研究iptables在K8S上的技术实现。
Service Route(服务路由) 如下可知,通过nginx-web-1服务可实际访问到后端pod:
# nginx pod ip地址: # kubectl describe pod nginx-web-1-fb8d45f5f-dcbtt | grep "IP" IP: 10.129.1.22 # Service服务,通过172.30.132.253:80则实际访问到10.129.1.22:80 # kubectl describe svc nginx-web-1 ... Type: ClusterIP IP: 172.30.132.253 Port:80/TCP TargetPort: 80/TCP Endpoints: 10.129.1.22:80 Session Affinity: None ... # 重置nginx web页面: # kubectl exec -it nginx-web-1-fb8d45f5f-dcbtt -- sh -c "echo hello>/usr/share/nginx/html/index.html" # curl 10.129.1.22 hello # curl 172.30.132.253 hello
Service服务分配的CLUSTER-IP以及监听的端口均虚拟的,即在K8S集群节点上执行ip a与netstat -an命令均无法找到,其实际上,IP与Port是由iptables配置在每K8S节点上的。在节点上执行如下命令可找到此Service相关的iptables配置,简析如下:
当通过Service服务IP:172.30.132.253:80访问时,匹配第3条规则链(KUBE-SERVICES)后,跳转到第4条子链(KUBE-SVC-...)上;
第4条子链做简单注释后,继而跳转到第1、2规则链(KUBE-SEP-...)上;
当源Pod通过Service访问自身时,匹配第1条规则,继而跳转到KUBE-MARK-MASQ链中;
匹配到第2条规则,此时通过DNAT被重定向到后端Pod:108.29.1.22:80。
# iptables-save | grep nginx-web-1 -A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m comment --comment "demo/nginx-web-1:" -j KUBE-MARK-MASQ -A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m comment --comment "demo/nginx-web-1:" -m tcp -j DNAT --to-destination 10.129.1.22:80 -A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76 -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -j KUBE-SEP-UWNFTKZFYWNNNTK7
详细分析iptables规则,执行iptables-save命令可发现nat的PREROUTING与OUTPUT链中均有KUBE-SERVICES规则链,且处于第一顺位。
*nat -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES -A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
当通过Service访问应用时,流量经由nat表中的PREROUTING规则链处理后,跳转到KUBE-SERVICES子链,而此链包含了对具体Service处理的规则。如下所示,访问172.30.132.253:80将被跳转到KUBE-SEP-...子规则链中。
-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76 -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -j KUBE-SEP-UWNFTKZFYWNNNTK7
如下所示,KUBE-SEP-...子链存在两条规则:
第1条规则:Pod通过Service访问自身时匹配,此规则仅作标记(MARK)处理;
第2条规则:通过DNAT重定向到后端Pod实例上,至此,通过Service最终将流量导向到后端实例上;
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m comment --comment "demo/nginx-web-1:" -j KUBE-MARK-MASQ -A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m comment --comment "demo/nginx-web-1:" -m tcp -j DNAT --to-destination 10.129.1.22:80 -A KUBE-MARK-MASQ -j MARK --set-xmark 0x1/0x1Loadbalance(负载均衡)
执行如下命令将Deployment扩展为3个Pod后,继而再观察Service负载均衡方面的技术或问题。
# kubectl scale deploy/nginx-web-1 --replicas=3
再次dump防火墙规则,发现Service经由iptables的statistic模块,以random方式均衡的分发流量,也即负载均衡模式为轮训。
存在3条DNAT与KUBE-MARK-MASQ规则,分别对应3个后端Pod实地址;
KUBE-SERVICES链中存在3条子链,除最后一条KUBE-SVC-...子链外,其余子链使用模块statistic的random模式做流量分割或负载均衡:第1条KUBE-SVC-...应用33%流量,第2条KUBE-SVC-...规则应用剩余的50%流量,第3条KUBE-SVC-...规则应用最后的流量。
# iptables-save | grep nginx-web-1 -A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m comment --comment "demo/nginx-web-1:" -j KUBE-MARK-MASQ -A KUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m comment --comment "demo/nginx-web-1:" -m tcp -j DNAT --to-destination 10.129.1.27:80 -A KUBE-SEP-CDQIKEVSTA766BRK -s 10.129.1.28/32 -m comment --comment "demo/nginx-web-1:" -j KUBE-MARK-MASQ -A KUBE-SEP-CDQIKEVSTA766BRK -p tcp -m comment --comment "demo/nginx-web-1:" -m tcp -j DNAT --to-destination 10.129.1.28:80 -A KUBE-SEP-W5HTO42ZVNHJQWBG -s 10.129.3.57/32 -m comment --comment "demo/nginx-web-1:" -j KUBE-MARK-MASQ -A KUBE-SEP-W5HTO42ZVNHJQWBG -p tcp -m comment --comment "demo/nginx-web-1:" -m tcp -j DNAT --to-destination 10.129.3.57:80 -A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76 -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-BI762VOIAZZWU5S7 -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -j KUBE-SEP-W5HTO42ZVNHJQWBGSession Affinity(会话保持)
如下所示,调整Service服务,打开会话保持功能,并设置会话保持期限为3小时(PS:若不设置,则默认是3小时):
# kubectl edit svc nginx-web-1 ... sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800 ...
继续观察iptables实现,发现在原有基础上,iptables规则中添加了recent模块,此模块被用于会话保持功能,故kube-proxy通过在iptables中结合statistic与recent模块,实现了Service的轮训负载均衡与会话保持功能。
通过Service服务访问应用,封包进入KUBE-SERVICES规则链,并跳转到KUBE-SVC-...子链中;
在KUBE-SVC-SNP...子链中,recent位于statistic模块前,故而,有如下情况出现:
当客户端第一次访问Service时,KUBE-SVC-...子链中的规则(-m recent --rcheck --seconds 10800 --reap ...--rsource)池中未记录客户端地址,故封包匹配失败,从而封包被后续的statistic模块规则处理后,均衡分发到KUBE-SEP-...子链中,此链中使用recent模块的--set参数将客户源地址记录到规则池后,DNAT到实际后端实例上;
KUBE-SVC-...子链中recent模块配置了源地址记录期限,若客户端3(--seconds 10800 --reap)小时内未访问服务,则recent规则池中的客户端记录将被移除,此时客户端再次访问Service就如同第一次访问Service一样;
当客户端在3小时内再次访问Service时,匹配KUBE-SVC-...子链中的recent模块规则后,跳转到KUBE-SEP子链,其规则中recent模块--set参数将更新规则池中的Record TTL,而后DNAT到实际后端实例上;
# iptables-save | grep nginx-web-1 -A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m comment --comment "demo/nginx-web-1:" -j KUBE-MARK-MASQ -A KUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m comment --comment "demo/nginx-web-1:" -m recent --set --name KUBE-SEP-BI762VOIAZZWU5S7 --mask 255.255.255.255 --rsource -m tcp -j DNAT --to-destination 10.129.1.27:80 # 省略2条类似的KUBE-SEP规则 ... -A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76 -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-BI762VOIAZZWU5S7 --mask 255.255.255.255 --rsource -j KUBE-SEP-BI762VOIAZZWU5S7 # 省略2条类似的KUBE-SVC规则 ... -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-BI762VOIAZZWU5S7 -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK -A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" -j KUBE-SEP-W5HTO42ZVNHJQWBG总结
K8S中的Service服务可提供负载均衡及会话保持功能,其通过Linux内核netfilter模块来配置iptables实现,网络封包在内核中流转,且规则匹配很少,故效率非常高;而Service负载均衡分发比较薄弱,其通过statistic的random规则实现轮训分发,无法实现复杂的如最小链接分发方式,鉴于此,K8S 1.9后续版本调整了kube-proxy服务,其可通过ipvs实现Service负载均衡功能。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/33179.html
摘要:当通过访问应用时,流量经由表中的规则链处理后,跳转到子链,而此链包含了对具体处理的规则。再次防火墙规则,发现经由的模块,以方式均衡的分发流量,也即负载均衡模式为轮训。 前言 在K8S集群内部,应用常使用Service互访,那么,了解Service技术优缺点将有利于应用规划与部署,鉴于此,本文将通过简单案例以探索Cluster-Ip类型Service服务的利弊。 为便...
摘要:后端代理之前的文章部署最后的测试部分,创建了一组及服务来验证业务,继续以这个例子来说明集群中已经有如下一组都带有标签,对外暴露端口,访问路径会返回主机名。请求代理转发是一个虚拟的地址,并不是某张网卡的真实地址。 为什么需要service Kubernetes可以方便的为容器应用提供了一个持续运行且方便扩展的环境,但是,应用最终是要被用户或其他应用访问、调用的。要访问应用pod,就会有以...
摘要:中暴露服务访问自己实现了一个,它本质上是包装了,在真正创建负载均衡器上它会调用来创建自身的。 Kubernetes概述 最近的一年,kubernetes的发展如此闪耀,正被越来越多的公司采纳用于生产环境的实践。同时,我们可以在最著名的开发者问答社区StackOverflow上看到k8s的问题数量的增长曲线(2015.5-2016.5),开发者是用脚投票的,从这一点看也无疑证明了k8s的...
摘要:中暴露服务访问自己实现了一个,它本质上是包装了,在真正创建负载均衡器上它会调用来创建自身的。 Kubernetes概述 最近的一年,kubernetes的发展如此闪耀,正被越来越多的公司采纳用于生产环境的实践。同时,我们可以在最著名的开发者问答社区StackOverflow上看到k8s的问题数量的增长曲线(2015.5-2016.5),开发者是用脚投票的,从这一点看也无疑证明了k8s的...
阅读 988·2022-07-19 10:19
阅读 1758·2021-09-02 15:15
阅读 982·2019-08-30 15:53
阅读 2622·2019-08-30 13:45
阅读 2611·2019-08-26 13:57
阅读 1948·2019-08-26 12:13
阅读 971·2019-08-26 10:55
阅读 513·2019-08-26 10:46