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 有更小的开销和攻击面，但是妨碍它被更广泛应用的问题在于它往往需要修改应用，只适合比较特定的应用场景。

图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 所示。

图 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 的创建。

图 3-85 　Virtual Kubelet Autoscaler 工作原理

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

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