fix typo

isno · Jan 21, 2025 · 590bf7e · 590bf7e
1 parent 870009f
commit 590bf7e
Show file tree

Hide file tree

Showing 3 changed files with 9 additions and 8 deletions.
diff --git a/application-centric/Controller.md b/application-centric/Controller.md
@@ -1,10 +1,9 @@
-# 10.2 声明式应用管理的本质
+# 10.2 声明式管理的本质
 
-分析 Kubernetes 的工作原理，不难发现，无论是 kube-scheduler 调度 Pod、还是 Deployment 管理 Pod 的部署、还是 HPA 执行弹性伸缩，它们整体的设计上都遵循“控制器模式”。
 
 ## 10.1.1 控制器模式
 
-在 Kubernetes 中，用户通过 YAML 文件表达资源的“预期状态”，“控制器”（Controller）负责监视资源的实际状态，当资源的实际状态和“预期状态”不一致时，控制器对系统进行必要的更改，以至两者最终一致。实际状态向预期状态逼近的过程被称之为“调谐”（Reconcile）。
+分析 Kubernetes 的工作原理，不难发现，无论是 kube-scheduler 调度 Pod、还是 Deployment 管理 Pod 的部署、还是 HPA 执行弹性伸缩，它们整体的设计上都遵循“控制器模式”。
 
 举一个例子，用户定义了一个 Deployment 资源，指定运行的容器镜像、副本数量。Deployment 控制器根据该定义在 Kubernetes 节点上创建相应的 Pod，并持续监控运行状态。如果某个副本 Pod 异常退出，控制器会自动创建新的 Pod，确保系统的“实际状态”始终与用户定义的“预期状态”（8 个副本）保持一致。
 
@@ -13,7 +12,9 @@
   图 7-1Kubernetes 的控制器模式
 :::
 
-有了控制器模式，那么整个底层的基础设施能力，无论是扩缩容、负载均衡、服务发现还是状态一致性，只要描述好状态，通过声明式 API 的方式去暴露给用户。那么，背后的控制器，执行“调谐”来逼近预期状态与实际状态一致。这正是 Kubernetes 声明式应用管理最直观的体现。
+总结控制器模式就是，用户通过 YAML 文件表达资源的“预期状态”，“控制器”（Controller）监视资源状态，当资源的实际状态和“预期状态”不一致时，控制器执行相应的操作，以确保两者一致。在 Kubernetes 中，这个过程被称之为“调谐”（Reconcile），Reconcile 就是不断执行“检查 -> 差异分析 -> 执行”的循环。
+
+Reconcile 过程的存在，确保了系统状态与终态保持一致的理论正确性。许多人将“声明式管理”和“声明式风格的 API”混为一谈，实际上是对 Reconcile 的必要性缺乏正确的认识。这个逻辑很容易理解，第一次提交描述时系统达成了你想要的期望状态，并不代表、也不保证一个小时后的情况也是如此。
 
 
 ## 10.1.2 基础设施即数据思想
@@ -51,6 +52,6 @@ spec:
 
 借助 CRD（自定义资源定义），工程师便可突破 Kubernetes 内置资源的限制，根据需求创建自定义资源类型，例如数据库、CI/CD 流程、消息队列或数字证书等。配合自定义的控制器，便能将特定的业务逻辑、特定的基础设施能力无缝集成到 Kubernetes 中。
 
-最终，所有让人兴奋的技术演进，无论是插件、接口、容器设计模式，还是 Mesh 形式，它们都以“声明式基础设施”为基础下沉至 Kubernetes 中，并通过声明式 API 暴露出来。“下沉”虽然让 Kubernetes 变得越来越复杂，但声明式 API 的好处就在于，它能够在基础设施的复杂度呈指数级增长的同时，保证使用者的交互界面复杂度仅以线性增长。
+最终，云原生生态圈那些让人兴奋的技术，通过插件、接口、容器设计模式、Mesh 形式，以“声明式管理”为基础下沉至 Kubernetes 中，并通过声明式 API 暴露出来。虽然 Kubernetes 变得越来越复杂，但声明式 API 的好处就在于，它能够在基础设施的复杂度呈指数级增长的同时，保证使用者的交互界面复杂度仅以线性增长。
 
 
diff --git a/application-centric/app-model.md b/application-centric/app-model.md
@@ -6,6 +6,6 @@
 
 导致上面问题的根源在于，Kubernetes 的定位是“平台的平台”（The Platform for Platform），它的核心功能、服务的对象是基础平台工程师，而非业务研发人员与运维人员；它的声明式 API 设计、CRD Operator 体系，也是为了方便基础平台工程师接入和构建新基础设施能力而设计的。这就导致作为这些能力的最终使用者 —— 业务研发人员，跟 Kubernetes 核心定位之间存在明显的错位。
 
-“复杂”，是任何一个基础设施项目天生的特质而不是缺点，但这并不意味着这种“复杂”应该使用者承受。这就好比，Linux 内核是世界上最复杂的软件之一，但我们使用 Linux 系统却没有太多心智负担。这是因为 Linux 系统通过高度抽象屏蔽了底层的复杂性。既然 Kubernetes 被称为“云原生时代的操作系统”，现在，也该考虑学习 Linux 抽象方式，寻找一种应用层的软件交付模型和抽象，以更友好的方式服务最终用户。
+“复杂”，是任何一个基础设施项目天生的特质而不是缺点，但这并不意味着这种“复杂”应该由使用者承受。这就好比，Linux 内核是世界上最复杂的软件之一，但我们使用 Linux 系统却没有太多心智负担，因为 Linux 系统通过高度抽象屏蔽了底层的复杂性。既然 Kubernetes 被称为“云原生时代的操作系统”，现在，也该考虑学习 Linux 抽象方式，寻找一种应用层的软件交付模型和抽象，以更友好的方式服务最终用户了。
 
 接下来，笔者将介绍几种业界主流的应用封装与交付思路，供你参考。
diff --git a/consensus/Paxos.md b/consensus/Paxos.md
@@ -1,7 +1,7 @@
 # 6.3 Paxos 算法
 
-Paxos 算法由 Leslie Lamport[^1] 于 1990 年提出，是一种基于消息传递、具备高度容错特性的共识算法，是当今分布式系统中最重要的理论基础，几乎就是“共识系统”的代名词。
+Paxos 算法由 Leslie Lamport[^1] 于 1990 年提出，是一种基于消息传递、具备高度容错特性的共识算法。该算法是当今分布式系统最重要的理论基础，几乎就是“共识系统”的代名词。
 
-Paxos 算法因其复杂性而广为人知，围绕它发生过许多有趣的故事，这些已成为人们津津乐道的一段轶事。直接切入 Paxos 算法本身未免望文生畏，我们不妨从这段轶事开始学习 Paxos 算法之旅。
+Paxos 算法因复杂广为人知，围绕它发生过许多有趣的故事，这些已成为人们津津乐道的一段轶事。直接切入 Paxos 算法未免望文生畏，我们不妨从这段轶事开始学习 Paxos 算法之旅。
 
 [^1]: Lamport 在分布式系统理论方面有非常多的成就，比如 Lamport 时钟、拜占庭将军问题、Paxos 算法等等。除了计算机领域之外，其他领域的无数科研工作者也要成天和 Lamport 开发的一套软件打交道，目前科研行业应用最广泛的论文排版系统 —— LaTeX (名字中的 La 就是指 Lamport)