fix typo

consensus/raft-leader-election.md

@@ -27,7 +27,7 @@ Paxos 算法中“节点众生平等”，每个节点都可以发起提案。
   图 6-12 Raft 选举过程
 :::
 
-首先，初始状态下，所有的节点处于跟随者状态。因为集群中还没有领导者，某个跟随者未在选举超时时限内（通常是 150-300 毫秒的随机超时时间）收到领导者的心跳，该节点触发选举，节点的角色从跟随者转为 候选者。候选者增加自己的任期号，向其他节点广播“投票给我”的消息（RequestVote RPC）。
+初始状态下，所有的节点处于跟随者状态。如果跟随者在某个时限（通常是 150-300 毫秒的随机超时时间）未收到领导者心跳，则触发触发选举。节点的角色转为 候选者，任期号递增，然后向其他节点广播“投票给我”的消息（RequestVote RPC）。
 
 RequestVote RPC 消息示例如下：
 
@@ -40,7 +40,7 @@ RequestVote RPC 消息示例如下：
 }
 ```
 
-节点收到投票消息后，根据以下条件判断是否投票：
+其他节点收到投票消息后，根据下面的条件判断是否投票：
 
 - 候选者的日志至少与投票者的日志一样新（根据最后一条日志的任期号和索引号判断）。
 - 当前节点尚未在本任期投票。
@@ -54,7 +54,7 @@ RequestVote 响应的示例如下：
 }
 ```
 
-如果候选者获得多数（超过半数）节点的投票，即成为领导者。之后，领导者向其他节点广播心跳消息，维持领导者地位。如果没有获得多数票，进入下一轮选举，任期递增，重新发起投票。如果在选举过程中收到任期号更高的心跳或投票请求，转为跟随者。
+如果候选者获得多数（超过半数）投票，即成为领导者。之后，领导者向其他节点广播心跳消息，维持领导者地位。如果没有获得多数票，进入下一轮选举，任期号递增，重新发起投票。如果选举过程中收到任期号更高的心跳或投票请求，则转为跟随者。
 
 
 基于“少数服从多数”的原则，获得多数选票的领导者代表了整个集群的意志。现在，你思考：“代表集群意志的领导者发起提案时，是否还需要 Paxos 第一轮中 “准备阶段” ？”。

container/kube-scheduler.md

@@ -1,8 +1,8 @@
 # 7.7.3 调度器与扩展设计
 
 如果集群中节点的数量只有几十个，为新建的 Pod 找到合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时，情况就复杂了：
-- 首先，Pod 的创建、更新、节点资源无时无刻不在变化，如果每次调度都需要数千次远程请求获取信息，势必因耗时过长，增加调度失败的风险。
-- 其次，调度器频繁发起网络请求，极容易成为性能瓶颈，影响整个集群的运行效率。
+- 首先，节点资源无时无刻不在变化，如果每次调度都需要数千次远程请求获取信息，势必因耗时过长，增加调度失败的风险。
+- 其次，调度器频繁发起网络请求，极容易成为集群的性能瓶颈，影响整个集群的运行。
 
 :::tip <a/>
 为了充分利用硬件资源，通常会将各种类型(CPU 密集、IO 密集、批量处理、低延迟作业)的 workloads 运行在同一台机器上，这种方式减少了硬件上的投入，但也使调度问题更加复杂。