Serverless Kubernetes的思考与征程

原创

于 2023-02-24 10:53:30 发布 · 1k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #serverless #容器

本文介绍了阿里云如何通过ServerlessContainer技术对Kubernetes架构进行优化，特别是ECI（ElasticContainerInstance）在安全、资源管理和弹性方面的设计。文章详细阐述了ServerlessContainer的几个关键原则，如单一职责、不可变性和位置无关性，并讨论了其对Kubernetes架构的影响，包括不支持节点网络模型、容器安全模型的改变、运行时安全和资源授权模型等。此外，文章还探讨了ServerlessKubernetes在应对这些挑战时的解决方案，如Sidecar和Hidecar模式，以及混合调度和资源超售的处理。最后，提出了ServerlessKubernetes的采用路径和未来发展方向。

作者：牛秋霖、张维、李传云、易立

本文将针对Serverless Container技术的特殊性，分享其对Kubernetes的架构影响，以及阿里云在Serverless Kubernetes方面架构选择。

一、Serverless Container缘起

在2018年，容器团队与弹性计算团队启动了Serverless Container与Kubernetes的研发，其目标是融合容器技术和云基础设施能力，最大化利用云的弹性和自动化运维能力。为此，我们为Serverless Container定义了其几个关键架构原则：

单一职责Single Responsibility —— 在传统的容器编排中，需要预先分配的工作节点上调度容器应用执行，一个工作节点上可以运行多个容器应用，同节点内部应用共享OS内核，存在资源和安全干扰；而在Serverless Container中，每个应用运行在独立的安全沙箱中，独享OS内核，应用之间不存在相互的资源干扰，有明确的安全作用域。单一职责使得从资源弹性供给到应用调度的全链路可以一体优化，极大优化了弹性效率。

不可变性Immutability —— 在Serverless Container实例在创建后，作为一个不可变的基础设施只支持部分配置变更，比如ConfigMap配置，镜像版本，资源配额等。如果变更引发应用拓扑或者资源的变化，比如一个新版本的AI应用从之前只依赖CPU到依赖GPU设备，需要重建而非原地更新。不可变性极大简化了运维复杂性。

位置无关Location independency —— 用户可以通过一些部署策略，比如可用区、失效域等，控制 Serverless Container 的部署位置，但是用户无法指定Serverless Container所在的具体的物理节点。Serverless Container是临时性的（ephemeral），所有持久化应用状态要保存在外部存储中（比如EBS，NAS，OSS等）或数据服务中，而不能依赖宿主机文件系统。重建Serverless Container实例不能保障IP地址不变。位置无关使得容器可以在整个弹性资源池上进行供给和动态迁移

通过这几个基本原则，用Serverless Container和Serverless Kubernetes重新定位了云平台与开发者之间的边界，尽可能让开发者聚焦于应用，而将资源调度、基础设施运维、高可用、系统优化等复杂性交给到基础设施完成。实现将复杂留给自己，将简单留给用户的技术初心。

1.1 ECI弹性容器实例技术概览

Serverless Container的安全沙箱技术虽然脱胎于虚拟化技术，为了提供与OS容器相近的使用体验，我们要解决几个重要的技术挑战：

1）更快的启动速度 —— 将沙箱容器启动速度从VM的分钟级下降到秒级。

2）更低的性能损耗 —— 减少由于引入虚拟化技术，带来的额外性能损耗，尤其是存储与网络的性能。

3）更低的资源开销 —— 尽可能降由于引入沙箱技术额外增加的资源损耗，尤其是沙箱内部独占的Guest OS内核、系统管控组件等。

4）有保障的库存供给 —— 与OS容器在预分配集群资源进行调度不同，所有Serverless Container依靠云基础设施保障资源的按需供给，一旦库存不足或者创建失败，将影响业务发布与扩容。

阿里云ECI （Elastic Container Instance）是阿里云上Serverless Container的实现。每一个ECI 实例运行在一个独立的安全沙箱之中，有清晰的安全边界，只对外暴露标准化接口。系统可以通过API实现Pod生命周期管理, Liveness/Readiness/Startup 探针，日志/监控Metrics采集。在数据面，ECI包含了两种不同的实现架构，具备不同的优势和特点，可以由控制面按需调度满足用户资源供给需求。

并池架构：阿里云在神龙架构上实现了ECI实例、ECS实例、裸金属实例的统一供给，这样可以充分利用阿里云整体弹性计算资源池保障弹性资源供给；并且可以利用现有ECS规格实现丰富的资源类型，比如GPU实例、AMD、倚天实例等，以及地域覆盖；同时可以利用弹性计算资源池中的碎片资源，提升整体利用率。但是并池架构也存在一些挑战，比如，对每个ECI实例都会包含完整 ECI Agent、Container Runtime等组件，会占用较多的系统资源。此外，在支持ECS与ECI混布的场景下，复用了虚拟机的存储网络编配流程，容器的启动速度和并发度受限于整体链路效率。

专属池架构：ECI团队基于阿里云袋鼠沙箱容器实现一个面向容器场景的技术创新架构。架构特点是将ECI Agent中的Container Runtime等部分下沉到宿主机，只保留了必要的部分在ECI沙箱内部，降低了整体资源占用。同时可以利用容器镜像的特性优化容器启动效率，此外在管控链路和资源生产上也针对容器场景进行了优化。

在Serverless Container架构中，将并池和专属池相结合的方式可以最大化，弹性资源供给的规模、效率、成本与规格丰富度。得益于阿里云在虚拟化层，操作系统层和容器层的软硬一体协同优化，其中ECI启动速度P50为5s；性能与在VM中运行的OS container基本持平，优于KataContainer等开源实现20%。

Serverless Container的优势来源于技术取舍的结果，其特殊性也对Kubernetes架构以及用户应用产生影响，下文我们将介绍相关的改变与应对之道。

二、阿里云Serverless Kubernetes架构概览

在阿里云上容器服务提供了对ECI的全面支持和优化。其中ACK（Kubernetes Service）同时支持ECS节点和ECI实例，在保障兼容性的同时优化运维和弹性体验；而ASK（Serverless Kubernetes）是ACK集群的一个特殊类型，只支持Serverless Container，并默认提供了基于云服务、托管的K8s Addons（PrivateZone based DNS，ALB based Ingress Controller等等）,为客户提供更多的便捷性。ACK/ASK 支持ECI的Serverless Container的抽象架构如图：