共计 3131 个字符，预计需要花费 8 分钟才能阅读完成。
文丨陈晓宇，阿里云技术专家
在上一篇《故事，从 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 平台，点击这里查看：原文链接）
相干浏览：
故事，从 Docker 讲起 | 深度揭秘阿里云 Serverless Kubernetes（1）
