广告

KubeCon北美峰会热点之容器运行时

  • 浏览(269)
  • 评论(0)
  • 译者:k8s

K8S技术社区评论

虽然Docker在容器运行时领域仍然占据垄断地位,但是越来越多新的容器运行时在试图挑战Docker的领导地位,如本次KubeCon 2017大会最新发布的Kata项目,以及containerd、runC、rkt等等。对于Kubernetes背后的巨人Google而言,这种局面显然是它乐意接受的。虽然标准之争一方面是巨头之间的角力,但是成千上万像你我这样的容器使用者,同样也是左右这场游戏结果的关键力量。以下就容器运行时及接口为大家带来现场分享。

(K8S技术社区KubeCon北美峰会现场评论员 王后明)

KubeCon北美峰会热点之容器运行时

容器运行时及接口

1)Moby/containerd/linuxkit/infrakit — 用“乐高式”组件为不同业务场景构建专有容器管理系统

Session主题:Building Specialized Container-Based Systems with Moby

Docker 公司在今年上半年把 Docker 开源项目改名为Moby,并且把 Docker 这个名称版权化成自有产品和商标。 从这之后,Moby 肩负起 Docker 公司构建容器生态系统的重任,而Docker CE 和 Docker EE 成为基于 Moby 构建出来的社区版和商业化容器运行时产品。

1. containerd

Docker 在2016年把对 OCI runc的管理工具从 Docker Engine中独立出来形成containerd,并于2017年3月份捐赠给 CNCF 基金会,这样,containerd 可以脱离 Docker Engine的速度而单独发展;在加入 CNCF 之后,containerd 一方面推动 containerd 本身的稳定性,另一方面推动 CRI-containerd,让 containerd 作为 Kubernetes CRI 的一种实现;2017年11月份已经跟Kubernetes 1.8版本集成,12月份 containerd 1.0版本发布标志着 containerd 基本成熟稳定。

containerd 的技术目标和理念包括:完整的 gRPC API加客户端 library;全面兼容 OCI运行时和镜像规范;稳定、轻量级同时保证容器核心功能的完备;保证镜像、文件系统、运行时各子系统之间松耦合,从而让整个系统是可插拔可定制的。

2. linuxkit

linuxkit 可为每个容器裁剪定制的最小功能集不可变操作系统,跟传统的容器镜像相比,linuxkit 制作出的操作系统加镜像,不仅仅在应用层面是最小功能集,在系统内核层面,也是轻量级系统。这样一方面进一步缩短了应用启动时间,让不可变交付理念更容易落地;另一方面因为裁剪了通用操作系统中容器场景用不到的组件,也极大增加了系统安全性。

LinuxKit启动过程如下图所示:

init 进程启动之后,再采用系统容器的方式,用 runc 接管操作系统启动过程,按顺序进行网络配置、磁盘初始化等操作,在操作系统成功初始化之后,再用 containerd 来管理用户态服务,并行启动不同服务。这种方式跟 Kubernetes 里 Pod 启动概念类似,先利用 pause 基础架构容器来初始化网络存储 Namespace,然后再并行启动真正的应用容器进程。

跟传统的通用操作系统相比,linuxkit 有众多的不同点:包括根文件系统只读;可以从 ISO、initramfs等只读或内存文件系统启动;没有包管理功能,因为依赖包在创建容器镜像时都已包含;运行时无法更新软件,更新是通过更新镜像然后重启的方式来完成;彻底减少了操作系统安装升级重启的复杂性。

目前主流的公用和私有云平台和工具,如GCP、Azure、OpenStack等等,都已支持 linuxkit构建的系统和容器镜像。针对 Kubernetes,linuxkit 专门为 Kubernetes 定制了最小化不可变操作系统镜像:把 kubelet 运行于linuxkit 的系统容器内,并且支持 CRI-containerd 和 Docker 两种运行时,采用这种方式,Kubernetes 集群能更快被部署出来并且更安全地运行于云基础设施之上。

3. infrakit

infrakit可以理解成构建在 linuxkit 上一层的基础设施编排工具,linuxkit 是用来做单个应用的内核裁剪和镜像定制,infrakit 是利用裁剪好的镜像构建整个分布式系统。在云原生生态系统里,infrakit 的位置和主要特性如下图所示:

Docker 公司围绕 Moby 建立了一套工具链,目的是为了让容器应用更加轻量级、让容器操作系统更安全,让整个容器能可定制性强,从而满足各种不同应用场景。对容器性能、安全和可定制有更高要求的用户,可以去尝试这些技术。

2)CRI-O进展与计划

Session主题:CRI-O: All the Runtime Kubernetes Needs, and Nothing More

容器运行时接口项目CRI-O作为Kubelet和OCI标准容器运行时之间的桥梁,目前主要由RedHat、Intel等公司负责维护,本次大会上来自RedHat的工程师分享了CRI-O项目目前的现状和下一步计划。CRI-O的架构图如下所示。

KubeCon北美峰会热点之容器运行时

在Kubernetes 1.7的时候,CRI-O为1.0.x版本,从Kubernetes 1.8开始,CRI-O直接过渡到1.8.x版本,下一个发布的版本将会是v1.9.x。

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头