update

GitOps/background.md

@@ -1,13 +1,15 @@
 # 10.1 GitOps 出现的背景
 
-先来看一个传统的云原生应用如何进行持续交付。图 10-1 是一个典型的 Push 交付模型，包含了从开发人员提交代码到代码构建检测再到镜像构建最后进行数据以及后续测试的流程。
+先来看一个传统的云原生应用如何进行持续交付。
+
+图 10-1 展示了一个典型的 Push 交付模型，包含了从开发人员提交代码到代码构建检测再到镜像构建最后进行数据以及后续测试的流程。
 
 :::center
  ![](../assets/cicd-push.png)<br/>
  图 10-1 Push 交付模型
 :::
 
-当做好自动化以后，实施持续集成、持续部署、持续交付，看起来也没什么问题。
+当做好自动化以后，实施持续集成、持续部署/交付，看起来也没什么问题。
 
 ## 10.1.1 Push 交付模型的问题
 
@@ -24,7 +26,7 @@
 我们向一个工具描述我们想要让一个事物达到的目标状态，由这个工具自己内部去解决如何令这个事物达到目标状态。
 :::
 
-云原生应用的部署底座是 Kubernetes，而 Kubernetes 是一种声明式系统，这意味着应用可以用 yaml 文件进行描述（譬如使用 kustomize、Helm 定义应用）。把这些 yaml 文件存储在 Git 仓库中，再有一个链接 git 配置和集群状态自动同步的机制，如图 10-2 所示，以声明式系统为基座、以 Git 为单一可信源的一种新型交付模型出现了。
+云原生应用的部署底座是 Kubernetes，Kubernetes 是一种声明式系统，把应用状态用 yaml 文件进行描述状态（例如 kustomize、Helm 定义应用）。把描述应用状态的 yaml 文件存储在 Git 仓库中，再有一个连接 git 配置和集群状态自动同步的机制，如图 10-2 所示，以声明式系统为基座、以 Git 为单一可信源的一种新型交付模型出现了。
 
 :::center
  ![](../assets/gitops.svg)<br/>