k8s集群网络(5)-service之iptable node port实现原理

上一篇文章中我们主要介绍了集群内cluster ip service的实现原理,当然是基于iptable的nat的模式,也就是说利用OS的网络内核来完成负载均衡。在这里我们主要介绍node port的实现原理,当然我们这里的k8s容器网络还是基于iptable的,不是基于ipvs的。我们以之前文章中的nginx-ingress-controller-service为实际例子来介绍,nginx-ingress-controller-service在以前文章里我们以node port类型的service暴露给外界提供服务。

查看以前文章中部署的nginx-ingress-controller的service我们可以看到:

  • 这个service为node prot类型

  • cluster ip为10.254.188.128

  • 这个cluster ip关联了1个endpoints:10.1.27.2

  • host的8080端口映射到了cluster ip的80端口和pod的80端口

  • host的8443端口映射到了cluster ip的443端口和pod的443端口

kubectl describe service service-nginx-ingress -n kube-system

对node port类型的service来说,访问host的port就访问到了这个服务。所以从host网络角度来看,当host收到数据包的时候应该是进入host network namespace的PREROUTING chain中,我们查看host network namespace的PREROUTING chain。

iptables -nvL -t nat


根据规则,对于PREROUTING chain中,所有的流量都走到了KUBE-SERVICES这个target中。

查看KUBE-SERVICES target:

iptables -nvL -t nat | grep KUBE-SVC

在KUBE-SERVICES target中我们可以看到当访问nginx-ingress-controller-service在host上的8080或者8443port的时候,根据规则匹配到了KUBE-NODEPORTS这个target。

查看KUBE-NODEPORTS target:

iptables -nvL -t nat

在KUBE-NODEPORTS target中我们可以看到当访问8080和8443时:

  • KUBE-MARK-MASQ均会匹配

  • KUBE-SVC-QY5PTWKILTPBPDCE匹配8080端口访问

  • KUBE-SVC-SQYXO6PN7K55YEZU匹配8443端口访问

查看KUBE-MARK-MASQ target:

这里只是做了一下标记,并没有nat target。

iptables -nvL -t nat

查看KUBE-SVC-QY5PTWKILTPBPDCE和KUBE-SVC-SQYXO6PN7K55YEZU两个target:

iptables -nvL -t nat

我们可以看到

  • KUBE-SVC-QY5PTWKILTPBPDCE匹配进入KUBE-SEP-WM2TRROMQQXWNW4W

  • KUBE-SVC-SQYXO6PN7K55YEZU匹配进入KUBE-SEP-7XLQX5JZL77UC7RY

  • 看到这里细心的同学是不是觉得很熟悉,没错,这和上一篇文章里cluster ip类型的service在ipable里如出一辙。唯一不同的是上一篇文章里的例子nginx-application-service有2个endpoints,这里nginx-ingress-controller-service只有一个endpoint。所以会匹配到一个KUBE-SEP-XXX,如果有多个endpoints,那么一定会leverage内核随机模块random按百分比来均匀的匹配,从而实现对pord的访问负载均衡。

查看KUBE-SEP-WM2TRROMQQXWNW4W和KUBE-SEP-7XLQX5JZL77UC7RY两个target:

iptables -nvL -t nat

我们可以看到

  • 做了MASQ操作,当然这个应该是出站engress流量(限定了source ip),不是我们的入站ingress流量。

  • 做了DNAT操作,把原来的cluster ip给DANT转换成了pod的ip 10.1.27.2,把原来的port转换成了80或者443 port。

  • 根据iptable,经过PREROUTING chain发现DNAT之后的10.1.27.2不是本地的ip(肯定不是,因为这个ip是pod的ip,当然不会在host的network namespace里)。所以就走到了Forwarding chain中,根据host network namespace的路由表来决定下一跳地址。

所以综合上面的例子,对于ipable方式的k8s集群内node port类型的service总结为:

  • 在host netwok namespace的PREROUTING chain中会匹配KUBE-SERVICES target。

  • 在KUBE-SERVICES target会匹配KUBE-NODEPORTS target

  • 在KUBE-NODEPORTS target会根据prot来匹配KUBE-SVC-XXX target

  • KUBE-SVC-XXX target就和上一篇文章中的cluster-ip类型service一样了,后续的变化也和上一篇文章中的cluster-ip类型service一样。

目前先写到这里,下一篇文章里我们继续介绍k8s集群underlay网络中pod到pod的数据通讯。

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值