更新容器资源

container/auto-scaling.md

@@ -14,7 +14,7 @@ Kubernetes 弹性伸缩组件可以从伸缩方向和伸缩对象两个维度进
 
 HPA 组件根据资源利用率或者自定义指标自动调整 Deployment、StatefulSet 或其他类似资源的扩展和缩减，实现部署的规模接近于实际服务的负载。HPA 最初的 v1 版本只支持 CPU 指标的伸缩，局限性明显。因为传统的指标如 CPU 或内存不一定就能代表服务的负载情况，比如事件驱动的应用程序 Kafka，传入 kafka 事件的数量才是确定负载的真实指标。在持续集成（CI）流水线中，当提交代码时，可能会触发一系列的流水线作业（镜像编译、应用打包、可用性测试），如果持续集成的作业出现瓶颈，这里的度量标准应该是等待执行的任务数，那么基于作业队列数量伸缩比仅仅观察 CPU 或者内存指标更有效。
 
-当然，Kubernetes 也看到了这一点。HPA 在经过三个大版本的演进之后，最新的 autoscaling/v2 实现支持 Resource Metrics（资源指标，如pod的CPU）和 Custom Metrics（自定义指标）和 External Metrics（额外指标）的缩放。
+当然，Kubernetes 也看到了这一点。HPA 在经过三个大版本的演进之后，最新的 autoscaling/v2 实现支持 Custom Metrics（自定义指标）和 External Metrics（额外指标）的缩放。
 
 ## 基于事件驱动的方式
 

container/resource-limit.md

@@ -1,28 +1,30 @@
 # 7.7 资源与调度
 
-对于一个编排系统而言，资源管理至少要考虑这几个问题：**资源模型的抽象**（有何种资源、如何表示这些资源）；**资源的调度**（如何描述一个资源申请、如何描述一台 node 资源分配的状态以及调度的算法），对照上面几个问题，我们来看下 Kubernetes 是如何设计的。
+对于 Kubernetes 编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，调度的意思是实现两者之间最恰当的撮合，撮合的关键在于容器编排系统如何管理以及分配集群节点的资源。
+
+管理集群的资源至少要考虑这几个问题：资源模型的抽象（有何种资源、如何表示这些资源）；资源的调度（如何描述一个资源申请、如何描述一台 node 资源分配的状态以及调度的算法）；资源不足时，如何驱逐，如何实现 Pod 的优先级。
 
 ## 资源模型的抽象
 
-Kubernetes 将管理的物理资源抽象为**可压缩**和**不可压缩**两类。
+与调度关系最密切的物理资源是处理器和内存/显存，根据调度的处理方式的差别，这两类资源又可分为可压缩和不可压缩两类。
 
-**可压缩的资源典型的是 CPU**，当此类资源超限时，进程使用 CPU 会被限制，应用表现变得卡顿，业务延迟明显增加，但**进程不会被杀掉**。在 Kubernetes 中，CPU 的计量单位为毫核（m），一个 Node 节点 CPU 核心数量乘以 1000，得到的就是该 Node 节点总的 CPU 总数量。你得注意，CPU 的计量是绝对值，绝对值的意思是无论容器运行在单核、双核机器上，500m CPU 表示的是相同的计算能力。
+可压缩的资源典型的是 CPU，此类资源超限时，容器进程使用 CPU 会被限制，应用表现变得卡顿，业务延迟明显增加，但**容器进程不会被杀掉**。在 Kubernetes 中，一个 Node 节点 CPU 核心数量乘以 1000，得到的就是该 Node 节点总的 CPU 总数量。CPU 的计量单位为毫核（m），计量方式有多种写法：50m、0.5（`1000m*0.5`）。CPU 的计量是绝对值，这意味着无论容器运行在单核、双核机器上，500m CPU 表示的是相同的计算能力。
 
-**不可压缩的资源为内存、显存（GPU）**，当此类资源不足时，进程产生 OOM 问题（Out of Memory，内存溢出）并**被杀掉**。内存的计算单位为字节，计量方式有多种写法，譬如使用 M（Megabyte）、Mi（Mebibyte）以及不带单位的数字，以下表达式所代表的是相同的值。
+不可压缩的资源为内存、显存（GPU），此类资源不足时，容器进程产生 OOM 问题（Out of Memory，内存溢出）并**被杀掉**。内存的计算单位为字节，计量方式有多种写法，譬如使用 M（Megabyte）、Mi（Mebibyte）以及不带单位的数字，以下表达式所代表的是相同的值。
 
 ```plain
 128974848, 129e6, 129M, 123Mi
 ```
-注意 Mebibyte 和 Megabyte 的区分，123 Mi = `123*1024*1024B` = 129 M，123 M 等于 `1*1000*1000`字节，所以 1M < 1Mi，显然使用带这个小 i 的更准确。
+注意 Mebibyte 和 Megabyte 的区分，123 Mi = `123*1024*1024B` 、123 M = `1*1000*1000 B`。1M < 1Mi，显然使用带小 i 的更准确。
 
-## 资源调度
+## 资源申请及限制
 
 Kubernetes 抽象了两个概念 requests 和 limits 用以描述容器资源的分配。
 
 - **requests** 容器需要的最小资源量。举例来讲，对于一个 Spring Boot 业务容器，这里的 requests 必须是容器镜像中 JVM 虚拟机需要占用的最少资源。
 - **limits** 容器最大可以消耗的资源上限，防止过量消耗资源导致资源短缺甚至宕机。
 
-如下图所示，每一个容器都可以独立地通过 resources 属性设定相应的 requests 和 limits，容器的资源调度以 requests 为准。
+Pod 是由一到多个容器组成，所以资源的需求作用在容器上的。如下图所示，每一个容器都可以独立地通过 resources 属性设定相应的 requests 和 limits，容器的资源调度以 requests 为准。
 
 <div  align="center">
 	<img src="../assets/requests-limits.png" width = "500"  align=center />