测验：依赖与钩子

在无法访问互联网的环境中引用子 Chart 时，应如何填写 dependencies 的 repository？

• 直接放入 charts/ 后可以省略 repository 字段
• 只能使用 OCI Registry 地址
• 填写以 file:// 开头的本地路径
• 留空后由 Helm 自动查找

helm dependency update 与 helm dependency build 有什么区别？

• update 会重新解析依赖并改写 Chart.lock，而 build 会按现有 Chart.lock 原样复现依赖
• build 只能下载远程仓库中的 Chart，而 update 只能处理通过 file:// 指定的本地路径依赖
• 两者只是同一操作的别名，因此解析出的版本和 Chart.lock 内容始终相同
• build 会在把依赖 Chart 下载到 charts/ 后，继续将父 Chart 打包为 .tgz

希望在父 Chart 中把子 Chart cache 的副本数设为 3。正确的配置位置是哪里？

• 在父 Chart 的 values.yaml 中，于 global: 下设置 replicaCount: 3，使其传递给子 Chart
• 打开作为依赖引入的 cache Chart 的 values.yaml，直接把 replicaCount 改为 3
• 在父 Chart 的 values.yaml 中，于 cache: 键下设置 replicaCount: 3
• 在父 Chart.yaml 的 dependencies 列表中，于 cache 条目内同时设置 replicaCount: 3

已经通过 condition 禁用了子 Chart，但渲染结果中仍出现同名资源。最可能的原因是什么？

• condition 只对 install 生效，对 template 不生效
• 父 Chart 在自己的 templates/ 中直接创建了该资源
• 必须删除 charts/ 中的包
• 没有重新生成 Chart.lock

把值放在 global 下的目的是什么？

• 为了绕过 values.schema.json 的必填字段验证
• 为了加密该值并隐藏在 release Secret 中
• 为了让父 Chart 与所有子 Chart 都能访问同一个值
• 为了让该值比普通值优先级更高，甚至覆盖命令行 --set

如果没有为 hook Job 设置 helm.sh/hook-delete-policy，会出现什么问题？

• hook Job 会被视为普通 release 资源，并在回滚时恢复到先前状态
• hook 资源不归 release 所有，因此不会被清理而会不断累积，并在下次部署时发生同名冲突
• 用于确定同一阶段 hook 顺序的 hook-weight 会被忽略，hook 将随机执行
• 没有删除策略时，整个 hook 注解都会被视为无效，Job 根本不会运行