📚 课程目录第3章 Calico 部署模式选型

3. Calico 部署模式选型

Calico 在 Kubernetes 中并不是只有一种“标准装法”。同一个 Calico 版本，官方至少提供三条主流安装路径：直接应用静态 manifest、通过 Tigera Operator 声明式管理、以及使用 Helm Chart 渲染安装。三者在最终落地的数据面组件上高度一致，但在升级方式、配置来源、生命周期管理和可观测性上差异明显。选型的本质，是判断“谁来管理 Calico 的生命周期”以及“配置以什么形式被持久化”。

三种安装方式的本质差异

Manifest 方式是最原始也最透明的方式。执行 kubectl apply -f calico.yaml 后，Calico 的 DaemonSet、Deployment、CRD、RBAC、ConfigMap 全部以静态 YAML 形式进入集群。它的优点是零依赖、可离线、便于审计；缺点是升级需要手动替换镜像与清单，且 Calico 自身的 Installation、FelixConfiguration 等 CR 不会被 Operator 接管，配置漂移只能靠人工比对。

Operator 方式引入了一个常驻的 tigera-operator，它监听 Installation 与 APIServer 等自定义资源，并据此生成和调和底层工作负载。用户不再直接编辑 DaemonSet，而是修改 Installation.spec 中的 calicoNetwork、ipPools、encapsulation 等字段。Operator 会持续把实际状态拉回期望状态，因此升级、扩缩容、配置变更都变成“改 CR + 等调和”。

Helm 方式把 Calico 的清单参数化，通过 values.yaml 渲染出最终资源。它适合已经用 Helm 统一管理集群组件的团队，能复用 Helm 的版本回滚、diff 和 CI 流水线。但 Helm 只负责“渲染并提交”，不负责运行时的持续调和——这一点与 Operator 有本质区别。

生产环境选型依据

选型不能只看“哪个更高级”，而要看集群的运维成熟度与合规要求。以下几条判断依据按优先级排列：

是否需要持续调和：如果集群规模大、节点频繁增减、或希望 Calico 配置始终与期望状态一致，Operator 是首选。它把“配置漂移”从人工巡检变成控制器自动修复。
是否已有 Helm 统一管理：若集群中 Cilium、Ingress、监控等组件都已用 Helm 管理，引入 Operator 会多一套生命周期体系。此时 Helm 安装 Calico 能保持工具链统一，但需接受“升级靠 helm upgrade、运行时无调和”的代价。
离线与合规场景：金融、政务等离线环境常要求所有清单可审计、可离线分发。Manifest 方式最透明，但升级窗口需要人工介入，适合变更频率低的稳定集群。
版本升级频率：Calico 小版本迭代较快。Operator 支持通过修改 Installation.spec.version 触发滚动升级；Helm 通过 --version 切换 Chart；Manifest 则需要逐节点替换镜像，风险最高。
可观测性要求：Operator 会暴露 tigera-operator 的调和状态与 Installation 的 status 字段，便于接入告警；Manifest 与 Helm 方式下，这些状态需要自行从 DaemonSet 与 Pod 事件中推断。

实操示例：Operator 方式的关键配置

以 Operator 方式为例，安装分为两步：先部署 Operator 本身，再提交 Installation 自定义资源。以下为教学示例参数，实际值需按集群 CIDR 调整。

# 1. 部署 tigera-operator
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml

# 2. 提交 Installation CR（示例）
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
    - blockSize: 26
      cidr: 10.244.0.0/16
      encapsulation: VXLANCrossSubnet
      natOutgoing: Enabled
      nodeSelector: all()
  variant: Calico

提交后，Operator 会创建 calico-node DaemonSet 与 calico-kube-controllers。判断是否就绪，可观察 Installation 的 status 是否变为 Ready，以及 calico-node 的 DESIRED 与 READY 是否相等。若 status 长时间停留在 Progressing，通常说明节点未满足 nodeSelector 或镜像拉取失败。

若集群已存在旧版 Calico，切换安装方式前应先清理原有 DaemonSet 与 CRD，避免两套控制器同时管理同一批资源。生产环境建议在维护窗口内完成切换，并提前备份 FelixConfiguration 与 IPPool。

选型决策速查

场景特征	推荐方式	核心理由
大规模、节点频繁变动	Operator	持续调和，配置漂移自动修复
已统一使用 Helm 管理组件	Helm	工具链一致，版本回滚方便
离线、合规、变更频率低	Manifest	清单透明可审计，零额外依赖
需要快速升级与状态可观测	Operator	status 字段可接入告警，升级自动化

无论选择哪种方式，最终运行的都是同一套 Felix 与 BIRD 数据面。选型真正决定的是：配置以什么形式被保存、由谁负责把它拉回期望状态、以及升级时你愿意承担多少人工操作。把这三个问题回答清楚，安装方式的选择就不再依赖直觉。