简介面向Kubernetes集群运维与网络配置人员压缩包内是针对ARM64架构Linux系统的flannel v0.11.0离线安装包。flannel作为K8s常用的容器网络插件可帮助解决跨节点Pod通信与网络策略配置问题尤其适用于无法直接访问外网拉取镜像或二进制的内网环境。包体小巧仅8.03MB共包含3个文件以可执行的flanneld主程序为主附带README说明文档与辅助用Shell脚本分别用于组件运行、配置指引及Docker环境选项生成整体简洁清晰。已有452人学习下载适合正在搭建ARM集群或需手动部署flannel的用户。通过该包可快速获得适配arm64的flannel核心程序配合说明脚本完成基础网络参数设置为集群网络初始化提供关键支持。 先扔一个场景运维同事发来一个链接里面是一个叫flannel-v0.11.0-linux-arm64.tar.gz的文件紧跟着一句“生产集群要加 ARM 节点赶紧把这个包弄好。”这时候你要是只想着“解压、扔到目录、启动”大概率会在后面的一连串网络问题里耗掉大半天。别问我怎么知道的我在这条路上踩过不少坑。这篇文章就把这个包里面的门道、部署步骤和排查经验一次性讲清楚。这个文件本身不复杂但背后的东西远不只是“一个二进制包”它是 Kubernetes 网络插件 Flannel 的 ARM64 版本v0.11.0 又是一个非常特殊的时间节点版本。我会从为什么这个老版本依然值得用到包结构、内核依赖、systemd 托管、CNI 对接、MTU 排查再到升级思路按实际操作的顺序带你走一遍。无论你是在树莓派、鲲鹏服务器还是其他 ARM64 设备上搭 K8s这份笔记都能直接参考。1. 为什么还在用 v0.11.0一个“老版本”的现实价值先泼盆冷水v0.11.0 是 2019 年就发布的版本GitHub 上现在已经到 v0.21甚至官方仓库都改了很多次目录结构。那为什么还要用说白了生产环境最怕的不是老而是变化。我维护过好几套基于 etcd v2 的 K8s 1.15/1.16 集群Flannel v0.11.0 和这些老集群的 CNI 接口、etcd 数据模型是高度绑定的。你冒然升级到新版可能就要把整个 etcd 的数据迁移方案重做一遍风险远大于收益。另外一点ARM64 架构在嵌入式、边缘计算场景中占比很高很多设备预装的系统镜像本身就很老比如 Ubuntu 18.04、CentOS 7 的 ARM build新版本 Flannel 对 glibc、内核版本的要求更高。v0.11.0 的二进制体量小、依赖少做成tar.gz直接丢上去就能跑非常适合离线部署。这也是为什么直到今天你仍然能在很多内网运维文档里看到这个版本。当然如果你是新建集群我建议直接用新版 Flannel。但如果你和我一样需要在老集群上扩容 ARM 节点或者你手里的平台环境就是这么固定下来的那么 v0.11.0 就是一个“稳定大于一切”的合理选择。记住一个原则网络插件这种基础设施能不动就不动动了就要有完整的回退方案。2. 解压之前先看懂 tar.gz 包内的门道拿到flannel-v0.11.0-linux-arm64.tar.gz第一件事不是解压是校验。尤其从非官方渠道下载的包强烈建议先看官方提供的 SHA256 校验和。假设你把它放在/opt/downloads目录下cd /opt/downloads sha256sum flannel-v0.11.0-linux-arm64.tar.gz输出的哈希值要和官方 release 页面保持一致。如果不一致立刻停手重新下载。这不是小题大做容器网络的二进制一旦被掉包整个集群的流量都可能被劫持。校验通过后解压tar -xzf flannel-v0.11.0-linux-arm64.tar.gz ls -lh你会看到类似这样的内容total 22M -rwxr-xr-x 1 root root 22M ... flanneld -rw-r--r-- 1 root root 315 ... README.md就这么简单一个主二进制flanneld一个 README。有人可能困惑“怎么没有 CNI 插件”没错v0.11.0 的发布包里只带了flanneld守护进程而flannelCNI 插件也就是会调用于创建网络命名空间的那个程序是独立发布的通常需要单独下载cni-plugins-linux-arm64-v0.8.x.tgz这个包里的flannel才是给 kubelet 用的 CNI 插件。很多人就是只解压了flanneld然后发现 Pod 网络根本起不来其实不是 Flannel 的问题而是 CNI 插件缺了。这里还有个细节ARM64 的二进制和你常见到的 x86_64 二进制在文件格式上不同不确认的情况下可以用file工具看一下file flanneld # 正确输出例如flanneld: ELF 64-bit LSB executable, ARM aarch64...如果输出是x86-64说明你下载错了包直接跑会报exec format error别浪费时间调其他东西。3. ARM64 环境准备与必需的内核条件在部署flanneld之前ARM64 Linux 服务器的内核和网络配置必须先过关。很多人在树莓派上折腾半天最后发现是内核模块没开。首先确认系统架构和内核版本uname -m # aarch64 uname -r # 建议 4.9 以上v0.11.0 对内核要求不高但模块要齐全Flannel 最常用的 VXLAN 后端依赖vxlan内核模块。有些精简的 ARM 板卡镜像默认没带需要显式加载modprobe vxlan如果想开机自动加载在/etc/modules-load.d/modules.conf里加一行vxlan。另外还需要确保bridge、nf_tables或iptables相关模块存在。检查方式lsmod | grep vxlan如果输出为空大概率模块没加载。加载后可以再跑ip link add vxlan-test type vxlan id 1 dev eth0做一次临时测试创建成功就说明内核完全支持。其次开启 IPv4 转发。ARM 嵌入式系统默认往往不开启而 Flannel 的网关转发全靠这个开关。编辑/etc/sysctl.confnet.ipv4.ip_forward 1 net.bridge.bridge-nf-call-iptables 1执行sysctl -p生效。注意第二项需要bridge模块先加载否则会报错。最后建议关闭或正确配置 NetworkManager。在纯 server 版系统上通常没问题但 Ubuntu Desktop、某些 ARM 开发板的桌面版会跑 NetworkManager它可能会接管flannel.1这个虚拟网卡的地址导致 Flannel 刚配好的 IP 被 DHCP 或者其他机制冲掉。解决办法是给关键接口设置unmanaged或者像我一样直接在部署节点上卸载/禁用 NetworkManager改用netplan或传统/etc/network/interfaces。这块不是 Flannel 的问题但十次有八次网络异常都从这里开始。4. flanneld 安装启动实操从命令到 systemd 托管环境准备完下面开始部署。先把二进制放到系统路径并设置好权限cp flanneld /usr/local/bin/ chmod x /usr/local/bin/flanneld官方文档里Flannel 启动时需要两个核心信息etcd或者 Kubernetes API 地址以及分配给 Flannel 的网段。对于 v0.11.0 和老的 etcd 模式我习惯先把配置写到环境变量文件/etc/flannel/options.envFLANNELD_ETCD_ENDPOINTShttp://192.168.10.10:2379 FLANNELD_ETCD_PREFIX/atomic.io/network FLANNELD_NETWORK10.244.0.0/16 FLANNELD_BACKENDvxlan FLANNELD_IFACEeth0重点解释几个参数FLANNELD_NETWORK整个集群的 Pod 网段必须是你在规划集群时预留好的大网段Flannel 会在这个网段里为每个节点分配一个子网。FLANNELD_BACKENDv0.11.0 支持udp、vxlan、host-gw等。ARM 节点一般带宽有限vxlan兼容性最好如果所有节点都在同一二层网络且对性能有要求host-gw可以减少封装开销但需要每个节点对非本机子网配置路由Flannel 会自动做不过节点间必须二层可达。FLANNELD_IFACE指定使用哪块网卡的 IP 来传输 VXLAN 流量。这个非常重要ARM 设备经常有多网口默认取默认路由网卡如果你设错了多节点之间根本建不了 VXLAN。然后创建 systemd unit 文件/etc/systemd/system/flanneld.service[Unit] DescriptionFlanneld Afternetwork-online.target Wantsnetwork-online.target [Service] Typenotify EnvironmentFile/etc/flannel/options.env ExecStart/usr/local/bin/flanneld Restarton-failure RestartSec5 LimitNOFILE1048576 [Install] WantedBymulti-user.target启动并设置开机自启systemctl daemon-reload systemctl enable --now flanneld systemctl status flanneld正常日志里会看到类似这样的输出I0523 10:00:01.123456 12345 main.go:530] Using backend: vxlan I0523 10:00:02.123456 12345 vxlan.go:137] VXLAN config: VNI1 Port8472 GBPfalse DirectRoutingfalse I0523 10:00:03.123456 12345 route.go:123] Deleting route: 10.244.0.0/24 dev flannel.1运行起来后用ip addr show flannel.1应该能看到一个10.244.x.0/32的地址同时系统路由表里会出现通过flannel.1转发的其他节点子网路由。这一步意味着 Flannel 数据平面已经工作了。5. 配置 CNI 与 Docker 对接让容器真正跑在 flannel 网络上flanneld只是给节点分配子网、维护路由和转发规则真正让容器接入这个网络的是 CNI 插件和容器运行时。如果你的集群是 Kubernetes 管理的需要把 CNI 插件安装到/opt/cni/bin。到 release 页面下载cni-plugins-linux-arm64-v0.8.7.tgz注意 v0.11.0 时代常用的是 0.8.x 的 CNI 插件集合mkdir -p /opt/cni/bin tar -xzf cni-plugins-linux-arm64-v0.8.7.tgz -C /opt/cni/bin然后创建/etc/cni/net.d/10-flannel.conflist{ name: cbr0, plugins: [ { type: flannel, delegate: { isDefaultGateway: true, hairpinMode: true } } ] }这个配置的核心是让 CNI 从 Flannel 的subnet.env文件由flanneld自动生成通常在/run/flannel/subnet.env中读取当前节点子网、MTU 等信息然后调用bridge插件创建容器网卡。所以你不需要手动在配置里写 IP 或网段Flannel 自己会同步。如果你的环境不用 Kubernetes而是裸的 Docker那就走老路子让 Docker daemon 把docker0网桥的地址池和 Flannel 子网保持一致。做法是在 Docker 配置里指定dockerd --bip$(grep FLANNEL_SUBNET /run/flannel/subnet.env | cut -d -f2 | tr -d ) --mtu$(grep FLANNEL_MTU /run/flannel/subnet.env | cut -d -f2 | tr -d )实际生产环境建议用 systemd drop-in 配置而不是裸命令。对于 DockerCompose 的场景这种“共生模式”完全够用但如果你要跑 Kubernetes走 CNI 一定是主线。我不推荐在同一个节点上同时让docker0接管和 CNI 接管你会在路由表里看到各种奇奇怪怪的重合和冲突。6. 网络连通性验证与 MTU 问题排查部署完不代表结束真正的问题往往在验证阶段露头。验证 Pod 跨节点通信最基本的方式是进入容器 ping 对端 Pod IP。我见过太多人一上来就ping 10.244.1.20通了就以为万事大吉直到传输大数据才发现 MTU 不对。所以要分层验证。先看本机路由ip route | grep 10.244假设本机是10.244.0.5/24对端节点是10.244.1.0/24你会在路由表中看到10.244.1.0/24 dev flannel.1 proto kernel scope link src 10.244.0.0这行路由说明 Flannel 已经为对端子网建立了 VXLAN 转发。然后在一个容器里执行这里以busybox为例kubectl exec -it busybox -- ping -c 3 10.244.1.20如果通再看 MTUkubectl exec -it busybox -- ping -M do -s 1472 -c 3 10.244.1.20VXLAN 默认封装头 50 字节物理网络 MTU 是 1500那么 VXLAN 内层 MTU 是 1450。1472 的 payload 加上 ICMP 头 8 字节 1480已经大于 1450正常情况下这里应该失败或分片。如果-M do -s 1472能通说明你的物理链路允许更大 MTU同时也意味着 Flannel 的 MTU 可能没有正确下发给容器。排查方法cat /run/flannel/subnet.env # FLANNEL_NETWORK10.244.0.0/16 # FLANNEL_SUBNET10.244.0.1/24 # FLANNEL_MTU1450 # FLANNEL_IPMASQtrue如果FLANNEL_MTU是 1450但容器内ip link show eth0的 MTU 是 1500那就是 CNI 配置里没有正确读取 subnet.env。检查/etc/cni/net.d下面是否有别的较老配置如bridge.conf跟 Flannel 的并发序冲突导致用了默认 MTU。还有一个经典问题不同节点之间VXLANPort不通。ARM 设备常见的原因是防火墙。例如有的系统默认开启了firewalld需要放行 UDP 8472 端口firewall-cmd --add-port8472/udp --permanent firewall-cmd --reload如果是ufwufw allow 8472/udp此外如果节点只有一个网卡且网卡本身 MTU 就是 1500那么把物理网卡手动调成 1600如果你的交换机支持 jumbo frame也可以让 VXLAN 内层 MTU 提升到 1550对整集群吞吐有明显帮助。但这是一个全局配置动作不能只改 Flannel否则同样会出现大小包行为不一致。7. 在 ARM64 设备上踩过的三个真实坑这一段是我自己反复趟雷后最想说的内容。第一个坑内核模块缺失导致 flanneld 静默退出。在树莓派 4B 的 Ubuntu 20.04 ARM64 上我遇到过flanneld起来后进程一直在但日志没有任何报错只是不创建flannel.1接口。后来排查发现是vxlan模块没加载但是日志里没打出来。这种静默失败在 ARM 精简系统上非常常见所以我建议启动前必须手动验证一次modprobe vxlan并且用lsmod确认。第二个坑FLANNELD_PUBLIC_IP配置在 ARM 多网卡环境下的误导。有时候你指定了FLANNELD_IFACEeth0但实际跨节点 VXLAN 还是连不通因为很多 ARM 设备默认有个docker0或者cni0接口主机的默认路由优先走物理网卡没问题但在一些系统里物理网卡 IP 不在默认路由项里Flannel 会拿docker0的地址作为public IP。解决办法是显式设置FLANNELD_PUBLIC_IP你的物理网卡IPv0.11.0 支持这个参数。这个坑在 x86 服务器上其实也有但 ARM 设备的网络接口命名更乱撞上的概率很高。第三个坑etcd 版本不一致导致数据写入失败。v0.11.0 仍默认使用 etcd v2 API 写入网络配置这也是它能在老集群上工作的主要原因。但如果你后端跑的是 etcd v3.4 以上且没有开启 v2 API 兼容flanneld会一直报连接成功但操作失败。解决办法是在 etcd 启动参数里加上--enable-v2true或者把 Flannel 切换到 Kubernetes API 模式。后者需要配置FLANNELD_KUBERNETES_API_SERVER和 token虽然复杂点但可以摆脱 etcd v2 的兼容性限制。8. 从 tar.gz 到长期运行备份与升级要点最后聊聊维护。flanneld本身是静态二进制升级理论上就是换包、重启服务但实际没那么简单。备份方面需要备份的不是二进制而是配置和数据等等还有 etcd 中的/atomic.io/network前缀数据。用etcdctl get /atomic.io/network/config或递归ls把配置导出来。备份每个节点的/run/flannel/subnet.env后期需要排障或重新生成时很有用。备份/etc/cni/net.d下所有配置。升级方面如果你计划从 v0.11.0 升级到 v0.13 或更高需注意几个变化--etcd-prefix默认值从/atomic.io/network改成了/coreos.com/network升级时要显式指定一致的前缀否则节点会认为自己进入了一个全新的网络。v0.11.0 直接使用--iptables-forward-rulesfalse的默认行为和后续版本有差异升级后要重新确认 MASQUERADE 规则是否还由 Flannel 管理。新版对 etcd v2 支持逐渐弱化如果集群依赖 etcd必须同步评估 etcd 迁移。如果你需要自己从源码构建 ARM64 包在 Go 环境里执行git clone https://github.com/flannel-io/flannel.git cd flannel git checkout v0.11.0 GOOSlinux GOARCHarm64 make交叉编译出来后用file flanneld验证是ARM aarch64。不过我这里要提醒不要轻易自己构建生产用网络组件除非你能完整测试所有后端和 CNI 组合。官方发布的tar.gz是经过完整 CI 的自构建只适合特殊定制场景。我个人的经验是网络插件这种底层东西除非有明确需求不然最好是“一次部署长期不动”。你要做的不是追新而是把当前版本摸透。v0.11.0 这个包虽然老但只要环境匹配、配置正确它在 ARM64 节点上完全可以稳定运行几年。真到了需要升级的时候先在一台测试 ARM 节点上完整走一遍确认路由表、VXLAN 隧道和 CNI 插件的协同行为都没有变化再逐步打补丁。手里有回滚方案心里就不慌。本文还有配套的精品资源点击获取