fix typo

isno · Jan 24, 2025 · 0e48aaf · 0e48aaf
1 parent b3aafc5
commit 0e48aaf
Show file tree

Hide file tree

Showing 2 changed files with 6 additions and 8 deletions.
diff --git a/application-centric/Operator.md b/application-centric/Operator.md
@@ -15,7 +15,7 @@ Kubernetes 使用 Deployment 编排无状态应用，假设所有 Pod 完全相
 
 Kubernetes v1.9 版本引入 StatefulSet 的核心功能就是用某种方式记录这些状态，当有状态应用的 Pod 重建后，仍然满足上一次运行状态的需求。不过有状态应用的维护并不限于此：
 - 以 StatefulSet 创建的 Etcd 集群为例，最多只能实现创建、删除集群等基本操作。对于集群扩容、健康检查、备份恢复等等高级运维操作，也需要配套支持。
-- 其次，使用 StatefulSet 创建 etcd 集群，还必须配置大量的细节，明确网络标识符、存储配置、集群成员管理、健康检查方式，告诉 Kuberntes 如何处理 Etcd。举一个具体的例子，让你体会在“在 YAML 文件里编程序”的感觉，请看：
+- 其次，使用 StatefulSet 创建 etcd 集群，还必须配置大量的细节，明确网络标识符、存储配置、集群成员管理、健康检查方式，告诉 Kuberntes 如何处理 Etcd。举一个具体的例子，供你体会在“在 YAML 文件里编程序”的感觉，请看下面配置 etcd 的 YAML 文件：
 ```yaml
 apiVersion: v1
 kind: Service
@@ -90,14 +90,13 @@ spec:
             storage: 1Gi
 ```
 
-观察上面的例子，不难发现，用户很难、也不想关心运维以及 Kubernetes 底层的各种概念。用户其实只关心下面两个信息。
+观察上面的例子，不难发现，用户很难、也不想关心运维以及 Kubernetes 底层的各种概念。用户其实只关心两个信息：我怎么连接它（端口 port）、etcd 的版本是多少（image）。如果向最终用户只暴露下述信息，是不是简洁很多了呢！
 ```
 port: 2379
 image: quay.io/coreos/etcd:v3.5.0
 ```
-将这样的对象暴漏给最终用户是不是简洁很多了呢！这种设计“简化版”的 API 对象，就叫做“构建上层抽象”，“构建上层抽象”是简化应用管理的必要手段。
 
-直接来看使用 Operator 后的情况，事情就变得简单多了。Etcd 的 Operator 提供了 EtcdCluster 自定义资源，在它的帮助下，仅用几十行代码，安装、启动、停止等基础的运维操作。
+这种设计“简化版”的 API 对象，就叫做“构建上层抽象”，“构建上层抽象”是简化应用管理的必要手段。接下来，看使用 Operator 后的情况，事情就变得简单多了。Etcd 的 Operator 提供了 EtcdCluster 自定义资源，在它的帮助下，仅用几十行代码，安装、启动、停止等基础的运维操作。
 ```yaml
 apiVersion: operator.etcd.database.coreos.com/v1beta2
 kind: EtcdCluster

diff --git a/consensus/raft-leader-election.md b/consensus/raft-leader-election.md
@@ -1,13 +1,12 @@
 # 6.4.1 领导者选举
 
-Paxos 算法中“节点众生平等”，每个节点都可以发起提案。多个提议者并行发起提案，是活锁、以及其他异常问题的源头。那如何不破坏 Paxos 的“节点众生平等”基本原则，又能在提案节点中实现主次之分，限制节点不受控的提案权利？Raft 对此的设计是明确领导者、通过选举机制“分享”提案权利。
+Paxos 算法中“节点众生平等”，每个节点都可以发起提案。多个提议者并行发起提案，是活锁、以及其他异常问题的源头。那如何不破坏 Paxos 的“节点众生平等”基本原则，又能在提案节点中实现主次之分，限制节点不受控的提案权利？
 
-先来看 Raft 算法中节点的分类：
+Raft 对此的设计是明确领导者、通过选举机制“分享”提案权利。直接来看 Raft 算法中节点的分类：
 
 - **领导者（Leader）**：负责处理所有客户端请求，将请求转换为“日志”复制到其他节点，不断地向所有节点广播心跳消息：“你们的领导还在，不要发起新的选举”。
 - **跟随者（Follower）**：接收、处理领导者的消息，并向领导者反馈日志的写入情况。当领导者心跳超时时，他会主动站起来，推荐自己成为候选人。
-- **候选人（Candidate）**：候选人属于过渡角色，他向所有的节点广播投票消息，如果他赢得多数选票，那么他将晋升为领导者；
-
+- **候选人（Candidate）**：候选人属于过渡角色，他向所有的节点广播投票消息，如果他赢得多数选票，那么他将晋升为领导者。
 
 联想到现实世界中的领导人都有一段不等的任期。自然，Raft 算法中也对应的概念 —— “任期”（term）。Raft 中的任期是一个递增的数字，贯穿于 Raft 的选举、日志复制和一致性维护过程中。