fix typo

Observability/logging.md

@@ -135,7 +135,7 @@ ORDER BY id;
 
 作为一款分布式数据系统，ClickHouse 自然支持“分片”（Sharding）技术。
 
-ClickHouse 将海量数据切分成多个较小的部分，并分布到多个物理节点。也就是说，只要有足够多的硬件资源，ClickHouse 就能处理数万亿条记录、PB 级别规模的数据量。根据 Yandex 内部的基准测试结果来看（图 9-9），ClickHouse 性能表现遥遥领先对手，比 Vertica（一款商业 OLAP 软件）快约 5 倍、比 Hive 快 279 倍、比 InfiniDB 快 31 倍。
+ClickHouse 将数据切分成多个部分，并分布到不同的物理节点。也就是说，只要有足够多的硬件资源，ClickHouse 就能处理数万亿条记录、PB 级别规模的数据量。根据 Yandex 公布的测试结果来看（图 9-9），ClickHouse 性能表现遥遥领先对手，比 Vertica（一款商业 OLAP 软件）快约 5 倍、比 Hive 快 279 倍、比 InfiniDB 快 31 倍。
 
 :::center
   ![](../assets/ClickHouse-benchmark.jpeg)<br/>

consensus/Basic-Paxos.md

@@ -40,10 +40,9 @@ WHERE id = ? AND version = ?;
 
 我们可以借鉴“乐观锁”的思路，尝试解决图 6-5 中的并发冲突问题。请看下面的操作：
 
-首先，S~1~ 发起提案，S~3~ 收到 S~1~ 提案时，应该意识到 S~5~ 发起的提案（blue）的 Quorum 已经达成，S~1~ 提案（red）已经失效。根据先到先得原则，S~1~ 应该更新自己的提案值（red 替换为 blue），这个操作相当于对提案编号（乐观锁中的 version）“锁定”，防止在之后出现多个冲突的提案编号。
-
-了解哪些编号被接受后，接下来的处理就变得简单了。现在，我们可以直面 Paxos 算法的细节了。
+首先，S~1~ 发起提案，S~3~ 收到 S~1~ 提案时，应该意识到 S~5~ 发起的提案（blue）的 Quorum 已经达成，S~1~ 提案（red）已经失效。根据先到先得原则，S~1~ 应该更新自己的提案值（red 替换为 blue），这个操作相当于对提案编号（乐观锁中的 version）“锁定”，防止之后出现多个冲突的提案编号。
 
+了解接受了哪些编，接下来的处理就简单了。现在，我们可以直面 Paxos 算法的细节了。
 
 ## 2. Paxos 算法描述
 
@@ -98,7 +97,7 @@ Paxos 算法的第二个阶段称“批准阶段”（Accept）。提议者向
 
 **情况四：从情况三可以推导出另一种极端的情况**，多个提议者同时发起提案，在准备阶段互相抢占，反复刷新决策者上的提案编号，导致任何一方都无法达到多数派决议，这个过程理论上可以无限持续下去，形成“活锁”（livelock）。
 
-解决这个问题并复杂，把重试时间随机化，就能减少这种巧合发生。
+解决这个问题并复杂，随机重试时间，就能减少这种巧合发生。
 :::center
   ![](../assets/paxos-p4.png) <br/>
   图 6-10 出现活锁问题

container/Extended-Resource.md

@@ -1,4 +1,4 @@
-# 7.7.2 扩展资源与 Device Plugin
+# 7.7.2 扩展资源与设备插件
 
 在 Kubernetes 中，节点的标准资源（如 CPU、内存和存储）由 Kubelet 自动报告，但节点内的异构硬件资源（如 GPU、FPGA、RDMA 或硬件加速器），Kubernetes 并未识别和管理。
 
@@ -88,4 +88,4 @@ service DevicePlugin {
 
 最后，再来看扩展资源和设备插件的问题。Pod 只能通过类似“nvidia.com/gpu:2”的计数方式申请 2 个 GPU，但这些 GPU 的具体型号、拓扑结构、是否共享等属性并不明确。也就是说，设备插件仅实现了基本的入门级功能，能用，但不好用。
 
-在“成本要省”、“资源利用率要高”背景推动下，Nvidia、Intel 等头部厂商联合推出了“动态资源分配”（Dynamic Resource Allocation，DRA）机制，允许用户以更复杂的方式描述异构资源，而不仅仅是简单的计数形式。DRA 属于较新的机制，具体的接口规范可能因硬件供应商和 Kubernetes 版本不同而有所变化。限于篇幅，笔者就不再扩展讨论了，有兴趣的读者可以查阅其他资料。
+在“成本要省”、“资源利用率要高”背景推动下，Nvidia、Intel 等头部厂商联合推出了“动态资源分配”（Dynamic Resource Allocation，DRA）机制，允许用户以更复杂的方式描述异构资源，而不仅仅是简单的计数形式。DRA 属于较新的机制，具体的接口规范因硬件供应商和 Kubernetes 版本不同而有所变化。限于篇幅，笔者就不再扩展讨论了，有兴趣的读者请查阅其他资料。

container/auto-scaling.md

@@ -1,6 +1,6 @@
 # 7.8 资源弹性伸缩
 
-为了平衡服务负载的巨大波动及资源预估与实际使用之间的差距，Kubernetes 提供了三种资源自动扩缩（autoscaling）解决方案：HPA、VPA 以及节点自动伸缩（Cluster Autoscaler）组件。
+为了平衡服务负载的巨大波动及资源预估与实际使用之间的差距，Kubernetes 提供了 HPA、VPA 以及 CA 三种资源自动扩缩（autoscaling）机制。
 
 ## 7.8.1 Pod 水平自动伸缩
 
@@ -10,7 +10,7 @@ HPA 的原理很简单，即监控资源使用程度做出相应的调整：
 - 当负载较高时，增加工作负载的 Pod 副本数量；
 - 当负载减少时，缩减工作负载的 Pod 副本数量。
 
-实现自动扩缩关键是，如何准确识别资源耗用程度？为此，Kubernetes 提供了一种称为 Metrics API 的指标接口，用于获取节点、Pod 资源情况。来看一个 Metrics API 的响应示例，输出了 cpu、memory 资源耗用情况。
+实现自动扩缩的关键在于如何准确识别资源的使用情况。为此，Kubernetes 提供了 Metrics API，用于获取节点和 Pod 的资源信息。以下是 Metrics API 的响应示例，展示了 CPU 和内存的资源使用情况。
 
 ```bash
 $ kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/minikube" | jq '.'
@@ -48,9 +48,7 @@ $ kubectl autoscale deployment foo --cpu-percent=70 --min=1 --max=10
 
 VPA 全称是 Vertical Pod Autoscaler（Pod 垂直自动伸缩）。它的实现思路与 HPA 基本一致，两者都是通过 Metrics 接口获取指标，评估后做出相应的调整。不同的是，VPA 调整的是工作负载的资源配额（如 Pod 的 CPU 和内存的 request 和 limit）。
 
-值得注意的是，VPA 是 Kubernetes 的附加组件，需要安装和配置后才能为工作负载（如 Deployment）定义资源调整策略。
-
-以下是一个 VPA 配置示例，供读者参考：
+值得注意的是，VPA 是 Kubernetes 的附加组件，需要安装和配置后才能为工作负载（如 Deployment）定义资源调整策略。以下是一个 VPA 配置示例，供读者参考：
 
 ```yaml
 apiVersion: autoscaling.k8s.io/v1
@@ -66,7 +64,7 @@ spec:
   updatePolicy:
     updateMode: Auto  # 决定 VPA 如何应用推荐的资源调整，也可以设置为 "Off" 或 "Initial" 来控制更新策略
 ```
-将上述 YAML 文件提交到 Kubernetes 集群后，通过 kubectl describe vpa 命令查看 VPA 推荐的资源策略。
+将上述 YAML 文件提交到 Kubernetes 集群后，通过 kubectl describe vpa 命令查看 VPA 推荐的资源策略：
 
 ```bash
 $ kubectl describe vpa example-app-vpa
@@ -89,7 +87,7 @@ Recommendation:
 ...
 ```
 
-相比于 HPA，VPA 适用于负载动态变化较大、资源需求不确定的场景，尤其是在无法精确预估应用资源需求的情况下。
+可以看出，VPA 更适用于负载变化较大、资源需求不确定的场景，尤其在无法精确预估应用资源需求时。
 
 ## 7.8.3 基于事件驱动的伸缩
 
@@ -140,9 +138,9 @@ spec:
 
 业务的增长（也有可能萎缩），会导致集群资源不足或者过度冗余。如果能根据集群资情况自动增/减节点，保证集群可用性的同时，还能最大程度降低资源成本！
 
-Cluster AutoScaler 是专门用于调整节点的组件，它的功能如下：
-- **自动扩展（Scale Up）**：当节点资源不能满足 Pod 需求时，Cluster AutoScaler 向云服务提供商（如 GCE、GKE、Azure、AKS、AWS 等）请求创建新的节点，扩展集群容量，确保业务能够获得所需的资源。
-- **自动缩减（Scale Down）**：当节点资源利用率长期处于低水平（如低于 50%），Cluster AutoScaler 将该节点上的 Pod 调度到其他节点，然后将节点从集群中移除，避免资源浪费。
+CA（Cluster AutoScaler）就是专门用于调整节点的组件，它的功能如下：
+- **自动扩展**（Scale Up）：当节点资源不能满足 Pod 需求时，Cluster AutoScaler 向云服务提供商（如 GCE、GKE、Azure、AKS、AWS 等）请求创建新的节点，扩展集群容量，确保业务能够获得所需的资源。
+- **自动缩减**（Scale Down）：当节点资源利用率长期处于低水平（如低于 50%），Cluster AutoScaler 将该节点上的 Pod 调度到其他节点，然后将节点从集群中移除，避免资源浪费。
 
 :::center
   ![](../assets/Cluster-AutoScaler.png)<br/>