测验：部署、升级与回滚

关于 Helm 3 保存 release 状态的方式，哪项是正确的？

• 状态以各 release 独立文件的形式保存在客户端主目录下，因此即使使用同一集群，其他人也无法查看历史记录
• 在安装 release 的 namespace 中，每个 revision 都保存为一个名为 sh.helm.release.v1.<이름>.v<리비전> 的 Secret
• 所有 release 的 revision 都追加保存在 kube-system namespace 中的单个 helm-releases ConfigMap 内
• 常驻集群的 Tiller server 将状态保存在内存中，CLI 必须向该 server 查询才能获知历史记录

一个 release 的最新 revision 是 3，将其回滚到 revision 2 后，历史记录会怎样变化？

• revision 编号仍停留在 3，只把对应 Secret 的内容覆盖为 revision 2 的内容
• 使用 revision 2 的 chart 和 values 计算并创建新的 revision 4
• 历史记录会被初始化，编号从 revision 1 重新开始，先前记录全部消失
• revision 3 的 Secret 会被删除，revision 2 再次成为最新 revision

升级被 API server 拒绝并失败。以下哪种结果是正确的？

• 整个 release 会变为 uninstalled 状态，Helm 还会一并清理已经运行的资源
• 被拒绝的尝试不会创建 revision，因此历史中只保留之前成功的 revision
• 不会创建新 revision，只会把之前成功 revision 的状态标记改为 failed
• 失败的尝试也会记录为新 revision，并标记为 failed；实际资源保持此前状态

Helm 3 的 three-way strategic merge patch 会比较哪三项内容？

• Chart.yaml 的 metadata、values.yaml 的默认值以及 templates/ 的渲染结果
• chart 默认值、通过 -f 传入的 values 文件以及通过 --set 传入的命令行值
• 上一 revision 的 manifest、当前集群的实际状态以及新渲染的 manifest
• 目前分别应用在开发、预发布和生产三个环境中的 manifest

helm get values my-app 与 helm get values my-app -a 有什么区别？

• -a 会搜索所有 namespace，汇总并显示同名 release 的 values
• -a 会按顺序拼接并一次性显示从 revision 1 到当前的所有 values
• -a 会把相同内容从 YAML 转换成 JSON 输出，便于解析
• -a 会显示合并 chart 默认值后的最终 values；不加该选项时，只显示用户实际传入的 values

需要观察部署失败原因时，为什么不添加 --atomic？

• 因为 --atomic 会在失败时自动回退到上一 revision，使人失去观察失败状态的机会
• 因为 --atomic 会关闭 --wait 并立即返回，无法观察 Pod 的就绪过程
• 因为 --atomic 会跳过 pre-upgrade hook，导致 migration Job 不留下日志
• 因为 --atomic 只适用于 install，添加到 upgrade 时会被静默忽略