fix typo

application-centric/Controller.md

@@ -36,7 +36,7 @@ IaD 思想在 Kubernetes 上的体现，就是执行任何操作，只需要提
 
 所以说，Kubernetes v1.7 版本引入了 CRD（自定义资源定义）功能，实质上赋予用户创建和管理自定义“数据”、将特定业务需求抽象为 Kubernetes 原生对象的能力。
 
-例如，用户定义一个 CRD 来描述持续交付流程中的任务。
+例如，可以定义描述持续交付流程的 CRD，描述任务的 Task、描述流水线的 Pipeline 等等。也就说，完全可以在 Kuberntes 之上构建一套全新的 CI/CD 系统。
 
 ```yaml
 apiVersion: tekton.dev/v1beta1

application-centric/OAM.md

@@ -1,10 +1,16 @@
 # 10.3.4 OAM
 
-2019 年 10 月，阿里云与微软在上海 QCon 大会上联合发布了开源项目 Open Application Model（OAM）。该项目以“关注点分离”（Separation of Concerns）为核心理念，为云原生应用的完整 DevOps 流程提供了高度抽象和封装。
+2019 年 10 月，阿里云与微软在上海 QCon 大会上联合发布了开源项目 Open Application Model（OAM）。该项目以“关注点分离”（Separation of Concerns）为核心理念，对云原生应用的整个 DevOps 流程提供了高度抽象和封装。
 
 OAM 项目有两个部分，OAM 规范（spec）和 OAM 规范的 Kubernetes 实现。
 
-详细的说，OAM 规范是基于自定义资源讲原先 All-in-One 的复杂配置做了一定层次的解耦，它强调一个现代应用是多个“组件”（Component）的集合，而非一个简单的工作负载或者 K8s Operator。更进一步的，OAM 把这个应用所需的“运维策略”（Trait）也认为是一个应用的一部分，在 OAM 中，一个应用程序包含三个核心理念：
+详细的说，OAM 规范是基于自定义资源讲原先 All-in-One 的复杂配置做了一定层次的解耦，应用开发者、运维人员和基础设施运维人员以一种标准化的方式连接起来。一言以蔽之：OAM 是一个高度可扩展的应用定义与能力装配模型。
+
+- 应用组件（Component）:
+- 运维特征（Trait）：
+- 
+
+它强调一个现代应用是多个“组件”（Component）的集合，而非一个简单的工作负载或者 K8s Operator。更进一步的，OAM 把这个应用所需的“运维策略”（Trait）也认为是一个应用的一部分，在 OAM 中，一个应用程序包含三个核心理念：
 - 第一个核心理念是组成应用程序的组件（Component），它可能包含微服务集合、数据库和云负载均衡器；
 - 第二个核心理念是描述应用程序运维特征（Trait）的集合，例如，弹性伸缩和 Ingress 等功能。它们对应用程序的运行至关重要，但在不同环境中其实现方式各不相同；
 - 最后，为了将这些描述转化为具体的应用程序，运维人员使用应用配置（Application Configuration）来组合组件和相应的特征，以构建应部署的应用程序的具体实例。

consensus/raft-ConfChange.md

@@ -9,7 +9,7 @@
 配置说明集群由哪些节点组成。例如，一个集群有三个节点（Server 1、Server 2、Server 3），该集群的配置就是 [Server1、Server2、Server3]。
 :::
 
-如果把“配置”当成 Raft 中的“特殊日志”。这样一来，成员动态变更需求就可以转化为“配置日志”的一致性问题。但需要注意的是，各个节点中的日志“应用”（apply）到状态机是异步的，不可能同时操作。粗暴的 apply “配置日志”很容易导致“脑裂”问题。
+如果把“配置”当成 Raft 中的“特殊日志”。这样一来，成员动态变更需求就可以转化为“配置日志”的一致性问题。但需要注意的是，各个节点中的日志“应用”（apply）到状态机是异步的，不可能同时操作。这种情况下，apply “配置日志”很容易导致“脑裂”问题。
 
 举个具体例子，假设有一个由三个节点 [Server1、Server2 和 Server3] 组成的 Raft 集群，当前的配置为 C~old~。现在，我们计划增加两个节点 [Server1、Server2、Server3、Server4、Server5]，新的配置为 C~new~。
 

consensus/raft-log-replication.md

@@ -29,20 +29,20 @@ Raft 算法中，领导者通过广播消息（AppendEntries RPC）将日志条
 
 根据图 6-14 所示，当 Raft 集群收到客户端请求（例如 set x=4）时，日志复制的过程如下：
 
-- 如果当前节点不是领导者，节点将请求转发给领导者；
+- 若当前节点非领导者，将请求转发至领导者；
 - 领导者接收请求后：
-  - 将请求转化为日志条目、写入本地仓库，日志条目初始状态为“未提交”（uncommitted）；
-  - 生成一条日志复制消息（AppendEntries RPC），广播给所有的跟随者；
-- 跟随者收到志复制消息后，检查任期（如本地任期是否比领导者任期大）、检查日志一致性（根据 prevLogIndex 判断日志是否缺失）。如果检查通过，跟随者将新的日志条目追加到自身的日志中，并发送确认响应。
-- 当领导者发现某个日志条目已经在多数节点上复制成功后，将该日志条目标记为“已提交”（committed），并向客户端返回执行结果。已提交的日志意味着：日志不可回滚，指令永久生效，可安全地“应用”（apply）到状态机。
+  - 将请求转化为日志条目，写入本地存储系统，初始状态为“未提交”（uncommitted）；
+  - 生成日志复制消息（AppendEntries RPC），并广播至所有跟随者；
+- 跟随者收到日志复制消息后，验证任期（确保本地任期不大于领导者任期）、日志一致性（通过 prevLogIndex 检查日志是否匹配）。若验证通过，跟随者将日志条目追加至本地存储系统，并发送确认响应；。
+- 领导者确认日志条目已成功复制至多数节点后，将其状态标记为“已提交”（committed），并向客户端返回结果。已提交的日志条目不可回滚，指令永久生效，且可安全地“应用”（apply）至状态机。
 
 :::center
   ![](../assets/raft-append-entries.svg) <br/>
  图 6-14 日志复制的过程
 :::
 
 
-领导者向客户端返回结果，并不代表日志复制过程已经完成，因为跟随者尚不清楚日志条目是否已被大多数节点确认。Raft 的设计通过心跳或后续日志复制请求中携带更新的提交索引（leaderCommit），通知跟随者提交日志。这样的设计将“达成共识的过程”优化为一个阶段，减少了客户端约一半的等待时间。
+领导者向客户端返回结果，并不意味着日志复制过程已完全结束，跟随者尚不清楚日志条目是否已被大多数节点确认。Raft 的设计通过心跳或后续日志复制请求中携带更新的提交索引（leaderCommit），通知跟随者提交日志。此机制将“达成共识的过程”优化为一个阶段，减少了客户端约一半的等待时间。
 
 
 :::tip 如何选择节点的数量

network/iptables.md

@@ -12,7 +12,7 @@ iptables 默认有五条链：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTIN
 
 iptables 把常用数据包管理操作总结成具体的动作，当数据包经过内核协议栈的钩子时（也就是 iptables 的链），根据 IP 数据包源地址/目的地址、传输层协议（TCP/UDP/ICMP/...）、端口等信息判断是否触发定义好的动作。
 
-如下为常见的动作说明：
+常见的动作及含义如下：
 
 - ACCEPT：允许数据包通过，继续执行后续的规则。
 - DROP：直接丢弃数据包。