Skip to content

Commit

Permalink
fix typo
Browse files Browse the repository at this point in the history
  • Loading branch information
@isno
isno committed May 5, 2024
1 parent c5208af commit 1b8e3e2
Show file tree
Hide file tree
Showing 3 changed files with 13 additions and 10 deletions.
11 changes: 7 additions & 4 deletions README.md
View file
Expand Up @@ -20,10 +20,13 @@

我会持续更新这个仓库的内容，如果想要关注可以点 `star` 。

<div align="center">
<img src="./assets/star-history-20231218.png" width = "460" align=center />
<p><a href="https://github.com/isno/theByteBook">https://github.com/isno/theByteBook</a></p>
</div>

:::center

[![Star History Chart](https://api.star-history.com/svg?repos=isno/thebytebook&type=Date)](https://star-history.com/#isno/thebytebook&Date)
<p><a href="https://github.com/isno/theByteBook">https://github.com/isno/theByteBook</a></p>
:::



## 如何阅读
Expand Down
4 changes: 2 additions & 2 deletions container/CRI.md
View file
Expand Up @@ -30,9 +30,9 @@ CRI 实现上是一套通过 Protocol Buffer 定义的 API，如下图：

## containerd

不过 Docker 也没有“坐以待毙”，与其将来被人分离或者抛弃不用，不如主动革新。
不过 Docker 也没有“坐以待毙”，与其将来被人分离或者抛弃不用，不如主动革新。docker 采取了“断臂求生”的策略推动自身的重构，把原本单体架构的 Docker Engine 拆分成了多个模块，早期 containerd 单独开源，后来捐献给了 CNCF，目的希望与 Kubernetes 深度绑定在一起。

于是 Docker 采取了“断臂求生”的策略推动自身的重构，把原本单体架构的 Docker Engine 拆分成了多个模块，其中的 Docker daemon 部分就捐献给了 CNCF，形成了 containerd 与 Kubernetes 深度绑定在一起。containerd 作为 CNCF 的托管项目，自然符合 CRI 标准的。但 Docker 出于自己诸多原因的考虑，它只是在 Docker Engine 里调用了 containerd，外部的接口仍然保持不变，也就是说还不与 CRI 兼容。
containerd 作为 CNCF 的托管项目，自然符合 CRI 标准的。但 Docker 出于自己诸多原因的考虑，它只是在 Docker Engine 里调用了 containerd，外部的接口仍然保持不变，也就是说还不与 CRI 兼容。

由于 Docker 的“固执己见”且 Docker 是当时容器技术主流存在，Kuberentes 虽然提出了 CRI 接口规范，仍然需要去适配 CRI 与 Docker 的对接，因此它需要一个中间层（shim，垫片）来对接 Kubelet 和 Docker 运行时实现。

Expand Down
8 changes: 4 additions & 4 deletions container/Docker.md
View file
Expand Up @@ -16,15 +16,15 @@

这也让当时 Docker 阵营和粉丝们无比担心 Docker 的命运，不管最终鹿死谁手，容器技术的分裂对所有牵涉其中的人没有任何好处，于是 Linux 基金会出面调和，双方各退一步，最终结果是 Linux 基金会于 2015 年 6 月在 DockerCon 大会上宣布成立 OCI（Open Container Initiative，开放容器倡议）项目[^1]。

OCI 的创始成员包括 Amazon、Microsoft、CoreOS、Docker、Intel、Mesosphere 和 Red Hat。Docker 在这个名单内只能算一个小角色，OCI 的成立最终结束了容器技术标准之争，Docker 公司也被迫放弃自己的独家控制权。作为回报，Docker 的容器格式被 OCI 采纳为新标准的基础，并且由 Docker 起草 OCI 草案规范的初稿。
OCI 的成立最终结束了容器技术标准之争，Docker 公司也被迫放弃自己的独家控制权。作为回报，Docker 的容器格式被 OCI 采纳为新标准的基础，并且由 Docker 起草 OCI 草案规范的初稿。

当然这个“标准起草者” 也不是那么好当的，Docker 需要提交自己的容器引擎源码作为启动资源。首先是 Docker 最初使用的容器引擎 libcontainer，这是 Docker 在容器运行时方面的核心组件之一 ，用于实现容器的创建、管理和运行。Docker 将 libcontainer 捐赠给了OCI，成为 OCI Runtime Specification 的基础。在 OCI 的基础上，OCI Runtime Specification 进一步发展演进，并形成了一个名为"runtime-spec" 的项目，后来为了更好地推进容器运行时的标准化和互操作性，OCI runtime-spec 项目与 OCI 的其他相关项目合并，形成了 OCI Runtime Bundle 规范，并将容器运行时的核心组件命名为"runc"。
当然这个“标准起草者” 也不是那么好当的，Docker 需要提交自己的容器引擎源码作为启动资源。首先是 Docker 最初使用的容器引擎 libcontainer，这是 Docker 在容器运行时方面的核心组件之一 ，用于实现容器的创建、管理和运行。Docker 将 libcontainer 捐赠给了OCI，成为 runtime-spec 的基础。在 OCI 的基础上，后来为了更好地推进容器运行时的标准化和互操作性，OCI runtime-spec 项目与 OCI 的其他相关项目合并，形成了 OCI Runtime Bundle 规范，并将容器运行时的核心组件命名为"runc"。

:::tip runc

RunC 是非常小的运行核，其目的在于提供一个干净简单的运行环境，他就是负责隔离 CPU、内存、网络等形成一个运行环境，可以看作一个小的操作系统。
RunC 是非常小的运行核，其目的在于提供一个干净简单的运行环境，他就是负责隔离 CPU、内存、网络等形成一个运行环境，可以看作一个小的操作系统。RunC 的使用者都是一些 CaaS 服务商，个人开发者知晓的并不是太多。

Docker 是从1.11支持RunC的，想必 Docker 当时的心态也很复杂：一方面作为 OCI 成员必须支持 RunC，但是另一方面他会担心 RunC 对 Docker 的替代的威胁。
Docker 是从 1.11 支持 RunC 的，想必 Docker 当时的心态也很复杂：一方面作为 OCI 成员必须支持 RunC，但是另一方面他会担心 RunC 对 Docker 的替代的威胁。
:::


Expand Down

0 comments on commit 1b8e3e2

Please sign in to comment.