kubernetes之flannel

时间:2022-03-22 15:16:35

kubernetes网络通信

  • 容器间的通信   pod内的容器通信(lo)
  • Pod之间的通信   pod IP <-----> pod IP
  • Pod与Service之间的通信 podIP <-----> ClusterIP
  • Service与集群外部的通信 ClusterIP <-----> 集群外部

CNI插件:

  • flannel
  • calico
  • canel
  • kube-route

解决方案:

  • 虚拟网桥
  • 多路复用  MacVLAN
  • 硬件交换  SR-IOV

Flannel

Flannel本身是一个框架,真正提供网络功能是他的后端实现。目前支持三种后端实现:

  • VXLAN
  • host-gw
  • UDP

UDP

UDP模式是Flannel早期支持的一种方式,却也是性能最差的一种方式。所以现在基本都弃用了。但是这种模式是最直接最容易理解的一种方式。

Node1的容器访问Node2的容器,Node1容器访问的目的地址不是在容器的路由规则里,所以会走默认路由到达宿主机的docker0 网桥上,从而出现在宿主机上,这个时候这个IP的下一步取决于这台宿主机的路由规则,这时候这条会使用flannel0的设备上,flannel是一个TUN设备,在Linux中,TUN设备是一种工作在三层的虚拟网络设备,TUN设备的功能是在操作系统内核和应用程序之间传递IP包。

当操作系统将一个IP包发送给flannel0设备后,flannel0 就会把IP包交给创建这个设备的应用程序,也就是flannel进行。这就是从内核态(Linux操作系统)到用户态(Flannel进程)的流动方向。

反之,如果flannel进程向flannel0设备发送一个IP包,那么这个IP包就会出现在宿主机网络栈,然后根据宿主机路由表进行下一步处理,这是用户态向内核态流动方向。

所以,当IP包从容器经过docker0出现在宿主机上,然后又根据宿主机路由表进入flannel0设备后,宿主机上的flannel进程就会收到这个IP包。然后,flannel看到了这个IP包的目的地址,就可以把他发送到Node2宿主机上。

flannel是如何知道目的IP地址对应的容器是运行在Node2上

源于flannel里的一个重要概念子网(Subnet)。事实上,在由Flannel管理的容器网络里,一台宿主机上的所有容器都属于该宿主机被分配的一个“子网”,所以flannel会根据目的IP地址找到对应的子网,从而在etcd里找到对应的宿主机。只要node1 和node2 互通,flannel进程一定会到达node2。

UDP模式的缺点

相比两台宿主机之间的直接通信,基于flannel UDP模式的容器通信网络多个一个额外的步骤,那就是flannel的处理过程,这个过程由于使用到了flannel0这个TUN设备,仅仅是发送IP包的时候,就需要三次用户态和内核态的数据拷贝。如图:

kubernetes之flannel

  1. 用户态容器进程发起IP包进过docker0网桥进入内核态
  2. IP包根据路由表进入TUN(flannel0)设备,从而回到用户态的flanneld进程
  3. flanneld 进行UDP封包之后重新进入内核态,将UDP包通过宿主机的eth0发出去

VXLAN

VXLAN全称虚拟可扩展局域网,是Linux内核本身就支持的一种网络虚拟化技术。所以说,VXLAN可以完全在内核态实现上述封装和解封工作,从而通过前面相似的“隧道机制”,构建出覆盖网络。

VXLAN覆盖网络的设计思想:在现有的三层网络之上,“覆盖”一层虚拟的,由内核VXLAN模块负责维护的二层网络,使得连接在这个VXLAN二层网络上的“主机”(可以是虚拟机也可以是容器)之间,可以像一个局域网里那样*通信,当然,实际上,这些“主机”可能分布在不同的宿主机上,甚至可以分布在不同的物理机房里。

而为了能够在二层网络上打通“隧道”,VXLAN会在宿主机上设置一个特殊的网络设备作为“隧道”的两端。这个设备叫VTEP,既:虚拟隧道端点。而这个VTEP设备的作用,其实跟前面的flanneld进程非常相似。只不过,它进行封装和解封装的对象是二层数据帧。而且这个工作的执行流程全部是在内核里完成的(因为VXLAN本身就是内核模块)。如图:

kubernetes之flannel

从图里看每个宿主机都有一个flannel1的设备,就是VXLAN所需的VTEP设备,它既有IP地址也有MAC地址。现在我们是container1 访问 container2,相对UDP比较来看,当container1发出请求后,这个目的的地址是10.244.1.3的IP包,会先出现在docker0网桥,然后被路由到本机flanner1设备上处理,也就是说,来到了“隧道”的出口。既目的宿主机的VTEP设备。而这个设备信息正是每台宿主机上的flanneld进程负责维护的。

当所有Node启动后,我们可以在Node1 上可以看到多个flannel1 网卡的路由信息,是因为flanneld启动后创建的。

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
10.244.1.0 10.244.1.0 255.255.255.0 UG flannel.
....

从上图看到10.244.1.0就是Node2的VTEP设备(就是flannel1 设备)的IP地址,而这些VTEP设备之间就需要想办法组成一个虚拟的二层网络,既:通过二层数据帧进行通信,而Node1上的VTEP设备收到原始IP包后,就要想办法把原始IP包加一个目的MAC地址,封装成二层数据帧,然后发送给目的VTEP设备。这里需要解决一个问题目的VTEP设备的MAC地址是什么?

根据路由表信息我们知道了目的VTEP设备的IP地址,而根据三层IP地址查询二层MAC地址正是ARP表的功能。而这里用ARP表的记录,也就是flanneld进程在Node2节点启动时,自动添加到Node1上的。如下:

$ ip neigh show dev flannel.
10.244.1.0 lladdr b2:ba:aa:a5::1a PERMANENT

有了这个MAC地址linux内核就可以开始二层封包了,上面提到的MAC地址,对宿主机的二层网络没有任何意义,所以上述封装的数据帧不能在宿主机的二层网络里传输,为了方便概述,我们把上述数据帧称为内部数据帧。所以Linux内核还要把内部数据帧进一步封装成宿主机网络的一个普通数据帧,好让他载着内部数据帧,通过eth0网卡进行传输。这次封装我们称为外部数据帧,为了实现这个搭便车的机制,Linux内核在封装内部数据帧前面,加上特殊的VXLAN头,用来表示这个乘客实际上是VXLAN使用的数据帧。而这个VXLAN头里有一个重要的标志VNI,它是识别某个数据帧是不是应该归属自己处理的标志。而flannel中,VNI的值是1,这也是为什么宿主机的VTEP设备都叫做flannel1的原因。这个时候linux内核会把这数据帧封装一个UDP包里发出去。虽然node1的flannel1知道node2的flannel2的MAC地址,但是不知道node2MAC的地址,也就是UDP该发往那台主机,实际上flannel1还要扮演一个网桥的角色,在二层网络进行UDP转发,而在Linux内核里面,网桥设备进行转发的依据来自FDB的转发数据库。这个flannel网桥对应的FDB信息,就是flannel进程维护的,他的内容如下:

$ bridge fdb show flannel.  | grep b2:ba:aa:a5::1a
b2:ba:aa:a5::1a dev flannel. dst 172.16.138.41 self permanent

我们可以看到发往的IP地址是172.16.138.41的主机,显然这台主机就是 Node2,UDP要转发的目的也找到了。接下来就是宿主机网络封包的过程了。

Flannel 在kubernetes上的应用

其实上述过程也是kubernetes的主要处理方法,只不过kubernetes是通过一个叫CNI接口维护一个单独网桥来代替docker0,这个网桥CNI网桥,默认叫做cni0。如图:

kubernetes之flannel

过程也是和VXLAN是一样的。需要注意的是,CNI网桥只是接管所有CNI插件负责的,既只是kubernetes创建的容器。

kubernetes之所以要设置这样一个与docker0网桥功能一样的CNI网桥,主要原因有两点:

  • kubernetes项目并没有使用Docker的网络模型,所以它不希望,也不具备配置docker0的能力。
  • 还与kubernetes如何配置Pod,也就是infra容器Network Namespace相关。

我们在部署kubernetes的时候,有一个步骤是安装kubernetes-cni包,他的目的就是宿主机上安装CNI插件所需要的基础可执行文件。

 ls /opt/cni/bin/
bridge dhcp flannel host-local ipvlan loopback macvlan portmap ptp sample tuning vlan

CNI的基础可执行文件,按照功能分三类:

  • Main插件 他是用来创建具体网络设备的二进制文件。例如:birdge(网桥设备)、ipvlan、lookback(lo 设备)、ptp(Veth Pair设备)、macvlan、vlan
  • IPAM插件 他是负责分配IP地址的二进制文件。例如:dhcp,这个文件会向dhcp服务器发起请求;host-local,则会使用预先配置的IP地址来进行分配。
  • CNI社区维护的内置CNI插件。例如 flannel,就是专门为Flannel项目提供的CNI插件。

从二进制文件来看,如果实现一个kubernetes用的容器网络方案,其实需要两部分工作,以Flannel下项目为例。

  • 首先实现这个网络本身,其实就是flanneld进程里主要逻辑,例如:创建和配置flannel.1设备,配置宿主机路由、配置ARP和FDB表。
  • 实现该网络方案对应的CNI插件,就是配置infra容器里的网络栈,并把他连接在CNI网桥上。

接下来进行第一步,在宿主机上安装flannel。而这个过程中,flanneld启动后会在每台宿主机上生成他对应的CNI配置文件(就是configmap),从而告诉kubernetes,这个集群要使用Flannel作为容器网络方案。

CNI配置文件内容如下:

cat /etc/cni/net.d/-flannel.conflist
{
"name": "cbr0",
"plugins": [
{
"type": "flannel",
"delegate": {
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}

需要注意的是Kubernetes 目前不支持多个CNI混用,如果在/etc/cni/net.d/里放置多个CNI配置文件的话,只会加载字母排序第一个配置文件。但另一方面,CNI允许你在一个CNI配置文件里,通过plugins字段,定义多个插件协作。假如我们定义了flannel和protmap这两个插件,这个时候dockershim会把这个CNI配置文件加载起来,并把列表第一个插件,就是flannel插件设置为默认插件,然后执行过程中flannel和portmap会按照定义顺序被调用,从而一次完成“配置容器网络”和“配置端口映射”。

CNI插件工作原理

当kubelet组件需要创建pod时,他一个创建的一定是infra容器,所以这一步,dockershim 就会先调用Docker API创建并启动infra容器,紧着执行一个叫做SetUpPod的方法,这个方法的作用是:为CNI插件准备构建参数,然后调用CNI插件为infra容器配置网络。这里要调用CNI插件是/opt/cni/bin/flannel;而调用它所需的参数,分两部分:

第一部分,是由dockershim设置的一组CNI环境变量。其中,最重要的环境变量参数叫做:CNI_COMMAND。他的取值只有两种ADD和DEL。这个ADD和DEL操作,就是CNI插件唯一实现的两种方法。

  • ADD 把容器添加CNI网络里
  • DEL 把容器从CNI网络里移除

在网桥类型的CNI里,这两个操作说明把容器以“Veth Pair”方式插在CNI网桥上,或者从网桥上拔掉。

第二部分,是dockershim从CNI配置文件里加载到的默认插件的配置信息。这个配置信息在CNI中被叫作Network Configuration,dockershim会把Network Configuration 通过JSON数据的方式,通过标准输入的方式传递给Flannel CNI插件。

将Flannel插件的后端改成VXLAN+DriectRouting

以下操作不适合在生产环境操作,kubernetes的网络环境需要根据未来的业务环境选择。所以要集群配置前做好规划。

VXLAN+DriectRouting是首先采用直接路由的方式,如果不可以就使用VXLAN的方式。

Flannel的默认配置是VXLAN,但是我们可以配置多个插件协作,接下来我们就使用VXLAN+DriectRouting这两个插件协作。

下载Flannel配置文件

wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/k8s-manifests/kube-flannel-legacy.yml

修改kube-flannel-legacy.yml,在net-conf.json里的增加一个type。

$ vim kube-flannel-legacy.yml
.......
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan",
"Type": "DriectRouting"
}
}
.....

删除flannel插件,重新生成配置文件。

$ kubectl delete ds kube-flannel-ds  -n kube-system
$ kubectl apply -f kube-flannel-legacy.yml

这样就修改完成了,切忌生成不可以直接操作。