钩子确认

使用未包含在发布密钥中的挂钩创建的作业会产生什么后果？

• Hook执行两次
• 即使回滚，钩子完成的工作仍然存在。
• 钩子根本不运行
• 发布大小增加

建议使用什么钩子删除策略作为基本实践？

• 钩子创建前，钩子成功
• hook-failed 只留下一个hook
• hook-succeeded 只留下一个钩子
• 根本没有删除政策

如何安全地部署删除列的架构更改？

• 一次处理好所有的钩子
• 添加--原子
• 打开备份并一次性处理所有内容
• 分为三个阶段：扩容→分发→清理

如果您将hook-failed设置为删除策略，您会失去什么？

• 在下一次部署中，根本不会创建钩子
• 成功的Job对象不断积累
• 失败的作业会立即被删除，并且查看原因的日志也会消失。
• 钩子之间的执行顺序是随机的

为什么即使我添加了--atomic，迁移也没有返回？

• 原子不适用于钩子，因此钩子本身不会运行。
• 回滚仅恢复清单，不会触及挂钩已更改的任何数据。
• 这是因为回滚是在钩子之前执行的。
• 原子仅存在于安装中，不存在于升级中

helm.sh/hook-weight是做什么的？

• 确定同一级别的钩子之间的执行顺序
• 确定分配给钩子的CPU和内存的比例。
• 设置钩子失败时重试的次数。
• 优先考虑发布中的钩子资源