09、Kubernetes学习总结-基础架构的未来是 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 产业的重新洗牌,很多传统的技术在云原生的场景下已经不再适用,譬如备份和容灾。传统的备份容灾还停留在数据搬运的层次上,备份机制比较固化,以存储为核心,无法适应容器化的弹性、池化部署场景;而云原生的核心是服务本身,不再以存储为核心,用户需要更贴合容器场景的备份容灾能力,利用云原生的编排能力,实现备份容灾的高度自动化,同时灵活运用云原生的弹性能力按需付费,降低成本。为了适应云原生场景,众多 Kubernetes 备份容灾产品开始涌现,比如 Veeam 推出的 Kasten K10[12] 以及 VMware 推出的 Velero[13]。