基础架构的未来 是 K8s，那么 K8s 的未来在何方？

随着容器技术大行其道，应用的复杂性只增不减，开发者们开始广泛使用更先进的工具，比如 Kubernetes。目前 Kubernetes 已经不年轻了，开始逐渐开始 boring，你可能会想问 Kubernetes 之后还有什么令人兴奋的新技术。但云计算是一个快速发展的领域，不太容易精准预测下一个令人兴奋的新技术，不如我们将目光聚焦到目前云计算没有完全覆盖的细分领域。

微型虚拟机 (MicroVM)
在 Kubernetes 之后，有一个前景广阔的云技术可能会被广泛接受，即微型虚拟机 (MicroVM)。微型虚拟机与容器的区别在于它不与宿主机共用内核，拥有自己的微内核，提供了与虚拟机一样的硬件虚拟化安全性。虚拟机抽象了内存、CPU、网络、存储和其他计算资源，而微型虚拟机是围绕应用程序来对资源进行抽象，只抽象了必要的资源，所以更加高效。

目前最受欢迎的微型虚拟机就是 AWS Firecracker [1] ，它使用 Rust 语言编写，内存开销极低，将微型虚拟机打包到 Kubernetes 集群中，以提高工作负载的安全性和隔离性。AWS 目前正使用 Firecracker 作为 Serverless 的基础单元，冷启动时间延迟极低。

Weaveworks 也开源了一个基于 Firecracker 的虚拟机管理器 Ignite [2] ，将 Firecracker MicroVM 与 Docker/OCI 镜像结合起来，统一了容器和虚拟机。它以 GitOps 的方式工作，可以像 Kubernetes 和 Terraform 一样声明式管理虚拟机。

还有一些其他项目，例如 slim [3] ，旨在从 Dockerfile 重新构建和运行微型虚拟机。它的工作原理是从 Dockerfile 中构建并提取 rootfs，然后将该文件系统与一个在线 RAM 中运行的微内核合并。

随着越来越多的应用程序被迁移到云端，以及越来越多的围绕 5G 技术建立的新业务解决方案，微型虚拟机将会发挥至关重要的作用。

高性能 WebAssembly
自从 1995 年 Netscape 公司推出 JavaScript 之后，很长一段时间它都是唯一的网络编程语言。之后人们提出了很多替代方案，但都没有成功，这些替代方案要么不支持跨平台，要么需要浏览器插件。因此，纵然 JavaScript 有它的缺陷性，还是变成了世界上最流行的编程语言之一。

WebAssembly 的出现打破了这个僵局，严格来说，它不是一种编程语言，而是一种二进制指令集。因此它对 JavaScript 没有威胁，也无意取代 JavaScript，它可以和 JavaScript 协同工作，你也可以将 JavaScript 编译成 WebAssembly 二进制格式。

但 WebAssembly 的潜力不仅局限于浏览器层面，全球著名的 CDN 厂商 Fastly 的 CTO 之前在一个视频中完美阐述了 WebAssembly 的价值：

虚拟机模拟了完整的计算机；容器模拟了完整的操作系统；WebAssembly 仅仅模拟了进程。
容器大家都比较熟悉，它只模拟了完整操作系统的用户空间，不包含内核空间，也不包含硬件相关的抽象。但是对于微服务和 Serverless 而言，它仍然很重，我只需要启动一个进程，你却让我先启动一个完整的操作系统再启动进程。

这时候 WebAssembly 的价值就体现出来了，你只需要启动一个进程，而我恰好就启动了进程，没有操作系统，也没有硬件虚拟化，只有孤单的进程，只是这个进程被放入了 WebAssembly 的沙盒中。

看到了这一点，众多工程师开始发挥自己的无限想象力，比如将 WebAssembly 作为 Kubernetes 的 CRI 运行时，代替容器以适应 Serverless 场景。

目前大约有 40 高级编程语言开始支持 WebAssembly，包括 C、C++、Python、Go、Rust、Java 和 PHP，未来可期。

轻量级 Kubernetes 发行版
为了避免 Kubernetes 的安装部署过于复杂，越来越多的人更愿意使用 Kubernetes 的阉割版本，即轻量版。像 K3s [4] 这样的轻量级发行版更容易通过命令行安装，它提供了更轻量级的存储后端，并且所有的组件都打包在一个单一的可执行文件中，体积更小。由于它只需要极低的资源就可以运行，因此它能够在任何地方 512MB 内存以上的设备上运行集群。

边缘计算与物联网
伴随着轻量级 Kubernetes 发行版的发展，适用于边缘计算和物联网场景的 Kubernetes 发行版也崭露头角，例如 KubeEdge [5] ，提供了边缘计算所需的轻量级和边缘自治能力。但 KubeEdge 缺少云端控制层面的支持，将混合云容器平台 KubeSphere [6] 与 KubeEdge 结合，可以解决边缘节点纳管、边缘工作负载调度和边缘可观测性等难题，结合 KubeSphere 已有的多集群管理将混合多云管理延伸至边缘侧。

多集群管理
虽然目前 Kubernetes 中有很多工具可以隔离多租户工作负载，但有时出于安全与合规原因，使用集群作为边界来隔离团队和应用程序更有意义。

随着越来越多的团队和组织在各个云中运行多个 Kubernetes 集群，对多个 Kubernetes 集群的管理和控制变得愈发艰难，像 CiliumMesh [7] 、 Submariner [8] 、 Skupper [9] 、 Istio [10] 和 KubeSphere [11] 这样的多集群管理工具将使多集群 Kubernetes 环境的管理更加方便和高效。

多集群的另一个好处是减少集群故障的影响范围，如果你有强隔离的要求，可以考虑使用多集群。此外，多集群也能简化操作流程，比如在同一个控制平面进行调度和升级。KubeSphere 目前已经支持将工作负载得多个副本按不同比例灵活分发到多个集群。

跨集群备份容灾
随着云原生对 IT 产业的重新洗牌，很多传统的技术在云原生的场景下已经不再适用，譬如备份和容灾。传统的备份容灾还停留在数据搬运的层次上，备份机制比较固化，以存储为核心，无法适应容器化的弹性、池化部署场景；而云原生的核心是服务本身，不再以存储为核心，用户需要更贴合容器场景的备份容载能力，利用云原生的编排能力，实现备份容灾的高度自动化，同时灵活运用云原生的弹性能力按需付费，降低成本。