容器战争响起, K8S 受天量资金加持就能赢得天下?

by admin on 2020年3月30日

引子

在前东家写完了 Eru2 之后,花了很长一段回顾过去 4
年容器圈的发展,学习其他系统的经验。一方面 CNCF
崛起之快令人难以置信,短短几年已经成为不亚于 ASF 的存在,在各种
conference
上面不遗余力强推自己的项目,或撕逼,隐约有一统江湖之势。另一方面
kubernetes 的调度编排战争已经几乎打完,依托于 CNCF
的推广和已经成为了事实的标准的 CNI/CRI 等接口规范,隔壁亲家 Docker
的核心组件拆的拆(containerd),「无奈」内置 CRI 实现的,逐步抛弃 CNM
模型等,完全毫无招架之力,拆得只剩个 bug 略多的 daemon。更别说亲儿子
Swarm 的下场了,丧权辱国的直接接上 K8s。也就 ASF 下的 Mesos
还能吊着一口气。但那不争气的 Marathon 啊,看看隔壁 K8S 的生态,What can
I say。

有意思的是 16 年我写 Docker 的未来 的时候还被人「教育」过不懂
Docker,不好意思你大爷还是你大爷。现在来看 cri-o、rkt 甚至 Docker 自己的
containerd
发展趋势,只能回一个关爱智障的微笑并手动再见。就连经过了大量生产验证的老牌网络组件
calico 都已在 3.X 版本之后不再维护和更新 libnetwork CNM 模型下的 docker
网络接口,去掉了对 Mesos 的支持,还说战争没打完的不是蠢就是坏。

毫无疑问战争已打完了,CNCF 天量资金加持下的 k8s
赢得了天下,但它真的就无懈可击么?

CRI-O是目前容器社区中除了Docker外,商用进程最快的、最广泛应用的容器引擎。红帽为CRI-O投入了大量的资源,包含了收购CoreOS后获得RKT的资源都投入到CRI-O中。CRI-O在17年推出了1.0版本,它对应的Kubenete版本是1.7.x。CRI-O
1.10与Kubenete 1.10兼容,CRI 1.11与kubenete 1.11兼容,CRI-O
1.12与Kubenete1.12兼容,CRI-O1.13与kubenete1.13兼容。总之CRI-O与kubenete在版本号一致时,保持兼容性。CRI-O在18年度商用进程突然加速,红帽的kubenete发行版本openshift3.9
中将CRI-O标记为GA,在18年8月Redhat宣布在自己的云服务Openshift Online
starter 里运行openshift
3.11使用CRI-O作为容器运行时。而在即将推出的openshift4.x中,在RedHat
Enterprise Linux和RHCOS(Redhat CoreOS
)平台上,将正式将CRI-O作为默认的容器运行时(虽然此版本依然可以使用Docker)
。在已经发布的Redhat
Enterprise Linux 8
beta中,除了CRI-O外还包含了前文中介绍的Podman,Buildah和Skopeo,通过这些工具在红帽8上,用户可以获得和Docker一样的容器操作用户体验。这无疑是整个容器社区非Docker容器最大的商用进展。

其中一个方式是,在容器引擎和编排工具中间实现一个抽象层,容器厂商如何实现这一层完全取决于他们自己。

新的战场

Docker 是输了编排和调度,也失去了那种号令天下的霸权。然而对 K8s
来说最不幸的是产生容器的「工厂」标准依然在 Docker 手中。

无论是 OCI 镜像标准和 Docker 镜像标准亲兄弟,还是运行层面的
containerd。K8s 整了 CRI/CNI 什么的,又扶持了 CRI-O 还有隔壁 Rkt
什么的,并没有一点卵用,看看那个 appc 的概念还有人提么。containerd
在最新 RC 中内置 CRI 支持,可以直接替换 kubelet 的 dockershim
实现,也把之前的 cri-containerd
丢入了历史的垃圾堆,已然成为了集大成的事实标准。

你 CRI-O 说自己测试完备率更高,高得过一直内置代码在 K8s 的
dockershim/containerd 一脉相承?你 rkt 说自己进程树扁平,能比 containerd
直接挂容器到 systemd 下更平?况且都抽象控制平面了,下面 runtime
不都是支持 runc runV 混布么。还有你一个 cri-o 别的不学,硬要去做个内置
pod 你让隔壁的 kubelet 没饭吃怎么办?

基础设施是一定图稳的,在目前换 CRI-O Rkt
等没有明显显著优势的情况下,甚至大劣的情况下,containerd
就是事实标准。Docker 回归到了他应该在的位置,那就是容器「引擎」。当然了
containerd 的成功也是依托于 K8s 的成功,随着 dockershim
的实现走进千家万户。

而随着 containerd
的日益成熟,新的编排系统,新的系统架构,也就有了新的血液。在这之上产生一个足以威胁到
K8s 的新基础设施系统,是完全可以期待的。

我们可以看到在18年度,Moby社区有大量Microsoft贡献者在活跃,在18年的所有Docker发布版本中可以看到大量Windows容器的特性和Bug修正。其中最大的突破出现在18年,Docker
Desktop和Docker-ce原本就是两个独立的产品。但是在Docker-ce18.09之前Docker
Desktop采用Docker-CE的版本号,例如18年8月推出了18.06.1-ce-win73
。但是在Docker-ce 18.09时刻,Docker
Desktop正式采用了自己独立的版本为2.0.0.0;其中引擎部分还是采用的Docker-ce
18.09

未来在编排领域,我们会看到一个激烈竞争的市场,而不是容器引擎领域。

人!人!人!

不可否认 k8s
是一个非常不错的系统,无论是调度编排这个层面还是宏观上架构设计层面。你可以说早期的
k8s 就是娘不亲爹不爱就那么几个工程师打着 Google
旗号在开源界见缝插的这个针。无奈是猪对手加 G
家光环,我一个开源系统怎么就做到了世界之王呢?

个人看来还是因为 G 家光环太过于耀眼。

前有 Mapreduce GFS bla bla 大量工业界论文,后有神乎其神的 Borg
把编排玩出花。大多数人选型的时候一看哟 G
家的东西啊,上上上,然后就没然后了。再加上对手实在是不够打,比如 Mesos
至今周边无论是语言还是完善度都不统一(当然你可以说它两层结构注定的),再比如愚蠢的
Swarm mode 助攻。人又不傻,有爹的东西当然最好啦。

然而我很不想说的是,每一家的东西无论开源与否都是立足于自身业务上的,不是用了
G 家的东西就会让你的团队成为 G 家的一毛一样,就和 G
家平起平坐站在工程界金字塔的尖端了。手头有什么牌就打什么牌,能赢那是技术好,但一对三真干不过四个二的。

我见过大多数用 k8s 的团队,很大程度上都是把 k8s
当黑箱用。规模小了搭建起来成本就很高,那么多概念上的东西在规模小的时候就去强加于业务真的有必要么?Pod
的设计不就是 Virtual Machine 下多进程业务在容器时代没办法的一个
Workaround,那服务治理概念一堆堆但本质上没有什么事是一个 proxy
解决不了的,有那不就再加个 proxy
么。另外规模大了这么一个大黑箱真出了什么毛病,怎么搞?我自己看 kubelet
的执行流程和实现,包括对比 cri-o rktnetes containerd docker-shim 等
runtime
实现细节想找人交流交流都很难找到。另外还有社区有更新你跟不跟,不跟有
security 问题怎么办,升级出了幺蛾子怎么搞,要知道 k8s
严格意义上可不算什么旁路编排和调度系统,升级惨案还少么?

真不是用了 G 家的东西就和 G 家工程师一个水平了。

  • rtk在18年度死亡
  • containerd在k8s上替代docker在18年度从谷歌和IBM走向试商用
  • cri-o 18在红帽openshift上完成试商用,在redhat8上将正式商用化
  • docker社区变化不大
  • gvisor处于萌芽期

谁需要重构,重构什么?

尾声

即便站在 2018
年这个时间点上,我依然认为调度和编排还是一件可以做的事情。怎么单独的用
containerd 去驱动容器,怎么解构复杂 Pod 转变为 native container (1
process 1 container)再通过上层的组合完成复杂业务形态,怎么通过 CNI
结合现有的基础网络等插件,怎么实现更高效的万台机器编排等,依然还有想象力空间。

旧的战争已经结束,新的战场已经硝烟四起。对于 containerd
的前途而言我个人是比较看好的。没有历史的包袱,又向下兼容各类系统的接口,稳定性经过了大量生产实践,还可以很方便的二次开发。也许过几年我们就能看到基于其新的调度编排「nginx」了吧。

来源:知乎 作者:彭哲夫

CRI-O,前身是OCID——OCI
Daemon,它的诞生源于2016年夏天谷歌的K8s工程师和Docker
CTO在社交媒体上的一起大论战。这场大论战背后是Docker在16年7月推出的Docker
1.12将Swarm集成到了Docker引擎内部,这无疑是动了K8s的蛋糕,所以双发终于在16年夏天擦枪走火。这场大论战的详细过程本文不去回顾,感兴趣者可以参考《容器,你还只用Docker吗?》。但是这场大论战的直接后果就是在谷歌的推动下K8s社区推出的了OCID项目,也就是现在的CRI-O项目。CRI-O在社区中有非常强有力的推动力量——谷歌和红帽(红帽因为Systemd和Docker之间也存在罅隙),而IBM,SUSE,Intel,Hyper等公司也是CRI-O的contributor。

我们和Mesosphere 创始人Ben Hindman 也探讨了这种可能性。

Kubernetes 的未来

不管怎么说,k8s 已经成为了事实的标准。可以预见的未来里面,在 CNCF
的支持下,社区是它最深的护城河。假如你需要一个能解决容器调度编排,能解决服务治理,能链路控制(升降级,流控,发现等),能一劳永逸开箱即用(抛开各种概念)的基础设施,它是唯一的选择,也是最好的选择。

但它实在是太复杂了,远的 Pod 不说,近一点服务治理里面的 Sidecar
概念和我单独起 SDK
中间件有啥区别。好你要说不需要语言绑定是没毛病,但比性能这种模式你也比不过
in-memory 的设计啊?

你想用 istio ok,上 k8s。你想用 linkerd ok,上 k8s
。拆开用是能用,但只有 k8s
下,这些东西所宣称的那些花样你才玩得溜,这和强制绑定有啥区别。hmmm,新时代的
Apache httpd 即视感有没有?

那么随着业务的增长,基础平台是抽象出来了,但依然需要大量人力成本去维护去学习。本来搞个平台层面的东西就想自动化压低成本,现在倒好概念能和前端界一样日新月异靠人堆,个人觉得并不是什么好事情。在战争结束前
K8s
可能还没这么多争议,战争结束后众口难调的情况下只有这一个靶子,摊手。可以想象得出随着时间的增长对
K8s 复杂度的吐槽将会越来越多。同样的,我也预计不久的将来,和 Apache
httpd 终究遭遇了 nginx 一样,编排和调度系统的
「nginx」也会出现在我们视野,就像老牌 Hashicrop 下的 nomad 一样等待着和
K8s 平分天下。

Moby社区在过去的18年发布了如下Docker-ce stable版本:

“关于如何与Kubernetes
通信,很多不同的容器引擎都非常感兴趣”,Philips说,“与其在kubelet中为每一个容器引擎构建一个接口,我们创造了一个更抽象的接口,允许容器引擎去接入而不用直接参与Kubernetes
的工作。”

版本 发布时间 重大变更
Docker 17.12.1 18年2月 采用GOLANG1.9.4编译,containerd 切换为1.0.1
Docker 18.03.0 18年3月 修正大量BUG
Docker 18.03.1 18年5月 GOLANG采用1.9.5,containerd 升级到1.0.3
Docker 18.06.0 18年7月 containerd 1.1.1,引入实验性质的镜像构建后端buildkit工具
Docker 18.06.1 18年8月 contaienrd 1.1.2
Docker 18.09.0 18年11月 containerd 1.2.0rc1,Buildkit可以已非实验性质运行,加入local log驱动

Mesosphere 的 DC/OS环境中也有这些组件做铺垫,Hindman
解释说,已经无需依赖 runc 或任何Docker
组件。容器社区的真正目标,正如他所说的,是在组件之间指定架构层面上的边界,并建立它们之间建立适当的接口。

图片 1CRI-O的架构

“还有很多,比如下载镜像、镜像打包、镜像解包 ——
还有更多的事情必须去做。对我来说,我认为行业中还在就一个问题争论:这些东西应不应该被分解和模块化?它不仅仅是
fork the repo 那么简单,还需要在架构上解释得通。”[ Ben Hindman ],

rtk和kubenete的集成出现在kubenete1.3版本,也就是因为rkt这一类容器的出现才促使kubenete社区在16年底kubenete1.5时刻推出的自己容器运行时标准接口CRI。在17年kubenete社区孵化了rkt的cri接口层rktlet,至今为止它只在17年11月推出了一个版本0.1.0。这个版本只通过了部分kubenete
1.9 e2e测试用例。

这是否意味着Mesosphere支持 CRI-O,CRI-O的目标也如Kelsey
Hightower向我们解释的一样,与Hindman 预计的完全兼容吗?

在18年5月,谷歌推出了一种全新的沙盒式容器运行时gvisor。gvisor它是一个支持OCI规范的容器运行时。它能够为容器提供更安全的隔离,同时比VM更轻量。gvisor的设计者认为现在的容器使用了用户态隔离而内核却是共用的,虽然使用seccomp,selinux和Appamor在控制了潜在的安全风险。但是传统容器中恶意应用依然存在逃逸的可能性。针对这样的安全风险,VM容器可以实现基于虚拟化层的强隔离;但是VM容器也引入了不小的虚拟化层开销——更多的cpu、内存消耗。而gvisor使用了类似于用户态Linux的方式,在内核和容器之间引入的新的linux系统调用隔离层将所有的容器内部发起的系统调用进行截击并重新实现

Hightower
将CRI(“CRI”在“CRI-O”之前)描述为一个抽象的概念,代表容器引擎应该支持的基本特性,而Kubernetes可以用来验证这些特性。一旦CRI完成,将重构Kubernetes代码以实现CRI。

对于文件访问,gvisor实现了自己的vfs层。其上实现了实现具体的文件系统。有
9p,tmpfs,procfs,sysfs
。真正的文件访问使用9pfs文件系统访问到宿主机上的文件。

OCI镜像格式的最终标准还没有确定,OCI发言人也表明OCI镜像格式1.0
发布之前还有两个迭代版本。

gvisor现在由两种系统调用截击方案:

该项目将编排工具放在容器技术栈的重要位置,同时降低了容器引擎的重要性。CRI
的一个Contributor说,让Kubernetes支持任意容器引擎,在理念上与Open
Container Initiative一脉相承。容器引擎可以是docker或CoreOS的rkt,或OCI
的 runc(它可以做很多如Docker 或 CoreOS  rkt
这类容器可以做的事情,比如从registry拉镜像,但它不会从makefile构建镜像)。

图片 2gvisor架构图

“对于我们而言,镜像格式比运行时格式更有趣,也有意义” ,Hindman
说,“Mesosphere 之所以拥抱 universal
containerizer,原因是希望支持所有开放格式的容器,包括OCI。”

  • ptrace方案
  • kvm方案

对于
Docker公司有意向将runc作为开放标准,Hindman非常认同,但他也不忘吐槽:完整的编排不仅仅是与与容器引擎交互。

发布Moby之后Docker-ce(docker的开源版本)发布采用两种方式,Stable版本和edge版本。Stable版本顾名思义为稳定版本,而两次Stable版本之间一月发一次Edge版本,一般的商用选择都是Stable版本。截止到18年上半年之前,Docker版本的发布采用3个月左右为周期进行发布。这样导致了上游社区特别是K8s社区对接上的麻烦,为了减少Docker用户频繁的更新版本,Docker在18年Q4调整了版本发布计划,从Docker
18.09开始,Docker版本保证6个月左右的版本维护期,中间不再发布Edge版本
,下一个版本是Docker-CE
19.03

超越Kubernetes

Containerd是Docker从15年12月推出的一个子项目,它将Docker引擎中的containerd捐献到社区中,由此出现了一个Containerd社区。Containerd的目标是开发遵循OCI规范的商用环境容器运行时。containerd并不是直接面向最终用户的,而是设计为被用于集成到更上层的系统里,如Swarm,
Kubernetes,
Mesos等容器编排系统。它利用已有的runtime,对容器生命期管理、容器镜像和容器存储上做出更多工作;而容器网络和编排交给了Docker引擎、Kubernetes等编排系统。

该项目通过与Kubernetes(或其商业版CoreOS
Tectonic)协作,可以帮助DevOps人员来管理容器的整个“生命周期”。

rkt是由前coreOS公司在14年底推出的容器引擎,rkt推出的初衷是因为当时Docker引入了Docker
swarm编排工具,向着Docker平台化的方向大步前行。coreOS认为Docker的设计理念偏离。所哟coreOS推出了自己的容器引擎Rocket(在15年更名为rkt)。rkt的设计目标就是纯粹的容器引擎,它不提供容器平台,不提供容器的编排。rkt从14年底推出0.0.0到18年4月11日推出最后一个版本1.30一共推出了46个版本。在rkt的github社区上列出了几个商用客户,由于不知所以本文就不再列出。

另一方面,CRI(通用容器接口API和Kubernetes)将给容器引擎厂商一个机会,以便接入Kubernetes系统。运行容器的环境中,只要暴露出适当的连接,不需要容器引擎进行代码重构就可以兼容Kubernetes。

对于容器网络,gvisor实现了用户态网络协议栈。其整个数据流跟原生容器一样,唯一区别在于
gVisor 需要捕获到安全容器内应用程序关于网络的系统调用。例如,
listen/accept/sendmsg 等等。之后再将其转换成 host
的系统调用来进行网络通信。

Hindman 总结说,Mesosphere
将继续支持OCI,将来会以同样的粒度支持CRI-O。但跟CRI-O相比,Mesosphere
的“universal container runtime”将以不同的方式被支持。

2014 年开始,Docker 和 Microsoft 便积极展开合作,在 2016 年,先让
Windows Server 整合了 Docker 引擎。到 2017 年,整合了 Windows 容器,让
Docker 能一次通吃 Linux、Windows 容器集群。在18年1月份,发布了Docker
Desktop 的Deta版本,在其上在可以部署kubernete集群了,在Docker
con旧金山大会上,Docker公司正式对外展示了Docker
Desktop-Windows部署kubernete集群。

开发人员需要使用容器引擎构建镜像,通常情况下更喜欢用自己的staging
环境做本地测试。但是管理和运营人员会发现,相对于标准容器引擎,
Kubernetes技术栈(比如编排系统、CRI和CRI-O)更适合用来管理复杂的生产环境。

图片 318年度容器社区大事记1图片 418年度容器社区大事件2

“前面我们谈到Pod,为了正确地实现它,你还需要了解很多东西”,Hightower
说,“把负担推给容器引擎,让它们去写一拖代码才能与kubernetes愉快地玩耍,这一点对于每个容器引擎都很不公平。想想看:他们还要为Mesos和Swarm去实现类似功能的代码,想想都可怕。为了简化这部分功能,我们将把Kubernetes专属的逻辑放到kubelet中;对于外部而言,通过一种友好的方式使用容器引擎本来就具备的特性。

rkt和rktlet社区都以coreOS公司为主导。18年发生了一个大事件,导致了rkt实际死亡,那就是18年1月红帽收购了coreOS。由于红帽早已大力主推自己的容器运行时项目CRI-O,所以rkt项目的实际运作在18年4月份中止了,rkt和rktlet的最后更新都停止在了18年4月。可以认为红帽将coreOS
rkt资源投入到了CRI-O中。

然而Hindman并不是为 OCI呐喊,需要注意的是,Mesosphere
是OCI的创始成员之一。 OCI的最初的目的是开发一种通用的运行时格式,让runc
能够以容器的方式启动它。容器社区也关心镜像格式,包括容器在非运行状态下的文件系统和元数据。所以OCI也接受这套理念。

Docker近期最大的变化实际发生在17年11月的Docker-ce
17.11,对应的Stable版本为18年2月出现的Docker-ce 17.12
在这两个版本中Docker使用的Containerd从Containerd0.2.x一跃升级为Containerd
1.x。Containerd
0.2.x和Containerd1.x之间API级不兼容,且架构发生重大变更
。由此引发了Docker-ce架构的巨大变更。这是Docker社区在17年底到18年发生的重大的变更项。

如果CRI-O成功,容器引擎厂商不需要对引擎代码库进行修改,就可以简单地与Kubernetes交互。

CRI-O认为大多数的用户只是使用k8s的容器,而并不关注其容器运行时到底是Docker、rkt还是别的什么。CRI-O
设计目标就是为OCI兼容的容器runtime实现了一个K8s
CRI接口层。目前CRI-O支持两种runtime:RunC和Kata。CRI-O是一个非常轻量的工具集,它使用runtime去管理容器的生命期,使用CNI插件创建容器网络,使用container/storage来管理容器的rootfs,使用container/image来管理容器镜像,使用conmon来监控容器的运行。container/storage目前支持overlayfs、devicemapper、AUFS和btrfs,Overlayfs作为缺省的存储驱动。目前计划支持网络文件系统nfs,ceph和Glusterfs。container/image支持从镜像仓库中pull镜像,支持Dokcer
V1和V2两个版本的镜像。原本CRI-O的设计初衷是为了对接Kubenete,并不是直接对接终端客户可以不提供类似于Docker
cli一样的命令行。但是为了调试目的,CRI-O推荐使用:crictl调试CRI-O容器引擎,podman工具管理kubenete
Pod,buildah构建、推送镜像为镜像签名,skopeo拷贝、删除、查看和签名镜像。

Google 的Hightower 说:“尽管Docker已经要求与Kubernetes
一起实现中间层,最终仍然是Google
的工程师去实现,而不是Docker的。Philips也表示,不管谁去实现中间层,Docker和其它容器引擎厂商遵循同样的规则,都不能搞特权。

Containerd的发布时就定位成容器编排工具的底层运行时,也就意味着Containerd可以被多种编排工具调用,一同提供容器服务。现阶段有Docker,阿里的Pouch这两个容器引擎使用Containerd作为自己的运行时。Kubernete从1.7开始使用cri-containerd的方式支持kubelete使用containerd;而Kubelete
1.10以上的版本就支持了直调containerd(通过containerd的cri-plugin)。在Kubelete直接使用containerd商用尝试上,谷歌和IBM走在了前列。在18年11月,它在自家公有云下kubenete服务GKE
1.1上宣布提供beta方式的支持kubelete直调containerd
。IBM在18年IBM cloud
Private上推出的三个release(5月的2.1.0.3,9月的3.1.0和11月的3.1.1)已经将kubenete直调containerd做为tech
preview方式。

“为了与CRI集成,Docker Engine和 rkt Engine都处在不断变化中”,Brandon
Philips如是说。

Containerd社区在18年发生的大事件有:

假设这已经是事实,现有容器引擎特性被隐藏在一个接口后面,该接口能够将pod为中心基于kubelet
的逻辑从kubernetes
隔离出来,与Kubernetes之外但有同样API的编排工具交互,这个编排工具对API可能有一套完全不同的实现方式(饼越来越大)。

  • 18年7月发布Containerd1.1.2正式将CRI-containerd以插件形式cri-plugion集成到了Containerd中。理论上来说,从此刻开始Containerd就可以独立支持Kubelete
    CRI了。

  • 18年9月Containerd1.2.rc0出现,它实现为支持VM类型的容器,提供了shimv2抽象。而Containerd
    1.2在19年1月15日才正式发布。Containerd
    1.2的出现标志着Containerd对VM容器(Kata容器,runV容器)的支持上了一个新台阶。

同时,Docker 在不断增强其容器引擎的特性,并且捆绑了Swarm
编排工具和服务发现。

Docker在17年4月的时候推出了名为Moby项目,Moby着眼于“一个将组件装配成定制化基于容器的系统的框架和一个所有容器发烧友试验与交流想法的场所”,它内部除了Docker
容器引擎外,还孵化了多个项目:Moby,buildkit,Datakit,HyperKit,VpnKit。Docker对Moby的玩法,就是从Moby中抽取Docker版本,然后将其他孵化项目中比较成熟的部分纳入到Docker里。其中BuildKit就是一个成功孵化并进入Docker的例子。

“我认为这个行业需要的是可拼凑的组件”,Hindman 对The New Stack
解释说。“在Kubernetes
案例中,我认为这很关键。Kubernetes依靠Docker做容器管理,并且他们尝试构建编排。当Docker整合Swarm时,他们不仅有一个容器管理器,也在做编排。仅仅从架构的角度来看,这是非常合理的。我想说的是:如果我们只做一个容器管理的组件,让很多人可以利用,岂不是很更好?”

ptrace方案可以应用于任何宿主机包括云主机环境上,它采用ptrace方式,在容器内部应用发起系统调用的时刻将应用跳转到自己实现的系统调用代码中。ptrace模式的工作模式类似于使用gdb调试用户态进程的方式。此外gvisor还支持kvm方式,在
KVM 模式下,gVisor 能够截获应用程序的每个系统调用,并将其转交给
gvisor自己实现的系统调用层进行处理。相比较 VM,我们看不到 Qemu
的身影,也看不到 Guest
Kernel,gvisor自己实现的系统调用层包揽了所有必要的操作。这种对虚拟化的实现方法,我们称之为“进程级虚拟化”。gvisor只实现了部分的系统调用:实现了
200 个左右的系统调用,而 Linux Kernel 则为 X86_64 提供了 318
个系统调用。所以现在部分软件还不支持gvisor,例如postgel。而且现阶段gvisor实现的部分系统调用依然依赖于宿主机上的内核系统调用。

但在这样一个最佳架构中,可能没有方法去规范工作负载的调度器。不同调度器的特性可能千差万别。因此,如果以这种方式,努力通过一个文件描述工作负载(可能是配置文件、元数据文件或manifest文件),并且试图对所有调度器通用,最终制定出来的标准可能满足不了任何调度器的需求,进而妨碍调度器本身特性的扩展。

gvisor作为容器运行时,它实际上和Docker世界的RunC是同层次的。gvisor目前支持替换runC作为Docker容器的运行时。Kubenete使用gvisor有两种方式,第一种方式是在Minikube里使用gvisor容器;另外一种方式是使用kubelete对接Containerd,配置Containerd使用gvisor-containerd-shim,那么所有带特定标记的容器都会以gvisor方式创建。截止到18年9月社区上kubenete
+docker+gvisor这条路依然没有走通。目前来看gvisor成熟尚需时日,未见任何商用用例。

对于Kubernetes,下一个版本的目标是1.5版本,包括CRI的最终版,允许kubelet
与Docker,rkt、Hyper.sh(中国团队开发)以及CRI-O(RedHat领导开发)进行通信。

CRI-O 是什么?

“现在,如果你想很happy地玩耍Kubernetes,必须构建一堆东西,而且可能修改你目前的做事方式”,Hightower
说,“你查看现有的代码库,看看为Docker做了哪些东西。在某种程度上,你需要付出类似的努力,去修改适合你的运行时引擎,从而与Kubernetes很好的配合。”

「  尽管 Open Container Initiative 类似的部分已经与
CRI-O的职责区别越来越大,两个项目的成员、贡献者和厂商也有很大重合,但CRI-O
仍然是OCI的自然延伸,它为容器引擎和镜像提供了一套标准接口。」,Kubernetes
工程师Kelsey Hightower 在The New Stack 的采访中说道。

“考虑到CRI的运行机制,你需要一个GRPC daemon
去监听请求”,Philips说,“它能与kubelet 通信;反过来,kubelet
可以通过socket对实现CRI的引擎发送一个远程调用”。

就像 CoreOS的Philips 解释的一样,每个容器引擎将利用一个中间层——
它能够将容器引擎的 API请求,转化成Kubernetes可以处理的形式。

在这一假设之下,是一个新奇的观点:编排才是容器生态的中心,而“引擎”就我们所知,只是一个开发工具。

“我认为这一切进展都不错,”Philips说,“人们可能不喜欢这样——这很正常,每个人都可以有自己的观点。对于Kubernetes
,我们仍然会提供一包东西。但我们在创造和改进它时,不认为它仅仅是一件商品(还有情怀)。

原文链接:

容器引擎中间层实现以后,CRI 
API(与Kubernetes连接的部分)将把更多的容器生命周期控制权交给kubelet ——
pod的管理者。Pod是Kubernetes
特有的概念,但容器生态系统必须采用这个概念。

CRI-O
项目的设想是用户不应该依赖任何特定的容器引擎去完成工作负载。按照最初的设想,该项目将为
Kubernetes提供一个工具集,使其能够管理容器的整个生命周期,而不需要Docker、rkt、OpenShift、Photon
或任何其他容器引擎。

Philips说,“目前对Docker和rkt的支持将被合并到CRI接口”。 CoreOS rkt
对CRI的实现目前已经在Github上开源,项目名称为rktlet。不管是rktlet,还是Docker对CRI的实现(不管将来叫什么名字),他预计都被重构为CRI。

本文由时速云翻译,如若转载,需注明转载自“时速云”

开源项目 CRI-O,其前身为OCID,官方简介是“OCI-based implementation of
Kubernetes Container Runtime Interface”。作为接口,它使得Kubernetes
不依赖于传统的容器引擎(比如Docker),也能够管理容器化工作负载。

但是,确定一个通用镜像格式则简单很多,最终取决于 Linux
是否支持该格式。“如果支持它,我们可以公开它。在镜像格式上,我认为没有太大的争论,因此,把它作为一个标准就OK。”

「 我们对容器引擎的功能要求很少,不管是Docker还是rkt,它们要做的工作都很少 」,Hightower说,「 我们需要的是访问内核的API,不仅仅针对Linux,也可以是Windows。如果这是社区想要去的方向,Kubernetes就要支持这些想法-因为在这一点上它比Docker公司更大 」。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图