k8s网络插件之Calico

Calico简介

Calico官方文档：https://projectcalico.docs.tigera.io/getting-started/kubernetes/quickstart

Calico是一套开源的网络和网络安全解决方案，用于容器、虚拟机、宿主机之前的网络连接，它是一个纯三层的虚拟化网络解决方案，它把每个节点都作为一个虚拟路由器，并把每个节点上的Pod当作是节点路由器后的一个终端设备并为其分配一个IP地址。各节点路由器通过BGP协议生成路由规则，从而实现不通节点上Pod间的通信。如下图：
在这里插入图片描述

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

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

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

另外，类似于Flannel的 VXALN后端启用Directrouting时的网络模型，Calico也支持混合使用路由和Overlay网络模型，BGP路由模型用于二层网络的高性能通信，IPIP或VXLAN用于跨二层网络节点间Pod报文的转发，如下图所示：
在这里插入图片描述

Calico架构

在这里插入图片描述
如上图所示，Calico的组件主要有Felix、etcd存储系统、BIRD和BGP路由反射器等，各组件的作用如下：

Felix：Felix是运行于各节点之上的守护进程，它主要负责完成接口管理、路由规划、ACL规则和状态报告几个核心任务，从而为各端点（vm或container）生成连接机制
1. 接口管理：负责创建网络接口，将接口信息配置到内核，以确保内核能够处理各端点的流量，尤其是要确保能用节点自身的MAC来响应当前工作节点上每个工作负载的ARP请求，以及为Felix管理的接口打开转发功能，另外接口管理还要监控各接口的变动以确保规则能够得到正确应用
2. 路由规划：负责为当前工作节点上的各端点在内核FIB（Forwarding Information Base）中生成路由信息，以保证到达当前节点的报文可以正确转发给端点
3. ACL规则：负则在Linux内核中生成ACL规则，以实现仅放行端点间的合规流量，并确保流量不能绕过安全规则
4. 状态报告：负责提供网络健康状态的相关数据，尤其是报告由Felix管理的节点上的错误和问题。这些报告和数据会存储在etcd中供其它组件或管理员使用
etcd存储系统：利用etcd，Calico可以有明确状态的系统，且易于通过扩展应对访问压力提升，避免自身成为系统瓶颈。另外，etcd也是calico各组件的通信总线
BIRD：BGP协议客户端，负责将Felix生成的路由信息载入内核并通告到整个网络中
BGP路由反射器：Calico的BGP路由模型默认采用节点网格模式（node-to-node mesh），随着节点数量的增加，节点之间的连接数量会快速增长，给集群网络带来较大的压力。因此，一般建议大规模集群使用BGP路由反射器模式进行路由学习，BGP的点到点通信也就转换为与中心节点的单路通信模型。另外，处于冗余考虑，生产环境应该配置多个BGP路由反射器。对于Calico来说，BGP客户端程序除了作为客户端使用，也可以配置为路由反射器。

另外，Calico可以将关键配置抽象为资源类型，并允许用户按需自定义资源对象已完成系统配置，这些资源对象保存在Datastore中，Datastore可以是独立的etcd，也可以是k8s集群使用的etcd。Calico专有资源类型有十几种，包括IPPool（IP地址池）、NetworkPolicy（网络策略）、BGPConfiguration（BGP配置参数）等。类似于Kubernetes API资源的定义，这些资源的配置格式同样以JSON使用apiVersion、kind、metadata和spec等一级字段进行定义，并能够使用calicoctl客户端工具进行管理，也支持由kubelet借助CRD进行这类资源的管理。

Calico部署

在k8s集群上实际部署时，Calico分为calico-node和calico-kube-controllers两个组件，它们通过Datastore读取与自身相关的资源定义完成配置

calico-node：Calico在k8s集群中每个节点运行的代理程序，负责提供Felxi、bird4、bird6和confd等守护进程
calico-kube-controllers：Calico运行在k8s集群上的自定义控制器，是Calico协同k8s的插件

从官网下载部署文件：
https://raw.githubusercontent.com/projectcalico/calico/v3.24.5/manifests/calico.yaml

curl https://raw.githubusercontent.com/projectcalico/calico/v3.24.5/manifests/calico.yaml -O

修改部署文件以适配k8s集群环境
首先修改部署文件中CALICO_IPV4POOL_CIDR变量的值，将其设置为初始k8s化集群时设定的pod-cidr，例如：
在这里插入图片描述
然后修改CALICO_IPV4POOL_BLOCK_SIZE变量的值，指定Calico为节点分配地址段的掩码长度，默认26

Calico的部署文件默认使用的是IPIP 隧道模式，这里就保持默认，不再进行修改。如果要使用纯BGP路由模式或者混合模式可以修改变量CALICO_IPV4POOL_IPIP的值，可用值如下：

Always：只使用IPIP隧道网络，默认值
Never：不使用IPIP隧道网络
CrossSubnet：启用混合网络模式

如果想要使用VXLAN隧道网络，而不是IPIP隧道网络，可以修改变量CALICO_IPV4POOL_VXLAN的值，可用值和逻辑与变量CALICO_IPV4POOL_IPIP一致。

更多变量的配置和介绍可以参考官网介绍：https://projectcalico.docs.tigera.io/reference/node/configuration

将部署文件应用到集群之上，等待Calico相关Pod成功运行且无报错就表示Calico部署成功。

kubectl apply -f calico.yaml

在这里插入图片描述

IPIP隧道网络

工作在IPIP模式的Calico会在每个节点创建一个tunl0接口作为隧道出入口设备来封装IPIP隧道报文。Calico会为每个Pod资源创建一对veth设备，其中一端作为Pod的网络接口，另一端（名为calixxx）留在宿主机的网络名称空间，它不使用虚拟网桥。如下图所示：
在这里插入图片描述
IPIP隧道网络也是依赖BGP来维护节点的路由信息。部署完成后，Calico会通过BGP协议在每个节点上生成到达其它节点Pod子网的路由信息。例如下面node-01上的路由信息，它们是由各节点上的BIRD以点对点的方式向网络中的其它节点进行通告并学习其它节点的通告而生成。
在这里插入图片描述

对于每个Pod，Calico都会在节点上为其生成一个专用路由条目，用于确保以Pod IP为目标的报文可以通过节点上的calixxx接口送达，这是因为Calico没有像Flannel一样使用虚拟网桥进行报文转发导致的。相关路由条目如下所示：
在这里插入图片描述

Pod通信流程分析
集群中node-02上运行一个nginx-pod（10.244.89.5），在node-01上的client-pod（10.244.169.3）上请求nginx-pod，其过程大致如下：

client-pod发送请求，根据Pod中的默认路由将报文送到主机上对应的calixxx接口，此时
src-ip：10.244.89.5 dst-ip：10.244.169.3
src-mac：b2:65:39:08:87:b0 dst-mac：ee:ee:ee:ee:ee:ee

在calixxx接口抓包如下：

此时发现一个问题，我们在client-pod内查看路由，发现默认路由是169.254.1.1，如下图所示。但是169.254.1.1这个地址是不存在的，这是什么情况？

根据网络常识，当数据包目的地址不是本机时，会根据路由表查询网关，查询到网关后发送ARP请求查询网关MAC，然后修改数据的的目标MAC，所以无论这个地址是不是存在，只要ARP请求可以获取它的MAC即可。

所以，在Pod内查看一下169.254.1.1对应的MAC，如下图：

169.254.1.1对应的MAC是ee:ee:ee:ee:ee:ee，这是主机上calixxx接口的MAC，但这也不符合逻辑，主机上的calixxx接口没有这个地址，为什么ARP获取到的MAC是它的MAC？

这其实是因为calixxx接口启用了网卡的ARP代理功能，如下图：

代理 ARP 是 ARP 协议的一个变种，当 ARP 请求目标跨网段时，网关设备收到此 ARP 请求，会用自己的 MAC 地址返回给请求者，这便是代理 ARP（Proxy ARP）。所以，Pod内发送的ARP请求到达calixxx接口时，calixxx接口直接返回了自己的MAC。
数据报文根据主机路由表，将报文转给tunl0接口进行IPIP封装

tunl0接口抓包如下：

此时应该是把外层的MAC头部给去掉了，然后进行IPIP封装
封装好的IPIP数据报文通过主机接口ens33发出，此时
inner-src-ip: inner-dst-ip：
outer-src-ip： outer-dst-ip：
src-mac： dst-mac：
node-02收到报文后进行解封装，然后发送给ngix-pod