没有银弹，只有取舍 - 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/Outreach/pc204/NoSilverBullet.html

[2]https://architecturenotes.co/fallacies-of-distributed-systems/

[3]https://wdenniss.com/building-gke-autopilot

[4]https://wdenniss.com/autopilot-capacity-reservation

[5]https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity

[6]https://www.paloaltonetworks.com/blog/2022/03/gke-autopilot-vulnerabilities/