fix typo

container/Extended-Resource.md

@@ -6,7 +6,7 @@
 
 作为一个通用型的容器编排平台，Kubernetes 自然需要与各类异构资源集成，以满足不同用户的需求。为此，Kubernetes 提供了扩展资源（Extended Resource）机制，使集群管理员能够声明、管理和使用除标准资源之外的自定义资源。
 
-为了能让调度器知道自定义资源在每台宿主机的可用量，宿主机节点必须能够访问 API Server 汇报自定义资源情况。汇报自定义资源的手段是向 Kubernetes API Server 发送 HTTP PATCH 请求。例如，某个宿主机节点中带有 4 个 GPU 资源。下面是一个 PATCH 请求的示例，该请求为 `<your-node-name>` 节点发布 4 个 GPU 资源。
+为了能让调度器知道自定义资源在每台宿主机的可用量，宿主机节点必须能够访问 API Server 汇报自定义资源情况。汇报自定义资源的手段是向 Kubernetes API Server 发送 HTTP PATCH 请求。例如，某个宿主机节点中带有 4 个 GPU 资源，请看下面的 PATCH 请求的示例：
 ```bash
 PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
 Accept: application/json
@@ -33,7 +33,7 @@ Status
   	nvidia.com/gpu: 4
 ```
 
-如此，配置一个 Pod 对象时，便可以像配置标准资源一样，配置自定义资源的 request 和 limits。以下是一个带有申请 nvidia.com/gpu 资源的 Pod 配置示例。
+如此，配置一个 Pod 对象时，便可以像配置标准资源一样，配置自定义资源的 request 和 limits。下面是一个带有申请 nvidia.com/gpu 资源的 Pod 配置示例。
 
 ```yaml
 apiVersion: v1
@@ -52,14 +52,13 @@ spec:
 
 当 Pod 被成功调度到宿主机节点后，进行相应的配置（设置环境变量，挂载设备驱动等操作），便可在容器内部使用 GPU 资源了。
 
-
 ## 2. Device Plugin
 
-当然，除非有特殊情况，通常不需用手动的方式扩展异构资源。
+除非特殊情况，通常不需用手动的方式扩展异构资源。
 
-在 Kubernetes 中，管理各类异构资源的操作由一种称为“Device Plugin”（设备插件）的机制负责。
+在 Kubernetes 中，管理各类异构资源的操作由一种称为设备插件（Device Plugin）的机制负责。
 
-Device Plugin 核心思想是提供了多个 gRPC 接口，硬件供应商根据接口规范为特定硬件编写插件。kubelet 通过 gRPC 接口与设备插件交互，实现设备发现、状态更新、资源上报等。最后，Pod 通过 request、limit 显式声明，即可使用各类异构资源，如同 CPU、内存一样。
+Device Plugin 核心思想是提供了多个 gRPC 接口，kubelet 通过 gRPC 接口与设备插件交互，实现设备发现、状态更新、资源上报等。最后，Pod 通过 request、limit 显式声明，即可使用各类异构资源，如同 CPU、内存一样。
 
 Device Plugin 定义的 gRPC 接口如下所示，硬件设备插件按照规范实现接口，与 kubelet 进行交互，Kubernetes 便可感知和使用这些硬件资源。
 

container/container-network.md

@@ -180,7 +180,7 @@ $ docker network create -d macvlan \
 
 可以看出，Underlay 底层网络模式直接利用物理网络资源，绕过了容器网络桥接和 NAT，因此具有最佳的性能表现。不过，由于依赖硬件和底层网络环境，部署时需要根据具体的软硬件条件进行调整，缺乏 Overlay 网络那样的开箱即用的灵活性。
 
-## 7.6.4 CNI 插件以及生态
+## 7.6.4 CNI 插件及生态
 
 设计一个容器网络模型是一个很复杂的事情，Kubernetes 本身并不直接实现网络模型，而是通过 CNI（Container Network Interface，容器网络接口）把网络变成外部可扩展的功能。
 

container/kube-scheduler.md

@@ -1,4 +1,4 @@
-# 7.7.3 调度器与扩展设计
+# 7.7.3 默认调度器及扩展设计
 
 如果集群中节点的数量只有几十个，为新建的 Pod 找到合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时，情况就复杂了：
 - 首先，节点资源无时无刻不在变化，如果每次调度都需要数千次远程请求获取信息，势必因耗时过长，增加调度失败的风险。

container/storage.md

@@ -192,16 +192,16 @@ volumeBindingMode: Immediate
 
 ## 7.5.6 Kubernetes 存储系统设计
 
-相信大部分读者对如何使用 Volume 已经没有疑问了。接下来，我们将继续探讨存储系统与 Kubernetes 的集成，以及它们是如何与 Pod 相关联的。在深入这个高级主题之前，我们需要先掌握一些关于操作存储设备的基础知识。
+相信大部分读者对如何使用 Volume 已经没有疑问了。接下来，我们将继续探讨存储系统与 Kubernetes 的集成，以及它们是如何与 Pod 相关联的。
 
-Kubernetes 继承了操作系统接入外置存储的设计，将新增或卸载存储设备分解为以下三个操作：
+在深入这个高级主题之前，我们需要先掌握一些关于操作存储设备的基础知识。Kubernetes 继承了操作系统接入外置存储的设计，将新增或卸载存储设备分解为以下三个操作：
 
 - **准备**（Provision）：首先，需要确定哪种设备进行 Provision。这一步类似于给操作系统准备一块新的硬盘，确定接入存储设备的类型、容量等基本参数。其逆向操作为 delete（移除）设备。
 - **附加**（Attach）：接下来，将准备好的存储附加到系统中。Attach 可类比为将存储设备接入操作系统，此时尽管设备还不能使用，但你可以用操作系统的 fdisk -l 命令查看到设备。这一步确定存储设备的名称、驱动方式等面向系统的信息，其逆向操作为 Detach（分离）设备。
 - **挂载**（Mount）：最后，将附加好的存储挂载到系统中。Mount 可类比为将设备挂载到系统的指定位置，这就是操作系统中 mount 命令的作用，其逆向操作为卸载（Unmount）存储设备。
 
 :::tip 注意
-如果 Pod 中使用的是 EmptyDir、HostPath 这类普通 Volume，并不会经历附加/分离的操作，它们只会被挂载/卸载到某一个 Pod 中。
+如果 Pod 中使用的是 EmptyDir、HostPath 这类 Volume，并不会经历附加/分离的操作，它们只会被挂载/卸载到某一个 Pod 中。
 :::
 
 Kubernetes 中的 Volume 创建和管理主要由 VolumeManager（卷管理器）、AttachDetachController（挂载控制器）和 PVController（PV 生命周期管理器）负责。前面提到的 Provision、Delete、Attach、Detach、Mount 和 Unmount 操作由具体的 VolumePlugin（第三方存储插件，也称 CSI 插件）实现。