Canal CNI插件是Calico与Flannel的组合，用于Kubernetes的CNI网络和NetworkPolicy，非阿里MySQL同步工具Canal Admin/Server；部署需匹配K8s版本、Pod CIDR，并正确应用RBAC与清单。
Canal 网络插件不是 Canal Admin/Server（那个 MySQL binlog 同步组件），而是 Calico + Flannel 的组合体，专用于提供 CNI 网络 + NetworkPolicy。部署错对象是新手最常踩的坑。
确认你真要的是 Canal CNI 插件，不是 Canal Admin/Server
如果你的目标是给 Kubernetes 集群加网络策略（NetworkPolicy）、控制 Pod 间通信、同时又希望底层网络用 Flannel（比如 VXLAN overlay），那才是 Canal CNI 的使用场景。而 Canal Admin/Server 是阿里开源的 MySQL 数据同步工具，两者同名但完全无关——连 GitHub 仓库、镜像源、YAML 文件都不同。
常见误判现象：
- 搜索 “k8s canal deploy” 出来的教程混着两类内容，一不留神就
kubectl apply -f canal-admin.yaml了，结果发现没 IP 分配、Pod 启不来 - 看到
canal.yaml文件里有flannel和calico字样，就默认是“网络插件”，其实 Canal Admin 的 Helm Chart 里也有同名配置项 - 在
kube-systemnamespace 看到canal相关 Pod，但kubectl get pods -n kube-system显示canal-node未就绪，其实是没装对版本或 CIDR 冲突
必须匹配 Kubernetes 版本和 Pod CIDR
Canal CNI 的 YAML 清单硬编码了默认 Pod 网段（10.244.0.0/16），且要求 kube-controller-manager 启动参数中已设置 --cluster-cidr=10.244.0.0/16 和 --allocate-node-cidrs=true。不一致会导致 Node 上的 canal-node 容器反复 CrashLoopBackOff。
检查方法：
- 运行
kubectl get nodes -o wide，看各 Node 的INTERNAL-IP是否能互通；如果不能，大概率是 CIDR 没对上 - 查
kube-controller-manager参数：ps aux | grep cluster-cidr（在 Master 节点执行） - 官方清单只支持特定 k8s 版本：v3.1 ~ v3.21 对应 k8s 1.10 ~ 1.25；2026 年主流集群多为 k8s 1.26+，此时应改用
calico单独部署并启用Calico CNI + NetworkPolicy，因为 Canal 官方已停止维护新版本适配
RBAC 和 DaemonSet 必须一步到位
Canal 依赖 RBAC 权限启动 canal-node DaemonSet，并在每个 Node 上注入 CNI 配置。漏掉 RBAC 或顺序错误，会导致 canal-node 因权限不足无法写入 /etc/cni/net.d/ 或调用 kube-apiserver。
正确执行顺序：
- 先应用 RBAC：
kubectl apply -f https://docs.projectcalico.org/v3.21/manifests/canal-rbac.yaml - 再应用主清单：
kubectl apply -f https://docs.projectcalico.org/v3.21/manifests/canal.yaml - 不要手动修改
canal.yaml中的etcdEndpoints—— Canal CNI 默认使用 Kubernetes API Server 作为后端，不依赖独立 etcd - 验证是否生效：
ls /etc/cni/net.d/在任意 Node 上应看到10-canal.conflist；kubectl get pods -n kube-system -l k8s-app=canal-node应全部 Running
NetworkPolicy 生效前必须确认 CNI 已接管
即使 canal-node Pod 全部 Running，NetworkPolicy 也可能不生效——因为 kubelet 还没加载 Canal 的 CNI 配置，或者旧的 Flannel 配置残留。
关键检查点：
-
cat /var/lib/kubelet/config.yaml | grep cni，确认cni-bin-dir和cni-conf-dir指向正确路径（通常是/opt/cni/bin和/etc/cni/net.d） - 删掉旧的 CNI 配置：
rm -f /etc/cni/net.d/*.conf /etc/cni/net.d/*.conflist，然后重启 kubelet（systemctl restart kubelet） - 一个最小验证策略：
apiVersion: networking.k8s.io/v1+podSelector: {}+policyTypes: [Ingress]，应用后，该 namespace 下所有 Pod 将拒绝任何入站流量（包括 ClusterIP Service 访问），这是最直接的生效证明
真正容易被忽略的是：Canal CNI 不支持 k8s 1.26+ 的 EndpointSlice 默认启用模式，若集群启用了 EndpointSlice 特性门控，NetworkPolicy 对 Service 的 Ingress 控制可能失效——这时别硬扛，换 Calico 原生方案更省事。
