导读：serverless kubernetes 是以容器和 kubernetes 为基础的 serverless 服务，它提供了一种简单易用、极致弹性、最优成本和按需付费的 kubernetes 容器服务，其无需节点管理和运维，无需容量规划，让用户更关注应用而非基础设施的管理。我们可以把 serverless kubernetes 简称为 ask。
serverless 容器
首先从 serverless 开始讲起，相信我们已经熟知 serverless 理念的核心价值，其中包括无需管理底层基础设施，无需关心底层 os 的升级和维护，因为 serverless 可以让我们更加关注应用开发本身，所以应用的上线时间更短。同时 serverless 架构是天然可扩展的，当业务用户数或者资源消耗增多时，我们只需要创建更多的应用资源即可，其背后的扩展性是用户自己购买机器所无法比拟的。serverless 应用一般是按需创建，用户无需为闲置的资源付费，可以降低整体的计算成本。
以上所讲的几种都是 serverless 理念的核心价值，也是 serverless 容器与其他 sererless 形态的相同之处。然而，serverless 容器和其他 serverless 形态的差异，在于它是基于容器的交付形态。
基于容器意味着通用性和标准性，我们可以 build once and run anywhere，容器不受语言和库的限制，无论任何应用都可以制作成容器镜像，然后以容器的部署方式启动。基于容器的标准化，开源社区以 kubernetes 为中心构建了丰富的云原生 cloud native 生态，极大地丰富了 serverless 容器的周边应用框架和工具，比如可以非常方便地部署 helm chart 包。基于容器和 kubernetes 标准化，我们可以轻松地在不同环境中（线上线下环境），甚至在不同云厂商之间进行应用迁移，而不用担心厂商锁定。这些都是 serverless 容器的核心价值。
（serverless 容器产品 landscape）
当下各大云厂商都推出了自己的 serverless 容器服务，上图为 gartner 评估机构整理的 serverless 容器产品 landscape，其中阿里云有 serverless kubernetes ask 和 eci；aws 有 fargate，基于 fargate 有 eks on fargate 和 ecs on fargate 两种形态；azure 有 aci。另外 gartner 也预测，到 2023 年，将有 70% 的 ai 应用以容器和 serverless 方式运行。
ask/ack on eci 容器服务
下面介绍阿里云 serverless 容器产品家族：eci、 ack on eci 和 serverless kubernetes。
1. eci
eci 全称是“elastic container instance 弹性容器实例”，是 serverless 容器的底层基础设施，实现了容器镜像的启动。eci 让容器成为和 ecs 一样的云上一等公民。eci 底层运行环境基于安全容器技术进行强隔离，每个 eci 拥有一个独立的 os 运行环境，保证运行时的安全性。eci 支持 0.25c 到 64c 的 cpu 规格，也支持 gpu，按需创建按秒收费。和 ecs 一样，eci 也支持 spot 可抢占式实例，在一些场景中可以节省 90% 的成本。eci 实例的启动时间目前约是 10s 左右，然后开始拉取容器镜像。我们也提供了镜像快照功能，每次容器启动时从快照中读取镜像，省去远端拉取的时间。值得强调的是，eci 和 ecs 共用一个弹性计算资源池，这意味着 eci 的弹性供给能力可以得到最大程度的充分保障，让 eci 用户享受弹性计算资源池的规模化红利。
eci 只可以做到单个容器实例的创建，而没有编排的能力，比如让应用多副本扩容，让 slb 和 ingress 接入 pod 流量，所以我们需要在编排系统 kubernetes 中使用 eci，我们提供了两种在 kubernetes 中使用 eci 的方式。一个是 ack on eci，另外一个是 ask。
在与 kubernetes 编排系统的集成中，我们以 pod 的形式管理每个 eci 容器实例，每个 pod 对应一个 eci 实例， eci pod 之间相互隔离，一个 eci pod 的启动时间约是 10s。因为是在 kubernetes 集群中管理 eci pod，所以完全连接了 kubernetes 生态，有以下几点体现：
- 很方便地用 kubectl 管理 eci pod，可以使用标准的 kubernetes 的 api 操作资源；
- 通过 service 和 ingress 连接 slb 和 eci pod；
- 使用 deployment / statefulset 进行容器编排，使用 hpa 进行动态扩容；
- 可以使用 proms 来监控 eci pod；
- 运行 istio 进行流量管理，spark / presto 做数据计算，使用 kubeflow 进行机器学习；
- 部署各种 helm chart。
这些都是使用 kubernetes 管理容器实例的价值所在。
需要留意的是 kubernetes 中的 eci pod 是 serverless 容器，所以与普通的 pod 相比，不支持一些功能（比如 daemonset），不支持 prividge 权限，不支持 hostport 等。除此之外，eci pod 与普通 pod 能力一样，比如支持挂载云盘、nas 和 oss 数据卷等。
2. ack on eci
接下来我们看下在 ack kubernetes 集群中使用 eci 的方式。这种方式适合于用户已经有了一个 ack 集群，集群中已经有了很多 ecs 节点，此时可以基于 eci 的弹性能力来运行一些短时间 short-run 的应用，以解决元集群资源不足的问题，或者使用 eci 来支撑应用的快速扩容，因为使用 eci 进行扩容的效率要高于 ecs 节点扩容。
在 ack on eci 中，ecs 和 eci pod 可以互联互通，eci pod 可以访问集群中的 coredns，也可以访问 clusterip service。
3. serverless kubernetes
与 ack on eci 不同的是，ask serverless kubernetes 集群中没有 ecs 节点，这是和传统 kubernetes 集群最主要的差异，所以在 ask 集群中无需管理任何节点，实现了彻底的免节点运维环境，是一个纯粹的 serverless 环境，它让 kubernetes 的使用门槛大大降低，也丢弃了繁琐的底层节点运维工作，更不会遇到节点 notready 等问题。在 ask 集群中，用户只需关注应用本身，而无需关注底层基础设施管理。
ask 的弹性能力会优于普通 kubernetes 集群，目前是 30s 创建 500 个 pod 到 running 状态。集群中 eci pod 默认是按量收费，但也支持 spot 和预留实例劵来降低成本。在兼容性方面，ask 中没有真实节点存在，所以不支持 daemonset 等与节点相关的功能，像 deployment / statefulset / job / service / ingress / crd 等都是无缝支持的。
ask 中默认的 ingress 是基于 slb 7 层转发实现，用户无需部署 nginx ingress，维护更加简单。
同时基于 slb 7 层我们实现了 knative serving 能力，其中 knative controller 被 ask 托管，用户无需负担 controller 的成本。
与 ack 一样，ask 和 arms / sls 等云产品实现了很好的集成，可以很方便地对 pod 进行监控，把 pod 日志收集到 sls 中。
这是 ask 的整体架构，核心部分是 ask-schduler，它负责 watch pod 的变化，然后创建对应的 eci 实例，同时把 eci 实例状态同步到 pod。集群中没有真实 ecs 节点注册到 apiserver。这个 nodeless 架构解耦了 kubernetes 编排层和 eci 资源层，让 kubernetes 彻底摆脱底层节点规模导致的弹性和容量限制，成为面向云的 nodeless kubernetes 弹性架构。
ask 典型功能
下面介绍 ask 的几个典型功能：
1. gpu 实例
第一个是 gpu 实例，在 serverless 集群中使用 gpu 容器实例是一件非常简单的事情，不需要安装 gpu 驱动，只需要指定 gpu pod 规格，以及容器需要的 gpu 卡数，然后就可以一键部署，这对于机器学习场景可以极大提高开发和测试的效率。
2. spot 抢占式实例
第二个是 spot 抢占式实例。抢占式实例是一种按需实例，可以在数据计算等场景中降低计算成本。抢占式实例创建成功后拥有一小时的保护周期。抢占式实例的市场价格会随供需变化而浮动，我们支持两种 spot 策略，一种是完全根据市场出价，一种是指定价格上限，我们只需要给 pod 加上对应的 annotation 即可，使用方法非常简单。
3. 弹性负载 elastic workload
第三个重要功能是弹性负载 elastic workload，弹性负载实现了 deployment 多个副本调度在不同的单元上，比如 ecs、eci 和 eci-spot 上，通过这种混合调度的模式，可以降低负载的计算成本。在这个示例中，deployment 是 6 个副本，其中 2 个为正常的 eci pod，其他副本为 eci-spot 实例。
ask 使用场景
上面我们已经对 serverless kubernetes 做了基本的产品和功能介绍，那么 ask 适合在哪些场景中使用呢？**
1. 免运维应用托管
serverless 集群最大的特点是解决了底层节点资源的运维问题，所以其非常适合对应用的免运维托管，让用户关注在应用开发本身。在传统 k8s 集群中的应用可以无缝部署在 serverless 集群中，包括各种 helm chart。同时结合预留实例劵可以降低 pod 的长计算成本。
2. eci 弹性资源池
第二个场景是 ack on eci 的优势，我们可以选择把 eci 作为弹性资源池，加到已有的 kubernetes 集群中，当应用业务高峰来临时，通过 eci 动态灵活地扩容，相比 ecs 节点扩容更有效率，这种比较适合电商或者在线教育这类有着明显波峰波谷的业务场景，用户无需管理一个很大的节点资源池，通过 eci 弹性能力来降低整体计算成本。
3. 大数据计算
第三个场景是大数据计算，很多用户使用 serverless 集群或者 ack on eci 来进行 spark / presto / ai 等数据计算或者机器学习，利用 eci 可以轻松解决资源规划和不足的问题。
4. ci/cd 持续集成
第四个场景是 ci/cd 持续集成，将 jenkins 和 gitlab-runner 对接 ask 集群，按需创建 ci/cd 构建任务，构建完成后直接部署到 ask 测试环境进行验证，这样我们无需为 job 类任务维护一个固定资源池，按需创建极大降低成本，另外如果结合 spot 实例还能进一步降低成本。
以上就是 serverless kubernetes 集群的典型场景，另有快速使用链接、产品文档以及使用示例，供大家学习交流：
- 控制台：https://cs.console.aliyun.com/ask
- 产品文档：https://www.alibabacloud.com/help/doc-detail/86366.htm
- 示例：https://github.com/aliyuncontainerservice/serverless-k8s-examples