酷应用

虚拟机才是 Kubernetes 的未来？

百家作者：CSDN 2019-01-17 14:12:09

Kubernetes 的未来到底在哪里？本文作者一一为你解析。

作者 | Paul Czarkowski

译者 | 弯月

责编 | 屠敏

出品 | CSDN（ID：CSDNNews）

凝视水晶球

今年对我的职业生涯而言，Kubernetes 是一项非常重要的技术，明年亦会如此。随着 2018 年的结束，我将在此做出一个大胆的预测。虚拟机才是 Kubernetes 的未来，而不是容器。

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

2018 年是中国农历的狗年，但在技术领域今年是 Kubernetes 年。现在有很多人都在学习 Kubernetes。各位首席信息官都在努力制定“Kubernetes 战略”（如果你还在尝试开发 Kubernetes 策略，那就已经输在了起跑线上，但那是另一个故事）。有些组织已经在 Kubernetes 上运行大量的生产工作负载了。

换句话说，纵观 Kubernetes 的加德纳技术成熟度曲线（Gartner Hype Cycle），每个阶段都有很多人。许多人正处于幻灭的低谷，或者陷入了绝望的陷阱。

图片来自维基百科，作者：Jeremykemp

我是容器的忠实粉丝，而且我没有暗示容器已死。2013 年 Docker 给我们带来了 Linux 容器的包装器，向我们展示了一种惊艳的构建、打包、共享和部署应用程序的新方法。当时我们已经开始认真对待持续交付，所以这个时机再恰当不过了。这些容器的模型非常适合现代交付流程，以及 PaaS 和后来的 CaaS 平台。

在 Google 工作的工程师都看到技术社区终于准备好迎接容器了。Google 使用（或多或少地发明）容器已经有相当长一段时间了。他们开始构建的 Kubernetes 正是现在众所周知的 Google 自己的 Borg 平台的重新构思，而 Borg 平台是社区共同努力创立的。

没过多久，大型公共云都开始提供基于 Kubernetes 的平台（GKE，AKS，EKS）。内部人员也很快建立了基于 Kubernetes 的平台（Pivotal Container Service，Openshift 等）。

脆弱的“软性”多租户

我们还需要解决一个棘手的问题，而且我认为这将成为压垮容器的最后一根稻草——多租户。

Linux 容器的构建目的并非是为了保障彼此孤立的沙盒（如 Solaris Zones 或 FreeBSD Jails）的安全。相反，它们建立在共享内核模型的基础上，该模型利用内核功能提供基本的进程隔离。正如 Jessie Frazelle 所说：“这些并非是真正的容器”。

更为复杂的是，大多数 Kubernetes 组件并不知道租户的存在。当然命名空间和 Pod 安全策略有租户的概念，但 API 本身与租户无关。内部组件 kubelet 或 kube-proxy 等也不知道租户的存在。这导致了 Kubernetes 的“软租赁”模型。

这意味着抽象泄漏。建立在容器之上的平台从方方面面继承了容器软租赁的特性。而建立在“硬性”多租户虚拟机之上的平台都继承了“硬租赁”（VMware，Amazon Web Services，OpenStack等）。

Kubesprawl 统治着我周围的一切

Kubernetes 的软租赁模式导致服务提供商和发行商处于一种尴尬的境地。 Kubernetes 集群本身属于“硬租赁”。由于种种原因（甚至在同一组织内部）要求用户（或应用程序）之间保持“硬租赁”。由于公共云提供完全托管的 Kubernetes 即服务产品，因此每个租户都可以轻松获得自己的集群，并以集群边界作为隔离点。

有些 Kubernetes 发行商（比如 Pivotal Container Service，PKS）非常了解这个租赁的问题，并采用了一种类似的模型，提供与公共云相同的 Kubernetes 即服务体验，只不过是在自家的数据中心实现的。

这导致了“许多集群”而非“一个大型共享集群”的新兴模式。Google GKE 服务的客户为多个团队部署数十个 Kubernetes 集群的现象并不罕见。通常每个开发商都会获得自己的集群。这种行为会产生惊人数量的 Kubesprawl。

在自家数据中心运行 Kubernetes 集群（基于上游或基于分布）的 Kubernetes 运营商可以选择自行承担管理大量集群的额外工作，或者直接接受一个或两个较大集群上的软租赁。

“这种行为会产生惊人数量的 Kubesprawl。”

通常，你可以获得的最小集群是 4 台计算机（或虚拟机）。一台（如需要高可用性则需要3台）给 Kubernetes Master，三台给 Kubernetes Worker。所以即使系统的大部分只是闲置在一边，也需要耗费巨额资金。

所以我们需要通过某种方式将 Kubernetes 转成硬租赁模型。Kubernetes 社区非常清楚这一需求，而且他们拥有一个多租户工作组。这个小组一直在努力解决这个问题，他们有几个建议的模型以及如何解决各个模型的提议。

Jessie Frazelle 撰写了一篇关于这个主题的文章（https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/），这篇文章非常棒，因为她比我更聪明，“听她一席话，胜读十年书”，所以你也可以关注她。如果你还没有阅读上面她的这篇文章，那么我建议你先暂停去读读看。

小型虚拟机的速度优化

Kata Containers 是一个开源项目和社区，致力于构建轻量级虚拟机的标准实现，这种虚拟机给人的感觉和执行就如同容器一样，但是还可以提供工作负载隔离和虚拟机的安全优势。

Jessie 建议使用 Kata Containers 等虚拟机容器技术。Kata Containers 结合了虚拟机级别的隔离，其动作和执行与容器一样。如此一来，Kubernetes 就可以为嵌套虚拟机容器（在底层IaaS提供的虚拟机内运行的虚拟机容器）中运行的每个租户（我们假定每个命名空间只有一个租户）提供自己的一组 Kubernetes 系统服务。

图片来自Jessie Frazelle的《Kubernetes的硬性多租户》（https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/）

这是一种针对 Kubernetes 多租户问题的一个优雅的解决方案。Jessie 还进一步建议 Kubernetes 使用嵌套的容器虚拟机来运行 Kubernetes 上的工作负载（Pod），如此即可大大提高了资源的利用率。

在此我们还有一个优化需要做，即为底层 IaaS 或云提供商构建合适的管理程序。如果虚拟机容器是 IaaS 提供的第一级抽象，那么我们就可以进一步提高资源的利用率。运行 Kubernetes 集群所需的最小虚拟机数量下降到一个（如需要高可用性则需要 3 个），即通过一台虚拟机来运行面向“超级用户”的 Kubernetes 控制平面。

多租户的资源（成本）优化

拥有两个名称空间且每个都运行了许多应用程序的Kubernetes部署大致如下：

注意：同一 IaaS 基础架构上还运行了其他云租户的工作负载。由于这些是虚拟机容器，因此它们的隔离级别常规云虚拟机相同。因此，它们能够以最小的风险在同一个虚拟机管理程序上运行。

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

超级用户通过云向 Kubernetes 集群发请求。云提供商创建一个容器虚拟机（如需要高可用性则需要 3 个），来运行主要的 Kubernetes API 和系统服务。超级用户可以选择在系统命名空间中部署 pod，或者创建新的命名空间以委派其他用户的访问权限。

超级用户创建两个命名空间 foo 和 bar。Kubernetes 向云请求两个虚拟机容器来运行每个命名空间的控制平面（Kubernetes API 和系统服务）。超级用户将这些命名空间的访问委派给每个部署一些工作负载（Pod）的用户，他们各自的控制平面再向虚拟机发请求来运行每个工作负载。

在此过程的所有阶段中，超级用户只需支付实际消耗的资源。所有云用户的可用资源属于云提供商。

旧事重提

云提供商已经在朝这个方向努力了。我们可以从开源社区发生的种种情况中看出一些端倪。（亚马逊的 Fargate 已经在秘密地有所行动了。）

最具代表性的是 Virtual Kubelet，它是一个开源工具，旨在伪装成一个 kubelet。它将 Kubernetes 连接到其他 API。如此便可允许 Kubernetes 通过云的容器虚拟机调度程序请求容器虚拟机。

还有许多其他新兴的虚拟机容器技术，例如上述提到的 Kata Containers，还有来自亚马逊的 Firecracker 和来自 Google的gvisor。

总结

通过正确地改进 Kubernetes 硬租赁模型，你就可以取得 Kubernetes 的成功。我们应该通过完全隔离 Kubernetes 工作负载与每个 Pod 的消耗成本模型，在 Kubernetes 上运行工作负载。

对于那些没有使用公共云的人来说，你无法获得与基础设施提供商（在这种情况下就是你自己）的容量负担相同的消耗模型。但是你仍然可以获得资源高利用率的好处，这可以降低对容量的需求。

我希望 VMware 和 OpenStack 可以关注这些问题，并为我们带来基于管理程序和适当的 Virtual Kubelet 实现的轻量级虚拟机容器技术。

原文：https://tech.paulcz.net/blog/future-of-kubernetes-is-virtual-machines/
作者：Paul Czarkowski，IBM 云开发实验室的技术主管。
本文为 CSDN 翻译，如需转载，请注明来源出处。

热文 推荐

☞ 华为再告急！

☞ 我是如何一步步拿下 Google Offer 的？

☞ 从此再也不怕爬虫“乱码”问题！

☞ 2019年人工智能行业又进入冬天了吗？

☞ 以太坊升级的拖油瓶，竟只是这几行代码

☞ 边缘计算精华问答 | 为什么需要边缘计算？

☞ 吃亏的程序员，是如何拿到了 9 个月的年终奖？

☞ 心疼！能为程序员男友做些什么吗？

print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！n");
cout < < "点个好看吧！" < < endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"