这是非云环境中Kubernetes的配置和运行的第七篇文章，本文将聚焦于如何理解Pod间的通信机制，阐释flannel的技术细节，及其在Kubernetes集群网络中的作用。

集群网络

“组网是kubernetes的核心，准确理解组网的工作机制非常有挑战。”

引用自： https://kubernetes.io/docs/concepts/cluster-administration/networking/

在阐释flannel及其如何适用于Kubernetes之前，理解集群的网络特性是非常重要的。

本文主要聚焦于如何理解Pod间的通信机制。

Kubernetes网络模型遵循一些基本假设。官方文档中指出，Kubernetes网络模型需要：

所有Pod均具有与其它Pod通信的能力，无需做NAT。
节点（即运行Kubernetes集群的机器。节点可以是实际物理机，也可以是虚拟机，或是任何可运行Kubernetes的环境。）也可与其它所有Pod通信，无需做NAT。
每个Pod能看到自己的IP，其它Pod也能看到同一IP。

Kubernetes网络模型

每个kubernetes节点（无论主节点还是工作节点）均是一台具有网络命名空间（netns）的Linux主机。节点提供网络接口为主要接口，可以是虚拟机，也可以是裸金属主机。网络接口在上图中显示为eth0。

细看上图，我们可以看到每个Pod还具有自己的eth网络接口。这表明每个Pod具有自己的网络配置，即IP地址、路由等。这也表明着每个Pod具有自己的netns。这样，netns通过网络接口相互隔离。

打个比方。假设你和一位同事去拉斯维加斯参加一次会议。企业资助你们参与此会，因此你们住在同一酒店（即Kubernetes节点）。酒店的每个房间（即Pod）装了客房电话（即网络接口）。

你使用客房电话与住在酒店之外的家人联系。当然，没有免费的服务，酒店会对使用客房电话打出酒店收费。为实现此，所有呼出电话通过一个中心（即eth0）。中心注册呼出电话，然后将呼叫转到酒店外。客房电话和中心间的链接，比喻了虚拟网络接口（veth）在网络中的功能。

“veth是一个虚拟以太网设备。其可担当netns间的通道，创建与不同netns中物理网络设备间的桥接，但也可用于独立网络设备。
veth设备通常成对创建并互联。”

引用自： http://man7.org/linux/man-pages/man4/veth.4.html

现在，你和同事希望在离开会议或吃晚饭等时候相互知道。你们考虑节约开支，因此决定使用酒店客房电话而非手机相互联系。在酒店办理入住手续时，前台告知你们可以通过输入“＃<房间号>”，实现房间相互呼叫。酒店提供一个内部中心实现这种通信。该中心类似于上图中cni0所扮演的角色，担当允许Pod间通信的桥梁。

这家酒店可能有多栋楼，你的同事入住的是二号楼。不过，酒店前台解释说根本没有问题。与其它楼的房间通信，只需要在房间号之前添加楼号，即“＃<楼号><房间号>”。内部中心（即cni）将知晓该地址不在本楼的内部，将呼叫重定向到中心（即eth0），进而重定向到另一栋楼（即另一个Kubernetes节点）的中心（类似于 eth0）。呼叫将依次传递到各栋楼自身的内部中心，最终定位到目标房间。更多技术说明，可查看本文“跨主机路由通信”一节。

在Kubernetes中，上述所有配置和管理是通过CNI（容器网络接口，Container Networking Interface）插件实现的。

什么是CNI?

CNI是“容器网络接口”（Container Networking Interface）的缩写，实现按规范良好定义接口的外部软件模块，为Kubernetes执行网络功能操作提供支持。

“每个CNI插件必须实现为可被rkt或Kubernetes等容器管理系统调用执行的可执行文件。”
“CNI插件负责将网络接口插入到容器的netns（例如，veth的某一端），并在主机上做必要的更改（例如，将veth的另一端连接到网桥）。然后，CNI插件对接口分配IP，并通过调用相应的IPAM插件，设置与IP地址管理一致的路由。”

引用自 https://github.com/containernetworking/cni/blob/master/SPEC.md#cni-plugin

Kubernetes流量路由

为阐释流量在Pod间的路由情况，本文详细介绍两类场景。

同一主机的流量路由

Pod 4和Pod 6之间通信的步骤如下：

网络包通过eth4网络接口离开Pod 4的netns，通过虚拟网络接口veth4到达root netns。
网络包离开veth4，到达cni0，并查找Pod 6的地址。
网络包离开cni0，重定向到veth6。
网络包通过veth6离开根netns，通过网络接口eth6到达Pod 6的netns。

跨主机路由通信

Pod 1到Pod 6的通信步骤如下：

网络包通过网络接口eth1离开Pod 1，通过虚拟网络接口veth1到达root netns。
网络包离开veth1，到达cni0，查找Pod 6的地址。
网络包离开cni0，重定向到eth0。
网络包从Master 1离开eth0，到达网关。
网络包离开网关，通过工作节点1的网络接口eth0到达root netns。
网络包离开eth0，到达cni0，并查找Pod 6的地址。
网络包离开cni0，重定向到虚拟网络接口veth6。
网络包通过虚拟地址接口veth6离开root netns。

“flannel是一种配置第三层网络结构的简单易用方式，该层网络专门针对Kubernetes设计。
flannel在每个主机上以称为flanneld的单个微小二进制程序运行代理，并负责从更大的预配置地址空间中对每个主机分配租用子网。Flannel直接使用Kubernetes API或etcd存储网络配置。配置包括所分配的子网及所有的辅助数据，例如主机的公共IP等。flannel支持使用多种后端机制转发数据包，例如VXLAN、各种云集成机制等。”

引用自： https://github.com/coreos/flannel

后端（Backends）

“Flannel可配合多种后端使用。后端一旦设定，在运行时不能更改。
VXLAN是推荐的后端配置。对于希望提高性能的有经验用户，在架构支持（通常不适用云环境）的情况下可使用host-gw。UDP通常只推荐用于调试目的，或是对于不支持VXLAN的非常旧的内核。”

引用自： https://github.com/coreos/flannel/blob/master/Documentation/backends.md

本教程解决方案中使用的VXLAN模式，下面介绍其主要内部机制。

Flannel网络空间

在默认情况下，flannel在划分更小子网时使用CIDR 10.244.0.0/16，其中每个节点使用10.244.X.0/24网络掩码，Pod的IP将位于分配给指定节点的子网内。

换句话说，这意味着每个节点可以具有254个活跃Pod。每个Pod在分配给节点的子网中占用不同的IP。

上述配置规范是在kube-flannel.yml规格文件中声明的，网络在net-conf.json中定义，如下例所示：

kind: ConfigMap 

apiVersion: v1 

metadata: 

name: kube-flannel-cfg 

namespace: kube-system 

labels: 

tier: node 

app: flannel 

data: 

cni-conf.json: | 

{ 

"name": "cbr0", 

"plugins": [ 

{ 

"type": "flannel", 

"delegate": { 

"hairpinMode": true, 

"isDefaultGateway": true 

} 

}, 

{ 

"type": "portmap", 

"capabilities": { 

"portMappings": true 

} 

} 

] 

} 

net-conf.json: | 

{ 

"Network": "10.244.0.0/16", 

"Backend": { 

"Type": "vxlan" 

} 

}

下面链接给出了flannel的官方定义： coreos/flannel

flannel是一种容器网络架构，设计用于Kubernetes。

veth：虚拟以太网设备

“veth是一种虚拟以太网设备。veth可作为netns间的隧道，创建桥接另一个netns中物理网络设备，也可作为独立的网络设备使用。”

引用自： http://man7.org/linux/man-pages/man4/veth.4.html

cni0：网桥设备

cni0是一种Linux网桥设备。所有veth设备将连接到该网桥，使得所有位于同一节点的Pod间可相互通信。参见上文给出的Kubernetes网络模型和酒店的比喻。

VXLAN设备（即flannel.）

“VXLAN（虚拟可扩展LAN，Virtual Extensible LAN）是一种网络虚拟化技术，用于解决大规模云计算部署中可扩展性问题。VXLAN使用类 VLAN封装技术，将 OSI中第二层的以太坊帧封装到第四层的 UDP报文中。VXLAN默认使用 IANA指定的4789端口作为UDP端口。VXLAN终端也被称为VXLAN通道终端（VETP），它是VXLAN通道的终点，支持虚拟或物理的交换端口。

引用自： https://en.wikipedia.org/wiki/Virtual_Extensible_LAN

VXLAN接口（即上图中的flannel.1）的主要功能是确保Pod及其网络间的通信经由Overlay二层网络，这是Kubernetes网络的前提之一。如前所述，每个节点具有一个子网，每个Pod的IP位于该子网中。

组网就是让各VXLAN如同连接在同一网络中工作。即每个VXLAN网络自成体系，但“处于”同一网络域内。

在上面的酒店比喻中，VXLAN是连接各栋楼的（物理）电话线，允许你所在楼（节点1）的客房（Pod 1）可与你同事所在的另一栋楼客房（Pod 4）通话。

flanneld

flanneld 是一个驻留内存进程，负责维持节点间路由及路由所在Pod的信息最新。

在上面的酒店比喻中，flanneld就是一名负责维护客房可用情况的酒店员工。例如，酒店新建了一栋楼，提供了新的客房；或是某栋楼正在装修维护，其中客房不可用。

原文链接：

Kubernetes Journey — Up and running out of the cloud — flannel

创作场景

非云环境中 Kubernetes 的配置和运行：flannel