fix typo

isno · Sep 26, 2024 · 04c2fdf · 04c2fdf
1 parent e5309f6
commit 04c2fdf
Show file tree

Hide file tree

Showing 5 changed files with 17 additions and 16 deletions.
diff --git a/ServiceMesh/MicroService-history.md b/ServiceMesh/MicroService-history.md
@@ -94,10 +94,10 @@ TCP/IP 协议出现之后，机器之间的网络通信不再是一个难题，
 
 早期的 Linkerd 借鉴了 Twtter 开源的 Finagle 项目，并重用了大量的 Finagle 代码：
 
-- 设计思路上，Linkerd 将分布式服务的通信逻辑抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等必要功能；
-- 具体实现上， Linkerd 作为和服务对等的代理服务（Sidecar）和服务部署在一起，接管服务的流量。
+- 设计思路上：Linkerd 将分布式服务的通信逻辑抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等必要功能；
+- 具体实现上：Linkerd 作为和服务对等的代理服务（Sidecar）和服务部署在一起，接管服务的流量。
 
-Linkerd 开创先河的不绑定任何基础架构或某类体系，实现了通用性，成为业界第一个服务网格项目。同期的服务网格代表产品还有 Lyft（和 Uber 类似的打车软件）公司的 Envoy（Envoy 是 CNCF 内继 Kubernetes、Prometheus 第三个孵化成熟的项目）。
+Linkerd 开创先河的不绑定任何基础架构或某类技术体系，实现了通用性，成为业界第一个服务网格项目。同期的服务网格代表产品还有 Lyft（和 Uber 类似的打车软件）公司的 Envoy（Envoy 是 CNCF 内继 Kubernetes、Prometheus 第三个孵化成熟的项目）。
 
 :::center
   ![](../assets/linkerd-envoy.png)<br/>

diff --git a/consensus/raft.md b/consensus/raft.md
@@ -6,22 +6,24 @@ Raft 是由 Re{liable|plicated|dundant} And Fault-Tolerant 组合起来的单词
 
 不可否认，Paxos 是一个划时代的共识算法。Raft 出现之前，绝大多数共识算法的实现都是基于 Paxos 或者受其影响，同时 Paxos 也成为了教学领域里讲解共识问题时的示例。
 
-但不幸的是 Paxos 理解起来非常晦涩，虽然论文中提到了 Multi Paxos，但缺少对细节的描述，这些都导致了工业界和学术界对 Paxos 算法普遍感到十分头疼。那段时期，虽然所有的共识系统都是从 Paxos 开始的，但工程师在实现过程中发现有很多难以逾越的难题，往往不得已又开发出一种与 Paxos 完全不一样的架构，这就导致 Lamport 的证明并没有太大价值。
+但不幸的是 Paxos 理解起来非常晦涩，虽然论文中提到了 Multi Paxos，但缺少实现细节的描述。这些都导致了工业界和学术界普遍对 Paxos 算法感到十分头疼。那段时期，虽然所有的共识系统都是从 Paxos 开始的，但工程师在实现过程中发现有很多难以逾越的难题，往往不得已又开发出一种与 Paxos 完全不一样的架构，这就导致 Lamport 的证明并没有太大价值。
 
-所以，在很长的一段时间内，实际上并没有一个被大众所认同的 Multi Paxos 算法。
+所以，在很长的一段时间内，实际上并没有一个被大众所认同的 Paxos 算法。
 
 :::tip Chubby 作者评论 Paxos
 Paxos 算法描述与工程实现之间存在巨大的鸿沟，最终实现的系统往往建立在一个还未被证明的算法之上。
 :::
 
-考虑到共识问题在大规模分布式系统的重要性，同时也为了提供一种更易于理解的教学方法，斯坦福大学的学者们决定重新设计一个完全可以替代 Paxos 的共识算法，该算法的首要目的是能够被多数人理解，当然，也必须满足容错和高效这两个关键要求。
+考虑到共识问题在分布式系统的重要性，同时也为了提供一种更易于理解的教学方法，斯坦福大学的学者们决定重新设计一个完全可以替代 Paxos 的共识算法。该算法的首要目的是能够被多数人理解，当然，也必须满足容错和高效这两个关键要求。
 
-2013 年，斯坦福学者 Diego Ongaro 和 John Ousterhout 发表了论文 《In Search of an Understandable Consensus Algorithm》[^1]，提出了 Raft 算法。Raft 论文开篇第一句描述了 Raft 的证明和 Paxos 等价，然后详细描述了算法如何实现，也就是说 Raft 天生就是 Paxos 算法的工程化。此后 Raft 算法成为分布式容错系统开发的首选共识算法。
+2013 年，斯坦福的 Diego Ongaro 教授和 John Ousterhout 博士发表了论文 《In Search of an Understandable Consensus Algorithm》[^1]，提出了 Raft 算法。Raft 论文开篇第一句描述了 Raft 的证明和 Paxos 等价，然后详细描述了算法如何实现，也就是说 Raft 天生就是 Paxos 算法的工程化。
 
 :::tip 《In Search of an Understandable Consensus Algorithm》开篇
 Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to (multi-)Paxos, and it is as efficient as Paxos, but its structure is different from Paxos;
 :::
 
-作为一个强领导者模型算法，本节内容以领导者选举、日志复制为线索讲解这些在 Paxos 难以落地的问题，Raft 算法是如何设计和解决的。
+此后 Raft 算法成为分布式容错系统开发的首选共识算法。
 
-[^1]: 论文参见 https://raft.github.io/raft.pdf，该论文是斯坦福教授 John Ousterhunt 指导 Diego Ongaro 完成的博士论文。
+接下来，本节内容以领导者选举、日志复制为主讲解这些在 Paxos 难以落地的问题，Raft 算法是如何设计和解决的。
+
+[^1]: 论文参见 https://raft.github.io/raft.pdf
diff --git a/container/container-network.md b/container/container-network.md
@@ -198,7 +198,7 @@ $ ls /opt/cni/bin/
 bandwidth  bridge  dhcp  firewall  flannel calico-ipam cilium...
 ```
 
-CNI 插件工作的流程大致如图 7-33 所示。当需要设置容器网络时，由容器运行时根据 CNI 的配置规范（例如设置 VXLAN 网络、设置各个节点容器子网范围等）通过标准输入（stdin）向 CNI 插件传递网络配置信息。等待 CNI 插件配置完网络后，再通过标准输出（stdout）向容器运行时返回执行结果。
+CNI 插件工作的流程大致如图 7-33 所示。当创建 Pod 设置容器网络时，由容器运行时根据 CNI 的配置规范（例如设置 VXLAN 网络、设置各个节点容器子网范围等）通过标准输入（stdin）向 CNI 插件传递网络配置信息。等待 CNI 插件配置完网络后，再通过标准输出（stdout）向容器运行时返回执行结果。
 
 :::center
   ![](../assets/CNI.webp) <br/>

diff --git a/container/kube-scheduler.md b/container/kube-scheduler.md
@@ -36,9 +36,9 @@ Kubernetes 默认调度器（kube-scheduler）双循环架构如下所示。
 - 节点过滤策略：与宿主机节点相关的策略。例如检查 Pod 是否能容忍节点的污点；确保 Pod 调度到符合亲和性条件的节点；
 - 拓扑和亲和性策略：该策略主要处理 Pod 之间的亲和性规则，还有确保 Pod 在不同节点间均匀分布。
 
-在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下，这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。过滤阶段结束之后，接着进入打分阶段。
+在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下，这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。过滤阶段至此结束，接着进入打分阶段。
 
-在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。根据当前启用调度插件的打分策略，调度器会给每一个可调度节点进行打分。得分最高的 Node 就会作为这次调度的结果。如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。
+在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。根据当前启用调度插件的打分策略，为每一个可调度节点进行打分。得分最高的 Node 就会作为这次调度的结果。如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。
 
 在上述两个阶段结束之后，调度器 kube-scheduler 会将就需要将 Pod 对象的 nodeName 字段的值，修改为选中 Node 的名字，这个过程在 Kubernetes 里面被称作 Bind。为了不在关键调度路径里远程访问 API Server，Kubernetes 默认调度器在 Bind 阶段只会更新 Scheduler Cache 里的 Pod 和 Node 的信息。这种基于“乐观”假设的 API 对象更新方式，在 Kubernetes 里被称作 Assume。Assume 之后，调度器才会创建一个 Goroutine 异步地向 API Server 发起更新 Pod 的请求，kubelet 完成真正调度操作。
 
@@ -50,12 +50,11 @@ Kubernetes 从 v1.15 版本起，为 kube-scheduler 设计了可插拔的扩展
    图 7-38 Pod 的调度上下文以及调度框架公开的扩展点
 :::
 
-有了 Scheduling Framework，在保持调度“核心”简单且可维护的同时，用户可以编写自己的调度插件注册到 Scheduling Framework 的扩展点来实现自己想要的调度逻辑。
-
+有了 Scheduling Framework，在保持调度“核心”简单且可维护的同时，用户只要编写自己的调度插件注册到 Scheduling Framework 的扩展点就能实现自己想要的调度逻辑。
 
 值得注意的是，Scheduling Framework 属于 Kubernetes 内部扩展机制，需要按照规范编写 Golang 代码。
 
-例如下面一个插件，实现 Filter 和 Score 扩展
+例如，实现 Filter（筛选有 GPU 节点资源）和 Score 扩展点一个插件，供你参考。
 
 ```go
 package main

diff --git a/container/summary.md b/container/summary.md
@@ -12,7 +12,7 @@
 
 实现容器自动化部署、扩缩等一系列管理操作的系统称之为容器编排系统。过去十年间，Kubernetes 已成为容器编排系统的事实标准，并成为大数据分析、机器学习以及在线服务领域被广泛认可的最佳底座。然而，Kubernetes 在解决复杂问题的同时，也演变为当今最复杂的软件系统之一。目前，包括官方文档在内的大多数 Kubernetes 资料都聚焦于工程细节，鲜有对背后的设计思想进行解释。如果笔者撰写的内容继续停留在“是什么”和“怎么做”的层面，一则重复前人的工作，二则无法真正阐明 Kubernetes 的设计思想。
 
-自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，笔者将从这几篇论文着手，介绍 Google 内部容器系统是怎么演变的。汲取他人的设计思想后，再来深入理解 Kubernetes 在容器资源分配、容器间通信及容器持久化存储等方面的设计原理和应用。本章内容安排如图 7-0 所示。
+自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，笔者将从这几篇论文着手，介绍 Google 内部容器系统是怎么演变的。汲取他人的设计思想后，再来深入理解 Kubernetes 关于容器在资源、网络、存储、调度等方面的设计原理和应用。本章内容安排如图 7-0 所示。
 
 :::center
   ![](../assets/container-summary.png)<br/>