CAPA 模拟考 A

Workflow 资源的 entrypoint 字段指定什么？

• 工作流 Pod 要运行的容器镜像
• 保存结果制品的路径
• 工作流使用的 ServiceAccount 名称
• 从 templates 列表中的哪个模板开始执行

关于 Workflow 与 WorkflowTemplate 的关系，哪项正确？

• WorkflowTemplate 一经提交就会自行运行
• WorkflowTemplate 是保存在命名空间内、可复用的定义；执行由引用它的 Workflow 或提交操作启动
• Workflow 是定义，WorkflowTemplate 是执行实例
• 两者是同一种资源，只是名称不同

为什么使用 ClusterWorkflowTemplate？

• 为了把模板自动复制到多个集群
• 为了提高模板执行速度
• 因为它是不受命名空间约束的集群级模板，可供多个团队引用相同的公共步骤
• 为了只允许集群管理员提交工作流

与 container 模板相比，Argo Workflows 的 script 模板提供什么便利？

• 把 source 中的代码写入临时文件，并将文件路径作为最后一个参数传给镜像内由 command 指定的解释器
• source 中的代码在控制器进程内执行，因此不需要执行镜像和工作流 Pod
• 只有 script 能把标准输出作为 outputs.result 提供，container 只能提供基于文件的输出参数
• source 中的代码始终按 Python 解释，即使 image 中安装了其他解释器也无法选择

resource 模板的作用是什么？

• 为每个模板分别指定工作流 Pod 的 CPU 和内存请求
• 通过 create 或 apply 等操作处理 Kubernetes 清单，并指定成功条件，等待资源达到期望状态
• 预留制品存储库容量
• 创建工作流使用的卷

哪种场景最适合使用 suspend 模板？

• 自动重试失败的步骤
• 并行执行多个步骤
• 在生产部署前等待人工批准
• 压缩并保存制品

steps 是 [[A], [B, C]] 形式的嵌套列表，且三个步骤都成功、没有额外条件时，执行依赖关系是什么？

• A 成功后，B 和 C 作为同一并行组进入可执行状态
• A 成功后必须先等 B 成功，C 才可执行
• 即使内层列表不同，A、B、C 也从一开始都可执行
• B 和 C 会分别成为独立 Workflow，与 A 是否完成无关

在 dag 模板中，depends 字段比 dependencies 字段强在哪里？

• 可以同时列出多个前置任务
• 可以缩短执行时间
• 允许循环依赖
• 可以把前置任务的结果状态写入条件，从而表达仅在失败时运行等流程

希望对输入列表中的每一项重复运行同一步骤，应使用什么？

• 用 retryStrategy 指定重复次数
• 把 parallelism 提高到条目数量
• 用 withItems 或 withParam 展开条目并生成并行任务
• 按条目数量手动复制该步骤

工作流中区分参数和制品的标准是什么？

• 参数用于传递较小的字符串值，制品用于通过存储库传递文件或目录
• 参数只能作输入，制品只能作输出
• 参数只能用于 dag，制品只能用于 steps
• 制品只能在同一个 Pod 内传递

输出制品无法传给下一步骤并报错时，首先应检查什么？

• 工作流的 entrypoint 名称
• dag 任务名称的长度
• 分配给 Pod 的 CPU 请求量
• 是否配置了制品存储库，以及工作流能否凭其凭据读写该存储库

需要在步骤之间共享大型中间文件，为什么使用 volumeClaimTemplates？

• 因为它会自动缩短工作流执行时间
• 因为它能为每次工作流创建卷，让多个步骤共享同一磁盘，并可在结束后清理
• 因为它是替代制品存储库的唯一方式
• 因为它会加密 Pod 间的网络流量

同时指定 retryStrategy 的 limit 和 backoff 时会怎样？

• 第一次尝试前先等待一个 backoff 周期
• 忽略 limit，一直重试到成功
• 设置 backoff 后 limit 会自动变成无限
• 失败步骤最多按 limit 重试，并依据 backoff 规则逐渐增加重试间隔

已完成的工作流对象持续累积并给 etcd 带来压力，应如何处理？

• 为每个工作流新建命名空间
• 用 ttlStrategy 设置完成后的保留时间并自动删除，若需历史记录则另行启用归档
• 把控制器 parallelism 降为 1
• 另建定时任务手动删除已完成的工作流

工作流结束后 Pod 仍保留，而只需要日志时，应使用哪些设置？

• 用 activeDeadlineSeconds 规定 Pod 寿命
• 把 parallelism 设为 0 以停止 Pod
• 用 podGC 策略决定何时清理 Pod，并通过归档设置把日志保存在存储库中
• 在末尾添加 suspend 模板以保留 Pod

无论工作流成功还是失败，都要发送通知，应怎么做？

• 用 onExit 指定退出处理模板，使其在工作流结束时始终执行
• 在最后一步添加通知任务
• 把 retryStrategy 的 limit 设为 0
• 用 CronWorkflow 定期运行通知专用工作流

关于工作流控制器与执行器（executor）的职责划分，哪项正确？

• 控制器直接执行每个步骤的命令
• 控制器观察工作流状态并决定下一步创建哪个 Pod；执行器在 Pod 内负责命令执行、制品处理和输出收集
• 执行器接收工作流提交、调度 Pod，再通知控制器
• 两者在同一个 Pod 内共同运行

工作流步骤尝试创建 Kubernetes 资源时因权限错误失败，应检查什么？

• 工作流的 entrypoint 是否正确
• 制品存储库是否还有容量
• 工作流使用的 ServiceAccount 是否具备操作该资源的 RBAC 权限
• 控制器日志级别是否为 debug

要防止多个工作流同时操作同一个外部系统，应使用什么？

• 用 synchronization 的 mutex 或 semaphore 限制并发执行数
• 增加各工作流的 retryStrategy
• 把工作流放入不同命名空间
• 把 podGC 策略改为 OnPodCompletion

CronWorkflow 中，控制器短暂停止而错过计划时间时，由哪个字段决定如何处理？

• ttlStrategy
• activeDeadlineSeconds
• parallelism
• startingDeadlineSeconds

希望在多个工作流中复用同一步骤，关于模板引用哪项正确？

• 被引用的模板在保存时而非执行时复制并固定下来
• 通过 templateRef 指向另一个 WorkflowTemplate 中的模板，可以集中管理定义并供多个工作流使用
• 模板只能在同一工作流内引用
• 引用前必须把模板复制到 ConfigMap，并放在同一命名空间

即使某个任务失败，也要继续其余流程，应使用什么设置？

• 用 continueOn 指定失败时仍继续后续任务
• 增加 activeDeadlineSeconds
• 把 podGC 设为 OnWorkflowCompletion
• 把 entrypoint 改成该任务

Argo CD Application 的 destination 指定什么？

• 资源要部署到的目标集群和命名空间
• 存放清单的 Git 仓库地址
• 发送同步结果通知的频道
• Helm chart 的 values 文件路径

自动同步中 prune 与 selfHeal 有什么区别？

• prune 回滚失败的同步，selfHeal 执行重试
• prune 删除集群中已从 Git 消失的资源，selfHeal 将集群内直接修改的状态恢复为 Git 中的状态
• prune 只作用于命名空间，selfHeal 只作用于 Pod
• 两者功能相同，只需启用一个

Application 要部署到的命名空间尚不存在时，应使用哪个同步选项？

• Replace
• ApplyOutOfSyncOnly
• Validate
• CreateNamespace

要在应用部署之前运行数据库迁移，应使用哪个资源钩子？

• PreSync
• PostSync
• SyncFail
• Skip

由钩子创建的 Job 不断累积，应通过什么设置控制？

• 启用同步选项 Replace
• 缩小 AppProject 的 destinations
• 降低 Application 的 revisionHistoryLimit
• 指定钩子删除策略，在成功后或下次运行前删除旧钩子资源

只有证书控制器管理的 caBundle 与 Git 不同。已确认该字段由外部管理，且仍要监控其他差异，应如何配置比较？

• 只关闭自动同步，比较也会停止，因此 OutOfSync 提示会消失
• 将整个证书资源排除在比较之外，同时忽略其他字段变化
• 将 ignoreDifferences 精确限定到该资源及 caBundle 路径
• 从 Git 删除证书资源，并通过自动 prune 删除实际资源

哪一项正确匹配了 Argo CD 组件及其职责？

• repo-server 负责用户认证
• application-controller 提供 Web UI
• redis 复制并保存 Git 仓库
• repo-server 生成清单，application-controller 将其与集群状态比较并执行同步

Argo CD 处理 Helm chart 时，哪项描述正确？

• 它应用 chart 渲染出的清单，因此集群中留下的是各个资源，而不是 Helm release
• 它直接运行 helm install 并创建 release secret
• 它不支持 Helm chart，必须先转换为 Kustomize
• 它完全不支持 chart 钩子

删除 Application 后，集群中的资源也一并被删。是什么决定了这一行为？

• 同步策略的 selfHeal 设置
• 资源上存在级联删除 finalizer，从而执行了连锁删除
• AppProject 的角色设置
• repo-server 的缓存过期设置

Argo CD 正在跟踪分支并启用了定期刷新，但没有 Webhook；仓库访问和签名验证均无错误。为什么 push 后不能立刻检测到变更，如何改善？

• 可能要等到下一次定期刷新；连接 Webhook 可缩短变更检测等待时间
• 分支跟踪不会读取新提交，必须为每次提交打标签才能检测
• 启用自动同步后，Git 变更检测会自动从轮询切换为 Webhook
• Webhook 会跳过比较并立即应用清单，因此也会自动绕过手动同步策略

为什么要区分 Sync 状态与 Health 状态？

• Sync 表示最近同步是否成功，Health 表示同步耗时
• Sync 只能在 UI 查看，Health 只能在 CLI 查看
• Sync 表示 Git 与集群清单是否一致，Health 表示已部署资源是否真正正常运行，因此可能出现 Synced 但 Degraded
• 两者总是同步变化，本质上是同一个指标

某个自定义资源一直处于 Progressing，应如何处理？

• 将该资源排除在同步目标之外
• 关闭自动同步
• 把资源改成 Deployment
• 为该资源类型注册自定义健康检查，定义何种状态算健康

多个团队共用一个 Argo CD 时，AppProject 的作用是什么？

• 自动为每个团队创建独立 Argo CD 实例
• 限定可从哪些仓库向哪些集群和命名空间部署哪些类型的资源
• 强制执行团队资源配额
• 设置 Git 仓库的分支保护规则

关于 Argo CD RBAC 中项目角色与全局策略的关系，哪项正确？

• 项目角色始终覆盖全局策略
• 存在全局策略时项目角色会被忽略
• 全局策略规定整个实例的权限，项目角色在项目范围内授予权限，用于按团队委派
• 两者必须写在同一文件中，且只能二选一

要让用户通过组织账号登录 Argo CD，应采用什么方式？

• 通过 OIDC 或内置 Dex 对接外部身份提供商，并尽量限制本地管理员账号
• 为每位用户创建本地账号并分发初始密码
• 在团队聊天中共享 API token
• 共用一个管理员账号

要在一个 Application 中同时使用多个仓库的清单和值文件，应怎么做？

• 每个仓库创建一个 Application，再手动协调顺序
• 把所有清单复制到同一个仓库
• 使用可指定多个 source 的多源配置，并从另一个 source 引用值文件
• 按仓库数量部署多个 repo-server

ApplicationSet 的 cluster generator 做什么？

• 根据仓库目录列表创建 Application
• 读取已注册到 Argo CD 的集群列表，并为每个集群创建 Application
• 自动创建并注册新集群
• 按集群节点数调整副本数量

在 UI 中创建的 Application 在重建集群后全部消失，如何避免再次发生？

• 定期转储并备份 Argo CD 的内部存储
• 在 UI 创建后保存截图
• 把 Application 声明为清单存入 Git，并由上层 Application 管理
• 制定禁止重建集群的策略

关于 Argo CD 识别自己所管理资源的方式，哪项正确？

• 根据资源创建时间判断所有权
• 只有命名空间名称与应用名称相同时才视为受管资源
• 在受管资源上写入跟踪信息，标示其所属 Application；可配置使用标签或注解方式
• 必须在清单中显式填写所有者才能识别

要控制同步顺序，先创建 CRD，再创建自定义资源，应怎么做？

• 按字母顺序排列资源文件名
• 设置 sync wave，使数值较小的资源先应用
• 分别交给不同的 Argo CD 实例
• 手动执行两次同步

把现有 Deployment 迁移为 Rollout 时，使用工作负载引用有什么好处？

• 可直接引用 Deployment 的 Pod 模板，无需重复定义，只叠加渐进式发布策略
• 让 Rollout 在没有 Deployment 时也能运行
• 自动把副本数增加一倍
• 无需分析也能保证自动晋级

要让金丝雀策略的 setWeight 精确控制实际流量比例，需要什么？

• 将副本数设为 100 的倍数以精确分配比例
• 给 Pod 添加标签
• 将节点划分为金丝雀专用节点
• 对接支持流量路由的 Ingress 或 Service Mesh 等提供方；否则只能按副本比例近似

金丝雀步骤中设置不带 duration 的 pause 会怎样？

• 默认 5 分钟后自动进入下一步
• 无限期等待，直到有人发出晋级命令
• Rollout 会被判定为失败
• 立即进入下一步

AnalysisTemplate 的作用是什么？

• 保存 Rollout 历史
• 限制金丝雀 Pod 的 CPU 和内存用量
• 定义指标查询和成功条件，在 Rollout 过程中自动判定，失败时促使回滚
• 创建 Ingress 规则

以下哪项不能作为分析的指标提供方？

• Prometheus 查询
• 调用任意 HTTP 端点的 Web 方式
• 运行 Kubernetes Job 并检查退出码
• 读取 Git 仓库的提交消息

蓝绿策略为什么要区分 activeService 和 previewService？

• 因为两个 Service 分别管理不同命名空间
• 为了先通过预览地址验证新版本，确认就绪后再把真实流量地址切换到新版本
• 因为单个 Service 不能拥有两个以上副本
• 为了分别收集旧版本日志

在蓝绿发布中关闭自动晋级后会怎样？

• 新版本不会部署
• 旧版本会立即删除
• 配置的分析步骤会自动停用
• 新版本就绪后仍不接管活跃流量，而是等待手动晋级

金丝雀发布过程中发现问题，要立即回退，应采取什么措施？

• 执行中止 Rollout 的命令，把流量切回之前的稳定版本
• 把副本数降为 0
• 删除命名空间
• 晋级到下一步骤以完成发布

什么场景适合使用 Experiment 资源？

• 查询已完成 Rollout 的历史
• 按团队分配各命名空间的资源配额
• 续期 Ingress 证书
• 在指定时间内并行运行多个版本，比较指标并据此决定是否发布

只想给金丝雀 Pod 临时添加标签，以便区分指标，应使用什么功能？

• 在 Pod 模板中添加标签，每次再手工删除
• 为金丝雀和稳定状态分别指定临时元数据，使符合当前角色的标签自动添加并在晋级后清理
• 在 AnalysisTemplate 中定义标签
• 直接修改 Service 的 selector

Rollout 的 revisionHistoryLimit 有什么作用？

• 限制可同时执行的金丝雀步骤数量
• 规定分析结果的保留时间
• 限制为回滚而保留的旧 ReplicaSet 数量
• 限制 Rollout 对象的最大大小

Argo Events 的 EventSource 做什么？

• 定义事件条件满足时要执行的动作
• 接收 Webhook、日历或消息队列等外部事件，并将其送入 EventBus
• 把事件永久保存在存储系统中
• 把工作流执行结果作为通知发送

为什么要使用 EventBus？

• 为了在界面上可视化事件
• 为了检查 EventSource 发出事件的权限和签名
• 作为松耦合 EventSource 与 Sensor 的传输层，使一个事件可被多个 Sensor 接收，并能承受短暂故障
• 为了调度工作流 Pod

Sensor 的 dependencies 指定什么？

• trigger 将创建资源的依赖顺序
• Sensor Pod 所需的容器镜像列表
• EventBus 的副本数
• 等待哪个 EventSource 的哪个事件，并可通过过滤器进一步缩小条件

只响应推送到特定分支的事件，应如何实现？

• 在 dependency 上添加检查事件正文相应字段的数据过滤器
• 为每个分支创建一个 EventSource
• 让 trigger 启动的工作流自行检查分支后退出
• 为每个分支拆分一个 EventBus

如何把事件中的值传给 trigger 所创建工作流的输入？

• 在 trigger 参数中指定事件 payload 路径，并把值写入目标资源字段
• 事件会自动注入环境变量，无需额外配置
• 将 Sensor 与工作流放在同一个 Pod
• 先把事件保存到 ConfigMap，再让工作流读取

只有多个事件全部到达后才执行动作，应如何配置？

• 按事件数量复制 trigger
• 为每个事件创建独立 Sensor，再由人工核对结果
• 声明多个 dependency，并用 trigger 条件表达式描述逻辑关系
• 增加 EventSource 的轮询间隔，让事件积累

以下哪项不能作为 Sensor 的 trigger 目标？

• 创建 Argo Workflow
• 创建或更新任意 Kubernetes 对象
• 发送 HTTP 请求
• 修改节点内核参数