带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.6容器服务与弹性容器实例(五)-阿里云开发者社区

开发者社区> 电子工业出版社> 正文
登录阅读全文

带你读《弹性计算—无处不在的算力》第三章:计算产品和技术3.6容器服务与弹性容器实例(五)

简介: 《弹性计算—无处不在的算力》第三章:计算产品和技术3.6容器服务与弹性容器实例(五)

3. 安全沙箱技术

众所周知,虽然内核的namespace 和cgroup 技术有很强的隔离能力,但是内核是一个很大很复杂的系统,因此基于独立内核的容器技术(如 Docker)是不够安全的,很难从根本上彻底保证云上多租户安全,进而需要更好的隔离。业界主要有四种方法来实现这种隔离,如图3-83 所示。


第一种方法是最简单和直接的,就是把容器放在虚拟机里运行,这种方式不需要对软件栈做改动,只是让同一个用户的容器运行在自己的虚拟机里,但这样除了有额外的开销和不够高效,还有两层的维护复杂度。

第二种方法是MicroVM,仍然使用虚拟化技术来实现安全隔离,但是它的出发点是针对容器场景实现轻量化的虚拟机,并且实现运行时无缝对接容器生态,在保证兼容性的前提下尽量降低运行时和维护开销,并保证原生容器的用户体验。Kata Containers 就是一个MicroVM 方案。首先,对应用来说, 这是一个兼容runC 的容器运行时引擎,可以被Kubernetes 通过containerd/ CRI-O 调用,可以直接运行任何Docker 镜像或OCI 镜像。但与runC 不同的是,它使用了硬件虚拟化技术,直接面对用户应用的不再是宿主机的独立内核,而是一个装在轻量级虚拟机里的内核,即使有未知的安全漏洞导致这个内核被攻击,攻击者仍然无法轻易突破虚拟化技术构建的沙箱。Kata 的思路很不错,但是目前还在迭代完善中。

第三种方法基于进程虚拟化,使用一个特定的内核来提供Linux ABI,直接虚拟化进程的运行环境。Google 的gVisor 就是这样的进程虚拟化方案,实现了一个新的内核并努力去补齐和兼容Linux 的系统调用。这种方法的问题是很难做到Linux 的全兼容,无法支持部分应用。

第四种方法基于Unikernel/LibOS, 让应用带上自己的内核,好处在于简化的LibOS 有更小的开销和攻击面,但是妨碍它被更广泛应用的问题在于它往往需要修改应用,只适合比较特定的应用场景。

image.png

图3-83  多租户隔离方法

综合来看,MicroVM 在兼容性和成熟度上更好,是业界下采用的主流方法。阿154 


里巴巴对这些技术方向都进行了研究和探索,并且结合阿里云的

里巴巴对这些技术方向都进行了研究和探索,并且结合阿里云的场景,对相关技术进行了融合和创新,帮助ECI 等阿里云产品在轻量化、启动时间和性能等方面构建起业界领先的竞争力。

4. Virtual Kubelet 技术

Virtual Kubelet 最初是由微软 Azure 发起的开源项目,目标是让公共云的弹性容器实例类产品能与 Kubernetes 更好地集成,实现 Kubernetes 的 Serverless 能力。在实现上, Virtual Kubelet 提供了一种机制,可以与多家不同的供应商集成,如 Azure 的 ACI、AWS 的 fargate、华为的 CCI。

Virutal Kubelet 启动时会伪装成一个Kubelet 计算节点,即虚拟节点(Virtual Node),向 Kubernetes API Server 发起注册,并持续监听 Pod 变化事件。当Kubernetes 将Pod 调度到虚拟节点上时,Virtual Kubelet 会调用provider 的API 接口,将创建请求动态转发给底层的provider 的API 接口。在阿里云的Serverless Kubernetes 中, Virtual Kubelet 是Serverless Kubernetes 和 ECI 的连接器。如图 3-84 所示。

image.png

图 3-84  Virtual Kubelet 起到连接器的作用

5. 弹性伸缩技术

Kubernetes 开源的弹性伸缩技术是根据HPA(Horizontal Pod Autoscaler)的伸缩条件,动态地购买或销毁虚拟机实例,来实现计算节点资源的水平扩缩容的。它的缺点在于弹性伸缩效率受限于虚拟机弹出和接入集群的效率,在虚拟机弹出后还需要启动操作系统,以及Docker Daemon 和Kubelet 等服务,并最终接入Kubernetes 集群, 整个过程耗时较长。

而阿里云自研的Virtual Kubelet Autoscaler,简称VK-Autoscaler,采取的是完全不同的弹性伸缩方法。它能动态地将扩容请求转到Virtual Kubelet 上,无须启动任何新的计算节点,直接在阿里云海量的资源池之上扩容出新的容器实例,从而更快地满足业务对弹性的诉求。

在一个部署了Virtual Kubelet 的托管版Kubernetes 中,Virtual Kubelet Autoscaler 的工作原理如图3-85 所示。Kubernetes 在调度时,因为没有指定容忍度(Tolerations), 所以不会考虑虚拟节点,而是尝试在已有 ECS 节点中调度。当资源不足时,会报没有满足条件的节点错误事件,VK-Autoscaler 捕获这个事件后,把对应 Pod 重新调度到节点上,Virtual Kubelet 将请求转发给ECI 并完成Pod 的创建。

image.png

图 3-85  Virtual Kubelet Autoscaler 工作原理

这样做的好处在于可以充分利用每台ECS 的处理能力,最大化地提升ECS 和ECI 的资源利用率。由于ECI 按秒计费,所以对于有明显的波峰波谷特征的业务,即

通过托管模式Managed Kubernetes 在包年包月的ECS 上运行时的在线业务而言,是性价比很高的解决方案。而在遇到突发的业务流量时,通过Virtual Kubelet Autoscaler 将峰值压力分摊到ECI 实例上,以削峰填谷。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: