Calico在多网卡节点上默认first-found策略几乎必然选错网卡，因其依赖内核驱动加载顺序；可靠配置应使用interface=ens33或cidr=172.16.15.0/24，避免使用first-found。
Calico 在多网卡节点上默认会选错网卡，不是“可能”，而是几乎必然——它用 first-found 策略遍历接口，顺序由内核驱动加载时间决定，每次重启都可能变。你看到 Pod 间通信时断时续、tunl0 隧道走不通、BGP 对等体反复断连，八成是这个原因。
calico-node 的 IP_AUTODETECTION_METHOD 怎么设才可靠
关键不在“能不能设”，而在“设什么值才不翻车”。Calico 提供了四种检测方式，但只有两个真正可控：
-
interface=ens33：硬指定网卡名，最直接。但前提是所有节点网卡命名一致（比如都用ens33），否则要配合 NodeLabel + DaemonSet patch 分开管理 -
cidr=172.16.15.0/24：按 CIDR 匹配，推荐用于生产。它会扫描所有接口的 IP，选第一个落在该子网内的地址，和网卡名解耦，适配不同厂商命名习惯（eth0/enp0s3/ens1f0都能识别） -
can-reach=10.10.10.1：探测可达性，适合跨机房或带跳数的场景，但依赖目标地址始终在线，CI/CD 测试环境容易误判 -
first-found：别用。文档里写着“for testing only”，但很多人上线还留着它
设置方式统一加在 calico-node DaemonSet 的环境变量里：
env: - name: IP_AUTODETECTION_METHOD value: "cidr=172.16.15.0/24"
kubelet 的 --node-ip 和 Calico 冲突吗
不冲突，但必须对齐。kubelet 的 --node-ip 只影响 API Server 记录的 Node.Status.Addresses[0].address，而 Calico 默认会读这个字段作为自己的节点 IP —— 除非你显式设置了 IP_AUTODETECTION_METHOD。
常见错误是：kubelet 指定了 --node-ip=172.16.15.12，但 Calico 还在用 first-found，结果选了另一张网卡上的 192.168.1.100，导致 BGP 建连失败或路由下一跳错乱。
正确做法是两者统一指向业务网段：
- 修改
/var/lib/kubelet/config.yaml或 systemd service 文件，确保nodeIP: 172.16.15.12 - 同时在
calico-node中设置IP_AUTODETECTION_METHOD=cidr=172.16.15.0/24 - 验证：
kubectl get node <node> -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}'和kubectl exec -it -n kube-system calico-node-xxxxx -- ip addr show tunl0 | grep 'inet '应该返回同一网段 IP
为什么改完配置后 calico-node 还没生效
因为 calico-node Pod 不会自动 reload 环境变量——它只在启动时读一次。你改了 DaemonSet，必须强制滚动更新：
- 先删掉旧 Pod：
kubectl delete pod -n kube-system -l k8s-app=calico-node - 或者加个无害 annotation 触发重建：
kubectl patch ds calico-node -n kube-system -p '{"spec":{"template":{"metadata":{"annotations":{"timestamp":"'"$(date +%s)"'"}}}}}' - 检查日志确认新策略被识别：
kubectl logs -n kube-system -l k8s-app=calico-node | grep "Using autodetection method"，应输出类似Using autodetection method: cidr=172.16.15.0/24
最容易忽略的是：某些发行版（如 RHEL/CentOS）的 calicoctl 版本太老，calicoctl get nodes -o wide 显示的 IP 仍是旧值，这不是配置没生效，而是缓存未刷新；以 tunl0 接口 IP 和 BGP peer 状态为准。
