fix typo

consensus/raft-leader-election.md

@@ -1,12 +1,12 @@
 # 6.4.1 领导者选举
 
-Paxos 算法中“节点众生平等”，每个节点都可以发起提案。多个提议者并行发起提案，是活锁、以及其他异常问题的源头。那如何不破坏 Paxos 的“节点众生平等”基本原则，又能在提案节点中实现主次之分，限制节点不受控的提案权利？
+Paxos 算法中“节点众生平等”，每个节点都可以发起提案。多个提议者并行发起提案，是活锁、以及其他异常问题的源头。那如何不破坏 Paxos 的“节点众生平等”基本原则，又能在提案节点中实现主次之分，约束提案权利？
 
 Raft 对此的设计是明确领导者、通过选举机制“分享”提案权利。直接来看 Raft 算法中节点的分类：
 
-- **领导者（Leader）**：负责处理所有客户端请求，将请求转换为“日志”复制到其他节点，不断地向所有节点广播心跳消息：“你们的领导还在，不要发起新的选举”。
-- **跟随者（Follower）**：接收、处理领导者的消息，并向领导者反馈日志的写入情况。当领导者心跳超时时，他会主动站起来，推荐自己成为候选人。
-- **候选人（Candidate）**：候选人属于过渡角色，他向所有的节点广播投票消息，如果他赢得多数选票，那么他将晋升为领导者。
+- **领导者**（Leader）：负责处理所有客户端请求，将请求转换为“日志”复制到其他节点，不断地向所有节点广播心跳消息：“你们的领导还在，不要发起新的选举”。
+- **跟随者**（Follower）：接收、处理领导者的消息，并向领导者反馈日志的写入情况。当领导者心跳超时时，他会主动站起来，推荐自己成为候选人。
+- **候选人**（Candidate）：候选人属于过渡角色，他向所有的节点广播投票消息，如果他赢得多数选票，那么他将晋升为领导者。
 
 联想到现实世界中的领导人都有一段不等的任期。自然，Raft 算法中也对应的概念 —— “任期”（term）。Raft 中的任期是一个递增的数字，贯穿于 Raft 的选举、日志复制和一致性维护过程中。
 
@@ -56,7 +56,7 @@ RequestVote 响应的示例如下：
 如果候选者获得多数（超过半数）投票，即成为领导者。之后，领导者向其他节点广播心跳消息，维持领导者地位。如果没有获得多数票，进入下一轮选举，任期号递增，重新发起投票。如果选举过程中收到任期号更高的心跳或投票请求，则转为跟随者。
 
 
-基于“少数服从多数”的原则，获得多数选票的领导者代表了整个集群的意志。现在，你思考：“代表集群意志的领导者发起提案时，是否还需要 Paxos 第一轮中 “准备阶段” ？”。
+基于“少数服从多数”原则，获得多数选票的领导者代表了整个集群的意志。现在，你思考，代表集群意志的领导者发起提案时，是否还需要 Paxos 第一轮中 “准备阶段” ？
 
 
 

container/borg-omega-k8s.md

@@ -14,9 +14,9 @@ Borg 的架构如图 7-1 所示，是典型的 Master（图中 BorgMaster) + Age
   图 7-1 Borg 架构图 [图片来源](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/)
 :::
 
-开发 Borg 的过程中，Google 的工程师为 Borg 设计了两种工作负载（Workload）[^1]：
-- **长期运行服务（Long-Running Service）**：通常是对请求延迟敏感的在线业务，例如 Gmail、Google Docs 和 Web 搜索以及内部基础设施服务；
-- **批处理任务（Batch Job）**：用于一次性处理大量数据、需要较长的运行时间和较多的计算资源的“批处理任务”（Batch Job）。典型如 Apache Hadoop 或 Spark 框架执行的各类离线计算任务。
+开发 Borg 的过程中，Google 的工程师为 Borg 设计了两种工作负载（workload）：
+- **长期运行服务**（Long-Running Service）：通常是对请求延迟敏感的在线业务，例如 Gmail、Google Docs 和 Web 搜索以及内部基础设施服务；
+- **批处理任务**（Batch Job）：用于一次性处理大量数据、需要较长的运行时间和较多的计算资源的“批处理任务”（Batch Job）。典型如 Apache Hadoop 或 Spark 框架执行的各类离线计算任务。
 
 区分 2 种不同类型工作负载的原因在于：
 
@@ -51,26 +51,26 @@ Borg 生态的发展由 Google 内部不同团队推动。从迭代结果来看
 
 Google 开发的第三套容器管理系统是 Kubernetes，其背景如下：
 
-- 全球越来越多的开发者开始对 Linux 容器产生兴趣（尽管 Linux 容器是 Google 的技术基础，但开发者们首先想到的是 Docker，Google 并没有吃到红利）。
-- 同时，Google 已将公有云基础设施作为业务重点并实现持续增长（虽然 Google 提出了云计算的概念，但市场领先者已被 AWS 和阿里云占据，Google 起了大早赶了个晚集）。
+- 全球越来越多的开发者开始对 Linux 容器产生兴趣（Linux 容器是 Google “家底”，但提到容器，开发者们首先想到的是 Docker。Google 并没有吃到容器技术的红利）；
+- 同时，Google 将公有云服务作为业务重点并实现持续增长（虽然 Google 提出了云计算的概念，但市场被 AWS 抢占先机。Google 起了大早赶了个晚集）。
 
 2013 年夏，Google 的工程师们开始讨论借鉴 Borg 的经验开发新一代容器编排系统，希望通过十几年的技术积累影响云计算市场格局。Kubernetes 项目获批后， 2014 年 6 月，Google 在 DockerCon 大会上宣布将其开源。
 
 通过图 7-3 观察 Kubernetes 架构，能看出大量设计来源于 Borg/Omega 系统：
 
 - Master 系统由多个分布式组件构成，包括 API Server、Scheduler、Controller Manager 和 Cloud Controller Manager；
-- Kubernetes 的最小运行单元 Pod，其原型是 Borg 系统中的 Alloc（资源分配的缩写）；
-- 工作节点上的 kubelet 组件，其设计来源于 Borg 系统中的 Borglet 组件；
+- Kubernetes 的最小运行单元 Pod，其原型是 Borg 系统对物理资源的抽象 Alloc；
+- 工作节点上的 kubelet 组件，其设计来源于 Borg 系统中各节点里面 Borglet 组件；
 - 基于 Raft 算法实现的分布式一致性键值存储 Etcd，对应 Omega 系统中基于 Paxos 算法实现的 Store。
 
 :::center
   ![](../assets/k8s-arch.svg)<br/>
   图 7-3 Kubernetes 架构以及组件概览 [图片来源](https://link.medium.com/oWobLWzCQJb)
 :::
 
-出于降低用户使用的门槛，并最终达成 Google 从底层进军云计算市场意图，Kubernetes 定下的设计目标是**享受容器带来的资源利用率提升的同时，让支撑分布式系统的基础设施标准化、操作更简单**。
+出于降低用户使用的门槛，并最终达成 Google 从底层进军云计算市场意图，Kubernetes 的设计目标是**享受容器带来的资源利用率改善，同时让支撑分布式系统的基础设施标准化、操作更简单**。
 
-为了进一步理解基础设施的标准化，来看 Kubernetes 从一开始就提供的东西 —— 用于描述各种资源需求的标准 API：
+为了进一步理解基础设施的标准化，来看 Kubernetes 从一开始就提供的东西 —— 用于描述各种资源需求的 API：
 
 - 描述 Pod、Container 等计算资源需求的 API；
 - 描述 Service、Ingress 等网络功能的 API；
@@ -87,12 +87,9 @@ Google 开发的第三套容器管理系统是 Kubernetes，其背景如下：
 
 ## 7.1.4 以应用为中心的转变
 
-从最初的 Borg 到 Kubernetes，容器化技术的价值早已超越了单纯提升资源利用率。更深远的变化在于，系统开发和运维理念从“以机器为中心”转向“以应用为中心”。
+从 Borg 到 Kubernetes，容器技术的价值早已超越了单纯提升资源利用率。更深远的影响在于，系统开发和运维的理念从“以机器为中心”转变为“以应用为中心”：
 
-- 容器封装了应用程序的运行环境，屏蔽了操作系统和硬件的细节，使得业务开发者和基础设施管理者不再需要关注底层实现。
-- 基础设施团队可以更灵活地引入新硬件或升级操作系统，最大限度减少对线上应用和开发者的影响。 
-- 每个设计良好的容器通常代表一个应用，因此管理容器就等于管理应用，而非管理机器。
-- 将收集的性能指标（如 CPU 使用率、内存用量、每秒查询率 QPS 等）与应用程序而非物理机器关联，显著提高了应用监控的精确度和可观测性，尤其是在系统垂直扩容、机器故障或主动运维等场景。
-
-
-[^1]: 在 Kubernetes 中的 Workload 资源包括多种类型，例如 Deployment、StatefulSet、DaemonSet、ReplicaSet 等等
+- 容器封装了应用程序的运行环境，屏蔽了操作系统和硬件的细节，使得业务开发者不再需要关注底层实现；
+- 基础设施团队可以更灵活地引入新硬件或升级操作系统，最大限度减少对线上应用和开发者的影响； 
+- 每个设计良好的容器通常代表一个应用，因此管理容器就等于管理应用，而非管理机器；
+- 将收集的性能指标（如 CPU 使用率、内存用量、QPS 等）与应用程序而非物理机器关联，显著提高了应用监控的精确度和可观测性。

container/container-network.md

@@ -1,7 +1,5 @@
 # 7.6 容器间通信的原理
 
-理解了容器的演进、持久化存储的原理之后，相信还有个问题反复萦绕在你心头：“一个集群内，各个容器是如何实现相互通信的？”。
-
 要理解容器网络的工作原理，一定要从 Flannel 项目入手。Flannel 是 CoreOS 推出的容器网络解决方案，是业界公认是“最简单”的容器网络解决方案。Flannel 支持两种工作模式：VXLAN 和 host-gw，分别对应容器跨主机通信的 Overlay（覆盖网络）和三层路由方式。
 
 接下来，笔者将以 Flannel 为例，详细介绍容器间 Overlay 网络和三层路由模式通信的原理、容器网络接口（CNI）的设计及生态。
@@ -11,9 +9,9 @@
 
 本书第三章 5.4 节已详细介绍了 Overlay 网络的设计思想，一言蔽之：即在现有三层网络之上“覆盖”一层由内核 VXLAN 模块维护的虚拟二层网络。
 
-为了在宿主机网络之上构建虚拟的二层通信网络（即建立一条隧道网络），VXLAN 模块会在通信双方配置一个特殊的网络设备作为隧道端点，称为 VTEP（VXLAN Tunnel Endpoints，VXLAN 隧道端点）。VTEP 实际上是一个虚拟网络设备，因此它既有 IP 地址，也有 MAC 地址。VTEP 设备根据 VXLAN 通信规范，对 VXLAN 二层网络中的“主机”（如容器或虚拟机）进行数据包的封装和解封。通过这种方式，这些“主机”可以像在同一局域网内通信。实际上，这些“主机”可能分布在不同的节点、子网，甚至位于不同的物理机房内。
+为了在宿主机网络之上构建虚拟的二层通信网络（即建立一条隧道网络），VXLAN 模块会在通信双方配置一个特殊的网络设备作为隧道端点，称为 VTEP（VXLAN Tunnel Endpoints，VXLAN 隧道端点）。VTEP 实际上是一个虚拟网络设备，因此它既有 IP 地址，也有 MAC 地址。VTEP 设备根据 VXLAN 通信规范，对 VXLAN 二层网络中的“主机”（如容器或虚拟机）进行数据包的封装和解封。通过这种方式，分布在不同的节点、子网“主机”可以像在同一局域网内通信。
 
-上述基于 VTEP 设备构建“隧道”通信的流程，可以总结为图 7-26 所示。
+上述基于 VTEP 设备构建“隧道”通信的流程，可以总结为图 7-26。
 
 :::center
   ![](../assets/flannel-vxlan.svg) <br/>