fix typo！

application-centric/Kustomize.md

@@ -2,9 +2,9 @@
 
 Kubernetes 官方对应用的定义是一组具有相同目标资源合集。这种设定下，只要应用规模稍大，资源配置文件就开始泛滥。尤其是当不同环境（如开发和生产环境）之间的差异较小时，你就会发现通过 kubectl 管理应用十分“蛋疼”。
 
-Kubernetes 对此的观点是，如果逐一配置和部署资源文件过于繁琐，那就将应用中的稳定信息与可变信息分离，并自动生成一个多合一（All-in-One）的配置包。完成这一任务的工具名为 Kustomize。最初，Kustomize 是一个独立的小工具，但从 Kubernetes 1.14 版本开始，它被集成到 kubectl 命令中，成为 Kubernetes 的内置功能。
+Kubernetes 对此的观点是，如果逐一配置和部署资源文件过于繁琐，那就将应用中的稳定信息与可变信息分离，并自动生成一个多合一（All-in-One）的配置包。完成这一任务的工具名为 Kustomize。
 
-Kustomize 可以看作是 YAML 模板引擎的变体，由它的应用结构包括两个主要部分：base 和 overlays。base 目录存放原始的 Kubernetes YAML 模板文件，overlays 目录用于管理不同环境的差异。每个目录下都有一个 kustomization.yaml 配置文件，描述如何组合和修改 Kubernetes 资源。
+Kustomize 可以看作是 YAML 模板引擎的变体，由它组织的应用结构有两个部分：base 和 overlays。base 目录存放原始的 Kubernetes YAML 模板文件，overlays 目录用于管理不同环境的差异。每个目录下都有一个 kustomization.yaml 配置文件，描述如何组合和修改 Kubernetes 资源。
 
 ```bash
 .

application-centric/OAM.md

@@ -2,7 +2,7 @@
 
 2019 年 10 月，阿里云与微软在上海 QCon 大会上联合发布了全球首个开放应用模型（OAM，Open Application Model）。OAM 的核心理念是通过模块化设计，将应用拆解为多个功能单元，从而实现开发、运维和平台人员之间的关注点分离。开发人员专注于业务逻辑的实现，运维人员关注程序的稳定性，而平台人员则致力于提升基础设施的能力与可靠性。
 
-OAM 规范下的应用模型并非纯粹的抽象概念，是可以被实际使用的自定义资源。（v0.3.0）这些概念的具体含义如下：
+OAM 规范下的应用由不同的组件构成，这些组件并非纯粹的抽象概念，是可以被实际使用的自定义资源。（v0.3.0）这些概念的具体含义如下：
 
 - **应用组件（Component）**：无论是前端还是后端，组件化构建应用的思想屡见不鲜。平台架构师将应用分解成成一个个可被复用的模块、每个组件都具有明确的功能和接口，开发人员通过配置文件填写组件参数、与其他服务的关系，就能描绘出一个完整的应用。
 - **运维特征（Trait）**：运维特征是可以随时绑定给待部署组件的模块化、可拔插的运维能力，比如：副本数调整、数据持久化、设置网关策略、自动设置 DNS 解析等。用户可以从社区获取成熟的能力，也可以自行定义。
@@ -18,7 +18,7 @@ OAM 规范下的应用模型并非纯粹的抽象概念，是可以被实际使
   图 4-0 OAM 应用部署计划
 :::
 
-KubeVela 是将 OAM“模型”化虚为实，也是第一个将“以应用为中心”的设计理念落地的项目。KubeVela 起源于 OAM 社区，由阿里巴巴、微软等公司的技术专家共同维护，它于 2021 年加入 CNCF，2023 年 2 月晋升为“孵化”（Incubating，意味着）级别项目，“孵化”意味着项目达到一定的成熟度，具备了可用性、活跃社区和稳定的技术路线。
+KubeVela 是将 OAM“模型”化虚为实，也是第一个将“以应用为中心”的设计理念落地的项目。它起源于 OAM 社区，于 2021 年加入 CNCF，2023 年 2 月晋升为“孵化”（Incubating，意味着）级别，“孵化”意味着项目达到一定的成熟度，具备了可用性、活跃社区和稳定的技术路线。
 
 KubeVela 基于 OAM 模型的关注点分离理念，将平台用户分为平台工程师（Platform Builder）和最终用户（End User）两类：
 - 平台工程师准备应用部署环境、维护稳定可靠的基础设施功能（如 MySQL Operator），并将这些基础设施能力作为 KubeVela 模块注册到集群中；

network/vxlan.md

@@ -92,7 +92,7 @@ $ ip link set up dev vxlan100
 :::
 
 从上述，我们看到 VXLAN 完美地弥补了 VLAN 的不足：
-- 一方面通过 VXLAN 中的 24 bits VNI 字段（如图 3-25 所示）提供多达 1,677 万租户的标识能力，远大于 VLAN 的 4,000；
+- 一方面通过 VXLAN 中的 24 bits VNI 字段（如图 3-18 所示）提供多达 1,677 万租户的标识能力，远大于 VLAN 的 4,000；
 - 另一方面，VXLAN 本质是构建了一条穿越不同物理网络的“虚拟隧道”，它通过封装原始的 Layer 2（以太网）帧在 Layer 3 网络中传输，使得不同物理网络之间的通信，就像在一个广播域内一样。虚拟机或者容器无论是迁移到 VLAN B 还是 VLAN C，仍然处于同一个二层网络，网络层的配置不需要任何变化。
 
 VXLAN 具有很高的灵活性、扩展性和可管理性，已经成为构建数据中心与容器网络的主流技术，绝大多数公有云的 VPC（Virtual Private Cloud，虚拟私有云）和容器网络都是利用 VXLAN 技术在一个大二层网络上构建。