Calico-kube-controller持续Pending状态排查及替代CNI咨询

一、Calico-Controller 处于Pending状态的排查方向 #

你的calico-kube-controllers Pod处于Pending状态，说明该Pod还未被调度到任何节点上，而非启动后崩溃，优先从调度相关维度排查：

1. 查看Pod调度事件（最关键步骤） #

执行以下命令获取Pod的详细调度日志，Events字段会直接说明调度失败原因：

kubectl describe pod calico-kube-controllers-555bc4b957-z4q2p -n kube-system

常见报错场景：

• 0/1 nodes are available: 1 node(s) didn't match node selector.：Pod的节点选择器与现有节点标签不匹配
• Insufficient memory/CPU：节点剩余资源不足以分配给Pod
• 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.：节点存在污点，Pod未配置对应容忍度

2. 检查节点资源状态 #

确认集群节点的CPU、内存是否有剩余：

# 查看节点资源使用情况
kubectl top node
# 查看节点详细资源分配
kubectl describe node ubuntu-18-extssd

重点关注Allocatable和Allocated resources部分，若已分配资源接近上限，需清理节点上的冗余Pod或扩容节点。

3. 验证Calico控制器的Deployment配置 #

检查calico-kube-controllers的调度约束是否合理：

kubectl get deployment calico-kube-controllers -n kube-system -o yaml

重点核对：

• spec.template.spec.nodeSelector：确保节点存在该标签，比如部分Calico配置会要求节点带有kubernetes.io/os=linux标签
• spec.template.spec.tolerations：若节点是master节点，需确认Pod配置了容忍node-role.kubernetes.io/master污点的规则
• spec.template.spec.resources：requests/limits设置是否过高，导致节点无法满足

4. 确认版本兼容性 #

Kubernetes 1.24.3需要搭配Calico 3.22及以上版本，若你安装的Calico版本过低，会存在调度或功能兼容性问题，可查看Calico版本：

kubectl get daemonset calico-node -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}'

二、稳定的替代CNI方案 #

若你认为Calico维护成本较高，可考虑以下生产环境常用的稳定CNI：

• Flannel：轻量极简的CNI，部署无依赖，资源占用极低，适合中小规模集群或对网络功能要求简单的场景，稳定性经过大量验证。
• Cilium：基于eBPF的高性能CNI，支持网络策略、透明负载均衡、可观测性等高级功能，性能远超传统CNI，适合高性能、复杂网络需求的生产集群。
• Weave Net：去中心化架构，自动节点发现，支持加密跨主机通信，部署无需额外依赖，适合跨机房或动态节点的集群场景。
• kube-ovn：基于OVN的企业级CNI，支持子网划分、QoS、负载均衡、多租户等丰富功能，适合需要复杂网络规划的集群。

内容的提问来源于stack exchange，提问作者Dean Schulze