10.1 GitOps 出现的背景
我们先来看一个传统的云原生应用如何进行持续交付。
下图是一个典型的 Push 交付模型，包含了从开发人员提交代码到代码构建检测再到镜像构建最后进行数据以及后续测试的流程。
当做好自动化以后，可以很好的实践持续集成、持续部署、持续交付，从而提升研发效率。
Push 交付模型的问题
但如果我们认真思考，会发现 Push 模型存在一个很大的问题：流程都是从左往右推进，针对于云原生应用（一切都可以用 yaml 文件进行描述，并存储在配置仓库中），很难保证配置描述和云原生底座（例如 kubernetes 集群）上的实际状态真正相符，随着时间的推移，很容易发生另外一种“配置漂移”（配置仓库和实际状态不相符合）。
随着集群数量和应用程序的增多，工程师们将疲于应对线上和配置状态不一致问题，还产生各类安全合规问题（人工操作 kubectl，无法追溯、不可回源等问题）。
解决问题的核心：声明式设计
你是否还能想起第一章声明式的介绍：
声明式设计要点
我们向一个工具描述我们想要让一个事物达到的目标状态，由这个工具自己内部去解决如何令这个事物达到目标状态。
既然云原生应用的部署底座是 Kubernetes，而 Kubernetes 是一种声明式系统，也即意味着应用可以用 yaml 文件来进行描述（例如使用 kustomize、Helm 定义应用）。只要把这些 yaml 文件存储在 GitHub/GitLab 等上，再有一个自动同步的机制——完成 GitHub/GitLab 上描述文件的变更到 kubernetes 集群上应用的更新。
如此，以声明式系统为基座、以 Git 为单一可信源的一种新型交付理念呼之欲出。
总字数:553字