1 Helm 与应用交付要回答什么
订单 API 准备上线时，交付物通常不止 1 个容器镜像。运行进程需要 Deployment，集群内访问需要 Service，配置需要 ConfigMap，应用访问云端数据服务还需要合适的身份与权限。测试环境希望节省资源，生产环境希望保留冗余。若每次发布都临时复制清单、修改镜像标签，再逐个执行命令，团队很难回答：这次到底提交了哪些资源，参数从哪里来，下次能否得到相同的结果？
Helm 面向的正是这组交付问题。它把相关的 Kubernetes 资源组织成 Chart，通过输入值生成清单，再以 release，也就是发布实例，记录安装与升级。可以把 Chart 理解为带参数的应用安装包：包里说明需要哪些资源，输入值决定本次安装的具体差异。Helm 帮助组织与执行发布，但应用进程是否正确、订单是否写入成功，仍要用运行状态和业务证据判断。
这里的“交付”至少包含 3 个可区分的结果。工件可以确定，意味着能找到准确的 Chart 和镜像；资源可以收敛，意味着集群逐步达到期望状态；业务可以验收，意味着真实请求得到预期响应。Helm 的命令主要连接前 2 个结果，验收还要依靠探针、日志、指标和业务请求。把命令返回成功直接写成“上线完成”，会跳过真正面向用户的那道门。
沿着订单 API 的请求路径看，入口把请求交给 Service，Service 把请求导向就绪的 Pod，Pod 使用配置和工作负载身份访问外部数据库。Chart 可以声明其中的 Kubernetes 对象，却不必拥有整条路径上的全部设施。例如，数据库可能由独立团队维护，入口证书可能由共享平台签发。交付边界应该明确说明谁提供依赖、谁维护应用资源、谁承担数据恢复责任。
设想新版本增加了订单查询接口。镜像已经通过构建测试，但生产环境需要 3 个副本，测试环境只要 1 个。Helm 可以让 2 个环境使用同一套资源结构，通过不同输入值选择副本数、资源请求和外部服务地址。这使环境差异变成可审阅的文件，而不是藏在发布人员的命令历史里。相同结构也有助于解释故障：先比较输入，再比较生成清单，最后比较实际运行状态。
这并不意味着任何差异都应该做成参数。若开发环境使用内存数据、生产环境使用持久化数据库，应用行为可能已经发生实质变化，不能只因为 Chart 相同就认定验证充分。入门阶段先掌握 1 条原则：Helm 可以重复表达部署意图，可靠交付还需要对依赖、数据和业务结果作出独立约定。后面的升级与回滚都围绕这个边界展开。
2 Chart、值与发布版本边界
Chart 是包含元信息、默认值和模板的目录或打包文件。常见入口包括 Chart.yaml、values.yaml 和 templates 目录。Chart.yaml 描述包名与包版本；values.yaml 给出可覆盖的默认配置；templates 中的文件根据输入生成 Kubernetes 清单。团队发布 Chart 时，应把这些文件作为整体评审，避免只审镜像地址，却忽略服务选择器或身份绑定的变化。
values 是渲染模板的输入，不会自动变成应用能读取的配置。模板如果把某个值写入容器环境变量，应用才能通过环境变量读取它；如果把值写入 ConfigMap，还要配置挂载或引用。反过来，values 中写了一个模板从未使用的字段，渲染结果可能完全不变。因此“值文件里已经设置”不是生效证据，必须沿着值、模板、清单、容器配置这条路径追踪。
release 是 Chart 在某个集群与命名空间中的安装实例。同一个 Chart 可以安装成测试环境的 orders，也可以安装成另一个命名空间中的 orders。交付记录至少需要集群、命名空间和 release 名称，单说“回滚 orders”还不够明确。应用相关对象也应使用稳定且合理的命名与标签，防止多个实例争用同名资源，或让 Service 错选其他实例的 Pod。
Chart 版本、应用版本、镜像标识和 release revision 是不同坐标。Chart 的 version 表示安装包本身的版本；appVersion 通常用于说明应用版本，不会自动替换镜像；镜像标签或摘要决定实际拉取的程序；revision 则记录某个 release 的操作历史。升级了模板但沿用原镜像，Chart 版本也应更新。镜像变了却没有更新 appVersion，也不能据此认定运行程序没变。
例如，Chart 版本为 0.3.0，appVersion 为 1.8.0，镜像由固定摘要标识，orders 的 revision 为 4。随后只调整探针配置，发布 Chart 0.3.1，可以得到 revision 5，而应用代码保持不变。再把这个实例回滚到 revision 4，通常会新增 revision 6，用历史配置重新表达目标状态。回滚不是删除中间记录，也不是让历史编号倒退。
还要区分包的可重复取得与部署的可重复生成。即使保留同名 Chart，如果依赖包会变化、镜像标签会漂移、模板读取外部实时状态，后续结果也可能不同。初学时优先固定 Chart 包版本、依赖版本与镜像摘要，保存经批准的值文件。需要排查时，再保留渲染清单及其校验信息。这样才能说明当时交付的是哪个输入组合，而不是仅给出一个模糊版本号。
release 的历史通常存放在目标集群中，具体存储方式可以配置，默认常见方式是 Secret。它包含理解发布所需的配置和清单等信息，因此访问 release 历史也应纳入权限管理。Helm 历史不是天然的安全归档，更不能代替独立的工件留存。若集群被重建，只有集群内历史而没有外部交付记录，重建路径仍会中断。
3 模板、钩子与回滚能力
模板把重复的资源结构与可变参数连接起来。例如，Deployment 的镜像字段来自 image.repository 和 image.tag，副本数来自 replicaCount。渲染阶段只是生成文本与资源定义，不代表 Kubernetes 已接受这些对象，更不代表容器已经启动。helm template 适合检查资源内容；helm lint 可以发现部分结构与模板问题；两者都不能代替目标集群中的权限、接口和运行验证。
良好的模板应让输入意图容易判断。副本数就表达副本数，服务端口就表达端口，避免用复杂条件把 1 个参数同时变成身份、网络和数据策略的开关。可以用 values.schema.json 约束类型、范围和必填字段，减少把字符串误填成数字等问题。这样的约束能尽早报错，但无法证明数据库地址可达，也不能证明调用方拥有读取订单的业务权限。
一次普通升级可以概括为：确定包与值，渲染清单，向集群提交资源变化，再观察资源是否达到要求。Deployment 的滚动更新由 Kubernetes 控制器执行，Helm 不会逐个手工启动 Pod。资源之间也未必按清单出现顺序变得可用。应用应能处理依赖暂时不可达，并通过探针表达自身状态，而不是假设配置文件排在前面就保证服务已经准备好。
钩子是放在安装、升级等特定阶段运行的资源，常见用途是执行检查或受控任务。例如，升级前用 Job 检查数据库兼容条件，升级后做轻量验证。钩子有自己的运行时机、失败结果与清理策略。它可能使用独立的 ServiceAccount、需要独立权限，也可能在主应用更新前就访问外部数据库。把任务标记成钩子，并不会自动获得安全性或可重复执行能力。
--wait 会等待受支持资源满足就绪条件，等待边界由 Helm 版本与资源类型决定；普通 Job 若也要纳入等待，需要考虑 --wait-for-jobs。钩子 Job 的完成通常会被 Helm 等待，应结合所用版本确认行为。--timeout 给等待设置上限；超过上限说明发布步骤未在期限内完成，不能直接推断所有资源都已撤销。等待期间仍应观察 Pod、事件及任务日志。
回滚重新应用历史 release 对应的资源配置，可以帮助恢复旧镜像或旧参数，但不会让外部世界自动回到过去。新版已经写入的订单、发送的通知、执行过的数据库变更，都可能继续存在。回滚后的旧代码能否读取当前数据，取决于兼容设计。因此，在上线前就要确定允许回滚的条件，例如新增字段先保持可选、旧版仍能读取数据，删除字段则安排到后续阶段。
某些 Helm 版本提供 --atomic 来在失败时尝试自动回滚，并关联等待行为；具体选项应以实际版本帮助为准。即使启用，它也不是跨 Kubernetes 和数据库的事务。回滚本身可能失败，钩子产生的副作用也可能保留。交付方案应写“尝试恢复哪些资源、如何确认恢复”，不能只写“失败自动还原”。钩子的执行权限、重试方式与清理规则也要在发布前明确。
4 动手：对比一次升级与回滚证据
这个实验只改变无状态应用的副本数，用来观察发布记录与实际资源的关系。准备 1 个可用测试集群、具备目标命名空间权限的身份，以及可运行的 Helm 和 kubectl。使用团队已有且检查过的 ./orders-chart：它至少生成 Deployment 与 Service，读取 replicaCount，具有可通过的就绪探针，且没有钩子、数据库迁移或外部写入任务。这里的 orders 是练习 release，不能指向生产实例。
先确认 Chart 生成的 Deployment、Pod 都带有 app.kubernetes.io/instance: orders 标签，且 Service 选择器与 Pod 标签匹配。实验将依靠这个标签查找资源；真实项目如果使用其他约定，要先调整选择器。镜像必须可拉取，并固定为同一个版本。这样后续出现的差异才主要来自副本数，而不是碰巧拉取了变化后的同名镜像。
kubectl config current-context
helm version --short
helm lint ./orders-chart
helm template orders ./orders-chart --namespace helm-lab --set replicaCount=1
helm install orders ./orders-chart --namespace helm-lab --create-namespace --set replicaCount=1 --wait --timeout 120s
helm history orders --namespace helm-lab
kubectl get deployment,pod,service --namespace helm-lab --selector app.kubernetes.io/instance=orders执行前检查渲染清单中的镜像、身份与命名空间。120s 是本实验的等待上限，不是推荐的生产固定值。安装成功后，记录安装时间、revision 和 Deployment 的期望副本数及可用副本数。如果安装失败，先停止后续升级，检查权限、镜像拉取、探针及事件；不要把失败的首次安装当作已经建立的回滚基线。
接下来把副本数改为 2，并显式重置为 Chart 默认值后应用这次参数。这是因为实验只允许副本数变化，不需要继承未知的历史覆盖值。在实际交付中，应传入完整、经审阅的环境值文件，不能无条件照搬重置选项，否则可能清掉镜像、资源或身份的必要覆盖。
helm upgrade orders ./orders-chart --namespace helm-lab --reset-values --set replicaCount=2 --wait --timeout 120s
helm history orders --namespace helm-lab
helm get values orders --namespace helm-lab --all
kubectl get deployment,pod --namespace helm-lab --selector app.kubernetes.io/instance=orders
helm rollback orders 1 --namespace helm-lab --wait --timeout 120s
helm history orders --namespace helm-lab
helm get values orders --namespace helm-lab --all
kubectl get deployment,pod --namespace helm-lab --selector app.kubernetes.io/instance=orders这里回滚目标 1 仅适用于刚创建、没有其他操作的练习 release。如果历史不同，必须从 history 选择实际目标。正常完成时，可预期 revision 从 1 到 2，再产生 3；副本目标从 1 到 2，再回到 1。Pod 名称可能改变，终止中的 Pod 也可能暂时出现。应以 Deployment 的期望与可用副本、滚动状态和 Service 后端为证据，不要仅靠某个 Pod 名字是否恢复判断回滚。
把 3 个阶段记录成对照：安装时的 values 与 1 个可用副本，升级时的 values 与 2 个可用副本，回滚后新 revision 与恢复到 1 的目标。随后对团队定义的健康接口和无副作用查询接口各发起请求，记录时间、状态码与返回内容。接口路径与访问方式由练习应用决定，不把任意公网地址当成实验前提。命令结果只证明发布与资源状态，业务响应补上使用者视角。
如果看到 values 已恢复而可用副本为 0，说明“历史配置恢复”与“应用恢复服务”发生了分离。进一步检查旧镜像是否仍可拉取、节点资源是否足够、应用配置是否仍然有效。练习结束后，可在确认命名空间只承载本实验的前提下卸载 release；不要把删除整个命名空间当作常规回滚步骤。卸载也不会自动清除所有外部数据或钩子副作用。
5 环境差异与配置分层取舍
配置分层要回答的是：哪些内容应共享，哪些差异必须明确写出来。对订单 API，共享内容可以是容器端口、标签约定和探针路径；环境差异可以是副本数、资源请求、数据库服务地址与入口域名。默认值应选择容易理解的基础状态，而不是把某个生产环境的具体身份和地址固化为所有安装的起点。否则新建环境时，可能意外指向已有数据服务。
常见做法是保留 Chart 默认值，再增加公共覆盖文件和环境覆盖文件。Helm 接收多个 -f 文件时，后面的同名设置通常覆盖前面；命令行设置还可能继续覆盖文件结果。映射与列表的合并方式也不同，列表不能想当然地按元素追加。发布前应检查最终合并结果，尤其是环境变量、端口与挂载列表，避免后面的短列表替换掉前面必要的条目。
helm template orders ./orders-chart --namespace orders-test -f values-common.yaml -f values-test.yaml这个命令的价值在于让审阅者看到最终清单，而不只是分别阅读 2 个输入文件。生产发布还应记录同样的覆盖顺序，避免有人把文件位置调换后得到另一组结果。频繁使用 --set 适合临时练习，却会把差异分散在命令中；若参数确实属于长期环境定义，就应进入受控文件。对值是沿用历史还是按文件重建，也要形成统一规则，并检查升级选项的实际语义。
每增加 1 个可调参数，都扩大了需要理解和验证的配置空间。假设 4 个布尔开关都可以独立使用，理论上就有 16 种组合；团队不一定验证过这些组合，也不一定需要支持它们。公共 Chart 过度追求适配所有服务，最终可能让普通发布也必须理解大量条件。入门时宁可让参数直接对应清晰需求，再随着真实复用需求演进。
与此同时，把所有值写死也会增加复制。团队复制 3 份模板，只为修改副本数，之后修复探针就要同步修改 3 处。比较方案时可以同时观察模板复制、参数数量和变更影响范围：共享结构减少重复；明确的环境文件保留差异；少量有边界的参数降低组合风险。不要用“同一套 Chart”来掩盖不同环境实际上采用了完全不同的资源结构。
身份和网络尤其需要谨慎分层。测试与生产应引用各自的工作负载身份，遵循各自的网络访问规则，不能靠改数据库域名就完成隔离。模板还应明确是否创建 ServiceAccount，以及由谁配置它与云身份的关联。Kubernetes ServiceAccount 本身不等于已经获得外部数据库权限，Service 可访问也不等于网络策略允许 Pod 访问数据库。
配置变化也未必自动触发进程更新。例如，修改 ConfigMap 后，通过环境变量读取配置的既有容器通常不会自动重新读取；挂载文件的更新与应用是否重新加载，也需要分别确认。团队可以设计受控的滚动更新触发方式，并写清应用读取配置的时机。验收时检查运行中的实际配置来源，避免只看到 ConfigMap 已改变，就认定订单 API 已使用新设置。
6 常见坑：把 values 当密钥库
values 文件很容易成为“所有配置放在一起”的地方，于是数据库密码、访问令牌甚至私钥也被写进去。问题不只是文件可能提交到代码仓库。值还会进入渲染流程、发布记录、调试输出和流水线日志，接触配置的角色往往比接触密钥的角色多。即使删除代码仓库当前文件中的密码，历史提交、构建产物和已输出日志也可能继续保留它。
把密码通过 --set 传入，也不能自动解决暴露问题。命令可能进入 shell 历史、流水线日志或进程参数记录；值还可能成为 release 的一部分。把它放进名为 Secret 的 Kubernetes 对象，也不意味着获得了完整保密保障。Secret 中常见的 base64 表示只是编码，能解码的人不需要破解密码；传输、静态存储保护与读取权限应分别管理。
更清晰的边界是让 values 保存密钥引用，例如已有 Secret 的名称和字段名，再由模板使用 secretKeyRef 等机制引用。真实内容由被授权的独立流程提供。采用外部密钥管理系统时，可以通过适当的同步或挂载机制交给工作负载，但这会引入额外组件与权限，需要明确维护方。入门先理解引用与内容的分离，不必在本课展开各类驱动的内部实现。
例如，Chart 允许设置 existingSecret: orders-db，Deployment 引用其中约定的键。这里的名称可以进入环境文件，密码内容则不随 Chart 打包。但这个字段只是团队设计的接口，Helm 不会因为看见这个名字就自动创建密钥。部署前要确认对象存在于正确命名空间，字段符合应用预期，工作负载能够使用，且不把内容打印为诊断信息。
引用也不意味着所有安全工作已经结束。能创建或修改工作负载的角色，可能通过改变挂载与启动命令间接获取 Secret，因此需要整体审视命名空间权限。Helm 执行身份、应用 ServiceAccount、数据库访问身份承担不同职责：发布者能改资源，不应因此自动获得业务数据库的全量读写权限。共享 1 个高权限身份虽然省事，却让泄露影响范围和故障归属都更难控制。
密钥轮换同样要考虑运行时行为。新值已经写入 Secret，不代表现有连接立即使用新凭据；环境变量需要新建容器才能更新，应用也可能缓存连接。轮换方案应约定新旧凭据的过渡窗口、更新顺序和验证方式。若回滚旧版本，它仍应通过当前有效引用访问服务，而不是期待 Helm 把已吊销的密码恢复成可用状态。
发现泄露时，重点是吊销或轮换凭据、评估访问范围，并处理相关历史与日志留存；单独回滚 Chart 不能让已被看到的密码重新保密。日常审阅则应检查默认值、示例文件、钩子日志和渲染产物，确认没有意外包含真实内容。需要分享排障材料时，保留名称、时间和错误类型通常就能建立线索，敏感字段应按团队规则脱敏后再流转。
7 案例：钩子失败留下半发布状态
订单 API 从旧版升级到新版，团队安排了 1 个 pre-upgrade 钩子 Job，为数据库增加辅助索引。任务先提交了数据库变更，随后访问另一个服务时超时，最终以失败退出。Helm 因钩子失败停止后续流程，主 Deployment 仍运行旧镜像。此时发布状态显示失败，旧接口也可能仍能访问，但数据库已经发生变化。所谓“半发布”描述的是这些状态没有共同回到同一个业务基线。
这个案例不应简化成“Helm 更新到一半所以坏了”。首先要确认失败阶段：pre-upgrade 失败可能让主资源尚未更新，post-upgrade 失败则可能发生在主应用已经变化之后。其次要区分钩子执行结果与外部操作结果：Job 失败只说明任务没有按预期结束，不保证前面执行的语句已撤销。数据库自己的事务边界也不能由 Helm 状态推断。
值班人员先记录集群、命名空间、release、失败 revision 与时间，再查看 history 和 status，确认当前尝试的阶段。随后查找钩子 Job、Pod 的状态、事件和日志，并对照 Deployment 的镜像与可用副本。数据库侧则由有权限的维护者检查索引是否存在、执行记录是否完整。日志中“开始建索引”不能替代数据库实际状态，任务最后的报错也不能证明索引未创建。
如果钩子设置了快速清理，失败 Job 或 Pod 可能已被删除，因此发布设计就应考虑证据留存。钩子资源的清理受钩子策略等机制影响，不能假设它像普通业务资源一样随 release 自动完整管理。可以保留适度时长的失败证据，或把日志送入受控的集中系统，同时限制敏感数据输出。清理策略需要兼顾排障与资源占用，而不是永远保留或立即删除。
此时最危险的操作是未经确认就重复升级。若任务再次执行同样变更，可能遇到对象已存在、重复处理数据或产生额外副作用。更好的任务设计是可安全重试：能识别已经完成的步骤，重复运行不会破坏正确结果。对于不能轻易重复的操作，应有明确的执行记录和人工恢复步骤。把超时时间调大只会改变等待上限，不会修复任务的重试语义。
恢复方向取决于兼容证据。若新增索引不影响旧代码，且旧服务指标正常，可以先保持旧版本服务，确认数据库状态后修正任务，再安排发布。若已经修改了旧代码依赖的数据格式，回滚应用可能无效，必须由数据维护者制定修复或向前完成的步骤。不要为了让 history 看起来成功，就在证据不足时反复执行升级与回滚。
最终验收至少包含发布记录可解释、主工作负载达到目标、数据库状态已确认、订单查询与写入满足约定。案例的改进点是把隐含副作用显式化：说明哪个钩子会改什么、用什么身份、能否重试、失败保留什么、谁决定恢复。对于数据变更较重的任务，也可以评估独立受控流程，减少它与应用资源更新之间难以解释的耦合。
8 把发布工件写进交付方案
交付方案应让接手者能够定位发布输入并判断结果。至少记录 Chart 的取得位置、版本与校验信息，镜像的固定标识，依赖包版本，以及环境值文件的版本和覆盖顺序。若交付链涉及额外脚本，也要纳入工件清单。只留一段 helm upgrade 命令是不够的，因为命令引用的目录、文件和镜像标签都可能在之后变化。
环境定位也属于交付内容。方案应写明目标集群、命名空间、release 名称、执行身份和应用身份，并说明入口、网络访问边界与外部数据服务的负责人。这里关注的是连接关系与职责，不需要复制所有基础设施配置。接手者应能判断：这个 Chart 会创建哪些对象，哪些对象由平台预先提供，哪些更改需要其他维护方参与。
发布前的检查应指向明确问题。渲染检查确认即将提交的镜像、身份、端口和资源要求；权限检查确认执行者能完成允许的资源操作；依赖检查确认密钥引用、外部地址与必要接口存在。若使用差异工具，还要说明工具与比较基线，不把某个可选插件假定为 Helm 自带能力。对清单的人工审阅尤其应关注删除资源、改变选择器和扩大权限的变化。
发布中的门槛则应表达何时停止。比如 Pod 在约定时间内持续无法就绪、错误率超过团队设定的阈值，或关键查询验证失败，就暂停扩大变更并进入排障。阈值应结合既有基线和流量解释，不能把本实验的 120s 直接变成所有应用的标准。副本达到目标也不能覆盖业务错误，反过来少量成功请求也不能证明全部副本都健康。
恢复部分要写清回到哪个 release revision 或哪个已知工件，哪些资源预计改变，哪些外部状态需要另行处理。旧镜像仍可取得、旧配置仍兼容当前数据库、密钥引用仍有效，这些都是恢复前提。恢复命令后还要重新进行资源和业务验收。对于不可逆的数据变更，应提前指定备份、恢复或向前修复路径，以及承担判断与执行的人。
证据应按同一次发布关联，而不是散落成无法对齐的截图。记录时间、revision、Chart 与镜像标识，关联 Deployment 状态、关键事件、错误率和代表性请求结果。保留范围要符合访问控制与数据留存要求，避免为了排障复制订单个人信息。清晰的标识使团队能够回答“从哪个时间开始、由哪次变化触发”，也便于把问题反馈到工件或配置修复。
初学团队可以从小规模交付开始：选定 1 个无状态服务、1 条清晰的发布路径、少量环境参数和明确的恢复基线。先让不同人员按同一份材料得到可解释的结果，再引入更复杂的策略。Helm 的价值在这里体现为把资源组合、参数与历史组织起来；交付方案则把这些技术记录连接到职责、验收和恢复，让一次上线成为可以交接的工作。
9 从Helm 与应用交付走向Serverless（C35）
到这里，我们仍然在显式管理应用工作负载：选择镜像、声明副本、提供探针、设置资源要求，并通过 Chart 组织对象。平台承担 Kubernetes 的一部分运行工作，团队仍要解释应用怎样启动、怎样访问数据、怎样更新与恢复。下一课的 Serverless 会继续调整这条责任边界，让使用者在某些场景中更多围绕函数、请求或事件组织应用。
Serverless 并不表示没有服务器，也不等于不需要交付。运行环境、应用代码、依赖、身份、触发器与配置仍然需要版本与审批。变化在于团队可能不再直接声明 Pod 和副本，而是提交函数包或容器，并配置请求入口、事件来源和并发限制。因此，本课最值得迁移的能力不是记住某个命令，而是区分工件、配置、运行状态和业务结果。
订单查询接口可以帮助理解这种迁移。放在 Kubernetes 中时，团队可能用 Deployment 保持若干副本，通过 Service 接收请求；采用某种 Serverless 服务时，平台可能根据请求启动和扩展执行实例。使用者看到的仍是同一个接口，但启动延迟、并发行为、连接管理与计费依据可能变化。不能仅因省去了副本字段，就认定原有容量与数据约束已经消失。
订单创建后的通知任务则可能由事件触发。交付时除了应用包，还要考虑事件来源、重试与失败处理，以及同一个事件被再次处理时是否重复发送通知。这与本课钩子的可重试问题有相通之处：执行失败不代表没有副作用，重新执行前要理解已经发生什么。后续会从事件与运行模型展开，不在这里深入执行平台内部调度。
Helm 与 Serverless 也不是互斥选项。团队可以用 Helm 交付常驻 API，同时让独立的事件任务采用另一种运行形态；某些运行平台本身也可能部署在 Kubernetes 上。比较时应先问工作负载需要什么：请求是否稳定、任务执行多久、是否依赖长期连接、状态放在哪里、平台负责到哪一层。不要把工具名称直接当成架构结论。
本课的发布证据思路仍然适用。若不再查看 Deployment，就应找到新的运行版本标识、调用日志、并发指标和错误证据；若平台提供版本切换，也要确认外部数据是否兼容。回到旧代码不等于撤回已发出的事件，更不等于删除新写入的数据。云服务改变了部分操作入口，没有消除版本兼容与恢复验证的需求。
带着 3 个问题进入 C35：平台接走了哪些运行责任，应用交付物和触发方式发生了什么变化，团队还必须掌握哪些身份、网络与数据边界。能回答这些问题，就可以把 Helm 学到的交付方法用于评估新的运行方式。选择依据应是可解释的责任与约束，而不是部署命令看起来更短，或某个名称听起来更先进。
放进方案里
为订单 API 写交付方案时，先把发布单元定义为固定 Chart、固定镜像与经审阅的环境值文件组合。记录包版本、校验信息、文件版本和覆盖顺序，注明目标集群、命名空间与 release。列出 Chart 创建的对象，并标明数据库、入口证书、密钥和云身份由谁提供。接手者应能从这些信息重建发布输入，识别依赖负责人。
将环境差异限定在有明确用途的参数中，例如副本数、资源要求、入口域名和密钥引用。真实凭据通过受控流程供应，不进入 values、命令参数和交付附件。写明应用身份所需权限与网络访问方向，确认测试环境不会误连生产数据。配置变更是否需要重建容器、应用何时读取新值，也要成为交付约定。
发布步骤包含渲染审阅、必要检查、执行升级和业务验收。记录期望镜像、资源就绪条件、等待期限及停止门槛；观察对象至少覆盖 release 历史、Deployment、Pod 事件和关键接口。把发布 revision、操作时间、指标与请求结果关联起来，保证出现异常时能够判断是提交失败、运行未就绪，还是业务行为不正确。
恢复方案指定可用的历史目标，并确认旧镜像可取得、旧代码兼容当前数据。逐项说明钩子的外部副作用、重试条件与失败证据留存方式；数据变更另行约定恢复或修复责任。回滚后重新检查资源、依赖与业务请求，只有达到约定门槛才宣布恢复。交付记录同时保留恢复结果，避免把命令退出成功当作最终结论。
方案评审时，让接手者沿“工件在哪里、配置怎样合并、失败看什么、恢复依靠什么”复述操作路径。任何只能由原发布者凭记忆补充的条件，都应补入材料。这样，Helm 的模板与历史才能成为可交接的发布依据，并为后续评估 Serverless 的责任变化提供基线。
10 小结：下一步Serverless（C35）
Chart 组织资源结构，values 提供输入，release 记录安装实例与操作历史。升级和回滚都需要观察资源收敛与业务结果；钩子和外部数据让恢复边界超出 Helm 本身。下一步学习 Serverless 时，继续追问交付物、执行身份、触发方式和恢复证据，把责任边界讲清楚再选择运行形态。