Kubernetes主流网络插件介绍

标签：插件 Kubernetes 网络 Calico BGP 主流 Pod 节点路由

一、Flannel

1.1 简介

Flannel由CoreOS研发，使用”虚拟网桥和veth设备”的方式为Pod创建虚拟网络接口，通过可配置的后端(backend)定义Pod间的通信网络。它支持基于VXLAN和UDP的Overlay网络，以及基于三层路由的Underlay网络。
对于每一个容器而言，在加入网络时，在每个节点创建一个虚拟交换机，并为每一个Pod/容器创建一对虚拟网卡(veth pair)，一端插入容器的网络名称空间，另一端插入节点(宿主机)的网桥。而Pod如何接入物理网络，则取决于后端的定义。
Flannel用于解决Kubernetes集群中各节点Pod之间的通信问题，它的主要思路是：预先留出一个网段，每个主机使用其中一部分，然后每个容器被分配不同的IP；让所有的容器认为它们都在同一个直连的网络，底层通过UDP/VxLAN/Host-GW等数据转发方式(后端)进行报文的封装和转发。
在IP地址分配方面，它将预留的一个专用网络(默认为10.244.0.0/16)划分为多个子网作为每个节点的IP地址范围(podCIDR)，使得每个Pod拥有一个独立的IP地址。具体由IPAM插件host-local进行IP地址分配，并将子网分配信息保存于etcd。
Flannel在每个节点上运行一个名为flanneld的二进制代理程序，它负责从预留的网络中按照指定或者默认的掩码长度为当前节点申请分配一个子网，并将网络配置、已分配的子网和辅助数据（比如主机的公网IP等）存储在Kubernetes API或独立的etcd中。

1.2 Flannel支持的后端

Flannel使用称为后端(backend)的容器网络机制转发跨节点的Pod报文。Flannel目前支持的主流backend如下：

vxlan

使用Linux内核中的vxlan模块封装隧道报文，以叠加(overlay)网络模型支持跨节点的Pod间的互联互通。同时支持直接路由模式，在此模式下，位于同一个二层网络内的节点之上的Pod间通信可通过路由模式直接发送，而跨二层网络的节点(两个节点不在同一网段，要经过路由器)之上的Pod间通信仍要使用VXLAN隧道协议转发(即兼具vxlan和host-gw两种后端的功能)。使用直接路由模式可以节省一部分隧道网络的开销。下图为VXLAN后端使用直接路由模式的示意图。

Kubernetes主流网络插件介绍_Flannel

vxlan模型中，flanneld监听udp协议的8472端口用于接收和发送封装的数据包。

host-gw

类似于VXLAN后端的直接路由模式，但不支持跨二层网络的节点，因此这种模式要求各节点处于同一个二层网络中，不太适用于规模较大的环境，但转发性能较好。下图为host-gw后端的示意图。

Kubernetes主流网络插件介绍_Kubernetes_02

udp

用常规UDP报文封装完成隧道转发，性能比vxlan和host-gw相比较差，仅在不支持vxlan和host-gw时使用；UDP后端模式中，flanneld监听UDP 8285端口发送报文。

1.3 VXLAN后端

Flannel的配置文件默认使用VXLAN后端，相关配置定义在kube-flannel名称空间下configmap/kube-flannel-cfg资源对象中。相关配置如下：

net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
}

1.4 直接路由

如果是VXLAN添加直接路由模式，则修改kube-flannel名称空间下configmap/kube-flannel-cfg资源对象，为VXLAN后端添加Directrouting: true键值对就可以开启DirectRouting模式(见下图)。

Kubernetes主流网络插件介绍_Flannel_05

以K8S-Node2为例，启用Directrouting模式后，节点上的路由变成如下图

Kubernetes主流网络插件介绍_Flannel_06

可以看到，Pod子网的下一跳地址由对端flannel.1接口地址变成了宿主机物理接口的地址，本地用于发出报文的接口由flannel.1变成了本地的物理接口(eg：ens33)。

显然，这种模式无法满足跨二层网络节点上Pod的通信需求，因为到达Pod子网的下一跳地址无法指向另一个二层网络中的节点地址。所以节点上依然保留与VXLAN隧道相关的flannel.1接口用于跨二层网络节点上Pod的通信需求。

1.5 host-gw后端

如果想修改后端类型，则修改kube-flannel名称空间下configmap/kube-flannel-cfg资源对象，将Backend的Type字段修改为指定类型(eg：host-gw)。

当修改为host-gw后端后，使用tcpdump -i ens33 -nn -X tcp port 80命令再次抓包，就会发现报文内已经没有了隧道封装。说明此时直接路由功能已经在发挥作用了。

Kubernetes主流网络插件介绍_Flannel_07

此时查看路由信息，发现Pod的子网对应的网关正好是Node节点物理网卡的IP地址，同时也不再需要flannel.1接口(因为没有了隧道封装的开销)。比如，位于10.244.1.0网段的某个Pod和其它网段的某个Pod通信通过192.168.131.14(即本机物理接口ens33的地址)直接把对端的物理网卡当作下一跳路由，完全通过路由的方式完成报文转发。

Kubernetes主流网络插件介绍_Flannel_08

当节点处于不同的二层网络时，host-gw后端就不能实现Pod间的通信(由于不具备隧道转发的能力)。相对来说，VXLAN的DirectRouting模式兼具VXLAN后端和host-gw后端的优势，既能保证传输性能，又可以跨二层网络转发Pod报文。

此外，Flannel并不支持为Pod网络添加网络策略以控制Pod间通信的能力，它只能借助额外的支持网络策略的插件实现此功能，Calico网络插件就是为此目的而设立的。

二、Calico

2.1 简介

Calico是一个三层的虚拟网络解决方案，它将每个节点都当做虚拟路由器(vRouter)，把每个节点上的Pod都当做是”节点路由器”后的一个终端设备并为其分配一个IP地址。各节点路由器通过BGP协议(Border Gateway Protocol，边界路由协议)学习生成路由规则从而实现不同节点上的Pod间的互联互通。

Kubernetes主流网络插件介绍_Flannel_09

与Flannel相比，Calico的一个显著优势是对网络策略的支持，它允许用户定义访问控制规则以管控进出Pod的数据报文，从而为Pod间的通信施加安全策略。

实际上，Calico提供的网络解决方案与Flannel的host-gw模式几乎一样，也是基于路由表实现容器的数据包转发。但不同于Flannel使用flanneld进程来维护路由信息的做法，Calico使用BGP协议来维护集群的路由信息。

Calico在每一个计算节点通过Linux内核实现了一个高效的vRouter(虚拟路由器，简单的理解为将节点内核视为路由器使用)进行报文转发，而每个vRouter通过BGP协议负责把自身所属的节点上运行的Pod资源的IP地址信息基于节点的agent程序(Felix)直接由vRouter生成路由规则向整个Calico网络内传播。

BGP是互联网上一个核心的去中心化自治路由协议，它通过维护IP路由表或”前缀”表来实现自治系统(AS，Autonomous System)之间的可达性，通常作为大规模数据中心维护不同的自治系统之间路由信息的矢量路由协议。Linux内核原生支持BGP，因而可以将Linux主机配置成为边界网关。

Calico把Kubernetes集群环境中的每个节点上Pod组成的网络视为一个自治系统(AS)，而每个节点就相当于自治系统的边界网关。各节点之间通过BGP协议交换路由信息并生成路由规则。但并非所有的网络环境都能支持BGP，而且BGP路由模型要求所有节点位于同一个二层网络中，所以Calico还支持基于IPIP或VXLAN的Overlay网络模型(IPIP和VXLAN二者为互斥关系，只能用其一)。

与Flannel在VXLAN后端使用直接路由(DirectRouting)的网络模型类似，Calico也支持混合使用路由和叠加(Overlay)网络模型，BGP路由模型用于二层网络通信，IPIP或VXLAN用于跨子网(Cross Subnet)的节点间报文转发。

Kubernetes主流网络插件介绍_Calico_10

2.2 Calico架构

Kubernetes主流网络插件介绍_Kubernetes_11

Calico主要由Felix、Orchestrator Plugin(编排系统插件)、etcd、BIRD和BGP Router Reflector(BGP路由反射器)等组件组成。

Felix：Calico的核心组件，运行在每个节点上。主要负责完成接口管理、路由规则、ACL规划和状态报告这几个核心任务，从而为各端点(VM或Container)生成连接机制。

接口管理：负责创建网络接口，将接口信息配置到内核，以确保内核能够处理各端点的流量，尤其是要确保能用节点自身的MAC来响应当前工作节点上每个工作负载MAC地址的ARP请求，以及为Felix管理的接口打开转发功能。另外，接口管理还要监控各接口的变动以确保规则能够得到正确应用。
路由规划：负责为当前工作节点上的各端点在内核FIB(Forwarding Information Base，转发信息库)中生成路由信息，以保证到达当前节点的报文可以正确转发给端点。
ACL规划：负责在Linux内核中生成ACL规则，以实现仅放行端点间的合规流量，并确保流量不能绕过Calico的安全措施。
状态报告：Felix负责提供关于网络健康状况的相关数据，尤其是报告由Felix管理的节点上出现的错误和问题。这些报告和数据会存储在etcd中供其它组件或管理员使用。

Orchestrator Plugin：编排系统插件的主要功能是将Calico整合进所在的编排系统(eg：Kubernetes、Openstack等云原生平台)中。可以通过各自的API来配置Calico网络实现无缝集成。Eg：Kubernetes的cni网络插件。
etcd：用于持久存储Calico相关配置数据(eg：使用的子网、网络策略等)的存储管理系统。
BIRD：Calico在每个运行着Felix的节点上同时运行一个名为BIRD的守护进程，它是BGP协议的客户端，负责将Felix生成的路由信息载入内核并通告到整个网络中，同时从其它节点学习到新的路由信息。学习到的路由信息由Felix生成路由表。
BGP路由反射器：可选组件。Calico的BGP路由模型默认采用节点网格模式(node-to-node mesh)，随着节点数量的增加，节点之间的连接数量会快速增长，给集群网络带来较大的压力。因此，一般建议大规模集群使用BGP路由反射器模式进行路由学习，BGP的点到点通信也就转换为与中心节点的单路通信模型。另外，基于冗余考虑，生产环境应该配置多个BGP路由反射器。对于Calico来说，BGP客户端程序除了作为客户端使用，也可以配置为路由反射器。

2.3 IPIP隧道网络

wget https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

2.4 BGP

可以将IPIP的值设为Cross-Subnet(CALICO_IPV4POOL_IPIP：Cross-Subnet)，当节点处在同一个子网时通过BGP进行路由学习生成路由信息。
等到calico清单文件apply成功后，再检查路由信息，发现节点将同一网络内其它节点相关的路由条目经由IPIP模式的tunl0接口传输变为节点的物理接口(eg：ens33)传输，这就与Flannel的host-gw后端的工作逻辑非常相似了。如下路由信息截取自K8S-Node1主机上。

与之前的测试方式类似，只不过这次抓包要针对Pod的IP来抓。下面命令在Node1节点执行。其中，192.168.12.5为demoapp Pod2的IP，在Node2节点上。

tcpdump -i ens33 -nn host 192.168.12.5

Kubernetes主流网络插件介绍_Flannel_16

此时，就直接显示源Pod(192.168.113.4)到目标Pod(192.168.12.5)的通信，没有了外层节点IP的封装。

标签：插件,Kubernetes,网络,Calico,BGP,主流,Pod,节点,路由
From： https://blog.51cto.com/u_15796303/6942008