fix typo

isno · Feb 6, 2025 · e62eddf · e62eddf
1 parent 7ad7d7c
commit e62eddf
Show file tree

Hide file tree

Showing 4 changed files with 15 additions and 44 deletions.
diff --git a/application-centric/Controller.md b/application-centric/Controller.md
@@ -10,7 +10,7 @@ Kubernetes 与其他基础设施的最大不同是，它是基于声明式管理
 
 :::center
   ![](../assets/deployment-controller.png)<br/>
-  图 7-1 Kubernetes 的控制器模式
+  图 10-1 Kubernetes 的控制器模式
 :::
 
 总结控制器模式的核心是，用户通过 YAML 文件定义资源的“预期状态”，然后“控制器”监视资源的实际状态。当实际状态与预期状态不一致时，控制器会执行相应操作，确保两者一致。在 Kubernetes 中，这个过程被称为“调谐”（Reconcile），即不断执行“检查 -> 差异分析 -> 执行”的循环。
@@ -27,6 +27,10 @@ IaD 思想主张，基础设施的管理应该脱离特定的编程语言或配
 
 IaD 思想在 Kubernetes 上的体现，就是执行任何操作，只需要提交一个 YAML 文件，然后对 YAML 文件增、删、查、改即可，而不是必须使用 Kubernetes SDK 或者 Restful API。这个 YAML 文件其实就对应了 IaD 中的 Data。从这个角度来看，Kubernetes 暴露出来的各种 API 对象，本质是一张张预先定义好 Schema 的“表”（table）。唯一跟传统数据库不太一样的是，Kubernetes 并不以持久化这些数据为目标，而是监控数据变化驱动“控制器”执行相应操作。
 
+:::center
+表 10-1 Kubernetes 是个“数据库”
+:::
+
 |关系型数据库|Kubernetes (as a database)|说明|
 |:--|:--|:--|
 |DATABASE|cluster|一套 K8s 集群就是一个 database |

diff --git a/application-centric/GitOps.md b/application-centric/GitOps.md
diff --git a/application-centric/Helm.md b/application-centric/Helm.md
@@ -6,7 +6,7 @@
 
 :::center
   ![](../assets/helm.webp)<br/>
-  图 Helm 的工作原理
+  图 10-2 Helm 的工作原理
 :::
 
 Chart 是一个包含描述 Kubernetes 相关资源的文件集合。以官方仓库中 WordPress 应用为例，它的 Chart 目录结构是这样的。

diff --git a/application-centric/OAM.md b/application-centric/OAM.md
@@ -9,22 +9,23 @@
 - **应用边界**（Application Scopes）:定义应用级别的部署特征，比如健康检查规则、安全组、防火墙、SLO、检验等模块。相对于运维特征而言，应用边界作用于一个应用的整体，而运维特征作用于应用中的某个组件。
 - **应用**（Application）：将 Component（必需）、Trait（必需）和 Scope（可选）组合并实例化，形成了一个完整的应用描述。
 
-OAM 使用上述自定义资源将原先 Kubernetes All-in-one 的复杂配置做了一定层次的解耦，应用研发人员负责管理 Component，运维人员 Component 组合并绑定 Trait 变成 Application，平台或基础设施提供方提供 OAM 的解释能力，将这些自定义资源映射到实际的基础设施。
+OAM 通过上述自定义资源将原本复杂的 Kubernetes All-in-one 配置进行了一定程度的解耦。应用研发人员负责管理 Component，运维人员将 Component 组合并绑定 Trait，形成 Application。平台或基础设施提供方则负责 OAM 的解释能力，将这些自定义资源映射到实际的基础设施上。各种角色的关注点恰当地分离，不同角色更聚焦更专业的做好本角色的工作。
 
-整个过程如图所示。
+整个过程如图 10-3 所示。
 :::center
   ![](../assets/OAM-how-it-works.png)<br/>
-  图 4-0 OAM 应用部署计划
+  图 10-3 OAM 工作原理
 :::
 
 KubeVela 是 OAM 规范在 Kubernetes 上的完整实现，它起源于 OAM 社区，由阿里巴巴、微软等技术专家共同维护。
 
-对于平台工程师（Platform Builder）来说，KubeVela 像一个可以无限扩展、Kubernetes 原生的应用构建引擎，他们准备应用部署环境、维护稳定可靠的基础设施功能，并将这些基础设施能力作为 KubeVela 模块注册到集群中；而对于最终用户（End User，研发人员或者运维人员）来说，他们选择部署环境、挑选能力模块并填写业务参数，就可以在不同运行环境上把应用随时运行起来！
+对于平台工程师（Platform Builder）来说，KubeVela 是一个具备无限扩展性的 Kubernetes 原生应用构建引擎。他们负责准备应用部署环境、维护稳定可靠的基础设施，并将这些基础设施能力作为 KubeVela 模块注册到集群中。对于最终用户（End User，研发人员或运维人员）来说，只需选择部署环境、挑选能力模块并填写业务参数，就可以在不同运行环境上把应用随时运行起来！
 
-KubeVela 工作流程如下图。
+
+KubeVela 工作流程如图 10-4。
 :::center
   ![](../assets/kubevela.jpg)<br/>
-  图 4-0 KubeVela 工作流程
+  图 10-4 KubeVela 工作原理
 :::
 
 :::tip 企业落地 Kubernetes 的难题
@@ -41,10 +42,10 @@ KubeVela 工作流程如下图。
 这里的关键点在于，上述能力在 Kubernetes 生态中都是常见且广泛支持的，有些甚至是 Kubernetes 内置功能。但是到了 PaaS 这里，要实现这些能力往往需要重新开发，而且由于先前的设计假设，可能还需要进行大规模的重构。
 :::
 
-KubeVela 本质上其实就是在 Kuberntes 上安装了一个 OAM 插件，从而使得平台工程师能够按照 OAM 规范，把 Kubernetes 生态中的各种能力或插件整合成一个应用交付平台。所以说，KubeVela 对最终用户提供媲美 PaaS 的使用体验，又为平台工程师带来 Kubernees 原生的高可扩展性和平台构建规范！
+KubeVela 本质上是在 Kubernetes 上安装了一个 OAM 插件，使平台工程师能够依据 OAM 规范，将 Kubernetes 生态中的各种能力和插件整合成一个应用交付平台。所以说，KubeVela 为最终用户提供了类似 PaaS 的使用体验，同时也为平台工程师带来了 Kubernetes 原生的高可扩展性和平台构建规范。
 
 
-不过，目前来看，KubeVela 背后的理论还是过于抽象，落地有一定的技术门槛！但 KubeVela 这种构建以”应用为中心“的上层平台的思想，无疑代表着云原生技术未来发展的趋向！
+不过，目前来看，KubeVela 背后的理论还是过于抽象，落地有一定的技术门槛！但 KubeVela 这种构建以”应用为中心“的上层平台的思想，毫无疑问代表着云原生技术未来的发展方向！