随着云计算的应用普及,最近几年,云原生技术(Cloud Native)的概念很火。Pivotal公司的Matt Stine于2013年首次提出云原生的概念;云原生的具体含义在过去的几年中也在不断发生变化。最近Pivotal官网对云原生的概念概括为4个要点:DevOps、持续交付、微服务、容器。
云原生的概念组成
符合云原生架构的应用应该是这样的:采用以kubernetes(k8s)和容器(Docker)为代表的技术对应用进行容器化部署;基于微服务架构提高应用的灵活性和可维护性;借助敏捷方法、DevOps支持持续迭代和运维自动化;利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
如前文《物联网关键技术:边缘计算》所述,边缘计算技术已广泛应用于物联网应用中,已在云计算领域实践多年的各种云原生技术,也可引入到边缘计算的场景中。
在边缘计算场景中应用云原生技术,可以为边缘计算带来很多好处:
依托云原生领域强大的社区和厂商支持,云原生技术对异构资源的适用性逐步提升。在物联网领域,云原生技术已经能够支持多种 CPU 架构和通信协议,并实现较低的资源占用,这意味着云原生技术不仅仅可以应用在云端,还可以应用在边缘网络及终端设备上。
目前已经有不少厂商在进行云原生边缘计算的尝试,并有了部分成功案例。适用于边缘计算的云原生容器技术主要可分为微虚机(MicroVM)和沙箱(Sandbox)两大类。
所谓的微虚机是指可以在容器环境下运行的虚拟机,这样既可以服用容器化的便利,轻量,同时又考虑了虚拟机的隔离安全性。亚马逊AWS的Firecracker、OpenStack基金会的Kata Container以及VMWare的vSphere Integrated Containers都属于微虚机技术。
Firecracker是一种利用 KVM 的虚拟化技术,专门用于创建和管理多租户容器以及基于函数的服务。 可以在几分之一秒内在非虚拟化环境中启动轻量级微虚拟机,充分利用传统虚拟机提供的安全性和工作负载隔离,同时兼具容器的资源效率。通过 RESTful API 控制 Firecracker 进程,可精确控制同一台计算机上数千个微虚机使用的网络和存储资源。
Kata Containers是由OpenStack基金会管理,但独立于OpenStack项目之外的容器项目。Kata Containers能够支持不同平台的硬件 (比如x86-64,arm等),符合开放容器规范(OCI:Open Container Initiative),同时还可以兼容k8s的 容器运行时接口规范(CRI:Container Runtime Interface)。这意味着Kata Container可以和容器生态的各种已有产品兼容,如docker、k8s等。
Docker引擎以前启动容器使用runc,现在可以换成kata了。
Kata Container可以当做docker的一个插件,可以通过docker命令启动Kata Container。Kata最大的亮点是解决了传统容器共享内核的安全和隔离问题,办法就是让每个容器运行在一个轻量级的虚拟机中,使用单独的内核。
k8s也使用kata取代runc创建容器
k8s传统创建pods的方法默认也是使用 runC 创建容器,现在是使用kata container先创建一个虚拟机,在虚拟机中再创建pods,这样就更安全。
沙箱不同于传统的容器以及微虚机,容器是通过namespace跟cgroup实现资源隔离,微虚机则是通过虚拟化技术实现资源隔离,而沙箱技术是通过对系统调用的劫持以及重定向,进而实现资源隔离的。google公司的gVisor就属于此类技术。
gVisor在内核之外实现了一个“内核进程”,叫做“哨兵”(Sentry),它能够提供大部分 linux 内核的系统调用。用户进程的大部分系统调用都被转化为对这个“哨兵”进程的访问。
传统系统调用和gVisor沙箱系统调用的对比
Google 将 gVisor 定位为“Sandbox”,而不是安全容器,主要因是 Sentry 还不能完全代替 Linux 系统内核,部分系统调用还是要转接到 Host Kernel 上。
gVisor 其能够为容器进程提供安全的隔离措施,同时继续保持远优于虚拟机的轻量化特性。而且gVisor还能够与Docker及Kubernetes实现集成,从而在生产环境中更轻松地建立起沙箱化容器系统。
随着微虚机、沙箱等轻量级容器技术的出现,使得容器对系统资源的要求进一步降低,非常适合于资源有限的边缘场景中应用,将边缘计算资源容器化,用云端一致的方式来进行资源管理。