From dbd84dac40f183967536a9995c29ab855cbc8233 Mon Sep 17 00:00:00 2001 From: isno Date: Mon, 30 Dec 2024 17:39:08 +0800 Subject: [PATCH] fix typo --- application-centric/Controller.md | 2 +- application-centric/OAM.md | 10 ++++++++-- consensus/raft-ConfChange.md | 2 +- consensus/raft-log-replication.md | 12 ++++++------ network/iptables.md | 2 +- 5 files changed, 17 insertions(+), 11 deletions(-) diff --git a/application-centric/Controller.md b/application-centric/Controller.md index 5bf48280..fd8eec82 100644 --- a/application-centric/Controller.md +++ b/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 diff --git a/application-centric/OAM.md b/application-centric/OAM.md index b1835702..5a64dd91 100644 --- a/application-centric/OAM.md +++ b/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）来组合组件和相应的特征，以构建应部署的应用程序的具体实例。 diff --git a/consensus/raft-ConfChange.md b/consensus/raft-ConfChange.md index 50475053..225cea34 100644 --- a/consensus/raft-ConfChange.md +++ b/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~。 diff --git a/consensus/raft-log-replication.md b/consensus/raft-log-replication.md index 03d3f347..239a66ca 100644 --- a/consensus/raft-log-replication.md +++ b/consensus/raft-log-replication.md @@ -29,12 +29,12 @@ 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)
@@ -42,7 +42,7 @@ Raft 算法中，领导者通过广播消息（AppendEntries RPC）将日志条 ::: -领导者向客户端返回结果，并不代表日志复制过程已经完成，因为跟随者尚不清楚日志条目是否已被大多数节点确认。Raft 的设计通过心跳或后续日志复制请求中携带更新的提交索引（leaderCommit），通知跟随者提交日志。这样的设计将“达成共识的过程”优化为一个阶段，减少了客户端约一半的等待时间。 +领导者向客户端返回结果，并不意味着日志复制过程已完全结束，跟随者尚不清楚日志条目是否已被大多数节点确认。Raft 的设计通过心跳或后续日志复制请求中携带更新的提交索引（leaderCommit），通知跟随者提交日志。此机制将“达成共识的过程”优化为一个阶段，减少了客户端约一半的等待时间。 :::tip 如何选择节点的数量 diff --git a/network/iptables.md b/network/iptables.md index de8153dd..b37d81da 100644 --- a/network/iptables.md +++ b/network/iptables.md @@ -12,7 +12,7 @@ iptables 默认有五条链：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTIN iptables 把常用数据包管理操作总结成具体的动作，当数据包经过内核协议栈的钩子时（也就是 iptables 的链），根据 IP 数据包源地址/目的地址、传输层协议（TCP/UDP/ICMP/...）、端口等信息判断是否触发定义好的动作。 -如下为常见的动作说明： +常见的动作及含义如下： - ACCEPT：允许数据包通过，继续执行后续的规则。 - DROP：直接丢弃数据包。