k8s集群网络(5)-service之iptable node port实现原理
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总结为：