Kubernetes的网络实现
在实际的业务场景中，业务组件之间的关系十分复杂，特别是随着微服务理念逐步深入人心，应用部署的粒度更加细小和灵活。为了支持业务应用组件的通信，Kubernetes网络的设计主要致力于解决以下问题。
（1）容器到容器之间的直接通信。
（2）抽象的Pod到Pod之间的通信。
（3）Pod到Service之间的通信。
（4）集群外部与内部组件之间的通信。
其中第3条、第4条在之前的章节里都有所讲解，本节对更为基础的第1条与第2条进行深入分析和讲解。
1.容器到容器的通信
同一个Pod内的容器（Pod内的容器是不会跨宿主机的）共享同一个网络命名空间，共享同一个Linux协议栈。所以对于网络的各类操作，就和它们在同一台机器上一样，它们甚至可以用localhost地址访问彼此的端口。
这么做的结果是简单、安全和高效，也能减小将已经存在的程序从物理机或者虚拟机移植到容器下运行的难度。其实，在容器技术出来之前，大家早就积累了如何在一台机器上运行一组应用程序的经验，例如，如何让端口不冲突，以及如何让客户端发现它们等。
我们来看一下Kubernetes是如何利用Docker的网络模型的。
如上图中的阴影部分所示，在Node上运行着一个Pod实例。在我们的例子中，容器就是图中的容器1和容器2。容器1和容器2共享一个网络的命名空间，共享一个命名空间的结果就是它们好像在一台机器上运行，它们打开的端口不会有冲突，可以直接使用Linux的本地IPC进行通信（例如消息队列或者管道）。其实，这和传统的一组普通程序运行的环境是完全一样的，传统程序不需要针对网络做特别的修改就可以移植了，它们之间的互相访问只需要使用localhost就可以。例如，如果容器2运行的是MySQL，那么容器1使用localhost:3306就能直接访问这个运行在容器2上的MySQL了。
2.Pod之间的通信
我们看了同一个Pod内的容器之间的通信情况，再看看Pod之间的通信情况。
每一个Pod都有一个真实的全局IP地址，同一个Node内的不同Pod之间可以直接采用对方Pod的IP地址通信，而且不需要采用其他发现机制，例如DNS、Consul或者etcd。
Pod容器既有可能在同一个Node上运行，也有可能在不同的Node上运行，所以通信也分为两类：同一个Node内Pod之间的通信和不同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之后的所谓“私有”IP地址也是可以找到的。Kubernetes会记录所有正在运行的Pod的IP分配信息，并将这些信息保存在etcd中（作为Service的Endpoint）。这些私有IP信息对于Pod到Pod的通信也是十分重要的，因为我们的网络模型要求Pod到Pod使用私有IP进行通信。所以首先要知道这些IP是什么。
之前提到，Kubernetes的网络对Pod的地址是平面的和直达的，所以这些Pod的IP规划也很重要，不能有冲突。只要没有冲突，我们就可以想办法在整个Kubernetes的集群中找到它。
综上所述，要想支持不同Node上Pod之间的通信，就要满足两个条件：
（1）在整个Kubernetes集群中对Pod的IP分配进行规划，不能有冲突；
（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。如下图所示：
在上图中：IP1对应的是Pod1，IP2对应的是Pod2。Pod1在访问Pod2时，首先要将数据从源Node的eth0发送出去，找到并到达Node2的eth0。即先是从IP3到IP4的递送，之后才是从IP4到IP2的递送。
在谷歌的GCE环境中，Pod的IP管理（类似docker0）、分配及它们之间的路由打通都是由GCE完成的。Kubernetes作为主要在GCE上面运行的框架，它的设计是假设底层已经具备这些条件，所以它分配完地址并将地址记录下来就完成了它的工作。在实际的GCE环境中，GCE的网络组件会读取这些信息，实现具体的网络打通。
而在实际生产环境中，因为安全、费用、合规等种种原因，Kubernetes的客户不可能全部使用谷歌的GCE环境，所以在实际的私有云环境中，除了需要部署Kubernetes和Docker，还需要额外的网络配置，甚至通过一些软件来实现Kubernetes对网络的要求。做到这些后，Pod和Pod之间才能无差别地进行透明通信。
为了达到这个目的，开源界有不少应用增强了Kubernetes、Docker的网络，在后面的章节中会介绍几个常用的组件及其组网原理。
