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 节点遗留的复杂性

ubernetes的数据面是由节点组成，节点可以是虚拟机，裸金属服务器或者物理机。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/

作者 | 易立(微垣)

来源 | 阿里云开发者公众号