10.1 GitOps 出现的背景
先来看一个传统的云原生应用如何进行持续交付。图 10-1 展示了一个传统的 Push（也就是主动推进）交付模型，该交付模型包含了开发人员提交代码 ，代码质量检测（使用 SonarQube），Docker 镜像构建，以及使用 Helm 部署到 Kubernetes 集群的整个过程。
图 10-1 Push 交付模型
上述流程做好自动化以后，看起来也没什么问题。
10.1.1 Push 交付模型的问题
但认真思考，会发现 Push 交付模型中的流程都是从左往右推进。如果是云原生应用（用 yaml 文件描述，并将配置存储在仓库中的应用），随着时间的推移会出现下面问题：
- 很难保证配置描述的状态和云原生底座（如 kubernetes 集群）中的运行状态真正相符。时间长了，容易发生“配置漂移”情况，即配置的期望状态和集群运行状态不相符；
- 随着集群数量和应用程序的增多，工程师们将疲于应对线上和配置状态不一致问题。因为人工操作 kubectl，无法追溯、不可回源等，还产生各类安全合规问题。
10.1.2 解决问题的核心：声明式设计
你是否还能想起本书第一章关于声明式的介绍。
声明式设计要点
我们向一个工具描述我们想要让一个事物达到的目标状态，由这个工具自己内部去解决如何令这个事物达到目标状态。
云原生应用的部署底座是 Kubernetes，Kubernetes 是一种声明式系统，它使用 yaml 来定义系统的最终状态应该是什么样子。如果把这些描述应用状态的 yaml 文件存储在 Git 仓库中，再实现 git 仓库中配置和集群状态自动同步的机制。如图 10-2 所示，一种以声明式系统为基座、以 Git 为单一可信源的新型交付模型出现了。
图 10-2 GitOps 中的应用同步模型
总字数:555字
