作者：易立(微垣)

Kubernetes 作为云原生核算的基础项目，已经在开发者和企业中取得广泛的支撑。可是其本身复杂性和陡峭的学习曲线依然让人望而生畏。在 CNCF 2020 年度调研陈述中，在 Kubernetes 技术落地过程中面对最大的应战便是复杂性。

IBM大型机之父 Fred Brooks 闻名的论文No Silver Bullet [ 1] ，软件体系中的复杂性可以分为实质复杂性 (essential complexity) 和隶属复杂性 (accidental complexity) 。实质复杂性是构建体系过程中不行避免的复杂性。隶属复杂性则是任何非必要的复杂性，比方因为规划失误或许工具不妥等引进的复杂性。隶属复杂性会跟着工具的改进而逐渐处理，而实质性的困难难以处理。

Kubernetes 的实质复杂性与隶属复杂性到底有什么？咱们应该怎么应对？

Kubernetes的复杂性应战

分布式体系的复杂性

在上世纪 90 时代，Sun 的几位工程师提出了分布式核算的八个错误 [ 2] ，这也解释了为什么构建可靠的分布式体系是一项艰巨的工程应战。

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

作为分布式集群办理体系，Kubernetes 本身要面对着众多的复杂性，比方，节点宕机，网络抖动、组件版别不共同等等。此外 K8s 还要可以用合理的笼统向上层运用屏蔽底层的不确定性、差异性和复杂性。

资源调度的复杂性

怎么高效有利地势用核算资源，下降核算成本是资源调度的重要方针。

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

Kubernetes 作为一个分布式集群办理体系，它的一个重要方针是：将适合的资源分配给适合的运用，满意对运用的 QoS 要求和取得最优的资源运用功率。

可是，分布式体系的资源调度有着十分高的复杂性。首要应战包括：

  • 对多形状异构资源的支撑，今天运用所需的核算资源不仅仅简略的 CPU，内存，存储等，而且包括多样化的加速设备，比方 GPU、RDMA 等。而且，为了考虑到核算功率的最优化，要考虑到核算资源之间的拓扑，比方 CPU core 在 numa 节点间的布局，GPU 设备间 NVLink 拓扑等。此外跟着高性能网络的的开展，GPU 池化、内存池化等相继出现，给资源调度带来更多的动态性和复杂性。
  • 对多样化的作业负载的支撑。从 Stateless 的 Web 运用、微服务运用，到有状况的中间件和数据运用，再到 AI、大数据、HPC 等核算使命类运用。他们对资源请求和运用的方式有不同的需求。
  • 对多维度的事务需求的支撑。调度体系在满意运用对资源的需求的一起，也要满意不同的事务需求，比方核算功率，优先级，稳定性，利用率等等。

调度体系需求在多样化的资源和多样化的束缚之间进行动态决议计划，全体应战很高。而且跟着时间推移，集群中逐渐出现负载不均衡的现象，资源热点会导致。怎么继续调整集群负载

基础设施环境的多样性

不同的环境，比方，线下数据中心与云，不同的云供货商之间，他们在基础设施才能上有着很多差异。相似单机操作体系要能支撑不同的硬件设备，一个分布式集群体系要向下屏蔽基础设施的差异，并向上层运用供给共同的编程接口和体会，协助运用在不同环境中搬迁。

Kubernetes 的处理之道

Kubernetes做出了几个重要的架构挑选，大大缓解了分布式集群办理体系的隶属复杂性。

操控循环（Control loops）

Kubernetes 架构的中心便是便是操控循环 （control loops），也是一个典型的”负反馈”操控体系。当操控器观察到期望状况与当时状况存在不共同，就会继续调整资源，让当时状况趋近于期望状况。

根据操控循环，K8s 完成了完好的自动化容器编列体系。比方，节点宕机后自动搬迁运用，修改运用副本数就可以完成运用的扩缩容，等等。

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

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

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

阿里云、Google、AWS 的容器产品也供给了保管节点池，可以完成自动化的节点组件晋级，CVE 修复，故障自愈等才能，将日常节点的运维复杂性留给云渠道，将简略留给客户。

云原生核算基金会 (CNCF) 2022 年度调查显现，79%受访者会运用云渠道供给的 Kubernetes 服务。在阿里云上挨近 80%的 K8s 用户也已采用阿里云容器服务 ACK。

Kubernetes 节点遗留的复杂性

Kubernetes 的数据面是由节点组成，节点可所以虚拟机，裸金属服务器或许物理机。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 的布置架构，而是将作业节点的运维与集群容量办理下沉到基础设施担任。

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

  1. GKE Autopilot 集群节点池/节点对用户不行见，也无法登录进行运维。
  2. 用户为运用请求的资源付费，而不是为底层资源进行付费。
  3. 用户无需进行容量办理。GKE Autopilot 的调度和计费单位是 Pod，可是扩容的单位依然是节点实例。当用户布置/扩容运用时，GKE 会先尝试调度到已有节点中；假如资源不足，GKE 服务根据 Pending Pod 来动态创立相应节点池/节点来适配运用；同理当运用删除/缩容时，GKE 服务也会根据状况缩容节点池来释放实践运用资源。

注：GKE Autopilot 根据节点池进行弹性，每个节点池中实例标准保持共同，整个节点创立流程如下图所示。

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

详细信息可以参考文末 [ 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 完成，也移除了节点池这些概念。在挑选牺牲部分灵活性的一起，这样的规划进一步下降了集群的复杂度也推进用户重视点上移。

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

在安全和稳定性模型上，ACK on ECI/ASK 依然采用了职责共担形式，可是数据面职责鸿沟上移。

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

某种意义上，根据 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 Kubernetesvs. Serverless Container 比照

没有银弹，只有取舍 - Serverless Kubernetes 的思考与征程（一）

  • Nodeless 愈加注重对兼容性的支撑，保留了节点的概念。
  • Serverless Container 恰当绝大部分保证兼容的前提下，更偏重弹性和简化。

阿里云挑选这条道路的原因，是咱们期望可以协助客户最大化弹性价值，简化用户的弹性体会的一起，也协助阿里云可以充分发挥全体弹性核算资源池的成本、规划和技术优势。

未完待续

本文试着整理 Kubernetes 所遇到的应战，规划 Serverless Kubernetes的原因、应战和开展途径。

后边会展开介绍 Serverless Kubernetes 下一步开展要处理的问题和考虑。

参考链接：

*[1]www.cgl.ucsf.edu/Outreach/pc…

*[2]architecturenotes.co/fallacies-o…

*[3]wdenniss.com/building-gk…

[4]wdenniss.com/autopilot-c…

[5]cloud.google.com/kubernetes-…

[6]www.paloaltonetworks.com/blog/2022/0…