关于kubernetes:深度揭秘阿里云-Serverless-Kubernetes

3次阅读

共计 3537 个字符，预计需要花费 9 分钟才能阅读完成。

简介：听阿里云技术专家聊聊 Serverless Kubernetes 一路走来的发展史，看看它是如何做到兼容 Kubernetes 应用形式的同时，领有免运维和极致弹性等特点~

作者 | 陈晓宇（阿里云技术专家）

策动 | 褚杏娟

随同着云原生的倒退，从新近的单机版 Docker 到 Kubernetes 的编排畛域的一统江湖，再到云上托管 Kubernetes，技术风雨变动。明天咱们就沿着历史的脉络，一起看一下 Serverless Kubernetes 的发展史。

故事尽管从 Docker 讲起，但咱们不能漠视了 IaaS（Infrastructure as a Service）先辈们在后面的乘风破浪，以及云计算大佬们很早就确定的云计算倒退布局。

在十几年前，先辈们从依照用户应用（云平台提供能力）维度，将云分为三层：

IaaS：Infrastructure as a Service，基础设施即服务，提供虚拟机或者其余根底资源作为服务提供给用户；
PaaS：Platform as a Service，平台即服务，将平台作为服务提供给用户，譬如在平台中能够随用随取各种中间件服务；
SaaS：Software as a Service，软件即服务，将利用作为服务提供给用户，譬如邮件服务。

如下图所示，从 IaaS 到 PaaS，用户（开发和运维）越来越少地感知根底资源，更加关注到业务当中。

让业余的人做业余的事件，从而施展整体的最大效率。譬如一个初创的互联网买菜公司，没有必要本人去建机房、洽购硬件、配置网络存储以及装置操作系统等与业务无关的事件，而是更应该把精力放到业务的开发和经营下面。

通过十几年的倒退，IaaS 曾经比拟成熟，各种根底资源，如 ECS、VPC、EBS 等曾经深入人心，但 PaaS 的倒退却十分迟缓。

早在 2008 年，Google 就推出了 App Engine 服务，想打造一个开发平台，让开发者只须要编写业务代码就能够在 App Engine 下面运行。这个思维过于超前，开发者还不能齐全承受。除了私有云以外，开源社区 PaaS 平台也在左突右冲。其中，IBM 的 Cloud Foundry 和 Redhat 的 OpenShift 最为闻名，他们都心愿提供一个利用疾速公布的平台，但也都是不温不火，反而因为各种兼容问题越来越难应用。

直到 2013 年 Docker 的诞生，一个对开发者充沛敌对、一个命令能够拉起一个服务，并极致简略的操作形式，让 Docker 一下成为社区最受欢迎的开源我的项目之一。

Docker 的劣势次要体现在：Docker 镜像将应该依赖的环境和利用打包成一个压缩文件，这个文件能够在任何装置了 Docker 的机器下面间接运行，解决了利用从开发、测试到生产各个环节部署问题，并且可能保障环境的一致性。

Docker 的胜利在于极致的简略操作而非技术的翻新，像 cgroup、namespace 这些技术早就退出内核个性了。所以，Cloud Foundry 新近并没有把 Docker 看做竞争对手，因为这些技术早就在 Cloud Foundry 上应用了。反而，Dcoker 镜像这个无心插柳的性能，让 Docker 真正实现了“Build once, Run anywhere”。

最后的 Docker 是单机版本，面对大规模部署的场景时须要一套治理平台，就像 OpenStack 治理 VM 一样。

容器治理平台初期也是百家争鸣，譬如 Mesos、Swarm 等，但它们都没有脱离 IaaS 固有思维，还是停留在把容器当做虚拟机治理。直到 Kubernetes 的呈现，才真正开始一统江湖。这里除了 Google 的背书以及脱胎于 Borg 的成熟架构以外，更重要的是 Kubernetes 在诞生之初就曾经想好了容器如何治理（Replica set）以及如何对外提供服务（Service）。

其中，最令人可惜的就是 Docker 公司自家的管理系统 Swarm。过后的 Docker 尽管曾经锋芒毕露，但 Docker 公司自身却没有实现盈利。于是公司推出了 Swarm 企业版，尽管 Swarm 前期也引入了很多 Kubernetes 的概念，但无奈大势已去，云原生的生态曾经围绕 Kubernetes 蓬勃发展。

Kubernetes 尽管由 Google 主导，但却放弃了足够的开放性，将资源的治理形象出接口标准，譬如针对容器运行时的 CRI、针对网络的 CNI、针对存储的 CSI，以及设施治理 Device Plugins 和各种准入管制、CRD 等。Kubernetes 正逐步演变成云操作系统，各种云原生组件就是运行在这个操作系统之上的零碎组件。

尽管 Kubernetes 确定了领导位置，但 Kubernetes 的运维却并非那么容易。在这种背景下，私有云纷纷尝试推出了云上 Kubernetes 托管服务，比方阿里云在 2017 年就推出了托管 Master 的计划：ACK。

在 ACK（Alibaba Cloud Container Service for Kubernetes）中，Kubernetes 治理组件的装置和运维托管给私有云，应用 ECS 或者裸金属作为 Kubernetes 的计算节点，这样一来极大地缩小了 Kubernetes 用户的应用老本。用户从云平台获取一个 kubeconfig 文件便能够间接通过 kubectl 命令行或者 Restful API 治理集群。

如果须要扩容集群容量，只须要调整 ECS 个数，新创建的 ECS 会主动注册到 Kubernetes Master。不仅如此，ACK 还反对一键降级集群版本和各种插件。ACK 将繁冗的运维工作转移到云上，并且借助云的弹性能力，可能做到分钟级别的资源扩大。

私有云绝对公有云更加关注老本，因为在公有云中，用户的基础设施老本根本是固定的，用户不可能下线一个服务后去机房停一台服务器。与之相同，私有云则提供了按量付费的模式。

如果集群外面运行工作大部分都是 long run 并且资源需要是固定的工作，应用 ACK 没有问题，但如果是大量 job 类型的工作或者存在突发流量的状况，ACK 这种长期扩容虚拟机在虚拟机上启用容器计划在弹性方面有所欠缺。

比方某在线教育公司，每天晚上 7-9 点上课高峰期会长期扩容几万个 Pod，如果应用 ACK 就须要事后评估这些 Pod 的容量，而后再折算成 ECS 的算力，提前购买对应数量的计算节点退出到 Kubernetes 外面，并且还须要在 9 点之后将这些 ECS 开释掉，操作十分繁琐。

那么，有没有一种既能兼容 Kubernetes 应用形式，又可能秒级启动 Pod，并且依照 Pod 维度计费（ACK 依照 Node 维度计费）的计划呢？

AWS 率先提出 Fargate，能够在没有实在 Node 的状况下，以 Pod 的维度退出到 Kubernetes 集群。阿里云在 2018 年也推出了相似的产品 ECI（Elastic Container Instance），每个 ECI 就是一个 Pod，这不过这个 Pod 是托管在云上的。

Kubernetes 应用 ECI 有两种形式：一种是 ASK（Alibaba Serverless Kubernetes），另一种是 ACK + Virtual Node 的计划。在 ASK 中，计算节点齐全变成了 Virtaul Node。Virtaul Node 是一个虚构的有限容量的计算节点，负责 ECI 生命周期治理。Virtaul Node 会注册到 Kubernetes 外面，对于 Kubernetes 来说，它就是一个一般的 Node 节点。用户只须要提交原生的 Kubernetes Yaml 便能够创立出 Pod，齐全兼容 Kubernetes 的应用。

Virtaul Node 还能够与一般 ACK 节点混用，用户能够将 long run 的任务调度到 ECS 节点上运行，而后利用 ECI 的疾速启动（10s 内拉起容器），将突发或者短周期任务调度到 ECI 下面，从而达到老本最优。

目前 ECI 曾经被很多互联网以及人工智能公司所采纳。在后续的文章中，咱们将逐渐分享几个典型用户在迁徙 ECI 过程中遇到的技术问题和挑战。

总结一下，咱们明天从技术倒退的角度回顾了容器和 k8s 的倒退历程，能够看到公共技术正逐步积淀到底层，无论是 k8s 还是 ServiceMesh，都在别离尝试将服务治理和流量治理下沉到基础设施中。但这些组件自身也存在治理老本，所以演化出云上托管。将来，随着技术的下沉，云计算提供的能力将一直上移、提供更加全面和丰盛能力，让开发专一在业务之上。

陈晓宇，阿里云技术专家，负责阿里云弹性容器（ECI）底层研发工作，曾出版《深入浅出 Prometheus》和《云计算那些事儿》。本文转载自 InfoQ，节选陈晓宇的《深度揭秘阿里云 Serverless Kubernetes》系列专题。

原文链接
本文为阿里云原创内容，未经容许不得转载。

正文完