这个系列走到第6篇前面控制平面组件已经全部就位etcd集群也稳定了工作节点干净利落地加了进来。结果你高高兴兴apply一个测试应用Pod们却齐刷刷卡在ContainerCreatingdescribe一看报错多半是network plugin not ready或者CNI配置没生效。对这就是网络插件这道坎。k8s高可用环境部署到了这个阶段Flannel和Calico几乎是最常被摆上桌的两个候选。很多朋友在这儿纠结的其实不是哪个更好而是我先装哪个——因为装错或者中途切换最轻也要重建一遍节点上的容器网络重一点的会搞出Pod网段错乱整个集群业务流量全部异常。这篇文章我就以自己实际搭过多套高可用集群的经验为底子把这两个网络插件从原理、选型、部署到切换、排障完整过一遍。不堆概念直接给能抄的命令和能避的坑。1. 网络栈为什么是控制平面就绪后最难啃的骨头1.1 前面的集群还缺哪块拼图到这一步我们的控制平面是什么状态apiserver、controller-manager、scheduler分别跑在多个master节点上etcd有自己的TLS和集群成员关系负载均衡器把请求分发到多个apiserver任何一个master挂掉集群的大脑仍然能工作。这就是高可用环境第一个层面的完成。但是Kubernetes对外承诺三件事节点和Pod能通信、Pod和Pod能跨节点通信、Pod和Service能通信。前一件事靠kubelet和容器运行时完成后两件事全部依赖CNI插件。换句话说控制平面是大脑网络插件是血管血管没接好大脑再正常业务也跑不起来。高可用集群里网络插件还多一层特殊性它不是跑在某个master上的单体进程而是以DaemonSet形式在每个节点上都跑一份。所以网络插件本身也必须具备单点故障不影响整体的形态。Flannel和Calico都能满足这个基本要求差异主要体现在封装方式、路由模式、策略能力和排障复杂度上。1.2 为什么偏偏要在Flannel和Calico之间纠结这个问题我在多个交流场合被问过。我的回答是因为这两个方案代表了两种完全不同的设计哲学。Flannel的定位非常纯粹它只解决一个核心问题让Pod IP在跨节点时能通。实现方式也走极简路线通过etcd或者直接走kubernetes的subnet管理接口来给每个节点分配一个子网再用VXLAN隧道或者host-gw路由把不同节点的Pod网段打通。整个Flannel只有一个daemon配置就是一个文件加几个参数出问题基本靠眼神就能排查。Calico则从一开始就没打算只做一个隧道工具。它把网络看成三层路由问题用BGP让每个节点都知道Pod网段的路由该往哪走再用Felix组件把iptables规则落实到每个Pod的进出流量上。这意味着Calico天然支持NetworkPolicy、命名空间隔离、甚至HostEndpoint保护等更接近防火墙语义的能力代价是组件更多、配置更复杂、排障链路更长。如果非要打个比方Flannel像在几间办公室之间凿了几扇门大家都能串门Calico像在每个办公室门口装了门禁考勤系统进出谁记录得清清楚楚。你选哪个取决于你的楼里到底需不需要门禁而不是门禁系统听起来更高级。2. 原理层面数据包从节点A到节点B到底怎么走2.1 Flannel的VXLAN在三层网络上搭一条隧道先看Flannel最常用的VXLAN模式。假设Pod网段是10.244.0.0/16Flannel会把它切成多个/24子网节点A分到10.244.1.0/24节点B分到10.244.2.0/24。节点A上一个IP为10.244.1.10的Pod要访问节点B上10.244.2.11的Pod数据包是这样走的Pod内的包先到达节点A上的cni0/veth网桥Flannel发现目标网段不在本机于是交给VTEP设备一个VXLAN虚拟网卡。VTEP把整个Pod以太网帧封装进一个UDP包里UDP目的端口是4789外层IP头的源地址是节点A的物理IP目的地址是节点B的物理IP。这个外层包走普通的三层网络到达节点B节点B的VTEP解封装把原始帧交给本地的网桥最终送到目标Pod。隧道模式最大的优点是不依赖底层网络结构。只要节点之间三层可达、UDP 4789端口能通Pod就能跨节点通信不管你们中间隔了几台交换机、有没有VLAN。代价是每包都多了一层封装MTU会从物理网卡的1500降到1450吞吐也有一定损耗。Flannel另一个后端是host-gw。它不封装任何包直接在每个节点上写路由节点A上写一条10.244.2.0/24 via 节点B物理IP的路由。Pod的包从网桥出来后直接以原始格式发给节点B的物理IP底层网络就像转发普通内网包一样把它送过去。host-gw性能接近线速但它要求所有节点在同一个二层网络里如果在数据中心跨网段场景路由中间设备可能不认识这些Pod网段就玩不转了。2.2 Calico的BGP/IPIP三层路由哲学的极致Calico默认推荐的纯BGP模式思路完全不同。它不建隧道、不封包而是让每个节点上运行的BIRD组件通过BGP协议把自己负责的Pod网段路由广播给邻居节点。节点A用BGP告诉节点B10.244.1.0/24这个网段下一跳是我节点A你往这个网段发包直接扔给我就行。节点B收到后写进内核路由表从此两个节点的Pod包就像普通三层路由一样在物理网络上直接转发。BGP模式性能好、排障直观在裸金属网络里能达到接近物理网络的转发速率。但它有一个硬性前提节点之间的物理网络必须允许这些私有的Pod网段路由传递。如果你的交换机做了严格的路由过滤或者云平台不允许你控制路由表纯BGP根本跑不起来。所以Calico才保留了IPIP模式作为兜底。IPIP把Pod报文再套一层IP头内层是Pod IP外层是节点物理IP跑在IP协议号4上。它的语义和VXLAN隧道类似只不过封装更轻MTU从1500降到1480。再晚一些的版本还支持VXLAN封装和Flannel的隧道体验接近。这一点很关键Calico的默认体验和上限能力是分开的你用IPIP模式时它长得像Flannel你切到BGP模式时它才露出真面目。Calico架构里还有一个Felix组件负责编排iptables规则。每个Pod的cali虚拟网卡、允许与禁止的流量策略、流出时的SNAT规则全由Felix生成和下发。这也是Calico能支持NetworkPolicy的底层原因。2.3 原理差异带来的性能与运维差异把两种方案的关键差异摆在一起看对比项FlannelCalico默认封装VXLANIPIP可切VXLAN/BGP封装开销50字节IPIP 20字节容器MTU1450IPIP 1480 / BGP 1500NetworkPolicy不支持支持且能力丰富跨子网能力VXLAN强host-gw弱BGP需规划IPIP强排障复杂度低路由表fdb中高需要calicoctl和节点日志每节点进程单Daemon多容器FelixBIRD等性能上最大的误解是Flannel一定比Calico慢。实测在VXLAN对VXLAN、IPIP对IPIP的同级对比下二者吞吐差异通常在个位数百分比以内而Flannel的host-gw和Calico的BGP在裸金属二层网络里都能跑到接近物理线速。对小规模高可用集群来说性能从来不是二选一的决定因素。运维上的差异倒是非常明显。Flannel排障只需要看节点路由表、fdb转发表和flannel容器日志Calico则多出一套etcd/crd存储、BIRD会话状态、felix规则生成链路。我见过不少团队装Calico时很爽快出问题时对着calico-node容器几十行日志发懵。这个隐性成本一定要在选型时算进去。3. 高可用集群里的实际选型规模、策略与排障成本3.1 先问自己集群到底会有多大很多人选型时爱看网上的性能评测但忽略了自己集群的真实规模。我在某生产环境维护过一套三十多个节点的集群从Flannel的VXLAN切到Calico的BGP后业务上几乎没有感知。为什么因为业务根本不是网络密集型应用Pod之间的流量一小部分走Service负载均衡大部分是HTTP短连接瓶颈根本不在overlay封装上。反过来我也见过一套只有九个节点的集群因为用了纯BGP模式每次交换机路由策略调整都要跟着改一遍BGP配置排障成本远超它带来的性能收益。所以给高可用集群选网络插件第一个要问的是规模上限五十个节点以内、业务以Web服务为主Flannel完全够用一百个节点以上、要跑分布式存储或大数据混部Calico的BGP和策略能力才值得付出额外的运维复杂度。3.2 NetworkPolicy不是可有可无的功能如果团队有明确的安全合规要求比如多租户隔离、默认拒绝策略、只允许指定ServiceAccount访问指定命名空间那就不用纠结了直接Calico。这不是Flannel的缺点而是它压根没有这个设计目标。Calico的NetworkPolicy可以做得很细按命名空间、Pod标签、端口范围、甚至根据来源IP做限制。更进阶的GlobalNetworkPolicy还能给节点本身下发主机端点策略相当于给宿主机也装了防火墙规则。对于高可用生产集群如果之前安全审计要求你提供Pod间访问控制表Calico能直接交一份由策略模板渲染出的清单Flannel则只能靠网络管理员手工梳理。不过也得提醒一句策略能力越强误写策略把自己锁外面的风险越大。我见过因为一条默认拒绝策略没放行kube-system的流量整个集群DNS解析全部超时的案例。启用NetworkPolicy前先在测试集群里把放行规则完整验证一遍再拿到生产。3.3 出问题的时候谁让你少熬夜高可用集群的网络问题往往不是完全不通更多是某个节点上的Pod访问另一个Pod偶尔超时。这种问题在Flannel环境下排查思路非常线性查VXLAN隧道是否建立、查目标节点的fdb表是否过期、查物理网络UDP 4789是否被安全组阻断。每一步都有明确的命令和可见的输出非常适合值班同学快速定位。Calico环境则多出好几个信息源BIRD的BGP会话状态、calico/node的Felix日志、calicoctl的节点状态、以及CRD里存放的IPPool配置。权限稍微复杂一点很多时候你需要反复确认规则到底下发了没有。但这是坏事吗未必。Calico的日志信息量大配合calicoctl node status和kubectl logs -n calico-system往往比Flannel的什么都看不到只能靠猜更能高效定位复杂问题。有一次我维护的某项目环境出现Pod间歇性不通Flannel模式下排查了两小时最后发现是交换机MAC表抖动VXLAN外层包被丢弃。如果当时用的是Calico并开了BGP丢包的路径会短很多判断起来也更快。这种隐性差异只有踩过坑才体会得到。4. 最快的Flannel落地路径从apply到数据面自检4.1 部署前先核对三件事Flannel部署本身只需一条kubectl apply -f kube-flannel.yml但在高可用环境里我强烈建议先花五分钟做三个核对否则大概率要返工。第一确认kube-controller-manager的--cluster-cidr参数它必须和Flannel的Pod网段一致。比如kubeadm或二进制方式启动时指定了--cluster-cidr10.244.0.0/16Flannel的net-conf.json里Network字段就必须是10.244.0.0/16。不一致的直接后果是节点分配的Pod CIDR和Flannel规划的对不上Pod起来后IP完全错乱。可以用kubectl get pods -n kube-system找到controller-manager对应的静态Pod或者直接看启动配置文件里的参数。第二确认每个节点有几块网卡以及Kubernetes的Node InternalIP用的是哪块。Flannel默认会选默认路由对应的网卡建立隧道但如果你的集群管理网和业务网是分开的默认路由往往落在管理网上Pod流量就会跑上管理网段。这种情况需要给Flannel的DaemonSet显式加--ifaceeth0替换成你实际业务网卡名。这个参数在配置文件里改不同节点的网卡名如果不一样就得用正则或者环境变量做映射。第三确认kubelet的CNI配置目录没有被其他插件污染。Flannel安装时会在/etc/cni/net.d/下生成10-flannel.conflist如果之前残留着其他CNI配置容器运行时按字典序选择配置可能会出现装了Flannel但Pod用的还是老配置的诡异现象。安装前把/etc/cni/net.d/清干净只保留空目录。4.2 kube-flannel.yml里值得手工改的地方从官方发布页拿到的kube-flannel.yml通常包含ConfigMap和DaemonSet两部分。新手最容易忽略的是ConfigMap里的net-conf.jsonkind: ConfigMap apiVersion: v1 metadata: name: kube-flannel-cfg namespace: kube-system data: net-conf.json: | { Network: 10.244.0.0/16, Backend: { Type: vxlan } }Network字段要和前面核对过的cluster-cidr严格一致。Backend.Type默认是vxlan如果你的所有节点确定在同一个二层网络里并且追求性能可以改成host-gw但我不建议高可用集群一上来就换先把vxlan跑通再评估要不要优化。DaemonSet的容器args里通常有一行--iface相关的配置如果你的节点网卡环境比较复杂需要改成这样containers: - name: kube-flannel image: docker.io/flannel/flannel:v0.24.2 args: - --ip-masq - --kube-subnet-mgr - --ifaceeth0另外要提醒一点如果你的集群节点无法访问外网镜像仓库提前把flannel镜像、pause镜像以及CNI插件二进制拉好或配置好内网镜像仓库。高可用环境里很多网络插件装不上的报错排到最后都是镜像拉取超时跟Flannel本身一点关系没有。4.3 数据面验证两个Pod跨节点互通的完整流程Flannel部署完成后先看DaemonSet是否在每个节点上都Runningkubectl -n kube-system get pods -o wide | grep flannel接着做一个双副本Deployment用nodeSelector把两个副本分别固定到不同节点上kubectl apply -f - EOF apiVersion: apps/v1 kind: Deployment metadata: name: nettest spec: replicas: 2 selector: matchLabels: app: nettest template: metadata: labels: app: nettest spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: nettest topologyKey: kubernetes.io/hostname containers: - name: nettest image: busybox:1.36 command: [sleep, 3600] EOF然后确认两个Pod落点在不同节点做三件事从Pod A ping Pod B的IP小包能通说明VXLAN隧道和路由没问题。用ping -M do -s 1422测试接近MTU上限的包如果大包不通小包通几乎可以断定是MTU问题。进Pod A执行route -n和ip addr show eth0确认Pod内默认网段走到了cni0/veth上。这套验证做完Flannel的数据面才算真正通了。不要只看Pod Running就宣布成功Pod Running只代表CNI配置生效不代表跨节点流量正常。5. 换用Calico从Flannel平滑迁移的完整序列5.1 Calico部署时必改的三个配置如果最终决定上Calico先明确一件事官方calico.yaml默认配置是为通用场景准备的直接apply能跑但大概率不是最优。我每次必改三个地方。第一是Pod网段。Calico的IPPool默认CIDR是192.168.0.0/16和Kubernetes的cluster-cidr没有任何关系必须手动改成你的Pod网段。可以在calico.yaml的环境变量里设置env: - name: CALICO_IPV4POOL_CIDR value: 10.244.0.0/16第二是网卡自动发现。多网卡环境下一定要设置AUTODETECTION_METHOD否则Calico可能选择错误的网卡作为BGP会话和IPIP隧道的出口env: - name: AUTODETECTION_METHOD value: interfaceeth.*第三是决定跑IPIP还是纯BGP。可以用环境变量控制env: - name: CALICO_IPV4POOL_IPIP value: NeverNever表示IPPool不启用IPIP封装后面全靠BGP路由转发。如果你的环境是物理机且节点间路由可控这是最优配置如果是云主机或者网络设备不好动建议保持默认的Always让IPIP封装兜底先把业务跑起来。5.2 从Flannel摘干净的删除顺序从Flannel切到Calico最容易出事的不是装Calico而是旧Flannel没清干净。两个CNI配置共存时容器运行时按字典序选择一个执行结果就是有些节点用Calico、有些节点还在用FlannelPod互相访问全靠缘分。我的删除顺序是固定一套先删Flannel的DaemonSet和ConfigMapkubectl delete -f kube-flannel.yml逐个节点清理残留文件。每个节点都要执行rm -f /etc/cni/net.d/10-flannel.conflist rm -rf /var/lib/cni/flannel rm -rf /var/lib/flannel/etc/cni/net.d/目录最后应该只剩下Calico生成的配置通常叫10-calico.conflist或者05-cali.conf。重启节点上的容器运行时和kubelet。存量Pod在CNI配置切换后不会自动重连需要让它们重建systemctl restart containerd systemctl restart kubelet把存量Pod全部重建。最省事的方式是滚动重启已有Deployment或者对节点做一次drain和uncordon。如果维护窗口允许直接把节点依次重启一遍是最干净的虽然粗暴但能确保所有Pod都在新的CNI下重新拉起。验证所有节点上Flannel的Pod已消失、Calico的Pod全部Running再用第4章的方法重跑一遍跨节点连通性测试。这里要特别强调第2步我见过不少案例Flannel的DaemonSet已经删了但节点上残留的conflist文件还在容器运行时继续按旧配置创建网络命名空间Pod起来后网卡是flannel.1而不是cali开头的接口。这种半残留状态比完全不装更让人头疼。5.3 纯BGP模式下必须确认的物理网络前提切纯BGP模式前先问自己三个问题节点之间的物理路由允不允许多播一条10.244.0.0/16的路由交换机或者云平台的安全策略有没有放行TCP 179端口节点数量超过几十个的话默认的BGP全互联会不会撑不住默认配置下Calico所有节点处于同一个AS内每对节点之间都会建立BGP会话形成全互联。节点数少无所谓节点数超过五十BGP会话数量按平方增长会话状态抖动会非常频繁。规模大了要用路由反射器RR收敛连接数但这需要额外部署BGP配置不是默认行为。如果你的集群在云上、跑在VPC里、还不允许自定义路由表那我建议放弃纯BGP直接用IPIP或者VXLAN模式。云环境的底层网络对BGP的开放程度普遍不友好强行启用BGP的结果往往是节点间的路由经常断然后你能做的只有调日志。高可用集群最怕这种时通时不通的状态。6. 跑起来不算完日常运维与三个经典坑6.1 MTU问题症状隐蔽的大包不通MTU问题是我在所有网络插件环境里遇到最多、也最坑的问题。症状非常有迷惑性SSH能连、普通的ping能通、小流量HTTP请求正常但一传大文件就卡住或者数据库备份总是超时。很多人会怀疑是带宽或者应用层问题折腾半天才发现是MTU。VXLAN模式下容器MTU是物理网卡MTU减50字节物理网卡1500时容器是1450。如果底层物理网络实际MTU只有1400比如某些虚拟化平台默认把虚机网卡设为1400那VXLAN包在物理链路上就会超过MTU被丢弃。小包不受影响因为封装后仍然小于1400大包直接卡死。定位方法很简单在Pod里执行ping -M do -s 1422 对端PodIP-M do禁止分片1422是1450 MTU下能通过的最大payload长度。如果1422通了、再加一两个字节就不通说明问题就在MTU上。接着检查节点物理网卡的MTU和VXLAN设备的MTUip link show | grep -E eth0|flannel|cali如果底层物理网络MTU真的小于1500最彻底的修复是调整物理网卡MTU。Calico还可以在IPPool里单独指定mtu字段。Flannel的VXLAN MTU会自动跟随物理网卡计算一般不建议手动改改了大概率更乱。6.2 多网卡机器上的iface选择与Pod漂移高可用集群的节点服务器通常不止一块网卡常见配置是管理网卡业务网卡或者eth0走外网、eth1走存储。网络插件一旦选错网卡表面上Pod照样能创建但流量全走了错误路径。我接手过一套环境就是这样所有Pod跨节点能通但访问存储服务时延迟高得离谱。查到最后Flannel把VXLAN隧道建在了管理网卡上管理交换机带宽只有百兆业务量一大就开始丢包。节点上Pod再健康也救不了物理路径不对。这类问题的排查思路是先确认节点上default route指向哪张网卡再确认Kubernetes的Node InternalIP使用哪张网卡的地址。kubectl get nodes -o wide能看到InternalIP。如果两者不一致必须给网络插件显式指定网卡Flannel加--ifaceeth1Calico设AUTODETECTION_METHOD: interfaceeth1。还有一种更隐蔽的情况节点重启后网卡名称变化比如从eth0变成enp1s0网络插件按旧名字找不到网卡Pod调度到该节点后网络一直处于not-ready状态。这时最好用稳定的匹配规则比如按PCI地址绑定或者用interfaceeth.*这类正则兜底。6.3 Pod A访问Pod B在不同节点的快速排查链路网络不通时我有一套固定的排查顺序从最外到最内每步都能快速收窄范围kubectl get pods -o wide确认两个Pod各自落在哪个节点、Pod IP是什么。如果Pod都没Running先解决调度问题。在Pod A所在节点上执行ip route | grep PodB网段看节点内核知不知道去PodB网段的路由。不知道问题在路由同步Flannel看隧道状态Calico看BGP会话。进Pod A执行ip addr和route -n确认Pod内有IP、有默认路由网关通常指向本机网桥。在节点上直接ping PodB的IP。节点到PodB能通说明三层路径OK问题在PodA这侧的netns配置或者出容器后的封装上。在PodA内ping PodB如果节点能通PodA不能通问题在PodA的veth或默认路由。如果节点上也不通看VXLAN/UDP 4789或IPIP协议是否被防火墙阻挡。在PodA所在节点抓包tcpdump -i any icmp看有没有发出封装包再到PodB所在节点tcpdump -i any udp port 4789或tcpdump -i any proto 4看有没有收到。收不到就是中间链路被丢一般就是安全组或交换机策略。检查网络插件容器日志和系统日志Flannel看kube-flannel日志Calico同时看felix和bird日志。这套链路走下来95%的问题能定位到具体环节。剩下5%基本是底层网络设备的诡异行为比如交换机MAC表老化、链路聚合哈希不均这种只能靠物理网络团队配合了。说实话每次看到有人上来就重装网络插件我都替他心疼。重装只是刷新了配置并不能解决物理链路或者网卡选择问题。先按链路收窄往往半天之内就能定位。6.4 踩过几次之后的个人选择如果你现在问我新集群高可用部署到这个阶段Flannel和Calico怎么选我给的默认答案大概率是Calico跑IPIP模式然后把BGP和策略能力留到以后真正需要时再开。理由不是Calico比Flannel快多少而是它给了更多后路未来要做NetworkPolicy不用换插件要上BGP提升性能不用重搭集群。Flannel简单、干净、排障轻松适合长期不折腾的稳定集群Calico功能冗余、组件多适合对安全、规模和排障工具链有更高要求的场景。最后分享一个小习惯无论选哪个网络插件我都会在集群维护文档里记录三样东西——Pod网段和Service网段的具体CIDR、节点物理网卡的MTU和命名规则、网络插件版本的升级记录。这三样东西看起来基础却能在半年后网络出问题时帮你省下好几个小时的排查时间。网络这层不像应用层有那么多日志可以看文档里的当初为什么这么配往往比任何监控面板都值钱。