测验：GitOps 原则
运行 kubectl diff 后，退出码为 1。这表示什么？
- 声明状态与实际状态之间存在差异
- 连接集群失败，无法进行比较
- 应用阶段发生错误而失败
- 清单存在模式错误，因而被拒绝
生产环境清单不应使用 :latest 标签，其根本原因是什么？
- 同一个提交可能随时间部署不同的镜像，导致仓库无法定义确定的状态
- latest 标签指向的镜像较大，会延长各节点的拉取时间
- 大多数镜像仓库会通过策略禁止覆盖 latest 标签
- Kubernetes 不会对 latest 标签应用 imagePullPolicy
处理故障时，使用 kubectl scale 增加了 replicas 并恢复了服务。事件结束后必须做什么？
- 将该值提交到仓库正式生效，或者按仓库中的基准恢复
- 手动修改后字段所有者变为 kubectl，因此该值会一直保留
- 将该资源加入
ignoreDifferences，排除在比较范围之外 - 等待下一次定期部署，因为届时会自动完成整理
从安全角度看，GitOps 为何更偏好拉取模式（集群内的代理读取仓库），而不是推送模式（CI 直接部署）？
- 因为推送模式的部署历史只会保留在 CI 日志中，而不在 git 中
- 因为只有拉取模式才能通过回退提交来执行回滚
- 因为无需把集群凭据交给 CI 系统
- 因为代理位于集群内部，所以部署总是更快
建议将应用代码仓库和清单仓库分开的最恰当理由是什么？
- 因为在一个仓库中混合应用代码和 YAML 会导致构建缓存每次都失效
- 因为每次应用 CI 运行都会触发同步，并使代码审查与部署审查混在一起
- 因为 ArgoCD 无法将仓库中的子目录指定为路径
- 因为清单历史累积后会更早达到仓库存储容量上限
在清单中添加 app.kubernetes.io/managed-by: gitops 这类标签，其实际目的是什么？
- 让 Kubernetes 根据该标签决定资源的应用顺序
- 因为缺少推荐标签时，apply 会在准入阶段被拒绝
- 让该标签成为把 Pod 调度到同一节点的提示
- 区分手动创建的对象与由仓库拥有的对象
为什么提交信息规范在 GitOps 中格外重要？
- 因为格式不符合规定的提交信息会被完全排除在自动同步之外
- 因为提交信息会作为渲染变量写入清单内容本身
- 因为提交信息越长，仓库轮询和 diff 计算就会明显变慢
- 因为回滚需要选择要撤销的提交，而故障期间人们能看到的往往只有一屏提交日志