如何无 downtime 平滑将原生K8s manifest应用切换为Helm Chart部署？

以下是无业务 downtime 的可行操作方案：

• 第一步：校验Helm Chart与现有资源的一致性
  首先要保证你开发的Helm Chart渲染出来的资源和当前集群运行的原生资源完全匹配，包括标签、注解、容器配置、服务端口、存储挂载等所有字段，不能有差异。你可以通过helm template命令把Chart渲染为yaml文件，和当前在用的原生manifest做diff校验，调整values配置直到两者完全一致：
  参考命令：helm template [自定义Release名称] [本地Chart路径] -n [目标命名空间] -f values.yaml > rendered.yaml，将rendered.yaml和现有部署yaml做比对，消除所有差异项。
• 第二步：执行Helm存量资源纳管操作
  Helm 3原生支持纳管现有Kubernetes资源，无需删除重建即可完成Release关联，操作步骤如下：
  1. 先执行带--dry-run参数的安装命令，确认输出内容不会创建新资源、也不会修改现有运行中的资源：
     helm install [自定义Release名称] [本地Chart路径] -n [目标命名空间] -f values.yaml --dry-run
  2. 校验dry-run结果无异常后，添加--no-hooks参数执行正式安装，该命令只会将现有资源关联到新创建的Helm Release上，不会触发任何资源重建或配置修改：
     helm install [自定义Release名称] [本地Chart路径] -n [目标命名空间] -f values.yaml --no-hooks
  3. 执行helm list -n [目标命名空间]确认Release状态为deployed，再执行kubectl get对应deployment、service、pod资源，确认运行状态和迁移前完全一致，业务流量无中断。
• 第三步：验证Helm操作能力
  纳管完成后可先执行一次低风险的helm upgrade测试，比如修改一个不影响业务的注解字段、或指定和当前一致的镜像Tag执行升级，确认Helm可以正常管理资源、不会触发意外重建。测试通过后后续所有应用变更都可以通过Helm操作，完全替代原生kubectl部署流程。

备选过渡方案（适合对纳管操作有顾虑的场景）
可以给Helm Chart渲染的资源配置和现有资源不同的名称，先部署Helm版本的应用，确认Pod运行正常后，将原有Service的selector切换到Helm版本的Pod标签上，观察业务流量完全切流无异常后，再删除旧的原生部署资源。该方案全程也不会产生 downtime，仅会临时运行两份应用数分钟。

内容的提问来源于stack exchange，提问作者Alexey Topolnitskiy