目前Serverless容器的行业趋势是什么？有哪些应用价值？如果Kubernetes诞生在云端，它的架构应该如何设计？无服务器容器需要什么基础设施？阿里云容器服务产品经理易立和阿里云ServerlessKubernetes产品负责人张伟将分享他们对Serverless容器架构及其背后的关键思考。从ServerlessContainer到ServerlessKubernetesServerless（无服务器）容器是一种让用户无需购买和管理服务器，直接部署容器应用的产品和技术形态。Serverless容器可以大大提高容器应用部署的敏捷性和弹性，降低用户计算成本；让用户专注于业务应用而非底层基础设施管理，大大提高应用开发效率，降低运维成本。目前，Kubernetes已经成为业界容器编排系统的事实标准。基于Kubernetes（Helm、Istio、Knative、Kubeflow、SparkonK8s等）的云原生应用生态使Kubernetes成为云操作系统。一方面，通过Serverless的方式从根本上解决了K8s本身的管理复杂性，让用户无需再受困于K8s的集群容量规划、安全维护、故障诊断；另一方面，它进一步释放了云计算的能力，将安全性、可用性、可扩展性等需求通过基础设施来实现，可以形成差异化的竞争力。行业趋势Gartner预测，到2023年，70%的AI任务将通过容器、Serverless等计算模型构建。在AWS的调查中，2019年40%的新ECS（AWSElasticContainerService）用户在Fargate上采用了ECS的ServerlessContainer形式。Serverless容器是现有ContainerasaService的演进方向之一，可以对fPaaS/FaaS（FunctionasaService）形成很好的补充。FaaS提供了一种事件驱动的编程方式。用户只需要在接收到用户上传的视频时，实现该功能的处理逻辑，如对视频进行转码、加水印等。FaaS方式的开发效率非常高，也能最大限度的发挥灵活性，但需要用户改变现有的开发模式来适应。ServerlessContainer应用的载体是容器镜像，容器镜像非常灵活，可以支持各种类型的带有调度系统的应用，比如无状态应用、有状态应用、计算任务应用等。用户已有的大量应用无需修改即可部署在ServerlessContainer环境中。来源：https://blogs.gartner.com/tony-iams/containers-serverless-computing-pave-way-cloud-native-infrastructure/Gartner报告中也提到，serverless容器行业标准未定，云厂商有一个大量空间通过技术创新提供独特的增值能力。它对云厂商的建议是：扩展Serverless容器的应用场景和组合，将更多常见的容器工作负载迁移到Serverless容器服务中。推动无服务器容器标准化，缓解用户对云供应商锁定的担忧。典型场景及应用价值自2018年5月阿里云ASK/ECI正式公测以来，我们很高兴看到Serverless容器的价值逐渐被用户认可。典型应用场景包括：基于ASK的在线业务弹性扩展，支持在线业务弹性扩展，可在30s内高速扩展500个应用实例，轻松应对预期和意外的突发流量。比如疫情期间，多个在线教育平台利用ASK/ECI的超强弹性能力，轻松应对业务高峰。免运维ServerlessAI平台是基于ASK开发的智能化、免运维AI应用平台，允许开发者创建自己的算法模型开发环境，平台可按需弹性扩展，大大降低系统维护和容量规划的复杂性。Serverless大数据计算基于ASK构建Serverless大数据计算平台。通过Spark、Presto等Serverless数据计算应用，灵活满足企业快速成长过程中不同业务部门对各种计算任务、高弹性、强隔离、免维护的需求。serverless容器架构思想不同于标准的K8s。ServerlessK8s与IaaS基础设施深度融合，其模式更有利于公有云厂商通过技术创新提升规模、效率和能力。在架构层面，我们将Serverless容器分为两层：容器编排和计算资源池。下面我们将对这两层进行深入分析，分享我们对Serverless容器架构及其背后的核心思考。Kubernetes成功的秘诀Kubernetes在容器编排方面的成功，不仅仅得益于Google的光环和CNCF（CloudNativeComputingFoundation）的努力。背后是其在大规模分布式资源调度和自动化运维领域的沉淀和升华GoogleBorg。几个技术点：DeclarativeAPI因为Kubernetes采用的是declarativeAPI。开发人员可以专注于应用程序本身，而不是系统执行的细节。例如，不同的资源类型（如Deployment、StatefulSet和Job）为不同类型的工作负载提供了抽象。对于Kubernetes实现，基于声明式API的“级别触发”实现可以提供比“边缘触发”方法更健壮的分布式系统实现。可扩展性架构所有K8s组件均基于一致且开放的API实现和交互。第三方开发者也可以通过CRD（CustomResourceDefinition）/Operator等方式提供领域相关的扩展，大大提升了K8s的能力。可移植性K8s通过LoadbalanceService、Ingress、CNI、CSI等一系列抽象，帮助业务应用屏蔽底层基础设施的实现差异，灵活迁移。ServerlessKubernetes设计原则ServerlessKubernetes必须兼容Kubernetes生态，提供K8s的核心价值，与云能力深度融合。用户可以直接使用Kubernetes的声明式API，兼容Kubernetes的应用定义。Deployment、StatefulSet、Job、Service等不需要修改。完全兼容Kubernetes的扩展机制。这非常重要，这样ServerlessKubernetes才能支持更多的工作负载。另外，ServerlessK8s本身的组件严格遵守K8s状态逼近的控制方式。Kubernetes的能力是通过尽可能充分利用云的能力来实现的，比如资源调度、负载均衡、服务发现等。从根本上简化容器平台的设计，增加规模，降低用户运维的复杂度。同时，这些实现应该对用户透明，保证可移植性，让用户已有的应用可以顺利部署在ServerlessK8s上，也应该让用户应用可以部署在传统容器和Serverless容器上。从NodeCentric到Nodeless，传统Kubernetes采用以节点为中心的架构设计：节点是Pod的运行载体，Kubernetes调度器在工作节点池中选择合适的节点运行Pod，使用Kubelet来完成Pod的生命周期管理和自动化运维；当节点池资源不足时，需要扩容节点池，进而扩容容器化应用。对于ServerlessKubernetes，最重要的概念就是将容器运行时与具体的节点运行环境解耦。只有这样，用户才无需关注节点运维和安全，降低运维成本；并且大大简化了容器弹性的实现，无需根据容量规划按需创建容器应用Pod；此外，Serverless容器运行时可以由整个云弹性计算基础设施支持，保证了整体弹性的成本和规模。2017年底，我们在启动ServerlessKubernetes项目的时候，一直在思考，如果Kubernetes诞生在云上，它的架构应该如何设计。我们对现有的Kubernetes设计和实现进行了扩展和优化。构建了CloudScale的无节点K8s架构——内部代号为Viking，以以速度和易操作性着称的古代维京战舰命名。Scheduler传统的K8s调度器的主要功能是从一批节点中选择一个合适的节点来调度Pod，以满足资源、亲和力等各种约束。由于ServerlessK8s场景没有节点概念，资源仅受底层弹性计算库存限制。我们只需要保留一些基本的概念支持，比如AZaffinity。这样就大大简化了调度器的工作，大大提高了执行效率。此外，我们对调度器进行了定制和扩展，可以对Serverless工作负载进行更多的调度优化，在保证应用可用性的同时充分降低计算成本。可扩展性K8s的可扩展性受很多因素的影响，其中之一就是节点数量。AWSEKSonFargate为保证Kubernetes兼容性，采用Pod和Node1:1模型（一个虚拟节点运行一个Pod），严重限制了集群的可扩展性。目前，单个集群最多支持1000个Pod。我们认为这样的选择无法满足大规模应用场景的需求。在ASK中，我们在保持Kubernetes兼容性的同时，解决了集群大小受Node.js限制的问题。单个集群可以轻松支持10K个Pod。另外，传统的K8s集群中还有很多因素会影响集群的可扩展性。例如，当部署在节点上的kube-proxy支持clusterIP时，任何一个端点的变化都会引起整个集群的变化风暴。在这些地方，ServerlessK8s也使用了一些创新的方法来限制变更传播的范围，我们会继续优化这些地方。基于云的控制器实现我们基于阿里云的云服务实现了kube-proxy、CoreDNS和IngressController的行为，以降低系统复杂性。例如：使用阿里云的DNS服务PrivateZone为ECI实例动态配置DNS地址解析，支持headless服务通过SLB/ALB提供的SLB七层路由提供负载均衡能力实现Ingress路由规则深度优化工作负载充分发挥未来的Serverless容器，我们需要根据工作负载优化的特点进行深入分析。Knative：Knative是Kubernetes生态中的一个Serverless应用框架，其中的serving模块支持根据流量自动扩容和缩容为零。基于ServerlessK8s能力，阿里云Knative可以提供一些新的差异化功能，比如支持自动缩容到成本最低的ECI实例规格，可以保证冷启动时间的SLA，有效降低计算成本。此外，IngressGateway通过SLB/ALB实现，有效降低系统复杂度和成本。在Spark等大规模计算任务场景中，也采用了一些垂直优化的方式来提高创建大规模任务的效率。这些能力已经在江苏跨域用户场景得到验证。Serverlesscontainerinfrastructure对于serverless容器，我们梳理了用户的核心诉求：更低的计算成本：弹性成本低于ECS，长期应用成本接近ECS订阅更高的弹性效率：ECI的扩展速度远高于ECS的弹性规模:不同于传统的ECS节点扩展，一个大规模的容器应用往往需要数万核的弹性计算能力。扁平化计算性能：ECI计算性能需要与同规格的ECS保持一致。更低的迁移成本：与现有容器应用生态完美融合。使用成本更低：全自动化的安全和运维能力。ECI的关键技术选择如下：轻量级MicroVM-basedsecurecontainerruntime对于云产品，首先考虑的是安全性。为此，ECI选择基于Kangaroo云原生容器引擎和轻量级MicroVM实现安全隔离的容器运行时。除了运行时的资源隔离，网络、存储、配额、弹性SLO等不同用户之间的一系列能力，也是基于阿里云基础设施实现严格的多租户隔离。在性能方面，ECI除了Kangaroo容器引擎高度优化的OS/容器外，还优化整合了阿里云现有基础设施在容器执行方面的能力，如支持ENI网卡透传、存储直挂等。这些能力保证了应用在ECI中的执行效率与现有ECS运行环境持平甚至略胜一筹。基于Pod的基本调度单元和标准，开放的API接口不同于ECS上的AzureACI、AWSFargate，在ECI设计初期就确定Pod为Serverless容器的基本调度和运行单元，可以更方便的实现结合上层Kubernetes编排系统。ECI提供Pod生命周期管理能力，包括Create/Delete/Describe/Logs/Exec/Metrics等。ECIPod与K8sPod具有相同的能力，只是它的沙箱是基于MicroVM而不是CGroup/Namespace。这样ECIPod就可以完美支持各种K8s应用，包括Istio等以sidecar方式动态注入的技术。另外，标准化的API屏蔽了底层资源池的具体实现，可以同时容纳不同形态、不同架构、不同资源池和生产调度实现。ECI底层架构经过多次优化迭代。比如袋鼠安全沙箱的创建可以通过神龙架构的MOC卡进行卸载，但是这些对上层应用和集群编排是不敏感的。另外，API需要足够通用，支持多场景使用，让用户在ASK/ACK、自建K8s、混合云场景中充分发挥Serverless容器的优势和价值。这也是阿里云ECI与同行的重要区别。ECI和ECS合并池架构通过合并池，我们有能力充分整合阿里云弹性计算资源池的算力，包括多模型（按volume、spot、RI、SavingPlan等）、多模型供应量（GPU/vGPU，全新CPU架构上线）、存储能力多样化（ESSD、本地盘）等，让ECI在功能、成本、规模等方面更具优势，满足用户对计算的强烈需求成本和弹性规模。Serverless容器的挑战Serverless容器资源的创建过程首先是计算资源的创建和组装过程，是计算、存储、网络等多种基础IaaS资源的协同组装过程。然而，与ECS不同的是，无服务器容器有许多独立的挑战。根据Sysdig2019容器使用报告（https://sysdig.com/blog/sysdig-2019-container-usage-report/），超过50%的容器的生命周期不到5分钟。Serverless容器需要具备秒级的启动速度，以满足用户启动Serverless容器的需求。Serverless容器本身的启动速度主要受以下因素影响：底层虚拟化资源的创建和组装，可以通过优化端到端控制链路的ECI，将资源准备时间优化到亚秒级.MicroVM操作系统启动时间袋鼠容器引擎针对容器场景对操作系统进行了裁剪和优化，大大降低了OS启动时间。图像下载时间从Docker注册表下载图像并在本地解压缩是一项非常耗时的操作。下载时间取决于图像大小，通常从30秒到几分钟不等。在传统的Kubernetes中，worker节点会将下载的镜像缓存在本地，这样下次启动就不会重复下载和解压。为了实现极致的弹性和成本效率，ECI和ECS采用了池化策略，计算和存储分离的架构，这也意味着我们不可能以传统方式使用本地磁盘来缓存容器镜像。为此，我们实现了一个创新的解决方案：容器镜像可以做成数据盘快照。ECI启动时，如果镜像快照存在，可以直接根据快照创建只读数据盘，实例启动时自动挂载。容器应用可以直接使用挂载的数据盘作为rootfs启动。基于盘古2.0架构和阿里云ESSD云盘极致的I/O性能，我们可以将图片加载时间缩短到1秒以内。这个领域还有很大的发展空间。下一步，我们将进一步优化多团队Serverless容器的启动效率。另外Serverless容器的调度比ECS更注重资源弹性供应的确定性。Serverless容器强调按需使用，而ECS更多的是提前购买预订。在大规模创建容器的场景下，如何保证单用户单AZ的弹性SLO保障是一个很大的挑战。在一系列用户支持的电商促销、跨年活动，以及近期突发的疫情中，用户非常看重云平台能否提供弹性的资源供应和确定性的SLO。此外，结合ServerlessK8s、上层调度器和ECI弹性供应策略，我们可以让用户对弹性资源供应有更多的控制权，平衡弹性成本、规模、持有时间等不同需求维度。Serverless容器的并发创建效率也很关键。在高弹性场景下，用户要求30秒内启动500个Pod副本来支持突发流量。Spark/Presto等计算服务对并发启动的需求更大。为了有效降低计算成本，Serverless容器应该提高部署密度。得益于MicroVM技术，每个ECI实例都有一个独立的操作系统内核。另外，为了兼容K8s语义，ECI内部运行了一些辅助进程。目前，每个ECI进程都有大约100M的额外开销。与Fargate上的EKS类似，每个Pod也有近256M的系统开销。这部分会降低Serverless的部署密度。我们需要将公共开销下沉到基础设施上，甚至??通过MOC软硬件集成来卸载。
