使用Tigera Operator在Kubernetes中部署Calico的实践指南
1. 为什么选择Tigera Operator部署Calico
在Kubernetes集群中，网络插件的选择直接影响着整个集群的性能和稳定性。Calico作为目前最流行的CNI插件之一，以其高性能、灵活的网络策略和跨云兼容性著称。而Tigera Operator则是Calico官方推荐的部署方式，相比传统的手动YAML部署，它能带来三大核心优势：
第一是生命周期管理自动化。Operator会持续监控Calico组件的健康状态，自动处理版本升级、配置变更等复杂操作。我去年在升级一个生产集群时，就深刻体会到Operator的价值——原本需要手动协调多个组件的升级过程，现在只需要修改CRD配置就能自动完成。
第二是配置声明化。所有参数都通过Kubernetes原生资源对象定义，比如下面这个典型的Installation CRD配置：
apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: registry: quay.io calicoNetwork: ipPools: - cidr: 10.244.0.0/16 encapsulation: VXLAN natOutgoing: Enabled第三是故障自愈能力。当Calico组件异常崩溃时，Operator会自动重建相关Pod。这个特性在我们某个测试环境中防止了至少三次网络中断事故。
2. 部署前的环境准备
2.1 版本兼容性检查
在开始部署前，首先要确认版本矩阵的兼容性。根据我的经验，这是最容易踩坑的环节。以下是经过验证的常见版本组合：
| Kubernetes版本 | Calico版本 | Tigera Operator版本 |
|---|---|---|
| 1.28+ | 3.26+ | v1.28+ |
| 1.25-1.27 | 3.24 | v1.25 |
| 1.22-1.24 | 3.21 | v1.22 |
检查集群版本的方法很简单：
kubectl version --short | grep Server2.2 网络规划建议
IP地址规划需要特别注意两个参数：
- Pod CIDR：默认10.244.0.0/16，需要确保不与现有网络冲突
- Service CIDR：通过
kubeadm config view查看默认配置
在私有化部署场景中，我推荐使用VXLAN封装模式而非默认的IPIP，因为：
- 更好的兼容性，能穿透大多数企业防火墙
- 支持跨子网通信，适合多机房部署
- 性能损耗在可接受范围内（实测约5-8%）
3. 分步部署指南
3.1 安装Tigera Operator
首先部署Operator的核心组件：
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.31.3/manifests/tigera-operator.yaml这里有个实际经验：如果网络环境特殊，可以先将YAML文件下载到本地，替换镜像仓库地址。比如我们内网环境是这样处理的：
wget https://raw.githubusercontent.com/projectcalico/calico/v3.31.3/manifests/tigera-operator.yaml sed -i 's|docker.io|registry.internal.com|g' tigera-operator.yaml kubectl create -f tigera-operator.yaml3.2 配置Calico核心参数
创建custom-resources.yaml文件时，这几个参数需要特别关注：
apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: ipPools: - blockSize: 24 cidr: 10.244.0.0/16 encapsulation: VXLANCrossSubnet natOutgoing: Enabled nodeAddressAutodetection: interface: "eth.*|en.*"关键配置说明：
blockSize: 24：为每个节点分配/24的子网，适合中型集群encapsulation: VXLANCrossSubnet：混合模式，同子网用BGP，跨子网用VXLANnodeAddressAutodetection：避免自动检测到错误的网络接口
4. 高级配置技巧
4.1 自定义镜像仓库
在企业内网环境中，通常需要替换默认的镜像仓库。这是我常用的完整配置示例：
spec: imageRegistry: registry.internal.com imagePath: calico variant: Calico componentResources: - componentName: node resourceRequirements: limits: cpu: "2" memory: 2Gi requests: cpu: "500m" memory: 512Mi4.2 网络策略调优
Calico的网络策略性能直接影响集群吞吐量，通过调整Felix配置可以提升性能：
apiVersion: operator.tigera.io/v1 kind: FelixConfiguration metadata: name: default spec: bpfEnabled: true logSeverityScreen: Info prometheusMetricsEnabled: true5. 运维与故障排查
5.1 状态监控方法
部署完成后，用这个命令检查所有组件状态：
watch kubectl get tigerastatus健康状态应该类似这样：
NAME AVAILABLE PROGRESSING DEGRADED apiserver True False False calico True False False ippools True False False5.2 常见问题处理
节点NotReady问题：
- 检查calico-node日志：
kubectl logs -n calico-system -l k8s-app=calico-node- 常见错误是IP地址检测失败，可以显式指定网卡：
nodeAddressAutodetection: interface: "eth0"网络策略不生效：
- 确认Felix组件没有报错
- 检查NetworkPolicy的selector是否匹配Pod标签
- 使用calicoctl工具诊断策略规则：
calicoctl get networkPolicy -o wide6. 版本升级策略
Operator模式下升级非常安全，推荐采用灰度升级：
- 先升级Operator：
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.31.3/manifests/tigera-operator.yaml- 然后修改Installation CRD中的版本号
- 监控升级过程：
kubectl get tigerastatus升级过程中Operator会自动处理CRD迁移、数据平面更新等复杂操作，通常不需要人工干预。但建议在非业务高峰期进行，并准备好回滚方案。