“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

Kubernetes 的未来是虚拟机,而不是容器?

  • 2019-01-03
  • 本文字数:3205 字

    阅读完需:约 11 分钟

Kubernetes的未来是虚拟机,而不是容器?

摘要

在中国的生肖中,2018 年是“狗年”,在科技领域则是“Kubernetes 年”。现在,有很多人才开始了解 Kubernetes。世界各地的首席信息官都在努力制定“Kubernetes 战略”。一些组织已经在 Kubernetes 上运行了大量的生产工作负载。

正文

本文最初发布于 Paul 的博客,经原作者授权由 InfoQ 中文站翻译并分享。


概述


作为一项技术,Kubernetes 今年对我的职业生涯非常重要,明年更是如此。在 2018 年即将结束之际,我们应该摒弃傲慢,做出大胆的预测。Kubernetes 的未来是虚拟机,而不是容器。


Kubernetes 的未来是虚拟机,而不是容器。


在中国的生肖中,2018 年是“狗年”,在科技领域则是“Kubernetes 年”。现在,有很多人才开始了解 Kubernetes。世界各地的首席信息官都在努力制定“Kubernetes 战略”。一些组织已经在 Kubernetes 上运行了大量的生产工作负载。


换句话说,对于 Kubernetes 来说,Gartner 炒作周期的每个阶段都有很多人。许多人被困在幻灭的低谷,或者被淹没在绝望的深渊。



来自Wikipedia,由 Jeremykemp 提供(Creative Commons CC BY-SA 3.0*)** *


我是容器的超级粉丝,我不会试图说明容器已死。在 2013 年,Docker 带给我们的是一个围绕 Linux 容器的封装器。它们向我们展示了构建、打包、共享和部署应用程序的新方法。来得正是时候,因为我们已经开始认真对待持续交付。它们的模型非常适合现代化交付管道和 PaaS 以及后来的 CaaS 平台。



根据谷歌工程师的观察,技术社区终于为容器做好了准备。谷歌已经使用(或多或少发明)容器很长时间了。他们开始构建 Kubernetes,我们现在都知道,这是谷歌对自己的 Borg 平台的重构,该平台的构建是作为一项社区工作以开放的形式开展的。


不久,大型公有云就提供了一个基于 Kubernetes 的平台(GKE、AKS、EKS)。本地部署人员也很快地构建了基于 Kubernetes 的平台(Pivotal Container Service、Openshift 等)。


软性多租户


还有一个棘手的问题需要解决,我认为这将证明容器的衰落……多租户。


Linux 容器的构建并不是为了成为安全的隔离沙箱(如 Solaris Zones 或 FreeBSD Jails)。相反,它们构建在一个共享的内核模型上,该模型利用内核特性提供基本的进程隔离。正如Jessie Frazelle所言,“容器不是一个真实的东西”。


更复杂的是,大多数 Kubernetes 组件不知道租户的存在。当然,你有名称空间Pod安全策略,但是 API 本身没有。 像 kubelet 或 kube-proxy 这样的内部组件也没有。这导致了 Kubernetes 的“软性租户(Soft Tenancy)”模型。



抽象泄漏。构建在容器之上的平台将继承容器软性租户的许多方面。构建在刚性多租户虚拟机之上的平台都继承了刚性租户(VMware、Amazon Web Services、OpenStack 等)。


Kubesprawl 统治了我周围的一切


Kubernetes 的软性租户模型将服务提供和分发置于一个奇怪的位置。Kubernetes 集群本身成了“刚性租户”。有许多原因(甚至在同一个组织内部)要求在用户(或应用程序)之间实现刚性租户。由于公有云提供了全托管的 Kubernetes 服务,所以每个租户都很容易获得自己的集群并使用集群边界作为隔离点。


Pivotal Container Service(PKS)这样的一些 Kubernetes 发行版非常清楚这个租户问题,它们采用了类似的模型,提供了与你从公有云中获得的服务体验相同的 Kubernetes,但是是在你自己的数据中心里。


这导致“多集群”模式的出现,而不是“一个大型共享集群”的模式。谷歌 GKE 服务的客户为多个团队部署了几十个 Kubernetes 集群,这种情况并不少见。通常,每个开发人员都有自己的集群。这种行为导致了数量惊人的 Kubesprawl。


或者,在自己的数据中心里运行自己的 Kubernetes 集群(上游或基于分布式的)的 Kubernetes 运营商可以自行承担管理大量集群的额外工作,或者只在一两个比较大的集群上接受软性租户。


“这种行为导致了数量惊人的 Kubesprawl。”


通常,最小的集群包含 4 台机器(或 VM),一台(或者 3 个,为实现 HA)作为 Kubernetes 主节点,三个作为 Kubernetes 工作节点。在大多数部分都空闲的系统中,这就占用了大量的资金。


所以,我们需要以某种方式将 Kubernetes 转移到一个刚性租户模型。Kubernetes 社区非常了解这种需要,并有一个多租户工作组。这个小组正在努力解决这个问题,他们就如何处理每个模型提出了几个建议模型和提案。


Jessie Frazelle 就这个话题写了一篇博文,很棒的一篇文章,因为她比我聪明得多,所以我可以让你和她取得联系,这样我就不用花十年的时间努力学习来赶上她了。如果你还没有读过,就不要往下读了,先去读那篇文章吧。


优化小型 VM 的速度


Kata 容器是一个开源项目和社区,致力于构建轻量级虚拟机(VM)的标准实现,这些虚拟机看起来和执行起来都像容器,但提供了 VM 的工作负载隔离和安全优势。


Jessie 建议使用 VM 容器技术,比如Kata容器。Kata 容器兼有虚拟机级别的隔离,表现和执行都跟容器类似。这使得 Kubernetes 可以为每个租户(假设每个名称空间有一个租户)提供一组在嵌套 VM 容器中运行的 Kubernetes 系统服务(VM 容器在底层 IaaS 提供的 VM 中运行)。



图片来自*ti-tenancy. Her sKubernetes中的刚性多租户


这是一个优雅的 Kubernetes 多租户解决方案。她甚至进一步建议 Kubernetes 把嵌套容器 VM 用于运行在 Kubernetes 上的工作负载(Pod),这样可以显著提高资源利用率。


这里至少还可以做一项优化。为底层 IaaS 或云提供商构建合适的虚拟机管理程序。如果 VM 容器是 IaaS 提供的第一级抽象,那么我们就可以进一步提高资源利用率。运行 Kubernetes 集群所需的最少 VM 数量下降到一个(或三个,为实现 HA),用于承载提供给“超级用户”的 Kubernetes 控制平面。


资源(成本)优化的多租户


下图是一个具有两个称空间的 Kubernetes 部署,每个部署运行多个应用程序。



注意:还有其他云租户工作负载运行在相同的 IaaS 基础设施上。因为这些是 VM 容器,所以它们具有与常规云 VM 相同的隔离级别。因此,它们就可以以最小的风险在同一个虚拟机管理程序上运行。


最初部署到云上的基础设施为零,因此超级用户的成本为零。


超级用户从云请求一个 Kubernetes 集群。云提供商创建一个单独的容器 VM(或三个,为实现 HA),它运行主要的 Kubernetes API 和系统服务。超级用户可以选择在系统名称空间中部署 Pod,或者创建新的名称空间以便把访问委托给其他用户。


超级用户创建两个名称空间 foo 和 bar。Kubernetes 从云中为每个名称空间的控制平面(Kubernetes API 和系统服务)申请两个 VM 容器。超级用户将对这些名称空间的访问委托给一些用户,这些用户各自部署一些工作负载(Pod),他们各自的控制平面为每个工作负载请求 VM 容器。


在所有阶段,超级用户只为实际消耗的资源付费。云提供商拥有任何云用户都可以使用的生产力。


我并没有说什么新东西


云提供商已经在朝着这个向努力了。通过观察开源社区中正在发生的事情,你就可以看到这个形成过程。(可以说,亚马逊已经在用 Fargate 做这件事了)。


第一个线索是Virtual Kubelet,这是一个开源工具,被伪装成了 Kubelet。它将 Kubernetes 与其他 API 连接起来。这将使得 Kubernetes 可以从云的容器 VM 调度器请求容器 VM。


其他线索包括新兴 VM 容器技术的数量,已经提到的Kata容器,还有来自亚马逊的Firecracker和来自谷歌的gvisor

小结

结合对 Kubernetes 刚性租户模型的恰当改进,你将得到 Kubernetes 的圣杯。完全隔离 Kubernetes 工作负载和在 Kubernetes 上运行工作负载时纯粹按 Pod 计算的消费成本模型。


对于那些不在公有云上的人,我们没有相同的消费模型,因为生产力职责在基础设施提供商(在这种情况下是你自己)那里。你仍然可以获得更高的资源利用率所带来的好处,从较低的生产力需求中得到回报。


我们希望 VMware 和 OpenStack 能够注意到这一点,并为我们带来基于虚拟机管理程序的轻量级 VM 容器技术和适当的 Virtual Kubelet 实现。


查看英文原文:The future of Kubernetes is Virtual Machines


2019-01-03 09:179944
用户头像

发布了 1008 篇内容, 共 372.1 次阅读, 收获喜欢 340 次。

关注

评论 2 条评论

发布
用户头像
虚拟机的安全独立内核、容器的弹性高性能,两者结合开拓,这是运行时技术的发展方向
2022-08-08 10:42
回复
用户头像
Docker 部署在宿主主机上才有意义,当下企业都在用虚拟机,在这种架构上 Docker 没有优势。
2019-01-05 21:37
回复
没有更多了
发现更多内容

Linux系统编程-进程间通信(管道)

DS小龙哥

2月月更

【行业云说直播间】就在明天下午!聚焦园区数智化转型

浪潮云

云计算运维

实时数仓:基于 Flink CDC 实现 Oracle 数据实时更新到 Kudu

腾讯云大数据

flink 执行 流计算 Oceanus

安全创新厂商长亭科技加入,牵手龙蜥共建网络安全新生态

OpenAnolis小助手

Linux 开源 网络安全

web前端培训:开发过程中比较实用的 Linux 命令

@零度

前端开发

再见收费的Navicat!操作所有数据库就靠它了!

沉默王二

Java

MySQL 常用备份工具流程解析

Qunar技术沙龙

用户体验超好的堡垒机哪里有?咨询电话多少?

行云管家

等保 堡垒机 网路安全 等级保护

Nacos中服务删除不了,怎么办?

王磊

springcloudAlibaba

web技术分享| WebRTC记录音视频流

anyRTC开发者

前端 音视频 WebRTC web技术 实时通讯

喜报 | 旺链科技入选上海市高新技术成果转化项目!

旺链科技

区块链 产业区块链 高新技术

java培训:JVM性能调优理论基础知识分享

@零度

JVM JAVA开发

数蛙科技百亿级物流标签轨迹时序数据压测

dgiot

物联网 2月月更 2月日更 dgiot dgiot物联网

尚硅谷Kafka新版视频教程发布

@零度

大数据开发 kafka 3.X

CentOS 安装 Oracle(单机版)

wong

oracle centos

基于流计算 Oceanus(Flink) CDC 做好数据集成场景

腾讯云大数据

flink 执行 流计算 Oceanus

火山引擎科技原力峰会:超视频时代如何提供交互性、高清化音视频体验

字节跳动视频云技术团队

理论+算法+实战,教你如何实现亿级流量下的分布式限流

华为云开发者联盟

高并发 服务器 分布式限流 限流 计数器

凡泰极客积极参与信通院“5G消息应用数据安全标准”落地工作

FinClip

5G消息 中国信通院

WebRTC 服务器架构 | 社区征文

liuzhen007

音视频 新春征文 2月月更

库珀科技招聘Java/前端/测试[20~60K][18~24薪][成都][可远程]

Mr. Xie

前端 测试 招聘 Java web

绿色数据中心:风冷GPU服务器和水冷GPU服务器综合分析

蓝海大脑GPU

第二期 OceanBase 技术征文大赛来袭!快来释放你的原力!

OceanBase 数据库

数据库 分布式 征文大赛 OceanBase 社区版

冬奥金牌冲击!为冬奥助力加油!

InfoQ写作社区官方

话题讨论 冬奥会 热门活动

AngularJS + Ionic 开发移动端 Hybrid 项目实战总结| 社区征文

No Silver Bullet

angular.js 经验分享 Ionic 新春征文 2月月更

如何编写sdk?

百度Geek说

前端

大数据培训:Flink窗口的开始时间的计算

@零度

flink 大数据开发

eBPF 科普第一弹| 初识 eBPF,你应该知道的知识

Daocloud 道客

基础软件 ebpf Daocloud

“翻墙”的罪与罚,国内互联网用户VPN“翻墙”的AB面

科技热闻

填问卷赢豪礼,吐槽 NGINX 顺便中个 AirPods 新款耳机~

InfoQ写作社区官方

nginx 热门活动

如何通过云效进行函数计算(FC)发布

阿里云云效

阿里云 云原生 CI/CD 持续交付 研发提效

Kubernetes的未来是虚拟机,而不是容器?_服务革新_Paul Czarkowski_InfoQ精选文章