文丨陈晓宇，阿里云技术专家
在上一篇《故事，从Docker讲起|深度揭秘阿里云Serverless Kubernetes（1）》的文章中，我们介绍了 Serverless Kubernetes 的演进历史，在这一篇我们将进入阿里云 Serverless Kubernetes 内部，从架构层面看一下阿里云是如何实现 Serverless Kubernetes 的。
整体架构
Serverless Kubernetes 设计的初衷是为了提供一套免运维的云上托管 Kubernetes。所以，我们不仅要解决 Kubernetes Master（etcd、kube-apisever、kube-controller-manager）的托管，而且还需要实现 Pod 的云上托管，这样用户只需要提交 Yaml 便可以启动服务，不再需要维护计算节点。基于此，我们将整个 Serverless Kubernetes 架构做了如下设计：
整个架构分为三层：Kubernetes Master 和虚拟 Kubelet、ECI 后台服务以及 ECI Agent。
最上层是一个云上托管的 Kubernetes Master 和一个虚拟 Kubelet（Virtual Kubelet）。Virtual Kubelet 和标准的 Kubelet 类似，只不过在启动 Pod 的时候不再是调用本地的 CRI 启动容器，而是通过 HTTP 的方式调用 ECI OpenAPI 启动 ECI 实例，每个 ECI 就是一个 Pod。Virtual Kubelet 设计的初衷主要是为了贴合 k8s 原生架构：在 k8s 中，Pod 是由 Kubelet 拉起并且定时同步状态。
中间层是 ECI 后台服务，负责资源配置和调度。如用户配置日志采集，ECI 后台会去 SLS（阿里云日志服务）创建日志采集配置，如果用户通过 PVC 为 Pod 挂载云盘，ECI 后台服务会创建云盘并将云盘挂载到 ECI 上。另外，ECI 后台还负责资源调度，选择合适的物理机节点启动 ECI，具体启动方式是通过部署在每个节点上的 proxy 完成。
底层是 ECI Agent， 负责启动业务容器。上面的 proxy 只是启动了一个安全沙箱，但用户需要的是一个运行业务的 Pod，所以我们还需要在这个沙箱里面拉起用户的业务容器，Agent 就是根据用户的 Pod 的定义，启动对应的容器，并且负责管理后续容器的生命周期，如果 Pod 异常退出，Agent 会重新拉起。
下面我们将从 Pod 创建的流程，分别介绍每个组件的工作原理。
云上托管的 Kubernetes
用户创建 Pod 的请求首先会发送到 k8s master，所以我们要解决的第一个问题是如何实现 k8s master 的云上托管。
这里我们使用了“k8s on k8s”的方案，借助 k8s 的能力运维用户的 k8s master。由于 k8s master 的配置项比较多，很难通过一个 Deployment 或者 Statefulset 表达，为了灵活控制，我们使用 k8s CRD（CustomResourceDefinition），将 k8s 集群抽象成一个 Cluster CRD，当用户在控制台创建一个 ASK 集群的时候，后台便会提交一个 Cluster CR。于是，CRD 控制器便会为每个集群单独创建一个 Namespace，并在这个 Namespace 里面创建 Etcd 和 k8s master (etcd、kube-apiserver、controller manager)集群。
细心的你可能发现，上面的 k8s 的管理组件没有 scheduler，这是因为在 ASK 中，没有真实的计算节点，不需要调度。Virtual Kubelet 会一直监听 k8s 的 apiserver，当用户提交创建 Pod 请求后，Virtual Kubelet 发现了这个 Pending 的 Pod 后，便会调用 ECI OpenAPI 直接创建 ECI（Pod），并且定时将 Pod 状态同步到 apiserver。
承上启下的 ECI 后台
当 Virtual Kubelet 通过 HTTP 接口请求创建 ECI 的时候，ECI 后台接收请求后首先会进行参数校验。譬如 ECI 不支持 HostPath（需要单独开白名单），如果用户配置了 HostPath 会直接返回错误，然后会将 ECI 元数据入库，并进入流控队列。出队之后，ECI 后台会通过库存系统，调度到一台合适的物理机上。每台物理机上都会部署一个 proxy，负责接收后台的创建请求并启动 ECI 安全沙箱。整个流程如下所示：
做个类比，操作系统向下管理一台机器硬件资源向上提供各种系统调用，那么 ECI 后台向下管理整个云数据中心的资源向上暴露 OpenAPI 提供 ECI 的管理能力。
从这个层面来说，ECI 的后台就是云操作系统。比如 ECI 后台中的流控队列就是为了保障多用户的公平调度，每个用户都会有一个队列，出队的时候，依次从每个队列出中取出未调度的 ECI ，从而确保不会出现调度饥饿。
伪装成 Pod 的 ECI-Agent
当 proxy 启动 ECI 沙箱后，ECI-Agent 会根据 Pod 的定义，在 ECI 里面启动容器。每个 ECI 都伪装成了一个 Pod，所以对于 k8s 来说，它必须满足 Pod 的日常行为，比如容器生命周期管理、健康检查、性能监控、执行 exec/log/attach，以及上报自己的状态（Status）和事件（Event）。所以在早期我们将 kubelet 和 containerd 经过简单删减后直接塞入 ECI-Agent 里面。
当 ECI-Agent 接收到 Pod 创建请求后，首先会将 Pod 信息本地持久化，这样 ECI 重启后就可以自行恢复。然后，ECI-Agent 会将 Pod 内容发送给 Kubelet，剩下的就是 Kubelet 执行原生启动 Pod 的逻辑了。Pod 启动成功后，Kubelet 会将 Pod 状态同步到 kube-apiserver，这样用户就可以实时地查看到 Pod 状态了。
这里大家可能有疑问，上面介绍了 Virtual Kubelet ，而 ECI 里面还有一个精简的 Kubelet，两者是不是存在冲突？
大家都知道，原生 Kubelet 主要工作是负责监听 kube-apiserver，当发现有 Pod 调度到本机后则会执行创建 Pod（拉起容器），并且上报状态。所以，我们这里将原生 Kubelet 拆解成两个部分：负责监听 kube-apiserver 的 Virtual Kubelet 和 ECI-Agent 里真正启动 Pod 容器和上报状态的精简 Kubelet。
至此，我们通过 ASK 中启动 Pod 整个流程，打通了 ASK 整体架构。大家可以简单把 ASK 理解成 “云上托管的 k8s master + ECI (弹性容器)”。一方面，云上托管的 k8s 集群减少用户的运维成本，另一方面，底层 ECI 按需使用秒级计费节省用户费用，可谓天作之合。
ECI 这种按照 Pod 维度所用随取的使用方式非常适合 Job 任务的运行，从 Job 任务开始计费到 Job 任务结束停止计费。目前，ECI 每天的创建量已经超过一百多万个，支持了众多互联网和人工智能公司。
在后续的文章中，我们将逐步拆解架构，分享更多实战和内部细节，请大家继续关注。
本文节选自阿里云技术专家陈晓宇的《深度揭秘阿里云 Serverless Kubernetes》系列专题。本专栏将主要围绕如何在 Serverless Kubernetes 场景中实现秒级扩容，以及在大规模并发启动中遇到的各种技术挑战、难点以及解决方案，系统地揭秘阿里云 Serverless Kubernetes 的发展、架构以及核心技术。
作者简介：
陈晓宇，阿里云技术专家，负责阿里云弹性容器（ECI）底层研发工作，曾出版《深入浅出 Prometheus》 和 《云计算那些事儿》。
（文章转自InfoQ平台，点击这里查看：原文链接）
