Helm 运维与 Argo CD 迁移

将静态 Kubernetes 清单迁移到 Helm，再迁移到 Argo CD，不仅会改变模板化方式，也会改变所有权。应盘点线上资源，保留不可变名称和存储，并在启用自动修剪前使期望状态可复现。

了解 Helm 的发布模型 #

对于直接的 Helm 发布，升级会比较之前的发布清单、新渲染的清单和线上对象。两个清单中都存在的资源会在其字段允许时更新；只存在于新清单中的资源会被创建；从 chart 中移除的资源通常会被删除。不可变字段可能需要明确的替换策略。

helm upgrade --install web ./chart \
  --namespace web --create-namespace \
  --values environments/production.yaml \
  --dry-run --debug

在既有工具链提供 helm diff 时使用它，并在升级后检查 helm get manifest 和 helm history。helm.sh/resource-policy: keep 注解可以在卸载期间保留资源，但这应是有意作出的生命周期决策，而不是通用的安全措施。

首先从源代码管理中获取实际的期望规格，并将其与线上对象比较。只将真正的环境差异（镜像版本、主机名、资源限制、存储类）参数化，而不要参数化每个字段。渲染 chart，并将其与现有资源比较。

首次迁移期间，保持稳定的 metadata.name、命名空间、选择器和持久卷声明名称。更改选择器可能使 Pod 无法归属；更改 PVC 名称会创建新的声明，并不会移动数据。对于有状态工作负载，在发生任何所有权转换前，应在非生产集群中演练备份、恢复和回滚流程。

当 Argo CD 渲染 Helm chart 时，避免针对同一资源运行单独的 helm upgrade。配置 Application，验证渲染后的清单和差异，先在不修剪的情况下同步，然后仅在应用健康且作用域中没有无关资源后启用修剪。

对于资源重命名或带有删除保护的依赖图，应使用分阶段迁移：

Argo CD 同步波可以对普通的应用和修剪顺序进行排序，但当涉及数据迁移、准入 Webhook 或外部客户端时，分阶段变更更清晰。