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创建,目的是将<服务虚拟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访问。

上一篇:基于微服务和Docker的PaaS云平台架构设计
下一篇:全球云计算厂商齐齐发力区块链