在实际的业务场景中，业务组件之间的关系十分复杂，特别是随着微服务理念逐步深入人心，应用部署的粒度更加细小和灵活。为了支持业务应用组件的通信，Kubernetes网络的设计主要致力于解决以下问题。
（1）同一Pod内容器到容器之间的直接通信。
（2）抽象的Pod到Pod之间的通信。
（3）Pod到Service之间的通信。
（4）集群外部与内部组件(service)之间的通信。
Kubernetes为Pod和Service资源对象分别使用了各自的专用网络，Pod网络由Kubernetes的网络插件配置实现，而Service的网络则由Kubernetes集群予以指定。
其中第3条、第4条在之前的章节里都有所讲解，本节对更为基础的第1条与第2条进行深入分析和讲解。
1. 容器到容器的通信
同一个Pod内的容器（Pod内的容器是不会跨宿主机的！！！）共享同一个网络命名空间，共享同一个Linux协议栈。它通常由构建Pod对象的基础架构容器所提供，例如，由pause镜像启动的容器。所有运行于同一个Pod内的容器与同一主机上的多个进程类似，彼此之间可通过lo接口完成交互，如图11-3所示，Pod P内的Container1和Container2之间的通信即为容器间通信。
所以对于网络的各类操作，就和它们在同一台机器上一样，它们甚至可以用localhost地址访问彼此的端口。
这么做的结果是简单、安全和高效，也能减小将已经存在的程序从物理机或者虚拟机移植到容器下运行的难度。其实，在容器技术出来之前，大家早就积累了如何在一台机器上运行一组应用程序的经验，例如，如何让端口不冲突，以及如何让客户端发现它们等。
我们来看一下Kubernetes是如何利用Docker的网络模型的。
如图7.8中的阴影部分所示，在Node上运行着一个Pod实例。
在我们的例子中，容器就是图7.8中的容器1和容器2。
容器1和容器2共享一个网络的命名空间，共享一个命名空间的结果就是它们好像在一台机器上运行，它们打开的端口不会有冲突，可以直接使用Linux的本地IPC进行通信（例如消息队列或者管道）。
其实，这和传统的一组普通程序运行的环境是完全一样的，传统程序不需要针对网络做特别的修改就可以移植了，它们之间的互相访问只需要使用localhost就可以。例如，如果容器2运行的是MySQL，那么容器1使用localhost:3306就能直接访问这个运行在容器2上的MySQL了。
2. Pod之间的通信
图11-3 Pod网络:
各Pod对象需要运行于同一个平面网络中，每个Pod对象拥有一个集群全局唯一的地址并可直接用于与其他Pod进行通信，如图11-3中的Pod P和Pod Q之间的通信。此网络也称为Pod网络。另外，运行Pod的各节点！！！ 也会通过桥接设备等持有此平面网络中的一个IP地址，如图11-3中的cbr0接口(网桥的IP地址！！！)，这就意味着Node到Pod间的通信也可在此网络上直接进行。因此，Pod间的通信或Pod到Node间的通信比较类似于同一IP网络中主机间进行的通信。
每一个Pod都有一个真实的全局IP地址，同一个Node内的不同Pod之间可以直接采用对方Pod的IP地址通信，而且不需要采用其他发现机制，例如DNS、Consul或者etcd。
Pod容器既有可能在同一个Node上运行，也有可能在不同的Node上运行，所以通信也分为两类：
- 同一个Node内Pod之间的通信
- 不同Node上Pod之间的通信。
2.1. 同一个Node内Pod之间的通信
同一个Node内两个Pod之间的关系，如图7.9所示。
可以看出，Pod1和Pod2都是通过Veth连接到同一个docker0网桥上的，它们的IP地址IP1、IP2都是从docker0的网段上动态获取的，它们和网桥本身的IP3是同一个网段的。
另外，在Pod1、Pod2的Linux协议栈！！！ 上，默认路由！！！ 都是docker0的地址！！！，也就是说所有非本地地址的网络数据，都会被默认发送到docker0网桥上，由docker0网桥直接中转。
综上所述，由于它们都关联在同一个docker0网桥上，地址段相同，所以它们之间是能直接通信的。
2.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进行通信。所以首先要知道这些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。如图7.10所示。
在图7.10中，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的网络，在后面的章节中会介绍几个常用的组件及其组网原理。
3. Service与Pod之间的通信
Service资源的专用网络也称为集群网络（Cluster Network），需要在启动kube-apiserver时经由“--service-cluster-ip-range”选项进行指定，如10.96.0.0/12，而每个Service对象在此网络中均拥一个称为Cluster-IP的固定地址。管理员或用户对Service对象的创建或更改操作由API Server存储完成后触发各节点上的kube-proxy，并根据代理模式的不同将其定义为相应节点上的iptables规则或ipvs规则，借此完成从Service的Cluster-IP与Pod-IP之间的报文转发，如图11-4所示。
图11-4: Service与Pod
4. 集群外部到Pod对象之间的通信
将集群外部的流量引入到Pod对象的方式有受限于Pod所在的工作节点范围的节点端口（nodePort）和主机网络（hostNetwork）两种，以及工作于集群级别的NodePort或LoadBalancer类型的Service对象。
不过，即便是四层代理的模式也要经由两级转发才能到达目标Pod资源：请求流量首先到达外部负载均衡器，由其调度至某个工作节点之上，而后再由工作节点的netfilter（kube-proxy）组件上的规则（iptables或ipvs）调度至某个目标Pod对象。