一 Kubernetes网络实现
1.1 Kubernetes网络优势
在实际的业务场景中，业务组件之间的关系十分复杂，微服务的理念更是让应用部署的粒度更加细小和灵活。为了支持业务应用组件的通信，Kubernetes网络的设计主要致力于解决以下问题。
- 容器到容器之间的直接通信。
- 抽象的Pod到Pod之间的通信。
- Pod到Service之间的通信。
- 集群外部与内部组件之间的通信。
二 Kubernetes网络通信
2.1 容器之间通信
同一个Pod内的容器（Pod内的容器是不会跨宿主机的）共享同一个网络命名空间，共享同一个Linux协议栈。所以对于网络的各类操作，就和它们在同一台机器上一样，它们甚至可以用localhost地址访问彼此的端口。这种方式简单、安全和高效，也能减小将已经存在的程序从物理机或者虚拟机移植到容器下运行的难度。
在Kubernetes使用如下方式利用Docker的网络模型：
如上图所示，在Node1上运行着一个Pod实例，且运行着容器1和容器2。容器1和容器2共享一个网络的命名空间，共享一个命名空间的结果就是它们好像在一台机器上运行，它们打开的端口不会有冲突，可以直接使用Linux的本地IPC进行通信（例如消息队列或者管道）。其实，这和传统的一组普通程序运行的环境是完全一样的，传统程序不需要针对网络做特别的修改就可以移植了，它们之间的互相访问只需要使用localhost就可以。例如，如果容器2运行的是MySQL，那么容器1使用localhost:3306就能直接访问这个运行在容器2上的MySQL了。
2.2 Pod之间的通信
每一个Pod都有一个真实的全局IP地址，同一个Node内的不同Pod之间可以直接采用对方Pod的IP地址通信，而且不需要采用其他发现机制，例如DNS、Consul或者etcd。Pod容器既有可能在同一个Node上运行，也有可能在不同的Node上运行，所以通信也分为两类：同一个Node内Pod之间的通信和不同Node上Pod之间的通信。
- 同一个Node内Pod之间的通信
由上图可知，Pod1和Pod2都是通过Veth连接到同一个docker0网桥上的，它们的IP地址IP1、IP2都是从docker0的网段上动态获取的，它们和网桥本身的IP3是同一个网段的。另外，在Pod1、Pod2的Linux协议栈上，默认路由都是docker0的地址，也就是说所有非本地地址的网络数据，都会被默认发送到docker0网桥上，由docker0网桥直接中转。综上所述，由于它们都关联在同一个docker0网桥上，地址段相同，所以它们之间是能直接通信的。
- 不同Node上Pod之间的通信
Pod的地址是与docker0在同一个网段的，我们知道docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行，因此要想实现不同Node上Pod容器之间的通信，就必须实现能通过主机的这个IP地址进行寻址和通信。
同时，这些动态分配且位于docker0之后的容器(Pod)“私有”IP地址也需要进行寻址。Kubernetes会记录所有正在运行的Pod的IP分配信息，并将这些信息保存在etcd中（作为Service的Endpoint）。
这些私有IP信息对于Pod到Pod的通信也是十分重要的，Kubernetes的网络模型要求Pod到Pod使用私有IP进行通信。所以首先获知这些IP是什么。由于Kubernetes的网络对Pod的地址是平面的和直达的，所以这些Pod的IP规划也很重要，若需要在整个集群中进行寻址，必须保证IP不能有冲突。
综上所述，要想支持不同Node上Pod之间的通信，就要满足两个条件：
- 在整个Kubernetes集群中对Pod的IP分配进行规划，不能有冲突；
- 需要一种方案，将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。
对于Kubernetes而言，采用了网络增强开源软件Flannel进行IP资源池的管理和分配。
同时采用相应的机制，实现Pod中的数据在发出时，能获知对方Pod的IP地址位于某个具体的Node上。也就是说先要找到Node对应宿主机的IP地址，将数据发送到这个宿主机的网卡，然后在宿主机上将相应的数据转发到具体的docker0上。一旦数据到达宿主机Node，则那个Node内部的docker0便知道如何将数据发送到Pod。
由上图可知，IP1对应的是Pod1，IP2对应的是Pod2。Pod1在访问Pod2时，首先要将数据从源Node的eth0发送出去，找到并到达Node2的eth0。即先是从IP3到IP4的递送，之后才是从IP4到IP2的递送。