host-gw模式flannel中有三种模式vxlanhost-gwUDP上文说的是vxlan模式下的通信过程接下来简单说下另外两个模式。其中UDP模式因为其性能实在太拉胯而被官方弃用了。vxlan和UDP都是封装为什么UDP被废弃而vxlan却存活了下来呢因为在发送UDP报文时进行了两次用户态和内核态的交互而接收端同样也要两次这种交互耗资源也耗时。数据路径Pod↓Kernel↓Userspaceflanneld↓Kernel↓Network↓Kernel↓Userspaceflanneld↓Kernel↓Pod看图而vxlan的封装/解封装均在内核态执行数据路径Pod↓Kernel↓Kernel VXLAN↓Network↓Kernel VXLAN↓Pod看图二者的区别UDP Backend flanneld 负责控制面 数据面数据包进入用户态处理。VXLAN Backend flanneld 只负责控制面分配子网、维护配置数据面全部由 Linux Kernel VXLAN 模块处理因此性能更高也正是官方废弃 UDP 模式的根本原因。看图下面我们来说下host-gw这个模式的效率比vxlan要高因为它是直接路由不需要封装从名字也能看出个大概主机网关。直接走主机路由表进行三层路由。我们指讨论三层通信二层和上文是一样的。但是使用这个模式有个大前提就是所有的node节点须在同一个二层网络中也就是所有 Node 的主机 IP 必须能够直接互通并且能够通过二层 ARP 找到对方 MAC。host-gw 默认要求所有 Node 位于同一二层网络因此部署最简单、性能最高理论上也可以跨三层网络但需要网络设备维护到各 Pod 网段的路由运维复杂因此实际生产中跨网段场景通常选择 VXLAN。实验简述设备版本VMware® Workstation 17 Pro17.6.2 build-24409262UbuntuUbuntu 24.04.3 LTS物理主机操作系统Windows 11 Home, 64-bit (Build 26200.8655) 10.0.26200k8s版本Client Version: v1.35.4Kustomize Version: v5.7.1Server Version: v1.35.0flannel版本flannel:v0.28.5node1eth0192.168.8.238/24flannel.110.244.1.0/32cni010.244.1.1/24node2eth0192.168.8.239/24flannel.110.244.2.0/32cni010.244.2.1/24我现在环境的flannel是vxlan模式将它改成host-gw的模式# node1的地址信息vagrantk8s-node1:~$ipa2: eth0:BROADCAST,MULTICAST,UP,LOWER_UPmtu1500qdisc fq_codel state UP group default qlen1000link/ether 00:0c:29:1c:57:1b brd ff:ff:ff:ff:ff:ff altname enp3s0 altname ens160 inet192.168.8.238/24 metric100brd192.168.8.255 scope global dynamic eth0 valid_lft 1371sec preferred_lft 1371sec inet6 fe80::20c:29ff:fe1c:571b/64 scopelinkvalid_lft forever preferred_lft forever4: flannel.1:BROADCAST,MULTICAST,UP,LOWER_UPmtu1450qdisc noqueue state UNKNOWN group default link/ether 2a:5e:b7:c2:72:db brd ff:ff:ff:ff:ff:ff inet10.244.1.0/32 scope global flannel.1 valid_lft forever preferred_lft forever inet6 fe80::285e:b7ff:fec2:72db/64 scopelinkvalid_lft forever preferred_lft forever5: cni0:BROADCAST,MULTICAST,UP,LOWER_UPmtu1450qdisc noqueue state UP group default qlen1000link/ether ee:4e:e8:c1:87:2c brd ff:ff:ff:ff:ff:ff inet10.244.1.1/24 brd10.244.1.255 scope global cni0 valid_lft forever preferred_lft forever inet6 fe80::ec4e:e8ff:fec1:872c/64 scopelinkvalid_lft forever preferred_lft forever# node1的路由信息vagrantk8s-node1:~$ route-nKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0192.168.8.20.0.0.0 UG10000eth010.244.0.010.244.0.0255.255.255.0 UG000flannel.110.244.1.00.0.0.0255.255.255.0 U000cni010.244.2.010.244.2.0255.255.255.0 UG000flannel.1192.168.8.00.0.0.0255.255.255.0 U10000eth0192.168.8.20.0.0.0255.255.255.255 UH10000eth0192.168.64.00.0.0.0255.255.255.0 U000eth1# 查看flannel的配置文件vagrantk8s-master:~$ k-nkube-flannel get cm NAME DATA AGE kube-flannel-cfg28d kube-root-ca.crt18d# 修改flannel的配置文件vagrantk8s-master:~$ k-nkube-flannel edit cm kube-flannel-cfg net-conf.json:|{Network:10.244.0.0/16,EnableNFTables:false,Backend:{Type:host-gw}# 重启flannelvagrantk8s-master:~$ k-nkube-flannel rollout restart daemonset kube-flannel-ds# 查看重启后的node1主机路由表vagrantk8s-node1:~$ route-nKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0192.168.8.20.0.0.0 UG10000eth010.244.0.0192.168.8.237255.255.255.0 UG000eth010.244.1.00.0.0.0255.255.255.0 U000cni010.244.2.0192.168.8.239255.255.255.0 UG000eth0192.168.8.00.0.0.0255.255.255.0 U10000eth0192.168.8.20.0.0.0255.255.255.255 UH10000eth0192.168.64.00.0.0.0255.255.255.0 U000eth1两张路由表对比可以看出之前有flannel.1接口处理的路由被改成了eth0主机网卡下面抓包验证。vagrantk8s-master:~$ k get po-A-owide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default test-pod-11/1 Running072m10.244.1.20 k8s-node1nonenonedefault test-pod-21/1 Running072m10.244.1.21 k8s-node1nonenonedefault test-pod-31/1 Running072m10.244.2.14 k8s-node2nonenonedefault test-pod-41/1 Running072m10.244.2.15 k8s-node2nonenone# 在node1上抓包vagrantk8s-node1:~$sudotcpdump-ieth0-nn-w/tmp/gwnode1.pacp-s0host10.244.2.14# 使用pod1 ping pod3vagrantk8s-master:~$ kexectest-pod-1 --ping-c410.244.2.14从报文中可以看出没有认证封装源目的mac均为node节点物理网卡的地址。IP分别为pod1和pod3的地址。直接使用pod的IP地址进行的路由。那么这个路由条目是怎么来的呢是flanneld通过监听Kubernetes API或 etcd得知该节点存活并持有了 10.244.2.0/24于是计算出下一跳为该节点的物理 IP。跨网段的实验我做不了没条件大家感兴趣可以自行验证vxlan和host-gw的组合它俩的组合就是不跨网段走host-gw跨网段走vxlan在这我就简述一下大家感兴趣可以自行验证。准确的来说是vxlan的一个优化功能。# 配置方法如下修改flannel配置文件。vagrantk8s-master:~$ k-nkube-flannel edit cm kube-flannel-cfg net-conf.json:|{Network:10.244.0.0/16,EnableNFTables:false,Backend:{Type:vxlanDirectrouting:true}# 重vagrantk8s-master:~$ k-nkube-flannel rollout restart daemonset kube-flannel-ds这样既可以享受host-gw的高效又可以减少运维难度进行跨网段通信。
