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的高效又可以减少运维难度进行跨网段通信。
浅析veth pair在flannel中的应用（续-host-gw）
发布时间：2026/6/28 11:20:46
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的高效又可以减少运维难度进行跨网段通信。
相关文章
5个必知技巧：用ExplorerPatcher彻底改造你的Windows 11界面体验
5个必知技巧：用ExplorerPatcher彻底改造你的Windows 11界面体验 【免费下载链接】ExplorerPatcher This project aims to enhance the working environment on Windows 项目地址: https://gitcode.com/GitHub_Trending/ex/ExplorerPatcher 还在为Windows 11的…
QtUnblockNeteaseMusic：3分钟快速上手，解锁网易云音乐版权限制
QtUnblockNeteaseMusic：3分钟快速上手，解锁网易云音乐版权限制 【免费下载链接】QtUnblockNeteaseMusic A desktop client for UnblockNeteaseMusic, made with Qt. 项目地址: https://gitcode.com/gh_mirrors/qt/QtUnblockNeteaseMusic QtUnbloc…
ExplorerPatcher：重新定义Windows工作流效率的革命性工具
ExplorerPatcher：重新定义Windows工作流效率的革命性工具 【免费下载链接】ExplorerPatcher This project aims to enhance the working environment on Windows 项目地址: https://gitcode.com/GitHub_Trending/ex/ExplorerPatcher 你是否曾在Windows 11的现…
【PolarCTF】刷新试一下
将压缩包拖入随波逐流，发现有隐藏的文件 使用binwalk提取文件 发现和解压出来的文件是一样的 下面这个就是压缩包直接解压出来的 可以看到图片属性中出现504，多半就是什么密码 打开rar.rar里面就是1111.jpg这张图片 将图片拖入随波逐流，没有任…
番茄小说下载器终极指南：开源工具实现高效批量下载与多格式导出
番茄小说下载器终极指南：开源工具实现高效批量下载与多格式导出 【免费下载链接】fanqienovel-downloader 下载番茄小说 项目地址: https://gitcode.com/gh_mirrors/fa/fanqienovel-downloader 番茄小说下载器是一个功能强大的开源Python工具，专为…
番茄小说下载器技术深度解析：从架构设计到生产部署
番茄小说下载器技术深度解析：从架构设计到生产部署 【免费下载链接】fanqienovel-downloader 下载番茄小说 项目地址: https://gitcode.com/gh_mirrors/fa/fanqienovel-downloader 番茄小说下载器是一款基于Python开发的强大开源工具，专为小说爱好…
番茄小说下载器终极指南：3种方法永久保存你的数字图书馆
番茄小说下载器终极指南：3种方法永久保存你的数字图书馆 【免费下载链接】fanqienovel-downloader 下载番茄小说 项目地址: https://gitcode.com/gh_mirrors/fa/fanqienovel-downloader 你是否曾经遇到过这样的场景：在地铁里网络信号时好时坏&…
番茄小说下载器终极指南：3步打造个人数字图书馆的免费神器
番茄小说下载器终极指南：3步打造个人数字图书馆的免费神器 【免费下载链接】fanqienovel-downloader 下载番茄小说 项目地址: https://gitcode.com/gh_mirrors/fa/fanqienovel-downloader 想要永久保存番茄小说平台的精彩内容吗？这款强大的番茄小…
有关于信息率失真函数的思考与研究（P124302083严恩可 P124302062张臣）
在无噪信道编码中，香农无失真编码定理指出：只要编码码率大于信源熵H(X)，就可以实现任意小的译码差错。但在图像、语音、视频等多媒体通信场景下，严格无失真编码需要极高的传输码率，会占用大量信道带宽。为此࿰…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…