CGOA 模拟考 A

在 GitOps 术语中，feedback loop 指什么？

• 开发者在代码评审中留下的意见会体现在下一个提交中的过程
• CI 流水线把测试结果通知到聊天工具的集成
• 观察实际状态，将其与期望状态比较，再把差异作为下一次协调输入的循环
• 通过用户调查收集门户满意度并反映到路线图中的流程

以下哪项属于声明式描述（declarative description）？

• 在 Deployment 清单中将 replicas 写为 3，以描述期望的最终状态
• 依次执行 kubectl scale deploy web --replicas=3 命令
• 在 shell 脚本中编写条件语句：如果只有两个 Pod，就再创建一个
• 在 Ansible playbook 的 shell 任务中依次列出 apply 命令

协调循环要检测漂移，必须具备什么条件？

• Git 仓库必须配置 webhook
• 所有清单必须集中在同一个仓库中
• 部署流水线必须记录上一次成功的时间
• 无论是否发生事件，都能定期读取并比较期望状态与实际状态

在 GitOps 术语中，rollback 是什么意思？

• 删除故障 Pod，让控制器创建新 Pod
• 把状态存储库恢复到此前验证过的修订版本，使系统收敛到该状态
• 暂时停止协调代理，使其不再应用变更
• 从镜像仓库中删除有问题的镜像标签

OpenGitOps 所说的 continuous，正确含义是什么？

• 每次提交变更时都必定进行同步
• 即使没有变更事件，协调也会持续重复；这与部署频率是不同概念
• 它保证零停机部署，与 continuous deployment 含义相同
• 流水线必须始终处于运行状态

以下哪项难以视为状态存储库（state store）必须具备的性质？

• 应保留变更历史，并能再次指定某个修订版本
• 事后应能审计谁批准了什么
• 已经生成的修订版本不能在之后被悄悄修改
• 必须使用 Git，其他存储方式不被承认为 GitOps

以下哪项对“GitOps managed software system”的描述最准确？

• 期望状态声明在状态存储库中，并由协调循环持续维持该状态的整个目标系统
• 专指 Argo CD 或 Flux 等协调引擎本身
• 指保存清单的 Git 仓库
• 仅指 Kubernetes 集群

对于用 Helm chart 管理的应用，哪一项属于“期望状态”？

• 上传到 chart 仓库中的软件包文件本身
• 仅指 values 文件中填写的参数值
• chart 与 values 渲染后得到的最终清单
• 保存在集群 Helm 发布历史中的内容

以下哪项正确匹配了执行 state reconciliation 的主体和方向？

• 软件代理把实际状态推向期望状态
• CI runner 按实际状态更新期望状态
• 运维人员查看仪表板后手动对齐两种状态
• API server 直接读取提交并自行创建对象

协调循环针对同一修订版本无论运行多少次，结果都应相同。这种性质叫什么？

• 原子性（atomicity）
• 可逆性（reversibility）
• 幂等性（idempotency）
• 局部性（locality）

把协调结果反馈给人的路径中断时，最先出现的问题是什么？

• 期望状态无法反映到存储库中
• 即使同步失败也无人知晓，旧状态会继续提供服务
• 代理停止协调循环并进入等待状态
• 存储库的提交历史被破坏

OpenGitOps 文档为什么使用“software agent”，而不是具体产品名？

• 因为这两个产品尚未成为 CNCF 毕业项目
• 为了强调代理必须在集群外运行
• 因为商标问题，文档中不能写产品名
• 为了明确 GitOps 是按原则定义的运维模型，而不是某个特定产品

将targetRevision改为提交哈希而不是分支名称，最直接加强的原则是什么？

• 陈述式
• 自动拉取
• 持续和解
• 版本化和不可变

像数据库模式迁移一样，将顺序是本质的工作放入GitOps流程的方法最合适的是什么？

• 只有迁移，CI Runner才会设置例外，直接在群集中运行。
• 宣布Job Manifest，并通过Hook或阶段指定明确执行顺序。
• 因为无法用声明式表达，所以从GitOps管理对象中排除。
• 运营者在发布前用手运行，并将结果记录在文件中。

打开自动同步，关闭自我修复时，实际发生的事情是什么？

• 即使有新的提交进来也不会同步。
• 漂移会立即退回，但新的提交会被忽略。
• 新的提交会自动应用，但手动修改的漂移会保持原样。
• 同步完全不工作，总是显示有差异。

将调整引擎放在目标群集以外的管理群集中的配置是否满足“Pulled Automatically”的依据是什么？

• 因为管理群集和目标群集都在同一网络中。
• 因为外部调整器只使用读取专用资格证明。
• 因为原则要求的是代理人自己拉动到被批准的状态的方向，而不是代理人的位置。
• 虽然原则上规定了位置要求，但因为在实际工作中被认定为例外。

为了满足“Continuously Reconciled”原则，需要什么？

• 每次提交都必须执行管道。
• 无论是否提交，都必须继续观察实际状态，并纠正差异。
• 分配批准程序必须自动化。
• 回滚应该可以用一次命令完成。

强制在设置存储中重新写入履历的做法破坏了什么？

• 无法再次指明已经分发的版本，因此不变性和审计追踪一起崩溃。
• 代理的抽样周期变长，收敛速度变慢。
• Manifest从声明式变更为命令式
• 调整循环无法读取实际状态

在存储库中删除了manifest，但群集的对象仍然存在。实际上破损的原则是什么？

• Declarative — 宣言文件不是声明型
• Versioned and Immutable — 删除提交没有留在历史记录中
• Pulled Automatically — 代理无法获取提交内容
• Continuously Reconciled — 实际状态未能趋向于期望的状态

当自动缩放器管理replicas的Deployment也用GitOps管理时，推荐的处理方法是什么？

• 删除自动缩放器，将replicas固定在存储库中
• 关闭自我治愈，忽略所有类型的漂移。
• 在manifest中宣布删除replicas或将该字段从比较对象中排除在外
• 将同步周期比自动缩放器的稳定化窗口延长

在GitOps中，“已批准的更改”这个表达在实际工作中指的是什么？

• 这是运营者按下发布按钮批准的操作。
• 这是安全团队在单独系统中结算的请求。
• 经过规定的审查，是合并到基本分支的提交。
• 这是经代理通过状态检查的部署。

为了在不把平文秘密放在存储库的同时保持你的原则，你需要什么？

• 只有秘密才设置例外，让CI Runner直接在群集中生成。
• 创建一个包含秘密的单独存储库，仅限制访问权限。
• 运营者用手在群集上制作，并记录在文件中。
• 只提交加密形式或参考，加密或查询在群集内进行。

将抽样周期从3分钟延长到30分钟时，从原则上看会发生什么变化？

• 虽然不是违反原则，但漂移被放任自流的时间会变长。
• 明显违反Continuously Reconciled原则
• Pulled Automatically原则改为push模式
• 因为没有留下历史，所以打破了不变性原则。

运营者急忙修改了群集，而该修改本身是正确的。符合原则的后续措施是什么？

• 在代理商的比较排除列表中添加相应字段，然后保持原样。
• 将相同的内容提交到设置存储库，更新所需的状态。
• 创建将群集状态写入的文件，并自动将其推入存储库。
• 永久关闭该应用程序的自动同步

实际实现“不在存储库的东西也不应该在群集中”的功能是什么？

• 整理对应已删除的manifest的对象的prune
• 重新尝试失败的同步的retry
• 分段指定应用顺序的sync wave
• 计算并展示差异的diff

在决定授予调整引擎的集群权限时，如何同时遵守原则和安全的方法？

• 给所有命名空间最高管理员权限，防止同步失败。
• 直接重复使用人运营者的kubeconfig
• 将CI Runner的代币与代理共享，将权限集中在一个地方。
• 通过实际处理的命名空间和资源种类来缩小权限范围。

以下中满足四个原则的构成是？

• 在存储库中放置宣言，在夜间克隆抓捕群集中执行应用命令。
• 运营者在管理画面上每次按下同步按钮进行部署。
• 群集中的控制器定期读取存储器并应用，并恢复漂移。
• CI将软件包工具发布到版本控制系统中，并将结果记录到存储库中。

从原则角度来看，将图像固定为摘要并分发的好处是什么？

• 注册表查询速度加快，调整延迟减少。
• 无论什么时候应用相同的提交，都指向相同的艺术品，因此不可变性扩展到艺术品。
• 图像签名验证自动激活
• 还原时无需恢复存储库历史记录。

如果允许直接推送到设置存储库的默认分支，从GitOps的角度来看，会失去什么？

• 代理检测变更的速度变慢
• 宣言不再是宣言型了。
• 滚动回溯所需的提交历史记录会消失。
• 在变更发布之前，审查的环节消失，没有批准界限。

即使引入GitOps，作为不变的危险，正确的是什么？

• 用手修改的变更会永久存活。
• 不知道是谁什么时候换了什么。
• 错误的宣言合并的话，那个错误就会准确而迅速地传播。
• 分发资格证书将保留在CI Runner中。

关于Infrastructure as Code和Configuration as Code的关系，正确的是什么？

• IaC是声明型，CaC是命令型，这一点上有所不同。
• IaC处理基础设施资源的生成，CaC处理其上系统的设置，GitOps可以适用于两者。
• CaC是IaC的旧名称，现在也用同样的意思写。
• IaC是云端的，CaC是本地端的

最准确地描述GitOps与DevOps文化的关系是什么？

• 这是在部署和运营领域具体实现DevOps所追求的协作和自动化的运营模式。
• 这是取代DevOps并占据其位置的新组织运营模式。
• 这是与DevOps文化无关的纯粹的技术规范。
• 这是将开发组织和运营组织合为一体的组织改组方法论。

将DevSecOps融入GitOps管道时，效果最大的点是什么？

• 发布结束后，用运行时扫描器找到漏洞，制作票证。
• 在合并前阶段，将Manifest政策检查和图像脆弱点检查作为合并条件。
• 每个季度，感谢团队都会亲自检查群集。
• 运营者在发布前确认安全检查清单。

在引入GitOps的团队中，适合作为CI管道最终产出的是什么？

• 这是已经应用于目标群集的版本。
• 这是整理了测试结果的报告。
• 这是上传到注册表中的图像和上传到设置存储库中的参考更新提交。
• 这是发给运营者的分发批准请求。

要根据GitOps原则处理用代码制作的云资源，需要什么？

• 让自动化的调整主体进行计划和应用，并继续确认状态差异。
• 运营者在本地应用并稍后提交结果。
• 将状态文件一起提交到存储库，作为履历。
• 因为基础设施不是GitOps的目标，所以通过单独的程序进行分离。

在GitOps存储库中设置代码所有者规则和分支保护的目的是什么？

• 为了缩短调整周期，更快地抓住漂移。
• 为了减少存储库容量，提高克隆速度。
• 为了限制代理可以读取的目录范围。
• 为了将发布权限移到存储库权限，每次变更时强制需要审查的人。

GitOps引进后，还需要观测体系的原因中，最准确的是什么？

• 因为即使存储库和群集一致，也需要单独确认该声明是否给用户带来好的结果。
• 因为代理不会在任何地方记录调整失败。
• 因为仅凭存储库历史记录无法知道是谁发布的。
• 因为轮询周期长的话，提交可能会丢失。

Continuous Delivery和Continuous Deployment的区别中正确的是什么？

• Delivery是用于容器环境，Deployment是用于虚拟机环境的术语。
• Delivery保持随时可以部署的状态，Deployment自动连接到该部署。
• Delivery包括自动部署，Deployment包括手动批准
• 这两个术语的意思相同，只是根据地区而表达方式不同。

将政策用代码管理并放入GitOps流程中时获得的最大优势是什么？

• 只有在运行时才能检测政策违规。
• 政策文件可以单独管理在Wiki中。
• 即使没有集群管理员权限也能绕过政策。
• 政策本身可以经过审查和版本管理，在合并前通过检查执行。

从平台工程的角度看GitOps，提供给开发者的接口是什么？

• 这是用于集群访问的kubeconfig文件
• 这是发给分发负责人的请求票。
• 这是上传到设置存储库的完整请求。
• 这是调整引擎的管理者控制台。

作为蓝色/绿色分发的特点，正确的是什么？

• 以比例慢慢移动流量，观察指标。
• 将新版本依次替换到现有平板电脑中。
• 只向部分用户以功能标志暴露
• 准备一个规模相同的全新环境，并一次性切换流量。

在卡纳里部署中，作为自动回滚判断的依据，最合适的是什么？

• 以向金丝雀的交通错误率和延迟指标为基准线与比较。
• 确认新帕德是否达到执行状态
• 发放后确认是否超过了规定的过期时间。
• 确认图像标签是否正常更新

渐进式传递与简单的滚动更新区分的关键是什么？

• 就是一次只更换一个垫子。
• 不是分发工具，而是CI进行转换。
• 每个转换阶段都使用观测指标来判断，决定进行或停止。
• 就是不立即删除以前版本的文件夹。

以基于事件的同步和基于轮询的同步同时使用的构成的性质中，正确的是什么？

• 如果网页链接进来，投票就会中断，所以两种方式是排他性的。
• Webhook减少延迟， polling 作为 Webhook 丢失的安全网，相互补充。
• 如果同时使用两种方式，会发生重复应用，状态就会被破坏。
• POLLING是pull，WEBHOOK是push，所以原则上不能一起使用。

在一个地方管理多个群集的外部调整器结构的代表性缺点是什么？

• 管理群集将汇集所有目标群集的证书信息，因此如果受到侵犯，影响范围会扩大。
• 每个目标群集都必须单独安装代理，并分别升级。
• 不能根据每个群集使用不同的宣言书。
• 不能将投票周期按每个群集设置不同。

当多个团队一起使用一个设置存储库时，最先要准备的是什么？

• 每个团队都启动单独的调整引擎实例。
• 这是目录单位所有权及其相应的审查规则。
• 这是统一提交消息格式的规定。
• 这是为了减少存储库大小而设置的浅层克隆。

在多个群集上部署相同的应用程序时，每个群集只想让值不同。最合适的结构是什么？

• 复制存储库的数量，分别修改。
• 只留下一份宣言书分发后，用手收钱。
• 每个群集都创建不同的分支，然后分配价值。
• 以共同基准为基础，仅用每个聚类的叠加或值文件来表示差异。

在网络入站被堵塞的私有群集上应用GitOps时，pull模式有利的原因是什么？

• 代理在里面和外面走动读取储存器，所以不需要打开入库通道。
• 因为代理程序即使没有状态存储库也能运行。
• 因为pull模型不使用加密，所以不需要防火墙例外。
• 因为pull模型不需要任何资格证明。

在卡纳里途中发生了自动滚动，但设置存储库仍然指向新版本。这时会发生什么？

• 调整引擎将回滚结果自动提交到存储库。
• 在下次调整中，可能会再次推迟到新版本进行部署，所以仓库也需要恢复。
• 分发控制器永久阻止该应用程序的同步
• 因为新版本已经失败了，所以调整引擎不再尝试了。

根据功能标志和部署战略的关系，正确的是什么？

• 使用功能标志的话就不需要部署策略了。
• 功能标志是部署工具分流流量的方式的另一个名称。
• 功能标志使滚动无法恢复，与GitOps不相容。
• 将发布和功能公开分开，单独控制已经发布的代码是否暴露。

当多个应用程序依赖相同的自定义资源定义时，如何安全地处理部署顺序？

• 将所有应用程序合并为一个manifest文件
• 每个应用程序都设置不同的调整周期，从而产生时差。
• 将其分为先应用正义的阶段，然后将其余部分放在后续阶段。
• 等待失败的应用程序被人重新同步。

当多个团队共享一个群集时，从GitOps的角度创建租户界限的方法是什么？

• 根据团队设置限制对象命名空间和允许资源、源存储库的项目边界。
• 每个团队都不同地设置调整周期和重试次数。
• 根据团队不同，分别发放签名密钥。
• 每个团队都使用单独的图像注册表。

Kustomize和Helm的区别中正确的是什么？

• Kustomize将补丁覆盖在现有YAML上进行渲染，Helm则用模板和值生成配置文件。
• Kustomize使用模板语言，Helm使用补丁合并
• Kustomize仅在群集中运行，Helm仅在群集之外运行
• 两个是同一工具的不同发行版，功能没有差异。

Flux从存储库读取内容和应用配置文件的工作由不同的控制器负责，这是为什么？

• 因为每个控制器要求的容器管理版本都不一样。
• 因为应用控制器无法解释Git协议。
• 为了分开获得和调整源代码，让多个对象共享一个源代码，并单独处理失败。
• 因为每个控制器都有不同的许可证，所以不能一起分发。

为了附加调整发动机的通知功能，最合适的是什么？

• 通知到达后，调整循环才会开始下一个周期。
• 成为存储通知频道想要的状态的第二个存储器。
• 通过通知，运营者可以直接修复群集。
• 在人知道同步失败或状态降低的情况下，建立路径，关闭反馈循环。

当新图像上传到注册表时，为了遵守自动更新设置存储库的原则，需要什么？

• 必须直接修改集群的Deployment映像字段
• 必须将新标签或摘要提交到设置存储库，让调整引擎读取它。
• 必须清除调整引擎的缓存，然后强制重新获取。
• 必须将注册表作为想要的状态的来源。

关于使用不是Git而是OCI艺术品存储库作为状态存储库的构成的说明，正确的是什么？

• 原则上只允许Git，所以这个配置不是GitOps。
• OCI存储库没有历史记录，无法还原。
• 版本被标记为不可变，如果代理可以拉取的话，原则上没有问题。
• 使用OCI存储库的话就不需要调整循环了。

调整引擎发送的指标中，查看部署健全性的最直接的是什么？

• 是每个应用程序的同步状态和最后成功同步后的经过时间。
• 是设置存储库的总提交数。
• 这是控制器帕德使用的图像标签。
• 这是集群节点的磁盘使用量和剩余容量。

渲染模板的结果，将Manifest也提交到存储库的方式的优点是什么？

• 因为调整引擎不需要支持模板工具，所以工具选择问题消失了。
• 可以直接审查完整请求中实际应用的YAML的差异。
• 存储空间减少，克隆速度加快。
• 不再需要管理价格文件了。

连接调整引擎和CI工具时不推荐的配置是？

• CI构建图像，并将参考更新提交上传到设置存储库
• 执行CI在解锁请求中提前显示渲染结果的检查。
• CI将政策检查和模式验证合并为条件执行。
• CI拿着集群资格证书进行分发后，通知调整引擎结果。