《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.2 游戏容器化部署最佳实践(4)

简介: 《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.2 游戏容器化部署最佳实践(4)

《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.2 游戏容器化部署最佳实践(3) https://developer.aliyun.com/article/1231999?groupCode=supportservice




使用弹性负载表达Deployment类型应用如下


# 弹性负载定义。
apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: ElasticWorkload
metadata:
 name: elasticworkload-sample
spec:
 sourceTarget:
 name: nginx-deployment-basic
 kind: Deployment
 apiVersion: apps/v1
 min: 2
 max: 4
 replicas: 6
 elasticUnit:
 - name: virtual-kubelet
 labels:
 alibabacloud.com/eci: "true"
 # min: 0 每个单元也可以指定自己的上下限。
 # max: 10


这个场景的弹性负载定义,弹性负载的使用方式与HPA类似,通过外部挂载的方式使用,对原有的业务无侵入。


弹性负载主要分为两个部分:


SourceTarget部分主要定义原始负载的类型、副本数目可变化的范围。

elasticUnit部分是一个数组,定义弹性单元的调度策略,如果有多个弹性单

元,则按照模板的顺序定义。

在上面的实例中,SourceTarget的副本上下限位2~4,表示当ElasticWorkload

的replicas为2~4个副本时,会分配到sourceTarget,当超过4个副本时,会分配到弹性单元virtual-kubelet即ECI上,而在弹性单元virtual-kubelet中可以定义这个单元所独有的调度策略(包括不限于nodeSelector,亲和性等等)。


image.png


弹性负载会监听原始负载,并根据弹性单元设定的调度策略,克隆并生成弹性单元的负载。根据弹性负载中副本的变化,动态的分配原始负载和弹性单元上面的副本数目。


使用ack-autoscaling-placeholder实现容器秒级伸缩


ack-autoscaling-placeholder组件可以为集群的自动扩展提供了缓冲区,它适

用于工作负载需要快速启动而无需考虑节点资源不足的使用场景。使用ack-autoscaling-placeholder可以实现容器秒级伸缩,尽量提升扩容过程中的速度。它实现的原理就是使用优先级非常低(负数)的占位容器来超额配置,以保留其他Pod可以使用的资源。如果集群没有可用的资源,真正的工作负载也会将占位容器所占用的资源抢占,实现快速启动,然后结合同时使用Cluster-Autoscaler,迫使集群进行节点维度的扩展。


该功能需要允许一定的资源可冗余,实现资源抢占时同时通过CA触发节点扩

容,双向进行,快速触发。


前提需要部署工作负载的PriorityClass,启动占位Pods


apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: high-priority
value: 1000000 #配置优先级。
globalDefault: false
description: "This priority class should be used for XYZ service pods only."
nameOverride: ""
fullnameOverride: ""
##
priorityClassDefault:
 enabled: true
 name: default-priority-class
 value: -1
##
deployments:
 - name: ack-place-holder
 replicaCount: 1
 containers:
 - name: placeholder
 image: registry-vpc.cn-shenzhen.aliyuncs.com/acs/pause:3.1
 pullPolicy: IfNotPresent
 resources:
 requests:
 cpu: 4 #资源占位4C8G
 memory: 8 
 imagePullSecrets: {}
 annotations: {}
 nodeSelector: #节点选择
 demo: "yes" 
 tolerations: []
 affiffiffinity: {}
 labels: {}




《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.2 游戏容器化部署最佳实践(5) https://developer.aliyun.com/article/1231995?groupCode=supportservice

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
0
0
0
83
分享
相关文章
云原生信息提取系统:容器化流程与CI/CD集成实践
本文介绍如何通过工程化手段解决数据提取任务中的稳定性与部署难题。结合 Scrapy、Docker、代理中间件与 CI/CD 工具,构建可自动运行、持续迭代的云原生信息提取系统,实现结构化数据采集与标准化交付。
云原生信息提取系统:容器化流程与CI/CD集成实践
容器化AI模型的持续集成与持续交付(CI/CD):自动化模型更新与部署
在前几篇文章中,我们探讨了容器化AI模型的部署、监控、弹性伸缩及安全防护。为加速模型迭代以适应新数据和业务需求,需实现容器化AI模型的持续集成与持续交付(CI/CD)。CI/CD通过自动化构建、测试和部署流程,提高模型更新速度和质量,降低部署风险,增强团队协作。使用Jenkins和Kubernetes可构建高效CI/CD流水线,自动化模型开发和部署,确保环境一致性并提升整体效率。
【赵渝强老师】数据库不适合Docker容器化部署的原因
本文介绍了在Docker中部署MySQL数据库并实现数据持久化的方法,同时分析了数据库不适合容器化的原因。通过具体步骤演示如何拉取镜像、创建持久化目录及启动容器,确保数据安全存储。然而,由于数据安全性、硬件资源争用、网络带宽限制及额外隔离层等问题,数据库服务并不完全适合Docker容器化部署。文中还提到数据库一旦部署通常无需频繁升级,与Docker易于重构和重新部署的特点不符。
224 18
【赵渝强老师】数据库不适合Docker容器化部署的原因
在Docker容器中部署GitLab服务器的步骤(面向Ubuntu 16.04)
现在,你已经成功地在Docker上部署了GitLab。这就是我们在星际中的壮举,轻松如同土豆一样简单!星际旅行结束,靠岸,打开舱门,迎接全新的代码时代。Prepare to code, astronaut!
159 12
Qwen3 大模型在阿里云容器服务上的极简部署教程
通义千问 Qwen3 是 Qwen 系列最新推出的首个混合推理模型,其在代码、数学、通用能力等基准测试中,与 DeepSeek-R1、o1、o3-mini、Grok-3 和 Gemini-2.5-Pro 等顶级模型相比,表现出极具竞争力的结果。
领取永久免费的ClawCloud云服务容器部署Alist网盘
领取永久免费的ClawCloud云服务容器部署Alist网盘,这是一款类似于 Vercel 和 Netlify 的在线开发平台,专为开发者和个人用户设计。如 Alist、Dify、frp 等,无需复杂的配置或高昂的成本。目前,平台提供永久免费的 5 刀/月额度,只需绑定一个注册超过 180 天的 GitHub 账号即可享受。
1605 10
ACK Gateway with Inference Extension:优化多机分布式大模型推理服务实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with Inference Extension组件,在Kubernetes环境中为多机分布式部署的LLM推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
容器化爬虫部署:基于K8s的任务调度与自动扩缩容设计
随着业务复杂度提升,传统定时任务和手工扩缩容难以满足高并发与实时性需求。本文对比两种基于 Kubernetes 的爬虫调度与扩缩容方案:CronJob+HPA 和 KEDA。从调度灵活性、扩缩容粒度、实现难度等维度分析,并提供 YAML+Python 示例。方案 A(CronJob+HPA)适合固定定时任务,配置简单;方案 B(KEDA)支持事件驱动,适合高并发与异步触发场景。根据实际需求可混合使用,优化资源利用与效率。
123 4

热门文章

最新文章

推荐镜像

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等