网站开发创意设计,免费单页在线制作,自助建站平台有哪些,松江建设投资有限公司网站简介#xff1a; 当前 Serverless 容器的行业趋势如何#xff1f;有哪些应用价值#xff1f;如果 Kubernetes 天生长在云上#xff0c;它的架构应该如何设计#xff1f;Serverless 容器需要哪些基础设施#xff1f;阿里云容器服务产品负责人易立及阿里云 Serverless Kube… 简介 当前 Serverless 容器的行业趋势如何有哪些应用价值如果 Kubernetes 天生长在云上它的架构应该如何设计Serverless 容器需要哪些基础设施阿里云容器服务产品负责人易立及阿里云 Serverless Kubernetes 产品 TL 张维将分享他们对 Serverless 容器架构和背后的关键思考。 导读当前 Serverless 容器的行业趋势如何有哪些应用价值如果 Kubernetes 天生长在云上它的架构应该如何设计Serverless 容器需要哪些基础设施阿里云容器服务产品负责人易立及阿里云 Serverless Kubernetes 产品 TL 张维将分享他们对 Serverless 容器架构和背后的关键思考。 从 Serverless 容器到 Serverless Kubernetes Serverless无服务器容器是让用户无需购买和管理服务器直接部署容器应用的产品、技术形态。 Serverless 容器可以极大提高容器应用部署的敏捷度和弹性能力降低用户计算成本让用户聚焦业务应用而非底层基础设施管理极大地提高应用开发效率降低运维成本。 目前 Kubernetes 已经成为业界容器编排系统的事实标准基于 Kubernetes 的云原生应用生态Helm, Istio, Knative, Kubeflow, Spark on K8s 等更是让 Kubernetes 成为云操作系统。一方面通过 Serverless 方式根本性解决 K8s 自身的管理复杂性让用户无需受困于 K8s 集群容量规划、安全维护、故障诊断一方面进一步释放了云计算的能力将安全、可用性、可伸缩性等需求由基础设施实现这样可以形成差异化竞争力。 1. 行业趋势 Gartner 预测到 2023 年70% AI 任务会通过容器、Serverless 等计算模型构建。在 AWS 的调研中在 2019 年 40% 的 ECSAWS 弹性容器服务新用户采用 ECS on Fargate 的 Serverless Container 形态。 Serverless 容器是现有 Container as a Service 的进化方向之一可以和 fPaaS/FaaS (Function as a Service) 形成良好的互补。FaaS 提供了事件驱动的编程方式用户只需实现函数的处理逻辑比如当接收到用户上传的一个视频时对视频进行转码和加水印。FaaS 方式开发效率很高也可以将弹性发挥到极致但需要用户改变现有的开发模式来进行适配。而 Serverless Container 应用的载体是容器镜像灵活性很好配合调度系统可以支持各种类型应用比如无状态应用、有状态应用、计算任务类应用等等。用户大量现有的应用无需修改即可部署在 Serverless Container 环境中。 图源 Gartner 报告中也谈到 Serverless 容器业界标准未定云厂商有很多空间通过技术创新提供独特的增值能力其对云厂商的建议是 扩展 Serverless 容器应用场景和组合迁移更多普通容器 workload 到 Serverless 容器服务。 推进 Serverless 容器的标准化减轻用户对云厂商锁定的担忧。 2. 典型场景与应用价值 自阿里云 ASK/ECI 从 2018 年 5 月份正式公测以来我们非常高兴的看到 Serverless 容器的价值逐渐被用户认可。典型应用场景包括 1在线业务弹性扩容 基于 ASK 支撑在线业务弹性扩容在 30s 之内可以极速扩容 500 个应用实例轻松应对预期和非预期突发流量。比如此次疫情时期多个在线教育平台使用 ASK/ECI 超强弹性能力轻松面对业务高峰。 2免运维 Serverless AI 平台 基于 ASK 开发的智能、免运维的 AI 应用平台可以让开发者创建自己的算法模型开发环境而平台则会按需弹性伸缩极大减少了系统维护和容量规划复杂性。 3Serverless 大数据计算 基于 ASK 构建 Serverless 大数据计算平台。通过 Serverless 化的 Spark, Presto 等数据计算应用灵活满足企业快速成长过程中不同业务部门的多种计算任务、高弹性、强隔离和免维护的需求。 Serverless 容器架构思考 不同于标准 K8sServerless K8s 与 IaaS 基础设施深度整合其模式更利于公有云厂商通过技术创新提升规模、效率和能力。在架构层面我们将 Serverless 容器分成容器编排和计算资源池两层下面我们将对这两层进行深度剖析分享我们对 Serverless 容器架构和背后的关键思考。 1. Kubernetes 的成功秘诀 Kubernetes 在容器编排的成功不止得益于 Google 的光环和 CNCF云原生计算基金会的努力运作。背后是其在 Google Borg 大规模分布式资源调度和自动化运维领域的沉淀和升华。 其中几个技术要点 1声明式 API 由于 Kubernetes 采用了声明式的 API。开发者可以关注于应用自身而非系统执行细节。比如 Deployment, StatefulSet, Job 等不同资源类型提供了对不同类型工作负载的抽象。对 Kubernetes 实现而言基于声明式 API 的 “level-triggered” 实现比 “edge-triggered” 方式可以提供更加健壮的分布式系统实现。 2可扩展性架构 所有 K8s 组件都是基于一致的、开放的 API 实现、交互。三方开发者也可通过 CRDCustom Resource Definition/Operator 等方法提供领域相关的扩展实现极大提升了 K8s 的能力。 3可移植性 K8s 通过一系列抽象如 Loadbalance Service, Ingress, CNI, CSI帮助业务应用可以屏蔽底层基础设施的实现差异灵活迁移。 2. Serverless Kubernetes 的设计原则 Serverless Kubernetes 必须要能兼容 Kubernetes 生态提供 K8s 的核心价值此外要能和云的能力深度整合。 用户可以直接使用 Kubernetes 的声明式 API兼容 Kubernetes 的应用定义Deployment, StatefulSet, Job, Service 等无需修改。 全兼容 Kubernetes 的扩展机制这个很重要这样才能让 Serverless Kubernetes 支持更多的工作负载。此外 Serverless K8s 自身的组件也是严格遵守 K8s 的状态逼近的控制模式。 Kubernetes 的能力尽可能充分利用云的能力来实现比如资源的调度、负载均衡、服务发现等。根本性简化容器平台的设计提升规模降低用户运维复杂性。同时这些实现应该是对用户透明的保障可移植性让用户现有应用可以平滑部署在 Serverless K8s 之上也应该允许用户应用混合部署在传统容器和 Serverless 容器之上。 3. 从 Node Centric 到 Nodeless 传统的 Kubernetes 采用以节点为中心的架构设计节点是 Pod 的运行载体Kubernetes 调度器在工作节点池中选择合适的 node 来运行 Pod并利用 Kubelet 完成对 Pod 进行生命周期管理和自动化运维当节点池资源不够时需要对节点池进行扩容再对容器化应用进行扩容。 对于 Serverless Kubernetes 而言最重要的一个概念是将容器的运行时和具体的节点运行环境解耦。只有如此用户无需关注 node 运维和安全降低运维成本而且极大简化了容器弹性实现无需按照容量规划按需创建容器应用 Pod 即可此外 Serverless 容器运行时可以被整个云弹性计算基础设施所支撑保障整体弹性的成本和规模。 在 2017 年底我们启动 Serverless Kubernetes 项目的时候我们一直在思考如果 Kubernetes 天生长在云上它的架构应该如何设计。我们在现有 Kubernetes 的设计实现上进行了扩展和优化。构建了 Cloud Scale 的 Nodeless K8s 架构——内部代号为 Viking因为古代维京战船以迅捷和便于操作而著称。 1Scheduler 传统 K8s scheduler 的主要功能是从一批节点中选择一个合适的 node 来调度 Pod满足资源、亲和性等多种约束。由于在 Serverless K8s 场景中没有 node 的概念资源只受限于底层弹性计算库存我们只需要保留一些基本的 AZ 亲和性等概念支持即可。这样 scheduler 的工作被极大简化执行效率极大提升。此外我们定制扩展了 scheduler可以对 Serverless workload 进行更多的编排优化可以在保证应用可用性的前提下充分降低了计算成本。 2可伸缩性 K8s 的可伸缩性受到众多因素的影响其中一个就是节点数量。为了保障 Kubernetes 兼容性AWS EKS on Fargate 采用 Pod 和 Node 1:1 模型一个虚拟节点运行一个 Pod这样将严重限制了集群的可扩展性目前单集群最多支持 1000 个 Pod。我们认为这样的选择无法满足大规模应用场景的需求。在 ASK 中我们在保持了 Kubernetes 兼容性的同时解决了集群规模受限于 Node 影响单集群可以轻松支持 10K Pod。此外传统 K8s 集群中还有很多因素会影响集群的可伸缩性比如部署在节点上的 kube-proxy在支持 clusterIP 时任何单个 endpoint 变更时就会引起全集群的变更风暴。在这些地方 Serverless K8s 也使用了一些创新的方法限制变更传播的范围这些领域我们将持续优化。 3基于云的控制器实现 我们基于阿里云的云服务实现了 kube-proxy、CoreDNS、Ingress Controller 的行为降低系统复杂性比如 利用阿里云的 DNS 服务 PrivateZone为 ECI 实例动态配置 DNS 地址解析支持了 headless service。 通过 SLB 提供了提供负载均衡能力。 通过 SLB/ALB 提供的 7 层路由来实现 Ingress 的路由规则。 4面向工作负载的深度优化 未来充分发挥 Serverless 容器的能力我们需要针对工作负载的特性进行深度优化。 KnativeKnative 是 Kubernetes 生态下一种 Serverless 应用框架其中 serving 模块支持根据流量自动扩缩容和缩容到 0 的能力。基于 Serverless K8s 能力阿里云 Knative 可以提供一些新的差异化功能比如支持自动缩容到最低成本 ECI 实例规格这样可以在保障冷启动时间的 SLA 并有效降低计算成本。此外通过 SLB/ALB 实现了 Ingress Gateway有效地降低了系统复杂性并降低成本。 在 Spark 等大规模计算任务场景下也通过一些垂直优化手段提高大批量任务的创建效率。这些能力已经在江苏跨域的用户场景中得到验证。 Serverless 容器基础设施 对于 Serverless 容器而言我们梳理的用户重点诉求是 更低的计算成本弹性成本要低于 ECSlong run 应用成本要接近 ECS 包年包月更高的弹性效率ECI 扩容速度要远高于 ECS更大的弹性规模与传统 ECS 节点扩容不同一个大规模容器应用动辄需要数万核的弹性算力。持平的计算性能ECI 计算效能需要和同规格 ECS 有一致的性能表现更低的迁移成本与现有容器应用生态完美集成更低的使用成本全自动化安全和运维能力ECI 的关键技术选择如下 基于轻量化 Micro VM 的安全容器运行时对于云产品而言首先的考虑就是安全性。为此ECI 选择基于袋鼠云原生容器引擎和轻量化 Micro VM 来实现安全、隔离的容器运行时。除了运行时的资源隔离之外不同用户之间的网络、存储、quota、弹性 SLO 等一系列能力也基于阿里云基础设施实现了严格的多租隔离。 在性能方面除了袋鼠容器引擎在 OS/容器方面的高度优化之外ECI 在容器执行上优化集成了现有阿里云基础设施能力比如支持 ENI 网卡直通、存储直接挂载。这些能力保障 ECI 中应用执行效率等于甚至略优于现有 ECS 运行环境。 基于 Pod 的基本调度单位和标准、开放的 API 接口与 Azure ACI, AWS Fargate on ECS 不同在 ECI 设计初期就确定了基于 Pod 作为 Serverless 容器的基本调度和运行单位这样可以更加简单地结合上层 Kubernetes 编排系统。 ECI 提供提供了 Pod 的生命周期管理能力包括 CreateDeleteDescribeLogsExecMetrics 等。ECI Pod 与 K8s Pod 能力一致不同之处在于其沙箱基于 Micro VM 而非 CGroup/Namespace。这样使得 ECI Pod 可以比较完美地支持各种 K8s 应用包括 Istio 这样以 sidecar 方式动态注入的技术。 此外标准化的 API 屏蔽了底层资源池的具体实现可以同时可以容纳底层不同形态、不同架构、不同的资源池和生产调度实现。ECI 底层架构做了多次优化、迭代比如袋鼠安全沙箱的创建可以通过神龙架构的 MOC 卡进行 offload但是这些对上层应用和集群编排是无感的。 此外 API 需要拥有足够的通用性支持在多个场景中使用让用户在 ASK/ACK、自建 K8s 和混合云场景中都可以充分利用 Serverless 容器的优势和价值。这个也是阿里云 ECI 和友商一个重要的不同。 ECI 与 ECS 并池架构通过并池我们有能力充分整合阿里云弹性计算资源池的算力包括多种模式按量spotRISaving Plan 等多种机型供应GPU/vGPU, 新 CPU 架构上线多样化的存储能力ESSD本地盘等让 ECI 在功能、成本和规模上更有优势满足用户对计算成本和弹性规模的强诉求。 Serverless 容器的挑战 Serverless 容器资源创建过程首先是一个计算资源的创建装配过程是计算、存储、网络多个基础 IaaS 资源的协同装配过程。然而与 ECS 不同Serverless 容器有很多独立的挑战。 根据 Sysdig 2019 年容器的调研报告, 超过 50% 的容器生命周期小于 5 分钟。Serverless 容器需要具备秒级的启动速度才能满足用户对 Serverless 容器的启动诉求。Serverless 容器自身的启动速度主要受如下因素影响 底层虚拟化资源的创建和组装通过端到端管控链路的优化 ECI 可以将资源准备时间优化到亚秒级。 Micro VM 操作系统启动时间袋鼠容器引擎针对容器场景对操作系统进行了大量剪裁和优化极大减少了 OS 启动时间。 镜像下载时间从 Docker 镜像仓库下载镜像并在本地解压缩是一个非常耗时的操作。下载时间取决于镜像大小通常在 30 秒到数分钟不等。在传统 Kubernetes 中 worker 节点会在本地缓存已下载过的镜像这样下次启动不会重复下载和解压。为了实现极致弹性成本效率ECI 和 ECS 采用并池的策略计算存储分离的架构这也意味着我们不可能通过传统方式利用本地盘来做容器镜像的缓存。 为此我们实现了一个创新的方案可以将容器镜像制作成一个数据盘快照。当 ECI 启动时如果镜像快照存在可以直接基于快照创建一个只读数据盘并随着实例启动自动挂载容器应用直接利用挂载数据盘作为 rootfs 进行启动。基于盘古 2.0 架构和阿里云 ESSD 云盘的极致 I/O 性能我们可以将镜像加载的时间缩小到 1 秒以内。 这个领域还有很大发展空间下一步会进一步和多个团队共同优化 Serverless 容器的启动效率。 此外 Serverless 容器的调度相比 ECS 更关注资源弹性供给的确定性。Serverless 容器强调按需使用而 ECS 更多是提前购买预留。在大规模容器创建场景下单用户单 AZ 弹性 SLO 保障是一个很大的挑战。在电商大促、跨年活动和最近的突发疫情保障的一系列用户支持中用户对于云平台是否能够提供弹性资源供给确定性 SLO 是极度重视的。此外结合 Serverless K8s上层调度器和 ECI 弹性供给策略配合我们可以给用户更多对弹性资源供给的控制能力平衡弹性的成本规模和持有时间等不同需求维度。 Serverless 容器的并发创建效率也至关重要。在高弹性场景用户要求 30s 内启动 500 Pod 副本来支持突发流量类似 Spark/Presto 等计算业务对并发启动的诉求更大。 为了有效减低计算成本Serverless 容器应该提升部署密度。由于采用 MicroVM 技术每个 ECI 实例拥有独立的 OS 内核。此外为了兼容 K8s 语义还有一些辅助进程运行在 ECI 内部。目前每个 ECI 进程会有 100M 左右的额外开销。类似 EKS on Fargate每个 Pod 也有近 256M 左右的系统开销。这部分会降低 Serverless 的部署密度。我们需要将共性的开销下沉到基础设施之上甚至通过 MOC 软硬一体的方式来进行卸载。 未来展望 在预期范围内各大云厂商将会持续投入 Serverless 容器方向来加大容器服务平台的差异化。上面已经提到成本、兼容性、创建效率和弹性供给保障是 Serverless 容器技术重要的硬核能力。 作者易立、张维
原文链接
本文为阿里云原创内容未经允许不得转载
