Kubernetes 的网络依赖于 Docker，Docker 的网络又离不开 Linux 操作系统内核特性的支持，所以在学习 Kubernetes 网络原理之前，有必要先深入了解 Docker 相关的网络基础知识，以及 Docker 的网络实现原理，详见《Docker的Linux网络基础》与《Docker网络原理》。
一、Kubernetes 网络模型
Kubernetes 网络模型设计的一个基础原则是：每个 Pod 都拥有一个独立的 IP 地址 ，并假定所有 Pod 在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个 Node 宿主机中，都要求它们可以直接通过对方的 IP 进行访问。 在 Kubernetes 世界里，IP 是以 Pod 为单位进行分配的。一个 Pod 内部的所有容器共享一个网络堆栈（相当于一个网络命名空间，它们的 IP 地址、网络设备、配置等都是共享的）。按照这个网络原则抽象出来的为每个 Pod 都设置一个 IP 地址的模型也被称作 IP-per-Pod 模型。 IP-per-Pod 模型的意义： （1）将 IP 地址和端口在 Pod 内部和外部都保待一致，就不需要使用 NAT 进行地址转换了，也就不需要考虑如何将容器端口映射到宿主机端口等问题。 （2）同一个 Pod 内的不同容器会共享同一个网络命名空间，也就是同一个 Linux 网络协议栈 。这就意味着同一个 Pod 内的容器可以通过 localhost 连接对方的端口，这种关系和同一个 VM 内的进程之间的关系是一样的，所以，使用这种模型可以很容易地将已有的应用程序从 VM 或者物理机迁移到容器。 从该模型的网络的端口分配、域名解析、服务发现、负载均衡、应用配置和迁移等角度来看， Pod 都能够被看作一台独立的虚拟机或物理机。二、Kubernetes 的网络实现
1. 容器到容器的通信
同一个 Pod 内的容器共享同一个网络命名空间，共享同一个 Linux 协议栈，就好像是在同一台机器上运行一样，可以直接使用 Linux 的本地 IPC 进行通信（例如消息队列或者管道）。
2. Pod 之间的通信
（1）同一个 Node 上 Pod 之间的通信
可以看出， Pod1 和 Pod2 都是通过 Veth 连接到同一个 docker0 网桥的，它们的 IP 地址 IP1、IP2 都是从 docker0 的网段上动态获取的，和网桥本身的 IP3 属于同一个网段。
另外，在 Pod1、Pod2 的 Linux 协议栈上，默认路由都是 docker0 的地址，也就是说所有非本地地址的网络数据，都会被默认发送到 docker0 网桥上，由 docker0 网桥直接中转。
综上所述，由于它们都关联在同 docker0 网桥上，地址段相同，所以它们之间是能直接通信的。
（2）不同 Node 上的 Pod 之间的通信
要想支持不同 node 之间的通信，就要满足两个条件： <1>在整个 Kubernetes 集群中对 IP 分配进行规划，不能有冲突； <2>找到一种办法，将 Pod 的 IP 和所在 Node 的 IP 关联起来，通过这个关联让 Pod 之间可以相互访问。 根据条件 2 的要求， Pod 中的数据在发出时，需要有一个机制能够知道目的 Pod 的 IP 地址挂在哪个具体的 Node 上。也就是说，先要找到 Node 对应宿主机的 IP 地址，将数据发送到这个宿主机的网卡，然后在宿主机上将相应的数据转发到具体的 docker0 上。一旦数据到达宿主机 Node，那个 Node 内部的 docker0 便知道如何将数据发送到 Pod 了。 而 Kubernetes 的设计是假设底层已经具备这些条件，它分配完地址并将地址记录下来就完成了自己的工作。所以要使 Kubernetes 能正常工作，除了需要部署 Kubernetes 和 Docker，还需要额外的网络配置，甚至通过一些软件来实现 Kubernetes 对网络的要求（Pod 的 IP 管理、分配以及它们之间的路由打通）。三、Pod 和 Service 的网络实践
在 Kubernetes 的网络模型中，每台主机上的 docker0 网桥都是可以被路由到的。也就是说，在部署了一个 Pod 时，在同一个集群中，各主机都可以访问其他主机上的 Pod IP，并不需要在主机上做端口映射。 实验环境：
1.部署一个 deployment/pod
（1）deployment yaml
（2）创建 deployment 和 pod
（3）查看 Pod 对应的容器
2.发布一个服务
（1）service yaml
（2）创建 service
Service 的 IP 段可以是任何段，只要不和 docker0 或者物理网络的子网冲突就可以。选择任意其他网段的原因是，这个网段将不会在物理网络和 docker0 网络上进行路由。这个 Portal Network 针对的是每 Node 都有局部的特殊性，实际上它存在的意义是让容器的流量都指向默认网关（也就是 docker0 网桥）。
（3）查看 iptables 规则
kube-proxy 服务给每一个新创建的服务都关联了一个随机的端口号，并且监听那个特定的端口，为服务创建了相关的负载均衡对象。服务创建后会生成对应的 iptables 规则，将所有从节点生成的发送给 service ip 的流量重定向到本地的这个端口（node 节点的端口），即重定向给 kube-proxy 服务完成一些负载均衡工作，最终转发给 service 对应的其中一个 Pod。
Kubemetes 的 kube-proxy 作为一个全功能的代理服务器管理了两个独立的 TCP 连接：一个是从容器到 kube-proxy；另一个是从 kube-proxy 到负载均衡的目标 Pod。
其中的关键在于，kube-proxy 如何找到 service 对应的其他 node 节点上的 pod，它们都分别位于哪些 Node 上？这便是使 Kubernetes 能正常工作的跨主机容器网络需要解决的问题。
四、CNI 网络模型
目前跨主机容器间的网络互通已经成为基本要求。主流的容器网络模型主要有 Docker 公司提出的 Containe Network Model (CNM) 和 CoreOS 公司提出的 Container Network Interface (CNI)。1.CNM 网络模型简介
CNM 模型主要通过 Network Sandbox、Endpoint 和 Network 三个组件进行实现：
（1）Network Sandbox：容器内部的网络栈，包括网络接口、路由表、DNS 等配置的管。Sandbox 可通 Linux 网络命名空间、 FreeBSD Jail 等机制进行实现 。一个 Sandbox 可以包含多个 Endpoint。
（2）Endpoint：用于将容器内的 Sandbox 与外部网络相连的网络接口。可以使用 Veth 设备对、 Open vSwitch 的内部 port 等技术进行实现。一个 Endpoint 仅能加入一个 Network。
（3）Network：可以直接互连的 Endpoint 的集合。可以通过 Linux 网桥、VLAN 等技术进行实现 。一个 Network 包含多个 Endpoint。
2.CNI 网络模型详解
CNI 是被 Kubernetes 采纳的容器网络规范，CNI 模型示意图如下：
CNI 定义了容器运行环境与网络插件之间的简单接口规范，通过一个 JSON Schema 定义 CNI 插件提供的输入和输出参数。一个容器可以通过绑定多个网络插件加人多个网络中。
（1）CNI 规范概述
CNI 提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操作和配置的规范，通过插件的形式对 CNI 接口进行实现。 CNI 仅关注在创建容器时分配网络资源与在销毁容器时删除网络资源。 对容器网络的设置和操作都通过插件 (Plugin) 进行具体实现，CNI 插件包括两种类型： CNI Plugin 和 IPAM (IP Address Management) Plugin，CNI Plugin 负责为容器配置网络资源， IPAM Plugin 负责对容器的 IP 地址进行分配和管理。 IPAM Plugin 作为 CNI Plugin的一部分，与 CNI Plugin 一起工作。（2）容器运行时与 CNI 插件的关系和工作机制
将容器添加到网络中或者删除某个网络是由容器运行时和 CNI 插件完成的。（3）CNI Plugin 详解
CNI Plugin 必须是一个可执行程序，由容器管理系统（如 Kubernetes) 调用。 CNI Plugin 负责将网络接口（network interface）插入容器网络名称空间（例如 Veth 设备对的一端），并在主机上进行任意必要的更改（例如将 Veth 设备对的另一端连接到网桥），然后调用适当的 IPAM 插件，将 IP 地址分配给网络接口，并设笠正确的路由规则。 CNI Plugin 需要支持的操作包括 ADD （添加 ）、 DELETE （删除）、 CHECK （检查）VERSION （版本查询）。这些操作的具体实现均由 CNI Plugin 可执行程序完成。 <1>ADD：将容器添加到某个网络中，主要过程为在 Container Runtime 创建容器时，先创建好容器内的网络命名空间，然后调用 CNI 插件为该 netns 完成容器网络的配置。ADD 操作参数如下：
<2>DEL：在容器销毁时将容器从某个网络中删除。
<3>CHECK：检查容器网络是否正确设置，其结果为空（表示成功）或错误信息（表示失败）。
<4>VERSION：查询网络插件支持的 CNI 范版本号，无参数，返回值为网络插件支持的 CNI 规范版本号。
容器运行时必须使用 CNI Plugin 网络配置参数中的 type 字段标识的文件名在环境 CNI_PATH 设定的路径下查找同名的可执行文件 。一旦找到，容器运行时就将调用该可执行程序，并传入环境变量设置的网络配置参数，供该插件完成容器网络资源和参数的设置。
（4）CNI 网络配置详解
（5）CNI 网络配置列表
CNI 网络配置列表（Network Configuration List）通过将多个网络配置按顺序配置，为容器提供连接到多个网络的机制 。每个 CNI Plugin 执行后的结果将作为下一个插件的输入信息。网络配笠列表也以 JSON 式进行描述，内容由多个网络配置组成，主要包括以下字段。
示例：
（6）IP 地址分配和 IPAM Plugin 详解
为了减轻 CNI Plugin IP 地址管理方面的负担， CNI 规范设置了一个独立的插件 IPAM Plugin 来专门管理容器的 IP 地址。 CNI Plugin 应负责在运行时调用 IPAM Plugin 完成容器 IP 地址的管理操作。 IPAM Plugin 负责为容器分配 IP 地址 、网关、路由和 DNS，并负责将 IP 地址操作结果返回给主 CNI Plugin ，典型实现包括 host-local 插件和 dhcp 插件。3.在 Kubernetes 中使用网络插件
Kubernetes 目前支持两种网络插件的实现：
为了在 Kubernetes 集群中使用网络插件，需要在 kubelet 务的启动参数上设置下面两个参数：
目前已有多个开源项目支持以 CNI 网络插件的形式部署到 Kubernetes 集群中，进行 Pod 的网络设置和网络策略的设置，包括 Calico、Weave、Contiv、Cilium、Infoblox、Multus、Flannel、Romana 等。
五、开源容器网络方案
Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁平网络空间中。这在 GCE 里面是现成的网络模型， Kubernetes 假定这个网络已经存在。而在私有云里搭建 Kubernetes 集群，就不能假定这种网络已经存在了。我们需要自己实现这个网络假设，将跨主机容器网络部署完成，再运行容器应用。 目前已经有多个开源组件支持容器网络模型。本节介绍几种使用不同技术实现的网络组件及其安装配置方法，包括 Flannel、Open vSwitch、直接路由和 Calico。1.Flannel 插件的原理
Flannel 之所以可以搭建 Kubernetes 依赖的底层网络，是因为它能实现以下两点： （1）它能协助 Kubernetes，给每一个 Node 上的 Docker 容器都分配互不冲突的 IP 地址。 （2）它能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
可以看到， Flannel 首先创建了一个名为 flannel0 的网桥，而且这个网桥的一端连接 docker0 网桥，另一端连接一个叫作 flanneld 的服务进程。
flanneld 进程并不简单，它上连 etcd，利用 etcd 来管理可分配的 IP 地址段资源 ，同时监控 etcd 中每个 Pod 的实际地址，并在内存中建立了一个 Pod 节点路由表；它下连 docker0 和物理网络，使用内存中 Pod 节点路由表，将 docker0 发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标 flanneld 上，从而完成 Pod 到 Pod 之间的直接地址通信。
Flannel 之间底层通信协议的可选技术包括 UDP、VxLan、AWS VPC 等多种方式 。通过源 flanneld 封包、目标 flanneld 解包， docker0 最终收到的就是原始数据，对容器应用来说是透明的，应用感觉不到中间 Flannel 的存在。
Flannel 完美地实现了对 Kubernetes 网络的支持，但是它引入了多个网络组件，在网络通信时需要转到 flannel0 网络接口，再转到用户态的 flanneld 程序，到对端后还需要走这个过程的反过程，所以也会引入一些网络的时延损耗。
另外， Flannel 模型默认采用了 UDP 作为底层传输协议， UDP 本身是非可靠协议，虽然两端的 TCP 实现了可靠传输，但在大流量高并发的应用场泉下还需要反复测试，确保没有问题。
Flannel 可以使用二进制方式部署，也能以 DaemonSet 的形式部署。
注意：Flannel 使用的 etcd 是另外安装的，不是直接使用 Kubernetes 中的 etcd。
数据转发流程：
（1）容器直接使用目标容器的 ip 访问，默认通过容器内部的 eth0 发送出去。
（2）报文通过 veth pair 被发送到 vethXXX。
（3）vethXXX 是直接连接到虚拟交换机 docker0 的，报文通过虚拟 bridge docker0 发送出去。
（4）查找路由表，外部容器 ip 的报文都会转发到 flannel0 虚拟网卡，这是一个 P2P 的虚拟网卡，然后报文就被转发到监听在另一端的 flanneld。
（5）flanneld 通过 etcd 维护了各个节点之间的路由表，把原来的报文 UDP 封装一层，通过配置的 iface 发送出去。（flanneld 负责 UDP 数据包的封装与解封）
（6）报文通过主机之间的网络找到目标主机。
（7）报文继续往上，到传输层，交给监听在 8285 端口的 flanneld 程序处理。
（8）数据被解包，然后发送给 flannel0 虚拟网卡。
（9）查找路由表，发现对应容器的报文要交给 docker0。
（10）docker0 找到连到自己的容器，把报文发送过去。
2.Open vSwitch 插件的原理
Open vSwitch 是一个开源的虚拟交换机软件，有点儿像 Linux 中的 bridge，但是功能要复杂得多。Open vSwitcb 的网桥可以直接建立多种通信通道（隧道） ，例如 Open vSwitch with GRE/VxLAN。这些通道的建立可以很容易地通过 ovs 的配置命令实现。在 Kubernetes、docker 场景下，我们主要是建立 L3 到 L3 的隧道。
首先，为了避免 Docker 创建的 docker0 地址产生冲突（因为 Docker daemon 启动且给 docker0 选择子网地址时只有几个备选列表，很容易产生冲突），我们可以将 docker0 网桥删除，手动建立一个 Linux 网桥，然后手动给这个网桥配置 IP 地址范围。
其次，建立 Open vSwitch 的 ovs 网桥，使用 vs-vsctl 命令给 OVS 网桥增加 gre 端口，在添加 gre 端口时要将目标连接的 NodeIP 地址设置为对端的 IP 地址。对每一个对端 IP 址都需要这么操作（对于大型集群网络，这可是个体力活，要做自动化脚本来完成）
最后，将 OVS 网桥作为网络接口，加入 Docker 网桥上 (docker0 或者自己手工建立的新网桥 ）。重启 OVS 网桥和 Docker 网桥，并添加一个 Docker 的地址段到 Docker 网桥的路由规则项，就可以将两个容器的网络连接起来了。
当容器内的应用访问另一个容器的地址时，数据包会通过容器内的默认路由发送给 docker0 网桥。 ovs 网桥是作为 docker0 网桥的端口存在的，它会将数据发送给 ovs 网桥。ovs 网络已经通过配置建立了与其他 ovs 网桥连接的 GRE/VxLAN 隧道，自然能将数据送达对端的 Node，并送往 docker0 及 Pod。通过新增的路由项， Node 本身的应用数据也被路由到 docker0 网桥上，和刚才的通信过程一样，也可以访问其他 Node 上的 Pod。
OVS 的优势是，作为开源的虚拟交换机软件，相对成熟和稳定 ，而且支持各类网络隧道协议，通过了 Open Stack 等项目的考验 。在前面介绍 Flannel 可知， Flannel 了支待建立覆盖网络，保证 Pod 到 Pod 的无缝通信，还和 Kubernetes、Docker 架构体系紧密结合。Flanne 够感知 Kubernetes Service ，动态维护自 己的路由表，还通过 etcd 来协助 Docker 对整个 Kubernete 集群中 docker0 的子网地址分配。而我们在使用 ovs 时，很多事情就需要手工完成了。无论是 ovs 还是 Flannel，通过覆盖网络提供的 Pod 到 Pod 的通信都会引入一些额外的通信开销，如果是对网络依赖特别重的应用，则需要评估对业务的影响。
由于 GRE 是点对点的隧道通信方式，所以如果有多个 Node 则需要建立 N✖(N-1) 条 GRE 隧道，即所有 Node 组成一个网状网络，实现了全网互通。
3.直接路由的原理
可以通过部署 MultiLayer Switch（MLS）实现这一点，在 MLS 中配置每个 docker0 子网地址到 Node 地址的路由项，通过 MLS 将 docker0 的 IP 寻址定向到对应的 Node 上。 还可以将这些 docker0 和 Node 的匹配关系配置在 Linux 操作系统的路由项中，这样通信发起的 node 就能够根据这些路由信息直接找到目标 Pod 所在的 Node，将数据传输过去了。这样做的前提是首先需要手工分配各个 Node 的 Docker bridge 地址，保证它们在不通的网段是不重叠的。 但是，在大规模集群中， 在每个 Node 都需要配置到其 docker0/Node 路由项，这会带来很大的工作量；并且在新增机器时，对所有 Nod 都需要修改配置；在重启机器时，如果 docker0 的地址有变化，则也需要修改所有 Node 的配置，这显然是非常复杂的。 为了管理这些动态变化的 docker0 地址，动态地让其他 Node 都感知到它，还可以使用动态路由发现协议来同步这些变化。在运行动态路由发现协议代理的 Node 时，会将本 LOCAL 路由表的 IP 地址通过组播协议发布出去，同时监听其他 Node 的组播包。通过这样的信息交换， Node 上的路由规则就都能够相互学习了。在实现这些动态路由发现协议的开源软件中，常用的有 Quagga、Zebra 等。 这样做的话，由于每个 Pod 的地址都会被路由发现协议广播出去，会不会存在路由表过大的情况？实际上，路由表通常都会有高速缓存，查找速度会很快，不会对性能产生太大的影响。当然，如果你的集群容量在数千个 Node 以上，则仍然需要测试和评估路由表的效率问题。4.Calico 插件的原理
Calico 是一个基于 BGP 的纯三层的网络方案，与 OpenStack、Kubernetes、AWS、GCE 等云平台都能够良好地集成。Calico 在每个计算节点都利用 Linux Kernel 实现了一个高效 vRouter 来负责数据转发 。每 vRouter 都通过 BGPI 协议把在本节点上运行的容器的路由信息向整个 Calico 网络广播，并自动设置到达其他节点的路由转发规则。Calico 保证所有容器之间的数据流最都是通过 IP 路由的方式完成互联互通的。Calico 节点组网时可以直接利用数据中心的网络结构 (L2 或者 L3) ，不需要额外的 NAT 、隧道或者 Overlay Network，没有额外的封包解包，能够节约 CPU 运算，提高网络效率。 Calico 在小规模集群中可以直接互联，在大规模集群中可以通过额外的 BGP route reflector 来完成：
此外， Calico 基于 iptables 还提供了丰富的网络策略，实现了 Kubemetes 的 Network Policy 策略，提供容器间网络可达性限制的功能。
Calico 的系统架构如下：
六、Kubernetes 的网络策略
为了实现细粒度的容器间网络访问隔离策略，Kubernetes 从 1.3 版本开始引入了 Network Policy 机制，到 1.8 版本升级为 networking.k8s.io/v1 稳定版本。 Network Policy 的主要功能是对 Pod 或者 Namespace 间的网络通信进行限制和准入控制， 设置方式为将目标对象的 label 为查询条件，设置允许访问或禁止访问的客户端 Pod 表。 目前查询条件可以作用于 Pod 和 Namespace 级别。 为了使用 Network Policy，Kubernetes 引入了一个新的资源对象 NetworkPolicy，供用户设置 Pod 之间的网络访问策略。 但这个资源对象配置仅仅是策略规则，还需要一个策略控制器（Policy Controller）进行策略规则的具体实现。策略控制器由第三方网络组件提供，目前 Calico、Cilium、kube-router、Romana、Weave Net 等开源项目均支持网络策略的实现。 Network Policy 的工作原理如下：
策略控制器需要实现一个 API Listener，监听用户设置的 NetworkPolicy 定义，并将网络访问规则通过各 Node 的 Agent 进行实际设置（Agent 则需要通过 CNI 网络插件实现）。
1.网络策略设置说明
网络策略的设置主要用于对目标 Pod 的网络访问进行控制，在默认情况下对所有 Pod都是允许访问的，在设置了指向 Pod 的 NetworkPolicy 网络策略后，到 Pod 的访问才会被限制。
2.Selector 功能说明
