Kubernetes网络模型原理

导语：

Kubernetes目前看来已经成为了docker的应用最多的编排工具，所以学习使用docker容器的话，就免不了使用Kubernetes，但是其网络原理还是比较晦涩难懂，所以还是有必要专门解析关于Kubernetes的网络原理。

Kubernetes的网络模型组成

1.Pod内部docker容器之间网络通讯[基础docker网络理论]

2.Pod所在的网络之间通讯[基础docker网络理论]

3.Pod和Service之间网络通讯[Kubernetes网络理论]

4.外界与Service之间网络通讯[Kubernetes网络理论]

Pod内部docker容器之间网络通讯

Kubernetes使用了一种“IP-per-pod”网络模型：为每一个Pod分配了一个IP地址，Pod内部的docker容器共享Pod的网络空间，即它们共享Pod的网络卡和IP。其原理是根据docker的“container网络”模型而来。

Pod所在的网络之间通讯

Kubernetes把各node主机上的docker的bridge网络“外包”给了flannel，然后通过etcd将各node主机上的bridge网络资讯收集起来，因此每个node之间的网络使用的是同网络的不同IP，保证了网络通讯的可靠性。其原理是根据docker的“bridge网络”模型而来。

Pod和Service之间网络通讯

在Kubernetes体系中Pod是不稳定的，Pod的IP地址会发生变化，所以Kubernetes引进了Service的概念。Service是一个抽象的实体，Kubernetes在建立Service实体时，为其分配了一个虚拟的IP，当外界需要访问Pod里的容器提供的功能时，不直接使用Pod的IP地址和埠，而是访问Service的这个虚拟IP和埠，由Service把请求转发给它背后的Pod。Kubernetes在建立Service时，根据Service的标签选择器（Label Selector）来查询Pod，据此建立与Service同名的EndPoints物件。当Pod的地址发生变化时，EndPoints也随之变化。Service接受到请求时，就能通过EndPoints找到对应的Pod。再深入探究，Service只是一个虚拟的概念，真正完成请求转发的是执行在node节点上的kube-proxy。Service的虚拟IP就是由kube-proxy实现的。kube-proxy有两种请求转发模式：userspace模式和iptables模式。在Kubernetes v1.1版本之前预设是userspace模式，v1.2版本后预设是iptables模式。

补充说明iptables模式：

当建立Service时，所有node节点上的kube-proxy都会建立两级iptables规则，一级为Service建立，目的是将的流量转给后端，另一级为EndPoints建立，目的是用于选择Pod。当service.spec.sessionAffinity值为”ClientIP”时，iptables模式选择Pod的算法和userspace模式相同（选择与请求来源IP更接近的Pod）。当service.spec.sessionAffinity值为”None”时，随机选择Pod，所以如果被选择的Pod没有响应，不会尝试选择另一个Pod。

外界与Service之间网络通讯

①ClusterIP型别，这种型别的Service只会得到虚拟的IP和埠，只能在Kubernetes丛集内部被访问，此模型是为预设型别。

②NodePort型别，这种型别的Service除了会得到虚拟的IP和埠，Kubernetes还会在所有node节点上为其分配埠。分配的埠的值可以通过spec.ports[*].nodePort指定，或由Kubernetes在配置好的区间里分配（预设为30000-32767）。这种Service即可以从Kubernetes丛集通过虚拟IP:埠访问，也可以从丛集外部通过Node节点的IP:nodePort访问。

③LoadBalancer型别，这种型别的Service除了会得到虚拟的IP和埠，Kubernetes还会在所有Node节点上为其分配埠，然后为其开通负载均衡。这种Service即可以从Kubernetes丛集通过虚拟IP:埠访问，也可以从丛集外部通过node节点的IP:nodePort访问，还可以通过负载均衡的IP访问。

总结

Kubernetes网络模型的理解会对使用第三方产商提供的服务有更深刻的体会，比如阿里云，华为云都已经全面支援Kubernetes的编排。其中涉及了很多Kubernetes的基本原理，回过头来仔细想想，也无非是万变不离其宗。