关于阿里云:没有银弹只有取舍-Serverless-Kubernetes-的思考与征程一

作者：易立 (微垣)

Kubernetes 作为云原生计算的根底我的项目，曾经在开发者和企业中取得宽泛的反对。然而其本身复杂性和平缓的学习曲线仍然让人望而却步。在 CNCF 2020 年度调研报告中，在 Kubernetes 技术落地过程中面临最大的挑战就是复杂性。

IBM 大型机之父 Fred Brooks 驰名的论文 No Silver Bullet [ 1]，软件系统中的复杂性能够分为实质复杂性 (essential complexity) 和从属复杂性 (accidental complexity)。实质复杂性是构建零碎过程中不可避免的复杂性。从属复杂性则是任何非必要的复杂性，比方因为设计失误或者工具不当等引入的复杂性。从属复杂性会随着工具的改善而逐步解决，而本质性的艰难难以解决。

Kubernetes 的实质复杂性与从属复杂性到底有什么？咱们应该如何应答？

Kubernetes 的复杂性挑战

分布式系统的复杂性

在上世纪 90 年代，Sun 的几位工程师提出了分布式计算的八个舛误 [ 2]，这也解释了为什么构建牢靠的分布式系统是一项艰巨的工程挑战。

作为分布式集群管理系统，Kubernetes 本身要面临着泛滥的复杂性，比方，节点宕机，网络抖动、组件版本不统一等等。此外 K8s 还要可能用正当的形象向下层利用屏蔽底层的不确定性、差异性和复杂性。

资源调度的复杂性

如何高效地利用计算资源，升高计算成本是资源调度的重要指标。

Kubernetes 作为一个分布式集群管理系统，它的一个重要指标是：将适宜的资源分配给适宜的利用，满足对利用的 QoS 要求和取得最优的资源应用效率。

然而，分布式系统的资源调度有着十分高的复杂性。次要挑战包含：

• 对多状态异构资源的反对，明天利用所需的计算资源不只是简略的 CPU，内存，存储等，而且包含多样化的减速设施，比方 GPU、RDMA 等。而且，为了思考到计算效率的最优化，要思考到计算资源之间的拓扑，比方 CPU core 在 numa 节点间的布局，GPU 设施间 NVLink 拓扑等。此外随着高性能网络的的倒退，GPU 池化、内存池化等相继呈现，给资源调度带来更多的动态性和复杂性。
• 对多样化的工作负载的反对。从 Stateless 的 Web 利用、微服务利用，到有状态的中间件和数据利用，再到 AI、大数据、HPC 等计算工作类利用。他们对资源申请和应用的形式有不同的需要。
• 对多维度的业务需要的反对。调度零碎在满足利用对资源的需要的同时，也要满足不同的业务需要，比方计算效率，优先级，稳定性，利用率等等。

调度零碎须要在多样化的资源和多样化的束缚之间进行动静决策，整体挑战很高。而且随着时间推移，集群中逐步呈现负载不平衡的景象，资源热点会导致。如何继续调整集群负载

基础设施环境的多样性

不同的环境，比方，线下数据中心与云，不同的云供应商之间，他们在基础设施能力上有着很多差别。相似单机操作系统要能反对不同的硬件设施，一个分布式集群零碎要向下屏蔽基础设施的差别，并向下层利用提供统一的编程接口和体验，帮忙利用在不同环境中迁徙。

Kubernetes 的解决之道

Kubernetes 做出了几个重要的架构抉择，大大缓解了分布式集群管理系统的从属复杂性。

管制循环（Control loops）

Kubernetes 架构的外围就是就是管制循环（control loops），也是一个典型的 ” 负反馈 ” 控制系统。当控制器察看到冀望状态与以后状态存在不统一，就会继续调整资源，让以后状态趋近于冀望状态。

基于管制循环，K8s 实现了残缺的自动化容器编排零碎。比方，节点宕机后主动迁徙利用，批改利用正本数就能够实现利用的扩缩容，等等。

所有 K8s 组件都是基于统一的架构实现。开发者也可通过 CRD（Custom Resource Definition）/ Operator 等办法提供畛域相干的扩大实现，极大扩大了 K8s 的利用场景。

此外因为分布式系统的稳定性挑战，基于管制循环的“level-triggered”实现比事件驱动的“edge-triggered”形式能够提供更加强壮的分布式系统实现。

申明式（Declarative）API

申明式 API 是云原生重要的设计理念，让开发者能够关注于利用本身，而非零碎执行细节。这样的架构形式也有助于将整体复杂性下沉，交给基础设施实现并继续优化。

比方，Kubernetes 为开发者提供了比方 Deployment, StatefulSet, Job 等不同类型工作负载形象。这些资源由相应 Controller 来负责具体的部署、变更、复原等，用户无需关注这些细节。

基础设施形象

K8s 通过一系列形象如 CNI – 容器网络接口，CSI – 容器存储接口，容许基础设施提供方提供差异化的实现，然而听从对立的管制面接口。这帮忙业务利用能够较少关注底层基础设施差别，可能在不同环境中统一治理、自在迁徙；也晋升了基础设施提供方的积极性，构建有竞争力的产品能力。

正是这些架构抉择，无效升高了分布式集群治理的从属复杂性。让 Kubernetes 成为博得了开发者的心。

Kubernetes 遗留的运维复杂性

在生产环境中落地 Kubernetes，继续保障系统的稳定性，安全性和规模化成长。对绝大多数客户仍然充斥挑战。很多企业的 K8s 团队的日常工作是这个样子的：

• 日常保护集群，进行版本升级

<!—->

• • 均匀每个月要进行一次小版本升级
  • 均匀每年要进行一到两次大版本升级

<!—->

• 日常更新操作系统安全补丁

<!—->

• • 均匀每个月要进行一次

<!—->

• 解决容器集群中各种问题应急

<!—->

• • 每天 n 次

<!—->

• 对集群进行容量评估，手动扩缩容

<!—->

• • 按需 

托管 Kubernetes 服务与责任共担模型

为了简化客户在云上应用容器技术，更好聚焦所有支流的云厂商都提供了托管 Kubernetes 服务。Google GKE，AWS EKS，阿里云 ACK，都是其中的代表。

对于托管集群，云服务商托管了 K8s 的管制面组件，提供了默认高可用、平安的管制面，局部简化了用户的运维。

对于 K8s 数据面的工作节点，能够是 ECS VM 或者裸金属实例，托管 K8s 服务只负责节点上 Worker Node 组件的生命周期，其余节点运维仍然须要本人负责。这意味着，在运维责任、安全性、稳定性方面，云和客户采纳如下图的责任共担模型。

阿里云、Google、AWS 的容器产品也提供了托管节点池，能够实现自动化的节点组件降级，CVE 修复，故障自愈等能力，将日常节点的运维复杂性留给云平台，将简略留给客户。

云原生计算基金会 (CNCF) 2022 年度考察显示，79% 受访者会应用云平台提供的 Kubernetes 服务。在阿里云上靠近 80% 的 K8s 用户也已采纳阿里云容器服务 ACK。

Kubernetes 节点遗留的复杂性

Kubernetes 的数据面是由节点组成，节点能够是虚拟机，裸金属服务器或者物理机。K8s 管制面动静调度 Pod 到节点进行执行。这样架构十分天然，但也有一些人造的毛病。

1. Pod 与节点生命周期不同步

• • 节点就绪后，能力进行 Pod 调度，升高了弹性的效率
  • 节点保护 / 下线 / 缩容，须要迁徙所有节点上的 Pod，极大减少了弹性的复杂性。

2. 同节点外部 Pod 共享资源

• • 共享内核，扩充了攻击面。用 OS 提供的 namespace，seccomp 等机制无奈实现很好的平安隔离。
  • 共享资源，产生相互影响。CPU，内存，I/O，长期存储容量等，有些无奈通过 cgroup 进行很好的资源隔离。

3. 容器网络与节点网络独立治理

• • 要为节点，容器、Service 独立配置 CIDR
  • 在跨多个可用区、混合云、或者企业网络拓扑编排等较简单场景下，大多数客户不足足够的能力实现正当的网络布局。

4. 容量布局与弹性配置简单

• • 须要用户治理节点池，抉择适合的节点规格进行扩容，优化整体资源利用率，减少了复杂性。

Serverless Kubernetes 的现实

咱们心愿对 Kubernetes 进行 radical simplification，实现几个要害的

1. 免运维 – 用户无需对 K8s 管制面和数据面进行运维。让用户聚焦业务利用而非底层基础设施治理
2. 按需付费 – 无需预留资源，按利用理论资源使用量费。
3. 简化容量治理 – 让利用能够弹性伸缩，无需关注集群资源的调整。

Serverless Kubernetes 的流派

实现 Serverless Kubernetes 的指标，不同厂商抉择了不同的门路。

Nodeless Kubernetes

Nodeless Kubernetes 的代表就是 Google GKE Autopilot。这个计划十分易于了解，它没有扭转 Kubernetes 的部署架构，而是将工作节点的运维与集群容量治理下沉到基础设施负责。

1. GKE Autopilot 集群节点池 / 节点对用户不可见，也无奈登录进行运维。
2. 用户为利用申请的资源付费，而不是为底层资源进行付费。
3. 用户无需进行容量治理。GKE Autopilot 的调度和计费单位是 Pod，然而扩容的单位依然是节点实例。当用户部署 / 扩容利用时，GKE 会先尝试调度到已有节点中；如果资源有余，GKE 服务依据 Pending Pod 来动态创建相应节点池 / 节点来适配利用；同理当利用删除 / 缩容时，GKE 服务也会依据状况缩容节点池来开释理论应用资源。

注：GKE Autopilot 基于节点池进行伸缩，每个节点池中实例规格保持一致，整个节点创立流程如下图所示。

详细信息能够参考文末 [ 3]。

这个计划最大的劣势是其与现有 Kubnernetes 生态兼容度十分高，它保留了节点的概念，反对 DaemonSet，节点抉择（nodeSelector）与节点亲和性（nodeAffinity）等与节点严密相干的概念。

同时，这个计划为了晋升 K8s 的易用性，抉择就义了一些通用性。比方，不反对对节点的拜访和操作，不反对自定义操作系统等等。

而且这个计划只是将节点运维的复杂性局部暗藏并下沉到基础设施，然而很多实质复杂性并未隐没。比方：

• 网络布局没有简化：仍然须要对 K8s 的节点网络 CIDR 进行布局
• 节点爆炸半径大：如果节点 OS 须要进行更新替换，须要对整个节点上的所有 Pod 进行迁徙。
• 存在资源争抢：一个节点上会运行多个利用，利用间可能存在互相烦扰问题，
• 弹性效率低：集群扩容是须要创立新的虚拟机实例，须要启动一个残缺的操作系统，一般而言整个过程须要数分钟。为了升高启动耗时，能够通过气球工作 [ 4] – 一个低优先级、可抢占的占位利用，来提前预留集群资源。（呵呵，感觉和 Serverless 又产生了抵触啊）
• 存在资源碎片：节点以 VM 作为资源扩容的最小单位，可能会造成肯定的资源节约。如果利用缩容，也会导致节点上存在碎片，须要从新调度实现资源整顿。
• 尚未反对超售：在资源调度上，因为用户无奈抉择节点规格以及资源超售比例，GKE autopilot 只反对 Guaranteed QoS，也就是 Pod 的 requests 资源和 limits 相等，不反对资源超售，不反对突发的资源需要。技术上存在反对资源超售的可能性，然而 K8s 的超售建设在对节点上利用的正当排布的根底上。因为目前产品状态节点规格和数量对用户不可见，较难实现。

此外因为用户和云平台的边界产生了变动，GKE Autopiot 在平安模型上与规范集群有十分不同的设计。

在数据面：

• 不反对对节点 SSH 拜访，因为节点的所有权属于 GKE 而非用户
• 默认不反对特权容器，避免入侵者通过容器提前动员攻打。
• 面向 Pod 的云资源受权应用 Workload Identity [ 5]

因为用户利用和云服务治理的零碎服务运行在同一个 VM 外部，而且一个 VM 外部反对多个用户利用，OS 也是一个全功能的 OS。数据面的平安攻击面是偏大的。

管制面的平安架构是通过定制的 Admission Controller 实现的，它会拦挡 K8s API 申请，并执行相干的安全策略（比方，不容许用户操作 kube-system 名空间下零碎级 Pod，限度特权容器等）。这个设计也存在肯定的脆弱性，比方相似往年发现的 安全漏洞 [ 6]。

整体而言 GKE Autopilot 是对 K8s 产品状态的一个翻新，而不是技术和架构改革。它在根本兼容的前提下，从新定义了云和用户运维 K8s 的边界，提供了翻新的计费模式。然而在体验上与 GKE 的托管节点池相比，简化了节点池和弹性策略的配置管理，然而也减少了更多的限度。

注：社区 Cluster Autoscaler 框架存在着一些先天问题。Karpenter 等新的弹性实现升了灵活性、升高了节点治理的复杂性。容器服务相干的工作也在停顿中，联合托管节点池能够给用户更加简略的治理体验。

Serverless Container

基于 Serverless Container 的 K8s 产品代表是 AWS EKS on Fargate，阿里云 ACK on ECI（弹性容器实例）/ASK 以及 Azure AKS with ACI

每一个 Pod 运行在一个独立的平安沙箱之中，采纳虚拟化技术实现资源隔离和平安隔离。此外不再有节点概念。

1. 用户无需关注节点运维和平安修复，升高运维老本；
2. 用户只为 Pod 资源付费；
3. 无需简单的集群容量布局，按需创立利用 Pod；

Serverless Container 能够与经典的 K8s 混合应用，作为弹性资源供应的伎俩，比方 ACK on ECI 或者 EKS on Fargate；或者能够更进一步实现一个齐全意义上的 Serverless Kubernetes，阿里云的 ASK 将更多 K8s 的能力默认通过云服务反对，比方 DNS 服务发现由 PrivateZone 实现，Ingress 路由治理由 ALB 实现，也移除了节点池这些概念。在抉择就义局部灵活性的同时，这样的设计进一步升高了集群的复杂度也推动用户关注点上移。

在平安和稳定性模型上，ACK on ECI/ASK 仍然采纳了责任共担模式，然而数据面责任边界上移。

某种意义上，基于 Serverless Container 的 K8s 在设计上扭转了 Kubernetes 的根底设计理念。

长处

1. 无资源争抢：每个 Pod 运行在一个独立的平安沙箱，也就意味着没有多个利用的互相资源烦扰；
2. 更高安全性：每个平安沙箱只需装置 / 开启利用所需的软件包，比方利用没有应用 NAS 存储，其沙箱中无需加载相应的 nfsd 内核模块，这大大减少了平安攻击面；每个利用运行在独立的平安沙箱中，独占 OS 内核，默认强隔离，Serverless Container 相比传统 OS 容器，大大晋升了安全性。
3. 无资源碎片：每个沙箱依照 Pod 理论申请资源进行调配，缩小了资源碎片的产生，也无需进行频繁的资源重整。
4. 更高的冷启动扩容效率：平安沙箱相比拟创立一个残缺的虚拟机有更多的优化伎俩。
5. 更简略高效的网络：每个 Pod 有独立的 IP，无需对节点进行网络布局，进一步简化了容器网络布局的复杂度。而且缩小了容器网络在虚拟化网络上的损耗。

毛病

1. 不反对与节点相干的 K8s 概念：比方 DaemonSet，Node Port 等。（前面会介绍一些解决之道）
2. 规模化较小：K8s 中 Kubelet，Kube Proxy 这样的节点组件会通过管制循环继续轮询 API Server 状态，实现节点状态与 Pod 实在运行状态、网络、配置的同步。这样的拜访操作在 Serverless Container 环境下会大大收缩。EKS 每个集群最多只反对 1000 个 Fargate，阿里云容器服务通过优化，每集群反对 20000 个工作型实例。然而依然远小于 ACK 集群中反对的 Pod 数量。
3. 额定的资源开销：每个 Serverless Container 因为领有独立的内核，相比传统的 OS 容器会有额定的资源开销，此外 Serverless Container 是自治的还有肯定的治理资源开销。这些都是每个云厂商心愿削减的中央。

Nodeless Kubernetes vs. Serverless Container 比照

• Nodeless 更加重视对兼容性的反对，保留了节点的概念。
• Serverless Container 适当绝大部分保障兼容的前提下，更偏重弹性和简化。

阿里云抉择这条路线的起因，是咱们心愿可能帮忙客户最大化弹性价值，简化用户的弹性体验的同时，也帮忙阿里云可能充分发挥整体弹性计算资源池的老本、规模和技术劣势。

未完待续

本文试着梳理 Kubernetes 所遇到的挑战，设计 Serverless Kubernetes 的起因、挑战和倒退门路。

前面会开展介绍 Serverless Kubernetes 下一步倒退要解决的问题和思考。

参考链接：

*[1]https://www.cgl.ucsf.edu/Outr…

*[2]https://architecturenotes.co/…

*[3]https://wdenniss.com/building…

[4]https://wdenniss.com/autopilo…

[5]https://cloud.google.com/kube…

[6]https://www.paloaltonetworks….