共计 2450 个字符，预计需要花费 7 分钟才能阅读完成。
2020 年 CNCF 中国云原生考察邀你一起来参加！
问卷链接（https://www.wjx.cn/jq/9714648…）
作者：Kostis Kapelonis
Argo CD（Argo 我的项目的一部分）是一个为 Kubernetes 而设的部署解决方案，遵循 GitOps 模式。
应用 Argo CD 部署到 Kubernetes
在最根本的场景中，Argo CD 应用 Kubernetes 清单继续监督 Git 仓库（也反对 Helm 和 Kustomize）并监听提交事件。
当产生提交（通常是更新镜像工件版本的提交）时，Argo CD 会启动一个“同步（synchronization）”过程，该过程负责使集群配置处于与 Git 中形容的雷同的状态。
当同步过程实现时，咱们晓得应用程序配置与 Git 清单完全相同。
Argo CD 的部署过程体现了 GitOps 背地的核心理念：
- 所有应用程序配置都存储在 Git 中（通常在与源代码不同的存储库中）
- 部署以一种“拉”形式进行，即集群从 Git 获取清单（而不是将更新“推”到集群的传统解决方案）。
- 部署是两种状态之间的协调过程（Git 中形容的状态与集群中部署的状态）
只管同步过程对于执行应用程序的初始部署是至关重要的，但 Argo CD 真正的劣势之一是在部署实现后可能继续监控两个状态（集群和 Git）。这种继续的监督对于解决配置漂移十分重要，配置漂移在具备大量部署指标的组织中是一个十分常见的问题。
不同 Kubernetes 集群之间的配置漂移
配置漂移是一个即便在传统虚拟机中也存在的问题，而且早在 Kubernetes 呈现之前，它就始终困扰着生产部署。当 CI/CD 平台执行到多个指标的部署并失败时，问题就会显现出来，因为一组本应类似的机器实际上配置不同。
在一些组织中，开发人员在应用程序部署到生产环境之前应用“登台（staging）”环境来测试其应用程序。现实状况下，登台环境应该与生产环境的配置相匹配，这样开发人员就能够确信他们在登台中执行的任何测试都将与生产环境严密匹配。
特地是在 Kubernetes 集群中，团队常常应用特地的命令（例如，通过 kubectl）在一个齐全不在 CI/CD 过程之外的集群上执行更改。
这些特地的更改是应用程序部署的一个次要问题。配置上的差别是导致部署失败的最常见起因之一。在登台环境中胜利通过所有测试的应用程序在生产中会呈现中断状态，因为没有提供所需的设置或采纳预期的格局。
另一个由配置漂移引起的暗藏问题是，逐步失落了在机器 / 节点上部署了什么以及最初一次更改的确切工夫的常识。Argo CD 解决了这个问题，它将 Git 作为以后部署和过来所有部署的实在起源。
在部署失败后，运营者和开发人员试图理解事变的起因，他们问的第一个问题是“这个集群最初产生的变动是什么”。如果集群在批准的 CI/CD 过程之外产生了未管制的更改，那么这个问题很难答复。
Argo CD 如何检测配置漂移问题
Argo CD 采纳了一种齐全不同的部署办法（“pull from Git”范式）。因为所有部署都能够追溯到 Git 提交，所以 Git 提交历史记录也是集群部署历史记录。
开发人员能够应用他们喜爱的 Git 工具来答复诸如“上周四集群上部署了什么？”或者“这周周一到周四之间产生了什么变动？”
让咱们假如团队中的一个人齐全绕过了 Argo CD，并应用 kubectl 间接对集群进行手动更改。其余 CI/CD 解决方案将齐全疏忽此更改，这为配置漂移问题提供了环境。
Argo CD 会了解集群上产生了变动，这两种状态（集群配置和 Git 清单）不再雷同。部署将立刻标记为“不同步（out-of-sync）”。
Argo CD 也将开掘得更深刻，甚至提供了一个很好的差别概述，扭转了什么：
在下面的例子中，Argo CD 检测到集群和 Git 之间服务的端口配置不再雷同。
当你检测到这样的差别，你能够手动使应用程序处于与 Git 雷同的状态（再次执行同步过程），或者批示 Argo CD 在检测到配置更改时主动进行本身的同步。
这意味着 Argo CD 配置的漂移（至多对 Kubernetes 应用程序而言）齐全打消了，特地是在启用了主动同步行为的状况下。
应用 Argo CD 的团队能够释怀地进行部署，因为他们晓得集群处于它应该处于的状态（该状态在 Git 清单中也有残缺的形容）。配置漂移不再是一个问题，放弃登台和生产过程尽可能靠近是一个非常简单的过程。
Argo 与 Devops 平台 的联合
除了 Argo CD 的次要我的项目，你可能也会发现 Argo Rollouts 我的项目很乏味。Argo Rollouts 是 Argo 的另一个我的项目，用于对 Kubernetes 进行渐进式（蓝 / 绿 / 灰度）部署。
Argo CD 和 Argo Rollouts 对于解决应用程序部署来说是十分好的，然而它们须要与一个残缺的自动化解决方案相结合，这个解决方案也将处理软件生命周期的所有其余方面，比方应用程序构建、单元测试、机密治理和拉取申请解决等。
Argo CD 非常适合理论部署，但它假如工件曾经由另一个解决方案创立。这就是为什么咱们始终致力将 Codefresh 和 Argo 集成在一起，以笼罩整个软件生命周期，甚至笼罩主动将变更推送到 Argo 监控 manifest 的 Git 仓库的场景（即执行主动提交，从而实际继续部署）。
理解更多信息，请拜访 Argo 的主网站。
Kostis Kapelonis 是 Codefresh 的开发者倡导者，Codefresh 是一个为 Kubernetes 和容器构建的继续交付平台。Kostis 以前是一名软件工程师，领有多年利用容器、构建 CI/CD 流水线和开发 Java 应用程序的教训。他住在希腊，喜爱滑旱冰。
点击浏览网站原文。
CNCF (Cloud Native Computing Foundation)成立于 2015 年 12 月，隶属于 Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。
