10.2 GitOps 的实施要素和流程

实施 GitOps 由以下三个要素：

一切皆代码：因为 GitOps 要将一切（不仅包含 IaC，也涵盖应用组织、状态描述等）代码化，然后用 Git 进行版本控制，应用程序或者基础设施的变更也都是通过 Git 进行。所以，GitOps 也被称为 IaC（Infrastructure as Code，基础设施即代码） + Git + CI/CD。
Git 为单一可信源：所有的变更都要从 Git 仓库侧发起，这样方便代码的安全和审计。
声明式系统为基座：以声明式系统（包括基础设施和应用程序）为基座（典型如 Kubernetes）。

GitOps 三要素下的 CI/CD 流程可以概括为图 10-3。

首先，团队成员 fork 仓库进行业务逻辑开发，然后提交 Pull Request。
接下来运行 CI 流水线，例如校验配置文件、执行自动化测试、构建镜像、推送到镜像仓库等。
CI 流水线执行完成后，拥有合并代码权限的人将 Pull Request 合并到主分支。
合并的事件触发 CD 流水线，结合 CD 系统（例如 Argo CD）将变更自动应用到目标集群中。

图 10-3 GitOps 下的 CI/CD 流程

基于 Git 仓库作为集群状态的唯一真实来源，再加上 Argo CD 这种自动同步的系统，那么就能：

回滚更快速：Argo CD 会定期拉取最新配置并应用到集群中，一旦新提交的配置导致应用出现故障，可通过 Git 历史将应用状态快速恢复到上一个可用状态。
集群灾备更简单：假如某个可用区的 Kubernetes 集群出现故障，且短期内不可恢复。这个时候可以直接创建一个新集群，然后将 Argo CD 关联到 Git 仓库，新的集群将自动同步仓库内所有应用的配置声明，期间完全不需要人工干预。
合规及安全：基于 Git 实现访问控制，开发人员 Pull Request，管理人员 Merge Request，没有额外的权限系统。且 Argo CD 已经部署在 Kubernetes 集群中，必须的访问权限已经配置妥当。除了集群管理员和少数人员外，其他人不再直接访问 Kubernetes 集群，这样就不再提供额外的证书、权限等，从而为 Kubernetes 集群提供更安全的保证。

总字数:618字