Skip to content

Commit

Permalink
更新
Browse files Browse the repository at this point in the history
  • Loading branch information
isno committed Jan 2, 2024
1 parent bb88ac1 commit 69ec37f
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 5 deletions.
2 changes: 1 addition & 1 deletion container/Container-Orchestration-Wars.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# 7.1 容器编排之争

为什么容器化技术会受到如此追捧?Kubernetes 为何成为容器编排的事实标准?对于以上的问题,如果笔者照本宣科地介绍 Kubernetes 架构如何新颖、设计如何优秀,相信并不能给读者们留有什么深刻印象,教条式介绍睡过一觉不会有多少人记起。故事让内容变得有趣**在容器技术变革的浪潮中,曾发生过一场”史诗大战“,业界称之为 ”容器编排之争(Container Orchestration Wars)“**。本篇我们回顾这段历史,从宏观角度去观察 Kubernetes 的诞生与演变的驱动力。
如果笔者照本宣科地介绍 Kubernetes 架构如何新颖、设计如何优秀,相信并不能给读者们留有什么深刻印象,教条式介绍睡过一觉不会有多少人记起,而故事让内容变得有趣**在容器技术变革的浪潮中,曾发生过一场”史诗大战“,业界称之为 ”容器编排之争(Container Orchestration Wars)“**。本篇我们回顾这段历史,从宏观角度去观察 Kubernetes 的诞生与演变的驱动力。

**容器技术的兴起源于 PaaS 技术的普及**,在云计算早期的 IaaS 阶段虚拟机还是太过于笨重,每一台虚拟机都需要消耗CPU、内存等计算资源才能支撑应用的运行,即便应用再小,系统的开销都是固定的成本。在 IaaS 时代,云计算厂商一直思考的一个问题是如何充分利用资源,这个问题在云计算进入 PaaS 时代找到了答案。

Expand Down
7 changes: 3 additions & 4 deletions container/resource-limit.md
Original file line number Diff line number Diff line change
@@ -1,21 +1,20 @@
# 7.6 编排调度模型

对于一个编排系统而言,资源管理至少要考虑这几个问题:**资源模型的抽象**譬如有何种资源,如何表示这些资源);**资源的调度**譬如如何描述一个资源申请、如何描述一台 node 资源分配的状态以及调度的算法),对照上面几个问题,我们来看下 Kubernetes 是如何设计的。
对于一个编排系统而言,资源管理至少要考虑这几个问题:**资源模型的抽象**有何种资源、如何表示这些资源);**资源的调度**如何描述一个资源申请、如何描述一台 node 资源分配的状态以及调度的算法),对照上面几个问题,我们来看下 Kubernetes 是如何设计的。

## 资源模型的抽象

Kubernetes 将管理的物理资源抽象为**可压缩****不可压缩**两类。

**可压缩的资源典型的是 CPU**,当此类资源超限时,Pod 中进程使用 CPU 会被限制,应用表现变得卡顿,业务延迟明显增加,但**进程不会被 kill 掉**。在 Kubernetes 中,CPU 的计量单位为毫核(m),一个 Node 节点 CPU 核心数量乘以 1000,得到的就是该 Node 节点总的 CPU 总数量。譬如,一个 Node 节点有两核,那么该 Node 节点的 CPU 总量为 2000m。需要注意,CPU 的计算单位是绝对值,无论容器运行在单核、双核机器上,500m CPU 表示的是相同的计算能力。
**可压缩的资源典型的是 CPU**,当此类资源超限时,进程使用 CPU 会被限制,应用表现变得卡顿,业务延迟明显增加,但**进程不会被杀掉**。在 Kubernetes 中,CPU 的计量单位为毫核(m),一个 Node 节点 CPU 核心数量乘以 1000,得到的就是该 Node 节点总的 CPU 总数量。你得注意,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 的更准确。


## 资源调度

Kubernetes 抽象了两个概念 requests 和 limits 用以描述容器资源的分配。
Expand Down

0 comments on commit 69ec37f

Please sign in to comment.