在实践的业务场景中，业务组件之间的关系十分复杂，特别是微效劳概念的提出，运用部署的粒度愈加粗大和灵敏。为了支持业务运用组件的通讯联络，Kubernetes网络的设计主要努力于处置以下场景：

(1)严密耦合的容器到容器之间的直接通讯;

(2)笼统的Pod到Pod之间的通讯;

(3)Pod到Service之间的通讯;

(4)集群外部与外部组件之间的通讯。

1. 容器到容器的通讯

在同一个Pod内的容器(Pod内的容器是不会跨宿主机的)共享同一个网络命名空间，共享同一个Linux协议栈。所以关于网络的各类操作，就和它们在同一台机器上一样，它们甚至可以用localhost地址拜访彼此的端口。这么做的结果是复杂、安全和高效，也能增加将曾经存在的顺序从物理机或许虚拟机移植到容器的难度。

如下图中的暗影部分就是Node上运转着的一个Pod实例。容器1和容器2共享了一个网络的命名空间，共享一个命名空间的结果就是它们似乎在一台机器上运转似的，它们翻开的端口不会有抵触，可以直接用Linux的本地IPC停止通讯。它们之间相互拜访只需求运用localhost就可以。

容器到容器间通讯

2. Pod之间的通讯

每一个Pod都有一个真实的全局IP地址，同一个Node内的不同Pod之间可以直接采用对房Pod的IP地址通讯，而不需求运用其他发现机制，例如DNS、Consul或许etcd。Pod既有能够在同一个Node上运转，也有能够在不用的Node上运转，所以通讯也分为两类：同一个Node内的Pod之间的通讯和不同Node上的Pod之间的通讯。

1)同一个Node内的Pod之间的通讯

如图，可以看出，Pod1和Pod2都是经过Veth衔接在同一个Docker0网桥上的，它们的IP地址IP1、IP2都是从Docker0的网段上自动获取的，它们和网桥本身的IP3是同一个网段的。另外，在Pod1、Pod2的Linux协议栈上，默许路由都是Docker0的地址，也就是说一切非本地的网络数据，都会被默许发送到Docker0网桥上，由Docker0网桥直接中转，它们之间是可以直接通讯的。

同一个Node内的Pod关系

2)不同Node上的Pod之间的通讯

Pod的地址是与Docker0在同一个网段内的，我们知道Docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通讯只能经过宿主机的物理网卡停止，因此要想完成位于不同Node上的Pod容器之间的通讯，就必须想办法经过主机的这个IP地址来停止寻址和通讯。另外一方面，这些静态分配且藏在Docker0之后的所谓“私有”IP地址也是可以找到的。Kubernetes会记载一切正在运转Pod的IP分配信息，并将这些信息保存在etcd中(作为Service的Endpoint)。这些私有IP信息关于Pod到Pod的通讯也是十分重要的，由于我们的网络模型要求Pod到Pod运用私有IP停止通讯。之前提到，Kubernetes的网络对Pod的地址是平面的和中转的，所以这些Pod的IP规划也很重要，不能有抵触。综上所述，想要支持不同Node上的Pod之间的通讯，就要到达两个条件：

(1)在整个Kubernetes集群中对Pod分配停止规划，不能有抵触;

(2)找到一种办法，将Pod的IP和所在Node的IP关联起来，经过这个关联让Pod可以相互拜访。

依据条件1的要求，我们需求在部署Kubernetes的时分，对Docker0的IP地址停止规划，保证每一个Node上的Docker0地址没有抵触。我们可以在规划先手工分配到每个Node上，或许做一个分配规则，由安装的顺序本人去分配占用。例如Kubernetes的网络增强开源软件Flannel就可以管理资源池的分配。

依据条件2的要求，Pod中的数据在收回时，需求有一个机制可以知道对方Pod的IP地址挂在哪个详细的Node上。也就是说要先找到Node对应宿主机的IP地址，将数据发送到这个宿主机的网卡上，然后在宿主机上将相应的数据转到详细的Docker0上。一旦数据抵达宿主机Node，则哪个Node外部的Docker0便知道如何将数据发送到Pod。

详细状况，如下图所示。

跨Node的Pod通讯

在图6中，IP1对应的是Pod1，IP2对应的是Pod2。Pod1在拜访Pod2时，首先要将数据从源Node的eth0发送出去，找到并抵达Node2的eth0。也就是说先要从IP3到IP4，之后才是IP4到IP2的送达。

3. Pod 到Service之间的通讯

为了支持集群的水平扩展、高可用，Kubernetes笼统出Service的概念。Service是对一组Pod的笼统，它会依据拜访策略(LB)来拜访这组Pod。

Kubernetes在创立效劳时会为效劳分配一个虚拟的IP地址，客户端经过拜访这个虚拟的IP地址来拜访效劳，而效劳则担任将央求转发到后端的Pod上。这个相似于反向代理，但是，和普通的反向代理有一些不同：首先它的IP地址是虚拟的，想从外面拜访需求一些技巧;其次是它的部署和启停是Kubernetes一致自动管理的。

Service在很多状况下只是一个概念，而真正将Service的作用落实的是背后的kube-proxy效劳进程。在Kubernetes集群的每个Node上都会运转一个kube-proxy效劳进程，这个进程可以看作Service的透明代理兼负载平衡器，其中心功用是将到某个Service的拜访央求转发到后端的多个Pod实例上。对每一个TCP类型的Kubernetes Service，kube-proxy都会在本地Node上树立一个SocketServer来担任接纳央求，然后平均发送到后端某个Pod的端口上，这个进程默许采用RoundRobin负载平衡算法。Kube-proxy和后端Pod的通讯方式与标准的Pod到Pod的通讯方式完全相反。另外，Kubernetes也提供经过修正Service的service.spec.-sessionAffinity参数的值来完成会话保持特性的定向转发，假设设置的值为“ClientIP”，则未来自同一个ClientIP的央求都转发到同一个后端Pod上。此外，Service的ClusterIP与NodePort等概念是kube-proxy经过Iptables和NAT转换完成的，kube-proxy在运转进程中静态创立与Service相关的Iptables规则，这些规则完成了ClusterIP及NodePort的央求流量重定向到kube-proxy进程上对应效劳的代理端口的功用。由于Iptables机制针对的是本地的kube-proxy端口，所以假设Pod需求拜访Service，则它所在的那个Node上必须运转kube-proxy，并且在每个Kubernetes的Node上都会运转kube-proxy组件。在Kubernetes集群外部，对Service Cluster IP和Port的拜访可以在恣意Node上停止，这个由于每个Node上的kube-proxy针对该Service都设置了相反的转发规则。

综上所述，由于kube-proxy的作用，在Service的调用进程中客户端无需关心后端有几个Pod，中间进程的通讯、负载平衡及缺点恢复都是透明的，如下图所示。

Service的负载平衡转发

(责任编辑：admin)