测验：Helm 与 Kustomize 集成

configMapGenerator 生成的 ConfigMap 名称末尾为什么会附加内容哈希？

• 因为 Kubernetes 会拒绝没有哈希后缀、由生成器创建的 ConfigMap
• 为了利用相同输入会产生相同名称这一特性，缓存构建结果
• 为了在配置内容变化时让名称也随之变化，进而改变引用它的 Pod 模板并自动触发滚动更新
• 只是为了避免多个 overlay 创建同名 ConfigMap 时发生冲突

只想把 dev 环境的 replicas 设为 1。正确的方法是什么？

• 在 dev overlay 中添加补丁，覆盖 base 中的值
• 把 base 的 deployment.yaml 改为 1
• 单独复制一份 dev 专用的 deployment.yaml
• 把 base 拆成两套

ArgoCD 同步以 Helm chart 为源的 Application 时，实际会执行什么操作？

• 把 chart 文件原样传到集群，在集群内渲染后直接应用
• 直接连接目标集群并原样执行 helm upgrade --install
• 由 repo-server 使用 helm template 渲染清单，然后 apply 渲染结果
• 通过集群中安装的 Tiller 组件创建新的 Helm release

将 spec.source.targetRevision 设为 HEAD 会产生什么问题？

• HEAD 不是分支名而是保留字，因此无法读取仓库
• 由于 revision 未固定，prune 会作为安全措施被强制启用
• 同一份 Application 定义会随时间部署不同内容，从而失去可复现性
• 由于无法确定用于比较的 revision，同步根本无法开始

如果 kustomize build 的结果中出现 kind: Kustomization，应该怀疑什么？

• 这是正常现象，构建结果本来就会同时输出配置说明文件的内容
• 配置有误，例如把配置说明文件本身作为 resources 引入了
• base 中没有任何 patch，因此原始内容被直接输出了
• kustomize 版本过低，无法过滤使用新版 API version 的配置说明文件

当 base 中有 namePrefix: labhub- 时，overlay 的 strategic merge patch 会用哪个名称查找目标？

• base 中写入的原始名称 web
• 名称转换完成后的 labhub-web
• patch 文件所在的路径和文件名
• overlay 指定的 namespace 名称

在 ArgoCD Application 中分开使用 helm.valueFiles 和 helm.parameters，最合理的原因是什么？

• 因为 valueFiles 已在 Helm 3 中废弃，正在迁移到 parameters
• 为了把各环境固定的一组值以文件形式保存在仓库中，而将每次部署都会变化的值（如镜像 tag）通过 parameters 传入
• 两者的渲染结果完全相同，用哪一种只是偏好问题
• 因为 parameters 比 valueFiles 更早读取，所以优先级更低