From de1d974af803654cbfa4b7b2ba47aac45088784f Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 31 Jan 2025 22:31:41 +0800 Subject: [PATCH] fix typo --- container/Extended-Resource.md | 11 +++++------ container/container-network.md | 2 +- container/kube-scheduler.md | 2 +- container/storage.md | 6 +++--- 4 files changed, 10 insertions(+), 11 deletions(-) diff --git a/container/Extended-Resource.md b/container/Extended-Resource.md index c09e35bd..4257d8e1 100644 --- a/container/Extended-Resource.md +++ b/container/Extended-Resource.md @@ -6,7 +6,7 @@ 作为一个通用型的容器编排平台，Kubernetes 自然需要与各类异构资源集成，以满足不同用户的需求。为此，Kubernetes 提供了扩展资源（Extended Resource）机制，使集群管理员能够声明、管理和使用除标准资源之外的自定义资源。 -为了能让调度器知道自定义资源在每台宿主机的可用量，宿主机节点必须能够访问 API Server 汇报自定义资源情况。汇报自定义资源的手段是向 Kubernetes API Server 发送 HTTP PATCH 请求。例如，某个宿主机节点中带有 4 个 GPU 资源。下面是一个 PATCH 请求的示例，该请求为 `` 节点发布 4 个 GPU 资源。 +为了能让调度器知道自定义资源在每台宿主机的可用量，宿主机节点必须能够访问 API Server 汇报自定义资源情况。汇报自定义资源的手段是向 Kubernetes API Server 发送 HTTP PATCH 请求。例如，某个宿主机节点中带有 4 个 GPU 资源，请看下面的 PATCH 请求的示例： ```bash PATCH /api/v1/nodes//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 便可感知和使用这些硬件资源。 diff --git a/container/container-network.md b/container/container-network.md index b8956a6a..2f694c3d 100644 --- a/container/container-network.md +++ b/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，容器网络接口）把网络变成外部可扩展的功能。 diff --git a/container/kube-scheduler.md b/container/kube-scheduler.md index 71cf5f29..9b90b2a7 100644 --- a/container/kube-scheduler.md +++ b/container/kube-scheduler.md @@ -1,4 +1,4 @@ -# 7.7.3 调度器与扩展设计 +# 7.7.3 默认调度器及扩展设计 如果集群中节点的数量只有几十个，为新建的 Pod 找到合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时，情况就复杂了： - 首先，节点资源无时无刻不在变化，如果每次调度都需要数千次远程请求获取信息，势必因耗时过长，增加调度失败的风险。 diff --git a/container/storage.md b/container/storage.md index 18598f8e..375a1370 100644 --- a/container/storage.md +++ b/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 插件）实现。