PRF&PUB:20171016 Introducing CRI-O 1.0.md

@geekpi
This commit is contained in:
wxy 2017-10-31 23:50:18 +08:00
parent e160a56523
commit a4d3fb3b9c

View File

@ -1,37 +1,41 @@
# 介绍 CRI-O 1.0
CRI-O 1.0 简介
=====
去年Kubernetes 项目推出了[容器运行时接口][11]CRI - 一个插件接口,它让 kubelet用于创建 pod 和启动容器的集群节点代理)有使用不同 OCI 兼容容器运行时的能力,而不需要重新编译 Kubernetes。在这项工作的基础上[CRI-O][12] 项目([原名 OCID] [13])准备为 Kubernetes 提供轻量级的运行时。
去年Kubernetes 项目推出了<ruby>[容器运行时接口][11]<rt>Container Runtime Interface</rt></ruby>CRI这是一个插件接口,它让 kubelet用于创建 pod 和启动容器的集群节点代理)有使用不同的兼容 OCI 的容器运行时的能力,而不需要重新编译 Kubernetes。在这项工作的基础上[CRI-O][12] 项目([原名 OCID] [13])准备为 Kubernetes 提供轻量级的运行时。
那么这个**真的**是什么意思?
那么这个**真的**是什么意思?
CRI-O 允许你直接从 Kubernetes 运行容器,而不需要任何不必要的代码或工具。只要容器符合 OCI 标准CRI-O 就可以运行它,去除外来的加工,并让容器做它们最好的:加速你的新一代原生云程序。
CRI-O 允许你直接从 Kubernetes 运行容器,而不需要任何不必要的代码或工具。只要容器符合 OCI 标准CRI-O 就可以运行它,去除外来的工具,并让容器做其擅长的事情:加速你的新一代原生云程序。
在引入 CRI 之前Kubernetes 通过“[一个内部的][14][易失性][15][接口][16]”与特定的容器运行时相关联。这导致了上游 Kubernetes 社区以及在编排平台之上构建解决方案的供应商的大量维护开销。
使用 CRIKubernetes 可以与容器运行时无关。容器运行时的提供者不需要实现 Kubernetes 已经提供的功能。这是社区的胜利,因为它让项目独立进行,同时一起工作。
使用 CRIKubernetes 可以与容器运行时无关。容器运行时的提供者不需要实现 Kubernetes 已经提供的功能。这是社区的胜利,因为它让项目独立进行,同时仍然可以共同工作。
在大多数情况下,我们不认为 Kubernetes 的用户(或 Kubernetes 的分发者,如 OpenShift真的关心容器运行时。他们希望它工作但他们不希望考虑太多。就像你不关心(通常)机器上是否有 GNU Bash、Korn、Zsh 或其他符合 POSIX 标准 shell。你只需要有一个标准的方式来运行你的脚本或程序。
在大多数情况下,我们不认为 Kubernetes 的用户(或 Kubernetes 的发行版,如 OpenShift真的关心容器运行时。他们希望它工作但他们不希望考虑太多。就像你(通常)不关心机器上是否有 GNU Bash、Korn、Zsh 或其它符合 POSIX 标准 shell。你只是要一个标准的方式来运行你的脚本或程序而已
** CRI-OKubernetes 的轻量级容器运行时**
这就是 CRI-O 提供的。该名称来自 CRI 和开放容器计划 OCI因为 CRI-O 严格关注 OCI 兼容的运行时和容器镜像。
### CRI-OKubernetes 的轻量级容器运行时
现在CRI-O 支持 runc 和 Clear Container 运行时,尽管它应该支持任何遵循 OCI 的运行时。它可以从任何容器仓库中拉取镜像,并使用[容器网络接口][17] CNI 处理网络,以便任何兼容 CNI 的网络插件可与该项目一起使用。
这就是 CRI-O 提供的。该名称来自 CRI 和开放容器计划OCI因为 CRI-O 严格关注兼容 OCI 的运行时和容器镜像。
现在CRI-O 支持 runc 和 Clear Container 运行时,尽管它应该支持任何遵循 OCI 的运行时。它可以从任何容器仓库中拉取镜像,并使用<ruby>[容器网络接口][17]<rt>Container Network Interface</rt></ruby>CNI处理网络以便任何兼容 CNI 的网络插件可与该项目一起使用。
当 Kubernetes 需要运行容器时,它会与 CRI-O 进行通信CRI-O 守护程序与 runc或另一个符合 OCI 标准的运行时)一起启动容器。当 Kubernetes 需要停止容器时CRI-O 会来处理。这没什么令人兴奋的,它只是在幕后管理 Linux 容器,以便用户不需要担心这个关键的容器编排。
![CRI-O Overview](https://www.redhat.com/cms/managed-files/styles/max_size/s3/CRI-Ov1_Chart_1.png?itok=2FJxD8Qp "CRI-O Overview")
![CRI-O Overview](https://www.redhat.com/cms/managed-files/styles/max_size/s3/CRI-Ov1_Chart_1.png?itok=2FJxD8Qp "CRI-O Overview")
**CRI-O 不是什么**
值得花一点时间在 CRI-O _不是_ 什么上。CRI-O 的范围是与 Kubernetes 一起工作来管理和运行 OCI 容器。这不是一个面向开发人员的工具,尽管该项目确实有一些面向用户的工具进行故障排除。
### CRI-O 不是什么
例如,构建镜像超出了 CRI-O 的范围,这些留给像 Docker 的构建命令 [Buildah][18] 或[ OpenShift 的 Source-to-Image][19]S2I这样的工具。一旦构建完镜像CRI-O 将乐意运行它,但构建镜像留给其他工具。
值得花一点时间了解下 CRI-O _不是_什么。CRI-O 的范围是与 Kubernetes 一起工作来管理和运行 OCI 容器。这不是一个面向开发人员的工具,尽管该项目确实有一些面向用户的工具进行故障排除。
例如,构建镜像超出了 CRI-O 的范围,这些留给像 Docker 的构建命令、 [Buildah][18] 或 [OpenShift 的 Source-to-Image][19]S2I这样的工具。一旦构建完镜像CRI-O 将乐意运行它,但构建镜像留给其他工具。
虽然 CRI-O 包含命令行界面 CLI但它主要用于测试 CRI-O而不是真正用于在生产环境中管理容器的方法。
**下一步**
### 下一步
现在 CRI-O 1.0 发布了,我们希望看到它作为一个稳定功能在下一个 Kubernetes 版本中发布。1.0 版本将与 Kubernetes 1.7.x 系列一起使用,即将发布的 CRI-O 1.8-rc1 适合 Kubernetes 1.8.x。
我们邀请您加入我们,以促进开源 CRI-O 项目的开发,并感谢我们目前的贡献者为达成这一里程碑而提供的帮助。如果你想贡献或者跟随开发,就去[ CRI-O 项目的 GitHub 仓库][20],然后关注[ CRI-O 博客][21]。
我们邀请您加入我们,以促进开源 CRI-O 项目的开发,并感谢我们目前的贡献者为达成这一里程碑而提供的帮助。如果你想贡献或者关注开发,就去 [CRI-O 项目的 GitHub 仓库][20],然后关注 [CRI-O 博客][21]。
--------------------------------------------------------------------------------
@ -39,7 +43,7 @@ via: https://www.redhat.com/en/blog/introducing-cri-o-10
作者:[Joe Brockmeier][a]
译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID)
校对:[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出