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

这是非云环境中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 之间通信的步骤如下：

1. 网络包通过eth4网络接口离开Pod 4的netns，通过虚拟网络接口veth4到达root netns。

2. 网络包离开veth4，到达cni0，并查找Pod 6的地址。

3. 网络包离开cni0，重定向到veth6。

4. 网络包通过veth6离开根netns，通过网络接口eth6到达Pod 6的netns。

跨主机路由通信

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

1. 网络包通过网络接口eth1离开Pod 1，通过虚拟网络接口veth1到达root netns。

2. 网络包离开veth1，到达cni0，查找Pod 6的地址。

3. 网络包离开cni0，重定向到eth0。

4. 网络包从Master 1离开eth0，到达网关。

5. 网络包离开网关，通过工作节点1的网络接口eth0到达root netns。

6. 网络包离开eth0，到达cni0，并查找Pod 6的地址。

7. 网络包离开cni0，重定向到虚拟网络接口veth6。

8. 网络包通过虚拟地址接口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