没有银弹,只有取舍 - Serverless Kubernetes 的思考与征程(一)

本文涉及的产品
函数计算FC,每月免费额度15元,12个月
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: Kubernetes作为云原生计算的基础项目,已经在开发者和企业中获得广泛的支持。然而其自身复杂性和陡峭的学习曲线依然让人望而生畏。在 CNCF 2020年度调研报告中,在Kubernetes技术落地过程中面临最大的挑战就是复杂性。

Kubernetes作为云原生计算的基础项目,已经在开发者和企业中获得广泛的支持。然而其自身复杂性和陡峭的学习曲线依然让人望而生畏。在 CNCF 2020年度调研报告中,在Kubernetes技术落地过程中面临最大的挑战就是复杂性。

IBM大型机之父 Fred Brooks 著名的论文No Silver Bullet[1],软件系统中的复杂性可以分为本质复杂性 (essential complexity) 和附属复杂性 (accidental complexity) 。本质复杂性是构建系统过程中不可避免的复杂性。附属复杂性则是任何非必要的复杂性,比如由于设计失误或者工具不当等引入的复杂性。附属复杂性会随着工具的改善而逐渐解决,而本质性的困难难以解决。

Kubernetes的本质复杂性与附属复杂性到底有什么?我们应该如何应对?


Kubernetes的复杂性挑战

分布式系统的复杂性

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

image.png

作为分布式集群管理系统,Kubernetes 自身要面临着众多的复杂性,比如,节点宕机,网络抖动、组件版本不一致等等。此外 K8s 还要能够用合理的抽象向上层应用屏蔽底层的不确定性、差异性和复杂性。

资源调度的复杂性

如何高效地利用计算资源,降低计算成本是资源调度的重要目标。

image.png

Kubernetes作为一个分布式集群管理系统,它的一个重要目标是:将适合的资源分配给适合的应用,满足对应用的QoS要求和获得最优的资源使用效率。
然而,分布式系统的资源调度有着非常高的复杂性。主要挑战包括:

  • 对多形态异构资源的支持,今天应用所需的计算资源不只是简单的CPU,内存,存储等,而且包括多样化的加速设备,比如GPU、RDMA等。而且,为了考虑到计算效率的最优化,要考虑到计算资源之间的拓扑,比如CPU core在numa节点间的布局,GPU设备间NVLink拓扑等。此外随着高性能网络的的发展,GPU池化、内存池化等相继出现,给资源调度带来更多的动态性和复杂性。
  • 对多样化的工作负载的支持。从Stateless的Web应用、微服务应用,到有状态的中间件和数据应用,再到AI、大数据、HPC等计算任务类应用。他们对资源申请和使用的方式有不同的需求。
  • 对多维度的业务需求的支持。调度系统在满足应用对资源的需求的同时,也要满足不同的业务需求,比如计算效率,优先级,稳定性,利用率等等。

调度系统需要在多样化的资源和多样化的约束之间进行动态决策,整体挑战很高。而且随着时间推移,集群中逐渐出现负载不均衡的现象,资源热点会导致。如何持续调整集群负载

基础设施环境的多样性

不同的环境,比如,线下数据中心与云,不同的云供应商之间,他们在基础设施能力上有着很多差异。类似单机操作系统要能支持不同的硬件设备,一个分布式集群系统要向下屏蔽基础设施的差异,并向上层应用提供一致的编程接口和体验,帮助应用在不同环境中迁移。


Kubernetes 的解决之道

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

控制循环(Control loops)

Kubernetes架构的核心就是就是控制循环 (control loops),也是一个典型的"负反馈"控制系统。当控制器观察到期望状态与当前状态存在不一致,就会持续调整资源,让当前状态趋近于期望状态。

基于控制循环,K8s实现了完整的自动化容器编排系统。比如,节点宕机后自动迁移应用,修改应用副本数就可以实现应用的扩缩容,等等。

image.png

所有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 组件的生命周期,其他节点运维依然需要自己负责。这意味着,在运维责任、安全性、稳定性方面,云和客户采用如下图的责任共担模型。

image.png

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

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


Kubernetes 节点遗留的复杂性

ubernetes的数据面是由节点组成,节点可以是虚拟机,裸金属服务器或者物理机。K8s 控制面动态调度Pod到节点进行执行。这样架构非常自然,但也有一些天然的缺点

  1. Pod与节点生命周期不同步:
  • 节点就绪后,才能进行Pod调度,降低了弹性的效率
  • 节点维护/下线/缩容,需要迁移所有节点上的Pod,极大增加了弹性的复杂性。
  1. 同节点内部Pod共享资源:
  • 共享内核,扩大了攻击面。用OS提供的namespace, seccomp等机制无法实现很好的安全隔离。
  • 共享资源,产生相互影响。CPU,内存,I/O,临时存储容量等,有些无法通过cgroup进行很好的资源隔离。
  1. 容器网络与节点网络独立管理:
  • 要为节点,容器、Service 独立配置 CIDR
  • 在跨多个可用区、混合云、或者企业网络拓扑编排等较复杂场景下,大多数客户缺乏足够的能力实现合理的网络规划。
  1. 容量规划与弹性配置复杂
  • 需要用户管理节点池,选择合适的节点规格进行扩容,优化整体资源利用率,增加了复杂性。


Serverless Kubernetes 的理想

们希望对 Kubernetes 进行 radical simplification,实现几个关键的

  1. 免运维 - 用户无需对K8s控制面和数据面进行运维。让用户聚焦业务应用而非底层基础设施管理
  2. 按需付费 - 无需预留资源,按应用实际资源使用量费。
  3. 简化容量管理 - 让应用可以弹性伸缩,无需关注集群资源的调整。


Serverless Kubernetes 的 流派

现Serverless Kubernetes的目标,不同厂商选择了不同的路径。

Nodeless Kubernetes

Nodeless Kubernetes 的代表就是 Google GKE Autopilot。这个方案非常易于理解,它没有改变Kubernetes的部署架构,而是将工作节点的运维与集群容量管理下沉到基础设施负责。

image.png

  1. GKE Autopilot集群节点池/节点对用户不可见,也无法登录进行运维。
  2. 用户为应用申请的资源付费,而不是为底层资源进行付费。
  3. 用户无需进行容量管理。GKE Autopilot 的调度和计费单位是Pod,但是扩容的单位仍然是节点实例。当用户部署/扩容应用时,GKE 会先尝试调度到已有节点中;如果资源不足,GKE服务根据 Pending Pod 来动态创建相应节点池/节点来适配应用;同理当应用删除/缩容时,GKE服务也会根据情况缩容节点池来释放实际使用资源。

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

image.png

详细信息可以参考[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实现,也移除了节点池这些概念。在选择牺牲部分灵活性的同时,这样的设计进一步降低了集群的复杂度也推动用户关注点上移。

image.png

在安全和稳定性模型上,ACK on ECI/ASK依然采用了责任共担模式,但是数据面责任边界上移。

image.png

某种意义上,基于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 对比

image.png

  • 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/


作者 | 易立(微垣)

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

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1月前
|
Kubernetes 前端开发 Serverless
Serverless 应用引擎产品使用合集之如何调用Kubernetes集群内服务
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
2月前
|
Kubernetes 安全 Serverless
破茧成蝶 - Serverless Kubernetes 的思考与征程(二)
本文将针对 Serverless Container 技术的特殊性,分享其对 Kubernetes 的架构影响,以及阿里云在Serverless Kubernetes方面架构选择。
189 1
|
2月前
|
人工智能 监控 Serverless
如何基于ACK Serverless快速部署AI推理服务
通过上述步骤,可以在ACK Serverless上快速部署AI推理服务,实现高可用、弹性扩展的服务架构。
245 1
|
2月前
|
弹性计算 Kubernetes Serverless
Serverless 版 ACK Serverless 是
阿里云容器服务 Serverless 版 ACK Serverless 是一种基于弹性计算基础架构的容器服务,它兼容 Kubernetes 生态,允许用户在无需管理和维护集群的情况下,快速创建和部署容器化应用程序。ACK Serverless 根据应用程序实际使用的 CPU 和内存资源量进行按需付费,使您能够更专注于应用程序本身,而无需担心底层基础设施。
139 2
|
2月前
|
机器学习/深度学习 运维 安全
阿里云 ACK One Serverless Argo 助力深势科技构建高效任务平台
阿里云 ACK One Serverless Argo 助力深势科技构建高效任务平台
101331 8
|
13天前
|
运维 Serverless 应用服务中间件
Serverless 应用引擎产品使用合集之关于OSS映射目录的大小限制,如何可以跳过
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
Serverless 应用引擎产品使用合集之关于OSS映射目录的大小限制,如何可以跳过
|
11天前
|
分布式计算 Hadoop Serverless
数据处理的艺术:EMR Serverless Spark实践及应用体验
阿里云EMR Serverless Spark是基于Spark的全托管大数据处理平台,融合云原生弹性与自动化,提供任务全生命周期管理,让数据工程师专注数据分析。它内置高性能Fusion Engine,性能比开源Spark提升200%,并有成本优化的Celeborn服务。支持计算存储分离、OSS-HDFS兼容、DLF元数据管理,实现一站式的开发体验和Serverless资源管理。适用于数据报表、科学项目等场景,简化开发与运维流程。用户可通过阿里云控制台快速配置和体验EMR Serverless Spark服务。
|
13天前
|
运维 Serverless API
Serverless 应用引擎产品使用合集之通过 API 调用 /tagger/v1/interrogate 时,出现unsupported protocol scheme "" 错误,如何处理
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
13天前
|
缓存 运维 监控
Serverless 应用引擎产品使用合集之在使用函数计算 FC 部署 stable-diffusion 应用时,选了 tagger 扩展插件却拿不到提示词,还报错“Error”,是什么原因
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
13天前
|
运维 监控 Serverless
Serverless 应用引擎产品使用合集之需要上传多个文件,该如何处理
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。

热门文章

最新文章