Kubernetes 与虚拟化和容器化的关系

写下这篇文章的起因是前段时间我尝试在 K8s 上部署一个测试用简单 Web 服务器+ Service Mesh 做流量控制。查阅各种资料让我觉得线索繁杂，无意中刷到下面这张图，觉得它完美描述当时我的内心独白：

在 K8s 的世界，想要完全理解某个东西可能没有看上去那么简单。

我的思绪开始散开：如果这只不幸的小恐龙继续下沉直至物理机层面，它一路上可以看到哪些东西呢？仔细一琢磨，觉得这个问题并不简单，想要回答这个问题需要对云计算有相对整体的了解。根据公开资料，我整理出了以下一张在公有云上运行 K8s 的示意图，注意，这不代表任何现实中的系统设计：

公有云的 VM 上运行 K8s 的可能的架构，其中相同颜色的层代表类似的功能。

接下来自顶向下进行简要介绍：

App：顾名思义是运行在容器内的业务代码。同时注意到根据业务代码的语言，其中也可能多一层JVM 或 Python 解释器之类的。
Docker：用于承载容器的创建和运行等。考虑到容器主要是基于 Cgroup 等命名空间进行资源隔离，Docker 在容器运行时实际对性能几乎没有直接影响。
K8s：编排并管理容器及其相关资源，是目前事实上的行业标准，类似与 Docker 对容器运行时的性能没有直接影响。
Guest OS: 用户可见可操作的操作系统，其上运行了 K8s。考虑到安全性，公有云交付给客户的一定是一个VM而不是容器，所以自然携带一个 OS。这一层时刻消耗资源，但是必要且无可避免。如果有的公司采用多云架构，比如同时使用 GCP，AWS，阿里云，腾讯云和自建的数据中心，那么一般会在这一层之下再构建一层相对简单的基于内网IP作为标签的管理系统。这样，1~4 层的开发者只需要关心自己的内网 IP，根据内网 IP 进行操作和冗余设计。
Hypervisor：用于承载用户虚拟机的创建和运行等。这是一个较大的话题，早期基于软件的全虚拟化效率感人，现在 KVM 通过 CPU 硬件虚拟化大大提高了效率，已经成为了主流方式。具体可以参考CPU 和内存虚拟化[1]。一般认为 I/O 操作通过这一层的代价会高一些。
类 Nova 虚拟机管理系统：用户创建的一堆虚拟机不是孤零零的运行就可以，运行在公有云上的 VM会面对一堆挑剔的客户需求和底层硬件故障，自然也需要一个虚拟机管理系统来进行虚拟机的创建、配置、删除、迁移、计费等等。Nova 是 OpenStack 中的对应组件，有兴趣的话可以参考 OpenStack Nova 总结 [2]。同样，这一层对实际性能几乎没有影响。
类 Container / VM 实例：上面的虚拟机管理系统等相关程序自然是公司内公有云部门开发的，但是他们是不会直接运行在物理机上的。为什么呢？因为对于公有云这种复杂的巨系统，软件开发和运维都是难题，它们必然是分开的。如果直接运行在物理机上，那么软件开发将不得不直面硬件并且进行管理。同时，上面提到的 "类 Nova 虚拟机管理系统" 其实只是众多公有云程序中的一种，考虑到环境和隔离，比较合理的方式是在此处再进行一次虚拟化/容器化。考虑到这里是公司内资源相对安全可控，使用类似容器的方式进行隔离对性能和运维都好。性能的损耗根据具体实现会有变化。
多任务资源隔离、管理系统：类似 K8s 或 Nova，对公司内的服务进行编排和资源管理等。这取决于上一层是 VM 还是 Container。同样，这一层对实际性能几乎没有影响。
Host OS: 运行在物理机器上的操作系统，没有特别需要说明的。
机器资源：物理机器，包括 CPU、内存等。

上面介绍的每一层都是仍在发展中的可以出很多书的大话题，第一张图漫画中的小恐龙仅仅是是下沉到了第三层的 K8s 已经憋不住气了。所以说学海无涯，回头是岸，面对公有云这样的复杂系统时，整体上还是应该好读书不求甚解，需要/有兴趣的时候再专注其中某一个小点吧~

引用链接

CPU 和内存虚拟化: https://zhuanlan.zhihu.com/p/31895393
OpenStack Nova 总结: https://blog.csdn.net/dylloveyou/article/details/80698420

本文转载自：「Cloud Native Community」，原文：https://tinyurl.com/y4gtcd6w，版权归原作者所有。欢迎投稿，投稿邮箱: editor@hi-linux.com。