秒级弹性!探索弹性调度与虚拟节点如何迅速响应瞬时算力需求?
作者:吴昆
前言
在前面的文章《弹性调度助力企业灵活应对业务变化,高效管理云上资源》中,我们介绍了阿里云容器服务 ACK 弹性调度为了帮助客户解决在使用云上弹性资源时,面对的“难以差异化控制业务资源使用量,缩容时部分业务 Pod 未释放”等挑战,提供了按照多级资源的优先顺序进行调度,以及按照定义的优先顺序进行缩容的能力。
本文将介绍弹性调度如何使用虚拟节点来满足您的业务弹性需求。
企业在实施应用弹性过程中,弹性速度和弹性位置是重点关注的两个核心指标。
对于追求高可用以及稳定性的企业来说,敏捷的弹性能够在业务流量突增时,保证系统的连续性与稳定性。同时,通过跨多地域部署应用,可以在地域性故障发生时,有效地维持服务的持续可用性。
对于大数据处理任务的企业来说,快速的弹性能够缩短任务执行时间,加快应用的迭代速度。同时,集中部署在单个地域,则可以减少应用之间的网络通信时延,从而进一步提升数据处理效率。
显然,这两个指标对于确保企业业务的稳定高效运行至关重要。
然而,许多企业在面对快速到来的业务流量高峰和日益增长的大数据算力需求时,现行的分钟级自动伸缩节点池的弹性响应已经无法满足需求。并且,通过合理的部署策略,实现预期的弹性位置,也颇具挑战。
为此,阿里云推出弹性容器实例(Elastic Container Instance,ECI),以十秒级的弹性速度,有效应对突发流量的弹性需求。同时,阿里云容器服务 Kubernetes 版(ACK)利用虚拟节点技术实现与 ECI 弹性资源的无缝集成,使得业务能够在集群内灵活动态地调用 ECI 资源,迅速应对弹性挑战。此外,容器服务 ACK 的弹性调度功能在将业务调度到 ECI 上时,还能维持业务的亲和性配置不变,确保应用运行的稳定和高效。
使用虚拟节点实现秒级弹性
为了在 ACK 中使用 ECI,需要在 ACK 集群中安装虚拟节点组件。
在 ACK Pro 版集群中,可以通过组件管理页面部署 ack-virtual-node 组件,该组件默认被托管,不占用 Worker 节点资源。
在 ACK 专有版集群中,可以通过应用市场页面部署 ack-virtual-node 组件,安装成功后会在 kube-system 命名空间下创建一个名为 ack-virtual-node-controller 的 deployment,该 deployment 会运行在您的 Worker 节点上。
安装成功后用户可以通过 kubectl get no 命令在集群中查看到若干虚拟节点,代表虚拟节点安装成功。
虚拟节点安装成功之后,可以使用弹性调度功能配置 ECI 的使用策略,以下是“优先调度 ECS,当 ECS 资源使用完后使用 ECI 资源”的示例。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: test spec: strategy: prefer units: - resource: ecs - resource: eci
配置了以上 ResourcePolicy 之后,在 default 命名空间下的所有 Pod 都将遵循以下的调度规则:优先使用 ECS,ECS 资源用完后使用 ECI。
🔔 需要注意的是: 以上配置会使得 ECS 节点上的抢占功能失效,如果需要同时保持在 ECS 上的抢占能力,请配置 preemptPolicy=BeforeNextUnit,如果需要限定生效的业务范围,请按需配置 selector。
以下是实际使用效果:
首先,提交一个 Deployment,8 个业务 Pod 中仅有 7 个业务 Pod 能够被成功调度。
此时,提交 ResourcePolicy,并将 Deployment 的副本数增加到 10,新的副本将全部运行在 ECI 上。
通过统计业务 Pod 的创建时间以及 startTime,可以看到这里新 Pod 的创建时间在 13 秒,远远低于自动伸缩节点所需的弹性时间。
降低大数据任务通信时延
若您的集群配置了多个可用区的虚拟节点,在默认情况下,ECI Pod 可能会被调度在多个可用区上。如下图,在默认情况下,nginx 被调度到了 C 和 D 两个可用区的 virtual node 上。
对于大数据型应用,配置可用区亲和往往意味着计算 Pod 之间的网络通信代价更小,进而带来更高的吞吐量。通过阿里云弹性调度,您可以通过 Pod 上的节点亲和以及 Pod 亲和限制业务调度的可用区,从而实现 ECS 上的 Pod 与 ECI 上的 Pod 调度在相同的可用区上。
以下是两种在 ECI 上配置相同可用区调度的示例,分别使用了指定可用区调度以及不指定可用区调度两种方式,在以下的两个例子中,已提前提交了 ResourcePolicy:
手动指定可用区
原生 Kubernetes 提供了节点亲和调度语义来控制 Pod 的调度位置,以下的例子中我们指定 nginx 服务仅在可用区 C 上进行调度。您唯一需要进行的修改是在工作负载的 PodTemplate 或 PodSpec 中添加节点亲和约束。
apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-deployment-basic spec: replicas: 9 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - cn-hongkong-c containers: - image: 'nginx:1.7.9' imagePullPolicy: IfNotPresent name: nginx resources: limits: cpu: 1500m requests: cpu: 1500m terminationMessagePath: /dev/termination-log terminationMessagePolicy: File
同样将业务 Pod 扩容到 9,此时能够观察到业务 Pod 全部运行在可用区 C 上,由于集群中 ECS 节点均为可用区 D 上的机器,因此所有业务 Pod 全部运行在 ECI 上。
最优可用区感知调度
为应对大数据计算需求,通常需要部署大量的 Pod,这时候确保 ECI 提供充足的算力资源成为关键。为确保选择到具有充足剩余算力的可用区,可以在指定可用区亲和时使用 Pod 亲和。在 ECI 调度过程中,调度器会参考 ECI 提供的可用区建议,选择一个可用算力更多的可用区,从而实现自动选择更优位置的效果。以下例子中我们将限制 Pod 仅在 ECI 上调度,并通过 Pod 亲和限制 Pod 必须被调度到同一个可用区。
🔔 注: Pod 亲和会使得后续 Pod 与第一个被调度的 Pod 亲和在相同可用区,当采用 ECS+ECI 弹性调度时,由于第一个被调度的 Pod 通常为 ECS Pod,会使得后续 ECI Pod 亲和在 ECS 相同的可用区,此时建议您使用 preferredDuringSchedulingIgnoredDuringExecution。
提交的 ResourcePolicy 为:
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: test spec: strategy: prefer units: - resource: eci
提交的工作负载为:
apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-deployment-basic spec: replicas: 9 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: topology.kubernetes.io/zone containers: - image: 'nginx:1.7.9' imagePullPolicy: IfNotPresent name: nginx resources: limits: cpu: 1500m requests: cpu: 1500m terminationMessagePath: /dev/termination-log terminationMessagePolicy: File
提交后可用发现,此时 Pod 依然均调度在相同的可用区,此时调度到的可用区将会是 ECI 推荐的更优可用区。
保证在线业务高可用
对于在线业务而言,配置业务多可用区部署是保证业务高可用的一种有效手段。通过阿里云弹性调度,您可以通过 Pod 上的拓扑分布约束来实现 ECS 上的 Pod 与 ECI 上的 Pod 遵循相同的拓扑分布约束,从而实现业务的高可用。
以下是一个在 ECI 上配置业务高可用的示例,指定了业务 Pod 在多个可用区上均匀分布,并且在 ECS 资源不足时使用 ECI。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: test spec: strategy: prefer units: - resource: ecs - resource: eci --- apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-deployment-basic spec: replicas: 9 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: topologySpreadConstraints: - labelSelector: matchLabels: app: nginx maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule containers: - image: 'nginx:1.7.9' imagePullPolicy: IfNotPresent name: nginx resources: limits: cpu: 1500m requests: cpu: 1500m terminationMessagePath: /dev/termination-log terminationMessagePolicy: File
提交上述资源清单后,Pod 最终的可用区和节点分布如下,由于可用区 D 上存在三个 ECS 节点,因此最终 Pod 在可用区 D 上存在 5 个 Pod,在可用区 C 上存在 4 个 Pod。能够满足约束中最大倾斜度为 1 的要求。
What's Next
阿里云容器服务 Kubernetes 版(ACK)在标准 K8s 调度框架的基础上扩展了弹性调度功能,致力于提高应用性能和集群整体资源的利用率,保障企业业务的稳定高效运行。
在前期文章《弹性调度助力企业灵活应对业务变化,高效管理云上资源》中,我们已经探讨了如何通过阿里云容器服务 ACK 的弹性调度有效管理各类弹性资源,以帮助企业优化资源配置,实现降本增效。
在本文中,我们又深入解析了 ACK 弹性调度如何与弹性容器实例(ECI)这一关键弹性资源结合,凭借 ECI 快速弹性、秒级计费和即时释放的优势,显著提升企业业务的稳定性和效率。
在即将推出的调度系列文章中,我们将详细介绍如何在 ACK 上管理和调度 AI 任务,助力企业 AI 业务在云端快速落地。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
2023京东零售技术年度盘点
过去一年,围绕开放生态建设、低价心智等主要方向,京东零售技术团队持续攻坚。从百亿补贴、调整流量分配机制为用户提供低价品质好货,到简化商家进驻流程、优化商家体验,带动商家数量增长和平台生态活跃,再到将大模型结合到内部大量业务场景,探索效率提升……快速响应、助力业务的同时,京东零售技术团队继续夯实增强自身能力、探索创新。 我们选取了11项有代表性的技术成果,与大家分享。 供应链创新技术入围行业最高奖项 京东长期致力于通过前沿的数智化技术和算法,提高供应链效率。2023年,智能供应链团队提出并应用了端到端库存管理技术和可解释AI技术,显著提升了补货决策的精准度,实现更快的库存周转和更高效的供应链决策、协同。前者入围2023年管理科学界最高奖项弗兰兹厄德曼奖决赛,后者入围2024年Gartner Power of the Profession供应链流程与技术创新奖决赛,也是该奖项唯一亚洲入围者。 传统的库存补货方法多采用先预测再优化的两步式方案,导致预测和优化阶段割裂。 智能供应链团队提出端到端库存管理技术,基于深度神经网络模型,直接根据原始的历史数据输出最优补货建议,将预测和优化问题一...
- 下一篇
大语言模型推理提速:TensorRT-LLM 高性能推理实践
作者:顾静 TensorRT-LLM 如何提升LLM 模型推理效率 大型语言模型(Large language models,LLM)是基于大量数据进行预训练的超大型深度学习模型。底层转换器是一组神经网络,这些神经网络由具有 self-attention 的编码器和解码器组成。编码器和解码器从一系列文本中提取含义,并理解其中的单词和短语之间的关系。 当前 LLM 模型推理的主要瓶颈是 GPU 显存资源不足。因此,各类加速框架主要集中于降低 GPU 显存峰值和提高 GPU 使用率两大目标。 TensorRT-LLM [ 1] 是 NVIDIA 推出的大语言模型(LLM)推理优化框架。它提供了一组 Python API 用于定义 LLMs,并且使用最新的优化技术将 LLM 模型转换为 TensorRT Engines,推理时直接使用优化后的 TensorRT Engines。 TensorRT-LLM 主要利用以下四项优化技术提升 LLM 模型推理效率。 1. 量化 模型量化技术是通过降低原始模型的精度来减少模型推理时的 GPU 显存使用。TensorRT 支持多种模型的多种精度,以下列举...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Mario游戏-低调大师作品
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能