2. CRD 版本迁移策略

在 Kubernetes 生态中，CRD（Custom Resource Definition）版本迁移是 Operator 生命周期管理中最具挑战性的环节之一。当 CRD 的 API 版本从 v1alpha1 演进到 v1beta1 或 v1 时，集群中已存在的存量资源对象必须被安全、无损地转换到新版本。本章深入剖析三种主流的版本迁移策略：原地升级、蓝绿部署和金丝雀发布，并给出选型建议。

2.1 原地升级策略

原地升级（In-Place Upgrade）是最直接的迁移方式：直接修改集群中已部署的 CRD 定义，并依赖 Kubernetes 内置的存储版本转换机制完成数据迁移。

2.1.1 工作原理

1. 更新 CRD 定义：通过 kubectl apply 或 Helm 升级，将 CRD 的 spec.versions 字段更新为包含新版本。
2. 设置存储版本：在 CRD 中指定 storage: true 的版本为新版本，Kubernetes 会自动将存量资源从旧存储版本转换为新存储版本。
3. Webhook 转换：如果 CRD 配置了 conversion webhook，Kubernetes API Server 会在读写资源时调用 webhook 完成版本间的双向转换。
4. Operator 适配：Operator 的控制器监听新版本资源，并处理从旧版本转换而来的对象。

2.1.2 关键代码示例

以下是一个典型的 CRD 定义片段，展示了如何配置存储版本和转换 webhook：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.example.com
spec:
  group: example.com
  names:
    kind: MyResource
    listKind: MyResourceList
    plural: myresources
    singular: myresource
  scope: Namespaced
  versions:
  - name: v1alpha1
    served: true
    storage: false
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              oldField:
                type: string
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              newField:
                type: string
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        service:
          namespace: operator-system
          name: conversion-webhook-service
          path: /convert
      conversionReviewVersions: ["v1", "v1beta1"]

2.1.3 优缺点分析

2.2 蓝绿部署策略

蓝绿部署（Blue-Green Deployment）通过维护两套独立的 CRD 和 Operator 实例，实现版本迁移的零风险切换。

2.2.1 架构设计

蓝绿部署的架构包含两个完全隔离的“环境”：

• 蓝环境（旧版本）：运行 v1alpha1 版本的 CRD 和 Operator，处理所有生产流量。
• 绿环境（新版本）：运行 v1 版本的 CRD 和 Operator，初始时不接收流量。

迁移流程如下：

1. 在绿环境中部署新版本 CRD 和 Operator。
2. 通过数据同步工具（如 Velero 或自定义迁移脚本）将存量资源从蓝环境复制到绿环境，并完成版本转换。
3. 在绿环境中验证资源状态和 Operator 行为。
4. 切换流量入口（如修改 Ingress 或 Service 的 selector），使新请求指向绿环境。
5. 观察一段时间后，下线蓝环境。

2.2.2 优缺点分析

2.3 金丝雀发布策略

金丝雀发布（Canary Release）是一种渐进式迁移策略，先让少量资源使用新版本，验证稳定后再逐步扩大范围。

2.3.1 实现方式

金丝雀发布在 CRD 版本迁移中的典型实现方式有两种：

• 基于标签选择器：在 CRD 中增加 version-migration: canary 标签，Operator 只处理带有该标签的资源。
• 基于命名空间：在特定命名空间中部署新版本 Operator，只处理该命名空间下的资源。

迁移流程：

1. 部署新版本 CRD 和 Operator，配置为只处理金丝雀资源。
2. 选择少量存量资源（如 5%），手动或自动将其标记为金丝雀。
3. 新版本 Operator 接管这些资源，执行版本转换。
4. 监控资源状态、Operator 日志和业务指标。
5. 如果稳定，逐步扩大金丝雀比例（10% → 30% → 50% → 100%）。
6. 全量切换后，下线旧版本 Operator。

2.3.2 优缺点分析

2.4 策略对比与选择

三种策略在多个维度上存在显著差异，以下表格帮助你在实际项目中做出选择：

2.4.1 决策流程图

以下决策树可以帮助你快速确定适合当前场景的迁移策略：

1. 集群规模如何？
   • 资源 < 1000 → 原地升级
   • 资源 1000~5000 → 金丝雀发布
   • 资源 > 5000 → 蓝绿部署
2. 业务关键性如何？
   • 非关键业务 → 原地升级
   • 关键业务 → 蓝绿部署或金丝雀发布
3. 团队对 Operator 的掌控力如何？
   • 完全掌控（可修改代码）→ 金丝雀发布
   • 仅能配置部署 → 蓝绿部署
4. 可接受的迁移窗口有多长？
   • 分钟级 → 原地升级
   • 小时级 → 蓝绿部署
   • 天级 → 金丝雀发布