测验：Argo 项目全景

说 GitOps 的拉式部署模型比推式模型更好的最准确依据是什么？

• 清单可以编写为简单的 YAML，因此学习曲线较低。
• 部署速度比kubectl apply更快
• 您可以为每个集群创建单独的管道。
• 集群凭证永远不会离开 CI 系统，并且控制器不断地比较它们，因此状态中会出现偏差。

不将 Argo CD 和 Argo Workflows 合并到一个控制器中的最根本原因是什么？

• 这是因为两个项目的开发团队不同。
• Argo CD 是无限协调循环，没有完成的概念，而工作流是有限执行，完成就是一切，因此重试、失败和成功的含义不同。
• 这是因为 Workflows 的创建比 Argo CD 晚很多，所以没有机会将它们结合起来。
• 因为工作流不使用 CRD

Argo Events 作为一个单独的项目而不是包含在 Argo CD 中最合适的原因是什么？

• 因为 Argo CD 根本不处理 webhooks。
• 这是因为 Argo Events 被设计为只能在 Kubernetes 集群外部运行，不能放置在集群内部。
• 为了避免将各种外部信号适配器（例如 GitHub、S3、Kafka、日历）放入分发控制器中，将其分成一个单独的轴，称为 EventSource/Sensor/Trigger。
• 因为 Events 不是 CNCF 项目

Argo CD被评为CNCF Graded，对于实际判断最合适的含义是什么？

• 这意味着您可以免费使用它。
• CNCF 已证明其性能比其他 GitOps 工具更快。
• 这是不存在安全漏洞的保证。
• 这是API和运行已经进入稳定阶段的信号，也是判断Application Manifest可以作为组织标准的依据。

即使由三个 etcd 成员维持仲裁，也可能会出现无法使用 kubectl 连接到集群的情况。最常见的原因是什么？

• 所有客户端的服务器地址固定为特定控制平面的物理IP，并且apiserver证书SAN中没有其他节点IP。
• 没有etcd快照备份。
• 因为控制平面的数量不是奇数，
• kubelet 版本高于 apiserver，因此不存在版本倾斜。

您的 Argo 项目与该角色之间的不匹配之处是什么？

• Argo Rollouts — 通过查看指标来提高 Canary 和 Bluegreen 新版本的曝光率
• Argo Workflows——容器任务组合成DAG一次完成
• Argo CD — 构建容器镜像并将其推送到注册表
• Argo Events — 接收外部信号和火灾触发器