导语：
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创建，目的是将<服务虚拟IP，端口>的流量转给后端，另一级为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指定，或由Knubernetes在配置好的区间里分配（默认为30000-32767）。这种Service即可以从Kubernetes集群通过虚拟IP:端口访问，也可以从集群外部通过Node节点的IP:nodePort访问。
③LoadBalancer类型，这种类型的Service除了会得到虚拟的IP和端口，Kubernetes还会在所有Node节点上为其分配端口，然后为其开通负载均衡。这种Service即可以从Kubernetes集群通过虚拟IP:端口访问，也可以从集群外部通过node节点的IP:nodePort访问，还可以通过负载均衡的IP访问。

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