ACP云原生容器工程师 - ASK概述与产品介绍

基本概念

Serverless基本概念

对于传统云服务来说，我们需要购买的基础设施是服务器节点ECS，然后在ECS上自行部署应用或者部署其余付费应用，但是我们为了更好地适应应用的使用情况，有时并不需要ECS支持，这样可以更轻量地部署应用，成本也会更低。这就是阿里云无服务Kubernetes(ASK)的基本概念。

  • 特点：

    • 用户无需购买和管理服务器

    • 直接部署容器应用

    • 提高容器应用部署的敏捷度和弹性能力

    • 降低用户计算成本

    • 让用户聚焦业务应用

  • 优势：

    • 敏捷部署、安全隔离、生态链接、高移植性

    • 无需节点容量规划

    • 无需OS和系统软件维护

    • 零基础设施运维

    • “无限”容量、秒级扩容、基于容器扩容

    • 更高的资源利用率、更低计算成本

 

发展趋势

  • 两种技术趋势的整合

    • 云平台托管的后台服务BaaS

    • 无状态计算模型：函数服务FaaS

  • Gartner

    • 到2023年，70% AI任务会通过容器、Serverless等计算模型构建

  • AWS

    • 在2019年 40%的ECS新客户采用Serverless Container

  • 采纳Serverless技术的行业广泛

    • 外包经济、金融业、服务业

  • Serverless是云计算必经的一场革命，会越来越流行

 

架构思考

  • Serverless场景的容器不是部署在传统的ECS上，而是部署在ECI上。然而ECS和ECI并不冲突，可以混合使用

  • 不同于标准K8s，Serverless K8s与IaaS基础设施深度融合，其产品模式更利于公有云厂商通过技术创新，提升规模、效率和能力

  • Serverless也分成容器编排和计算资源池两层。

  • Serverless的几个技术要点：声明式API、可扩展性架构、可移植性

 

架构设计

  • Serverless并不是一个单独的技术，必须兼容Kuubernetes生态，提供K8s的核心价值，此外要能和云的能力深度整合。

  • 用户可以直接使用Kubernetes的声明式API，Deployment、StatefulSet、Job、Service等无需修改

  • 全兼容Kuberenetes的扩展机制，这样才能让Serverless Kubernetes支持更多的工作负载，此外Serverless K8s自身的组件也是严格遵守K8s的状态逼近的控制模式

  • Kubernetes的能力尽可能充分利用云的能力来实现，比如资源的调度、负载均衡、服务发现等。根本性简化容器平台的设计，提升规模，降低用户运维复杂性

  • 这些实现应该对用户透明，保证可移植性，让用户现有应用可以平滑部署在Serverless K8s之上，也应该允许用户应用混合部署在传统容器和Serverless容器之上

 

Nodeless

  • 对于传统的Kubernetes来说，采用以节点为中心的架构设计：

    • 节点是Pod的运行载体，Kubernetes调度器在工作节点池中选择合适的node来运行pod，并利用kubelet完成对pod进行生命周期管理和自动化运维

    • 当节电池资源不够时，需要对节点池进行扩容，再对容器化应用进行扩容

  • 对于Serverless Kubernetes来说

    • 没有节点这个概念

    • 容器化应用是一等公民

    • 极大简化容器弹性实现，无需按照容量规划，按需创建容器应用pod即可

    • Serverless容器运行时可以被整个晕弹性计算基础设施所支撑，保障整体弹性的成本和规模

 

现有产品的架构

初始架构-Viking

优化方向

  1. 可伸缩性 - ECI

  2. 基于云的控制器实现 - PrivateZone、SLB、SLB/ALB

  3. 面向负载的深度优化 - Knative、垂直优化

 

ASK产品介绍

  • 是阿里云推出的无服务器Kubernetes容器服务

  • 无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划，并且饿根据应用配置的CPU和内存资源量进行按需付费（非包年包月，因为没有制程规格的节点）

  • 提供完善的Kubernetes兼容能力，同时降低了Kubernetes使用门槛，更专注于应用本身，而不是基础设施

  • ASK集群中的Pod给予阿里云弹性容器实例ECI运行在安全隔离的容器运行环境中

  • 每个Pod容器实例底层通过轻量级虚拟化安全沙箱技术完全抢格力，容器实例间互不影响。

 

核心优势

  1. 简单易用：无门槛，秒级部署容器应用

  2. 秒级伸缩：无需担心集群容量规划

  3. 安全隔离：通敌底层沙箱进行强安全隔离

  4. 降低成本：按需计费，无资源闲置费用

  5. 原生兼容：支持原生k8s应用和生态，service、helm、ingress等

  6. 服务集成：支持与其他云组件(数据库、vpc中现有应用直接交汇)

 

无节点管理(nodeless)

  • 更多专注于应用的开发，而不是基础设施的维护。更多关注pod/service/ingress/job等应用编排语义上，更少对底层node进行关注。

  • 无需管理节点也可以显著降低集群的运维管理成本，比如node的安全管理、监控/日志管理、基础系统软件的升级和维护

  • 在ASK集群中，我们使用虚拟节点virtual-kubelet代替ECS节点，此virtual-kubelet节点的容量可以认为是“无限大”，用户无需为集群的容量担忧，无需预先做容量规划

 

Serverless kubernetes vs Classic Kubernetes


 

无Master管理与极简的K8s

  • 与ACK托管版一样，ASK的Master等资源(apiserver, ccm, kcm等)被容器服务平台托管，用户无需管理这些核心组件的升级和运维，也不需要成本

  • ASK对Kubernetes进行大量简化，包括默认托管很多addon，用户无需在管理一些基础的addon，也不需要对此付费

  • 依赖阿里元原生的网络和存储等能力，以及独特的托管架构设计，ASK提供了极简但功能完备的Kubernetes基础运行环境

简化弹性伸缩

  • 因为无需管理节点和容量规划，当集群需要扩容时也就不需要考虑节点层面的扩容，只需要关注pod的扩容，这对于扩容的速度和效率都是极大的提升

  • ASK/ECI的方式被刻意用来快速应对业务流量高峰

  • 当前ASK/ECI支持30s完全启动500个pod，单个pod启动可以达到10s以内

 

更低的成本

  • 除去ASK集群本身的低成本创建外，pod的按需使用也让很多场景下资源利用率达到最优。对于很多Jobs或者数据计算场景而言，用户并不需要长期维护一个固定的资源池，这时ASK/ECI可以很好地支持这些诉求

  • 若pod一天运行少于16小时，使用ASK更加经济实惠；若超过16小时，使用ACK更加经济实惠。

 

ECI: 快速交付容器资源的弹性计算服务

  • ECI是阿里云基于ECS IaaS资源池提供的稳定、高效、高弹性容器实例服务

  • ECI让容器成为了公有云的一等公民，用户无需购买和管理ECS就可以直接部署容器应用，这种假话的容器实例产品形态和ASK形成了一个完美地组合

  • 用户可以直接使用ECI Open API创建容器资源实例，但在容器场景中用户普遍需要一个编排系统，来负责容器的调度、高可用编排等能力，而ASK正式这样的Kubernetes编排层。

  • 对于ASK而言

    • ECI让ASK容器服务免去了搭建后台计算资源池的必要，更不用为底层计算资源池的容量而担忧

    • 基于ECI就意味着基于整个阿里云IaaS规模化资源池，天然拥有了库存和弹性优势

    • 另外ECI和ECS复用资源池意味着 我们可以最大化释放规模化红利，给用户提供更低成本的计算服务

 

容器生态支持

  • ASK比较适合的场景：

    • CI/CD

    • 数据计算

    • AI

    • ServiceMesh

    • 测试

  • ASK集群不支持Helm v2，近期ACK/ASK会发布Helm v3的支持，之后用户可以非常方便地在ASK集群中部署Charts

 

小结

  • ASK基本概念

  • ASK产品介绍

  • ASK优势

  • ASK架构介绍与思考

posted on 2023-03-11 17:16  eryoung2  阅读(144)  评论(0)  编辑  收藏  举报