简介这是 Kubernetes 集群网络插件 Flannel 在 Linux ARM64 架构下的一个发行包标题为 flannel-v0.11.0-linux-arm64.tar.gz重点解决跨节点容器之间的网络互通问题。包内共包含 3 个文件flanneld 主程序负责运行 Flannel 守护进程并构建 Overlay 二层网络README.md 介绍了版本特性、编译方式、部署参数与常见问题注意事项mk-docker-opts.sh 辅助脚本可为 Docker 自动生成网络相关环境变量使其正确连接 Flannel 网络接口减少手动配置步骤。整个压缩包 gzip 后大小约为 8.03MB轻量紧凑文件结构清晰适合在树莓派或其它 ARM 服务器上快速部署。目前已有 453 人学习或下载过该资源适用于正在搭建 Kubernetes 集群、需要 ARM 网络插件的中高级运维工程师。获取后可省去自行编译流程直接获得可执行二进制与配套脚本并结合说明文档快速完成配置提高集群网络环境搭建效率并有效降低网络配置出错概率。1. flannel v0.11.0 离线包到底在解决什么拿到flannel-v0.11.0-linux-arm64.tar.gz这个文件名先别急着解压。它解决的是一类很具体的现场问题在纯内网、ARM64 架构的 Linux 服务器上用 kubeadm 或 KubeKey 初始化 Kubernetes 集群时控制面能起来但 Pod 网络迟迟不就绪kubectl get nodes看到节点一直是NotReady。原因就是集群缺少一个 CNI 网络插件而 flannel v0.11.0 的 arm64 离线包就是为这种场景准备的一剂后悔药——把网络组件、二进制、配置一次性打包成 tar.gz拷到目标机器上离线部署不依赖外网镜像仓库。这个包的核心价值有三个第一它是官方发布的 arm64 产物不是自己交叉编译的野包能直接用第二v0.11.0 这个版本在 Kubernetes 1.16~1.22 之间被大量生产环境验证过行为可预期第三tar.gz 格式意味着你可以在任意一台能联网的机器上先下载再通过 U 盘或内网传输推到离线环境。适合的人群很明确做国产化适配的、军工电网等内网机房的、以及手里只有 ARM64 服务器没有 x86 跳板机的运维和平台工程师。2. 拆包之前先搞懂 flannel v0.11.0 在集群里的角色2.1 flannel 的 Overlay 模型为什么 ARM64 上默认走 VXLANflannel 的原理并不复杂它为每个节点分配一个独立子网通过一个后台的分布式存储通常是 etcd 或 Kubernetes 的 API Server记录子网与节点 IP 的映射关系。节点之间的流量封装在 UDP 或 VXLAN 隧道里这样 Pod IP 就能跨主机通信。v0.11.0 这个版本默认的后端是 VXLAN端口 8472/UDP这个选择在 ARM64 上尤其重要因为 ARM 核的 CRC 卸载和 checksum offload 能力参差不齐VXLAN 在内核里实现相对成熟兼容性最好。如果你非要在这版里用手动配置的 host-gw 后端需要满足一个硬条件所有节点在同一二层网络且能直接路由。大多数 ARM64 服务器在机房里的网络拓扑是满足的但一旦跨 VLAN 就翻车。所以我的建议是一开始老老实实用 VXLAN等 Pod 网络通了你再逐节点评估能不能切 host-gw 提性能。2.2 tar.gz 包里的内容物镜像还是二进制先确认你的运行时解压之前先猜一下这个包里装的是什么。flannel 的官方发布模式有两种一种是纯二进制 tarball里面是flanneld可执行文件另一种是包含 Docker 镜像的包里面是一个flannel.tar或flanneld-image目录需要用docker load或ctr -n k8s.io images import导入。v0.11.0 时代的发布更常见的是前者但你在内网环境里用 KubeKey 装集群时KubeKey 生成的 manifest 会引用flannel镜像所以这个 tar.gz 极有可能是配合镜像包使用的镜像归档。判断方法很简单tar -tzf flannel-v0.11.0-linux-arm64.tar.gz | head -20这条命令不解压只列出包内的文件名清单。如果输出里有images目录或.tar文件说明你要走导入镜像的路线如果直接看到flanneld和README.md那就是二进制部署路线。参数说明-t表示列出内容-z表示通过 gzip 解压读取-f指定文件名。head -20只截取前 20 行避免目录项太多刷屏。内网机器上如果没有tar的 gzip 支持极少数精简系统可以先gzip -d再tar -tf但正常 Ubuntu、CentOS、麒麟系统都不会有这个问题。2.3 解压到指定目录别把文件散到根目录解压动作本身很简单但有个细节值得注意很多 tar 包里的路径是相对的直接tar -xzf会把文件全部释放到当前目录如果当前目录是/root后面排查时文件混在一堆脚本里很难看。我一般会先建独立目录再解压。mkdir -p /opt/flannel-offline tar -xzf flannel-v0.11.0-linux-arm64.tar.gz -C /opt/flannel-offline ls -l /opt/flannel-offline这段命令把解压目标锁死在/opt/flannel-offline之后无论是找镜像文件还是手工启动flanneld路径都是确定的。-C参数指定解压目标目录这是 tar 命令里最值得养成习惯的参数之一。解压完看一眼目录你会发现里面大概率有这几个物件flanneld二进制、kube-flannel.yml或flannel-deployment.yaml的 manifest、README.md。如果 manifest 文件里写的是image: quay.io/coreos/flannel:v0.11.0-arm64那你的部署路径就明确了先把镜像导入到节点的容器运行时再kubectl apply -f那个 manifest。3. 把包里的镜像推到私有仓库手动加载与 tag 重打3.1 为什么不能直接 apply manifestimagePullPolicy 与内网拉取的死结很多人第一步就踩坑kubectl apply -f kube-flannel.yml之后 Pod 一直ImagePullBackOff。原因是 manifest 里的镜像地址写的是公网仓库内网节点根本拉不到。就算你先在节点上docker pull或ctr images pull成功了Kubelet 的镜像拉取策略和 CRI 运行时的镜像命名空间不一致依然会去远程拉。这就是为什么第二章节要先确认 tar 包里有没有镜像归档——如果有直接导入本地镜像库让 Kubelet 认为镜像已经存在再 apply 就不会触发远程拉取。这里需要区分两个运行时Docker 和 Containerd。ARM64 的国产系统上KubeKey 默认初始化出来的是 Containerd而不是 Docker。很多从 x86 转过来的运维习惯性地敲docker load结果发现命令不存在因为节点上只有ctr和crictl。3.2 用 ctr 导入镜像到 k8s.io 命名空间如果你的包里有flannel.tar或flannel.image.tar用下面的命令导入ctr -n k8s.io images import /opt/flannel-offline/flannel.tar ctr -n k8s.io images list | grep flannel第一行的-n k8s.io是关键它把镜像导入到 CRI 专用的命名空间。如果你不加这个参数默认导到default命名空间Kubelet 照样不认。第二行是验证动作看到输出里有quay.io/coreos/flannel开头的镜像记录说明导入成功。参数说明ctr是 containerd 自带的 CLIimages import子命令支持 tar 格式的镜像归档兼容 docker save 的产物。grep flannel是过滤输出因为images list会列出所有已导入镜像不筛选你会看花眼。导入之后别忘了核对镜像的 tag 与 manifest 里写的是否一致。不一致的情况很常见包里的镜像 tag 是v0.11.0-arm64而你的 manifest 里写的是v0.11.0或v0.11.0-arm64。不一致时有两个办法改 manifest 里的 image 字段或者重新打 tag。3.3 镜像重打 tag 与 KubeKey 私有仓库推送如果集群里已经搭了 Harbor 或其它私有仓库更规范的做法是把镜像推到私有仓库然后修改 manifest 里的 image 地址指向私有仓库。KubeKey 生成的集群配置里通常在spec.kubelet.containerRuntimeEndpoint和spec.network.plugin控制但推镜像这件事跟 KubeKey 本身没关系它只是一个 load 工具。docker tag quay.io/coreos/flannel:v0.11.0-arm64 registry.internal:8443/coreos/flannel:v0.11.0-arm64 docker push registry.internal:8443/coreos/flannel:v0.11.0-arm64这是基于 Docker 的写法前提是你的节点或跳板机上装了 Docker。如果只有 ctr推送镜像更繁琐我一般建议直接ctr images export到 tar 再import别折腾 push。tag 重打的核心是让 manifest 里的 image 字段与本地镜像库里的repository:tag完全匹配不匹配时 Kubelet 会去远程拉拉不到就报ErrImagePull。这里有一个容易被忽略的边界如果 tar 包里的镜像同时带sha256和tag两个标识导入后images list会显示两条记录实际是同一个镜像的不同引用。你只需要确认 tag 那条存在即可。4. 用 kube-flannel.yml 拉起集群网络从 apply 到验证4.1 手动编辑 manifest 的四个必改字段拿到kube-flannel.yml之后不要直接 apply先看这几个字段第一image字段。离线环境必须改成能与本地镜像对上的地址否则 Kubelet 拉不到。第二args里的--iface字段。如果节点有多个网卡不指定的话 flannel 会选错网卡导致 Pod 网络通但 NodePort 和跨节点通信异常。第三Network字段。默认是10.244.0.0/16如果你的集群--pod-network-cidr用的是别的网段这里必须同步改否则 flannel 分配的子网和 kube-controller-manager 的预期不一致Pod 会拿不到 IP。第四backend类型。v0.11.0 默认 VXLAN除非你有充分理由别在这里改。常见做法是在 apply 之前先用sed替换把镜像地址改成私有仓库里的路径sed -i s#quay.io/coreos/flannel:v0.11.0-arm64#registry.internal:8443/coreos/flannel:v0.11.0-arm64#g kube-flannel.ymlsed的s#旧地址#新地址#g格式里用的是#做分隔符不是常规的/因为镜像地址本身含斜杠用#可以避免转义地狱。替换完成后用grep -n image: kube-flannel.yml确认结果。4.2 apply 之后 90 秒内该观察什么kubectl apply -f kube-flannel.yml kubectl get pods -n kube-system -o wide | grep flannelapply 之后不要干等立刻观察 Pod 调度情况。flannel 是 DaemonSet理想状态下每个节点都会出一个 Pod状态变成Running且READY 1/1。如果卡在ContainerCreating大概率是镜像没导入或 CNI 配置没写盘。如果CrashLoopBackOff看日志kubectl logs -n kube-system -l appflannel --tail50日志里出现Error registering network或failed to ensure lease exists多半是 etcd 或 API Server 连接不上出现could not find subnet则是网段冲突或配置不一致。这一步是整个部署里最花时间的排查环节日志信息要逐字看不要只看最后一行。Node 状态确认kubectl get nodes等所有节点Ready之后再验证跨节点 Pod 连通性。可以用busybox起一个测试 Pod ping 另一个节点的 Pod IP也可以直接在节点上用ping命令访问对端 Pod IPping -c 3 10.244.1.2能 ping 通说明 VXLAN 隧道和数据路径已经起来了。ping 不通先查防火墙和 SELinux这两个是最常见的黑匣子。4.3 手工生成 CNI 配置不通过 manifest 时的替代路线如果 tar 包里没有 manifest只有flanneld二进制需要手工规划。先把flanneld放到/opt/bin/flanneld再创建 CNI 网络配置文件和 flannel 的子网配置文件mkdir -p /etc/cni/net.d /var/lib/flannel cat /etc/cni/net.d/10-flannel.conflist EOF { name: cbr0, cniVersion: 0.3.1, plugins: [ { type: flannel, delegate: { hairpinMode: true, isDefaultGateway: true } }, { type: portmap, capabilities: {portMappings: true} } ] } EOF然后手工启动flanneld/opt/bin/flanneld --kube-subnet-mgr --ifaceeth0 --ip-masq--kube-subnet-mgr表示从 Kubernetes API Server 获取子网分配这是 v0.11.0 之后的主流模式不再依赖独立的 etcd。--ifaceeth0指定节点对外通信的网卡务必改成你实际环境里的网卡名可以用ip route get 8.8.8.8查默认出接口。--ip-masq开启 SNAT让 Pod 访问外部网络时做地址伪装内网环境一般开。手工路线适合没有 kubectl 权限或者只管理单节点的场景但它有个缺点flanneld进程不会自动重启节点一重启就没了。生产环境还是用 DaemonSet 方式托管进程更可靠。5. 避坑指南ARM64 内网部署 flannel 的六个典型翻车现场5.1 镜像导入成功但 Pod 还是 ImagePullBackOff现象ctr images list能看到 flannel 镜像但kubectl get pods显示ImagePullBackOff。原因Kubelet 使用的 CRI 运行时与导入镜像的运行时不一致。比如节点上同时装了 Docker 和 ContainerdKubelet 配的是 Docker endpoint但你用ctr导入的是 Containerd 的镜像库两边互相看不见。另一种可能是镜像 tag 不一致Kubelet 要拉v0.11.0-arm64导入的是v0.11.0。解决先用crictl images检查 Kubelet 视角的镜像列表如果为空说明导入的运行时不对。重新用docker load导入或者修改 containerd 配置让 Kubelet 指向 containerd 的 endpoint。tag 不一致就直接改 manifest 或重新打 tag。5.2 节点 Ready 但 Pod 之间 ping 不通现象kubectl get nodes全部 Ready但不同节点上的 Pod 互相 ping 不通同节点的 Pod 正常。原因VXLAN 的 8472/UDP 端口被防火墙挡住或者节点间 MTU 不一致导致大包被丢弃。ARM64 服务器上尤其常见的是 netfilter 的rp_filter开启导致 VXLAN 解封装后的包被当成源地址伪造丢弃。解决先放通 8472 端口iptables -A INPUT -p udp --dport 8472 -j ACCEPT然后检查 MTUip link show flannel.1如果 MTU 超过物理网卡的 MTU要在 flannel manifest 里设置VXLAN: {MTU: 1400}或者调低物理网卡 MTU。rp_filter的问题执行sysctl -w net.ipv4.conf.all.rp_filter0临时验证确认有效后写进/etc/sysctl.conf。5.3 flanneld 日志报权限错误现象Pod 启动后CrashLoopBackOff日志里出现operation not permitted或failed to create vxlan device。原因容器缺少NET_ADMIN权限或者内核模块vxlan没加载。ARM64 的某些精简内核把 VXLAN 编成了模块而非内建模块没加载就创建不了 VXLAN 设备。解决在 flannel DaemonSet 的securityContext里确认privileged: true。同时在节点上执行modprobe vxlan加载模块并写入/etc/modules-load.d/vxlan.conf让它开机自动加载。验证方法lsmod | grep vxlan。5.4 多网卡机器 flannel 选错网卡现象Pod 能起来但跨节点通信时通时不通而且 flanneld 日志里看到的public IP不是预期的节点 IP。原因节点有多块网卡flannel 选了一块不对外通信的网卡作为 VTEP 地址比如选了 docker0 或内网管理口。解决在 manifest 的args里显式指定--iface。如果节点间网卡名不统一可以用正则--ifaceeth.*匹配以 eth 开头的网卡。注意这个参数在 v0.11.0 里是--iface在老版本里叫--public-ip不要混用。5.5 与已有 CNI 冲突导致 flannel 配置被覆盖现象apply flannel 之后节点频繁 NotReadykubelet 日志出现failed to set up container network或 CNI 配置文件重复。原因节点上之前装过 Calico 或 Weave在/etc/cni/net.d/目录里残留了旧配置文件。CNI 插件按文件名顺序加载flannel 的配置文件名是10-flannel.conflist如果另一个插件是00-lo.conflist顺序靠前就会被优先加载。解决清理/etc/cni/net.d/下所有非 flannel 的配置文件保留10-flannel.conflist。如果不想删其它插件的文件改 flannel 配置名前缀为00-flannel.conflist抢第一优先级。5.6 麒麟 v10 或统信 UOS 上 flannel 起不来现象国产化系统上flannel Pod 一直是Init:Error日志里报mount失败或read-only file system。原因ARM64 的国产系统默认开启了 SELinux 或 AppArmor并且/run、/var/lib可能被安全策略限制写入。解决临时setenforce 0验证确认是 SELinux 后给 flannel 的容器加securityContext的seLinuxOptions: {type: spc_t}或者干脆在节点上关闭 SELinux。如果是只读文件系统问题检查/etc/fstab里/var/lib是否挂了只读选项改成可读写并重新挂载。6. 部署后的验证脚本与 flannel 参数微调集群网络 Ready 之后我一般会跑一组检查命令确认所有数据面路径都是通的而不是只看kubectl get nodes的状态。你可以把这套脚本固化下来以后每次加节点都用它做验收。#!/bin/bash # flannel 部署后健康检查 echo 1. Node 状态 kubectl get nodes -o wide echo 2. flannel Pod 状态 kubectl get pods -n kube-system -l appflannel -o wide echo 3. VXLAN 设备是否存在 ip link show flannel.1 echo 4. flannel 子网路由 ip route | grep flannel echo 5. 跨节点 Pod ping 测试 kubectl run ping-test --imagebusybox:1.36 --restartNever -- sleep 3600 kubectl exec ping-test -- ping -c 2 对端PodIP脚本里的ip link show flannel.1和ip route | grep flannel是验证 VXLAN 数据面的关键。flannel.1这个虚拟网卡存在说明 VXLAN 设备创建成功路由表里出现10.244.x.0/24 dev flannel.1说明子网路由已下发。如果这两项都正常但 Pod 仍不通问题基本出在主机防火墙或安全策略跟 flannel 本身没关系了。关于参数微调v0.11.0 在 ARM64 上最值得调的参数是 MTU 和 VNI。默认 VXLAN 的 MTU 是 1450如果你的物理网卡 MTU 是 1500这个值没问题。但如果你跑在云主机或虚拟化环境里物理网卡 MTU 可能只有 1450 或更小不调 MTU 的话大包会静默丢弃表现就是 ping 小包通、ping 带-s 1472的大包不通。修改方法是在 manifest 的args里加上- --ifaceeth0 - --vni4096vni参数指定 VXLAN Network Identifier默认是 1如果你在同一台物理机上跑了多套集群要改成不同的 VNI 防止互相串包。改完 MTU 或 VNI 之后需要滚动重启 flannel DaemonSetkubectl rollout restart daemonset kube-flannel-ds -n kube-system然后重新验证跨节点通信。这套从拆包、导镜像、apply 到验证的流程我已经在不同的 ARM64 环境上走过很多遍。整个过程里最耽误时间的往往不是 flannel 本身而是镜像导入的运行时选错和不看日志凭感觉猜。我的习惯是每一步操作后先跑验证命令确认当前步通过再进下一步别一次 apply 完再从头查。希望帮到你。本文还有配套的精品资源点击获取