ParallelClusterMaker：用CLI高效管理AWS HPC集群栈

如果你有过在 AWS 上搭建高性能计算集群的经历大概率会碰到这样的尴尬单台 EC2 实例可以五分钟启动但一个能稳定跑 MPI 作业、带共享存储、支持 Slurm 调度的 HPC 集群往往要折腾半天。需要处理网络、安全组、IAM 角色、文件系统挂载、节点启动脚本……每一步都在控制台点击 → 等待 → 报错 → 排查 → 重试里循环。本文要聊的 ParallelClusterMaker 正是为了解决这个问题而出现的一类 CLI 工具包。它的核心思路并不复杂把 AWS ParallelCluster 集群栈的生命周期管理从“零散的手工操作”收敛成“一组可重复执行的命令”。我的判断很明确对于需要频繁创建、更新、销毁 HPC 集群的团队这类工具带来的价值不只是省时间更重要的是把环境一致性、配置可追溯、操作可审计这几件事真正落地。围绕这个工具我会从概念、环境准备、核心流程、真实示例到常见故障完整地讲清楚它在实际项目中应该怎么用、有哪些坑、如何和现有 CI/CD 流程结合。如果你正在犹豫要不要把 ParallelCluster 纳入团队的基础设施体系这篇文章可以帮你建立一个清晰的决策框架。1. 这篇文章真正要解决的问题先回答一个最直接的问题AWS 官方已经提供了pcluster命令为什么还需要一个额外的 ParallelClusterMaker答案是pcluster解决的是“单集群操作”的问题而实际团队每天面对的是“多集群、多环境、多版本配置”的问题。举一个很常见的场景。你的团队同时维护三个集群一个是开发环境用的低成本小集群一个是生产环境跑仿真任务的中型集群还有一个是临时创建的 GPU 集群用于深度学习训练。每个集群都有自己的配置文件、子网、安全组、实例规格起始数量。如果没有一层统一的封装每个成员要么手动记住不同命令要么在脚本里复制粘贴pcluster create-cluster的冗长参数。任何一个参数抄错都会直接导致创建失败。ParallelClusterMaker 这类 CLI toolkit 的核心价值就是把“集群栈”当作一个可管理对象来对待。它通常会在原生pcluster命令之上提供更贴近团队工作流的命令比如校验配置文件的完整性和兼容性一键创建带统一命名规范的集群栈查看集群栈的当前状态和关键资源更新/销毁集群栈并清理关联资源。换句话说这篇文章真正要解决的问题是当你所在的团队需要使用 AWS ParallelCluster 构建 HPC 环境时如何通过一个 CLI 工具统一管理多个集群栈让环境的创建从“人为操作”变成“确定性流程”。适合阅读这篇文章的读者有三类负责 HPC 平台的运维工程师需要管理多个集群科研计算或仿真团队的开发人员希望快速申请/释放集群资源正在评估 HPC 基础设施方案的架构师需要了解工具链选型。2. AWS ParallelCluster 与 ParallelClusterMaker 的核心概念在进入操作之前先把几个关键概念理清楚否则后面很容易混淆。2.1 AWS ParallelCluster 是什么AWS ParallelCluster 是 AWS 官方的开源 HPC 集群管理工具。它允许用户通过一份配置文件定义计算节点、登录节点、调度器如 Slurm、共享文件系统、网络等资源然后自动在 AWS 上创建对应的云资源栈。底层来看ParallelCluster 依赖 AWS CloudFormation。你提交一份配置文件后它会把配置翻译成 CloudFormation 模板再由 CloudFormation 完成 EC2 实例、安全组、IAM 角色、EBS/EFS 存储等资源的创建。这带来一个关键特性整个集群是“可声明、可重建”的。官方命令行工具是pcluster常用的操作包括pcluster create-cluster创建集群pcluster describe-cluster查看集群详情pcluster list-clusters列出所有集群pcluster update-cluster更新集群pcluster delete-cluster删除集群。这些命令本身已经很好用但面对多团队、多环境时仍然需要一层更贴近业务场景的封装。2.2 什么是“集群栈”在 AWS CloudFormation 的语境里“栈”指一次部署创建出来的资源集合。一个 ParallelCluster 集群栈通常包括资源类型作用HeadNode 登录节点用户提交作业、管理集群的入口ComputeNode 计算节点实际运行 MPI/仿真/训练任务的实例调度器Slurm 等管理作业队列和资源分配共享存储EFS/FSx为所有节点提供统一的数据视图安全组与 IAM 角色控制网络访问和云资源权限理解了这一点你就能明白为什么用“管理 ParallelCluster 栈”而不是“管理集群”来描述工具的功能。因为工具不仅关心集群运行状态还需要管理集群背后整组云资源的创建、更新和清理。2.3 ParallelClusterMaker 的定位ParallelClusterMaker 本质上是一个面向 ParallelCluster 栈的 CLI toolkit。它不会替代pcluster而是建立在pcluster之上通过以下方式增加价值提供更简洁的项目级命令隐藏重复参数强制或推荐统一的目录结构和配置文件命名内置前置检查减少因配置错误导致的创建失败方便与 CI/CD 脚本集成。这种“官方工具 团队封装”的组合在基础设施领域非常常见。就好比 Kubernetes 有kubectl但很多平台团队仍然会封装一层自己的 CLI目的是把最佳实践固化到命令里而不是依赖每个成员自觉遵守。3. 为什么需要 CLI 工具管理 ParallelCluster 栈这一节从痛点出发解释这类工具存在的合理性。3.1 控制台方式的痛点如果你只在 AWS 控制台上手动创建 HPC 集群很快会遇到几个问题操作不可复现每点一次鼠标都可能有差异甚至同一个配置两次点击得到的结果也可能不同。过程不可审计谁知道哪个人在什么时候改了什么参数回滚困难配置错了不知道应该撤销哪个操作。效率低一个集群创建过程可能持续 10 到 20 分钟如果手工等待和检查会占用大量时间。控制台适合试用和学习但完全不适合生产环境。3.2 原生 CLI 的局限原生pcluster已经解决了“可复现”的问题因为配置是文件操作是命令。但它仍然有一个隐性门槛每个使用的人都需要掌握完整的命令参数、配置文件语法、错误日志查看方式。假设你要创建十个环境每个环境只是实例规格不同那么你需要复制十份配置文件并在命令中小心区分。原生 CLI 并不会帮你管理“这十个环境分别在哪份配置里”也不会帮你检查配置文件中是否写了不存在的子网 ID。这些工作需要额外的脚本或工具来弥补。ParallelClusterMaker 这类 CLI toolkit 的价值正是在这个环节体现出来。3.3 ParallelClusterMaker 的价值从架构层面看ParallelClusterMaker 的价值不是“造一个新轮子”而是把常用的最佳实践固化成一整套可复用的流程。具体来说降低新成员上手成本。新成员只需要按约定放好配置文件执行一两行命令而不是阅读一整套 ParallelCluster 官方文档再开始实践。提高配置的规范性。工具可以对配置文件做预校验发现子网、安全组、AMI 等资源不存在时提前报错而不是等 CloudFormation 创建到一半才失败。方便自动化。CLI 命令天然适合嵌入到 Shell 脚本、CI 流水线、定时任务中。团队可以实现“下班后自动销毁测试集群”“每天上班前自动拉起开发集群”这类需求。当然这也意味着团队需要维护工具本身。如果你的团队只有一个固定集群、几乎不变化那么引入这种工具反而是过度设计。这是需要权衡的地方。4. 环境准备与前置条件下面进入实操部分。在开始使用 ParallelClusterMaker 前需要完成以下准备。4.1 AWS 账号、区域与 IAM 权限这是所有步骤的前提。建议使用独立的 IAM 用户或角色而不是长期使用根账号。关于权限需要遵循最小权限原则ParallelClusterMaker 或底层pcluster通常需要以下权限EC2创建、查询、终止实例IAM创建实例角色和策略ParallelCluster 会自动创建相关角色CloudFormation创建、更新、删除栈EFS/FSx创建和管理共享文件系统S3如果配置了自定义脚本或模板需要读写权限。注意IAM 策略的具体资源范围应该按实际使用限制。比如生产环境只允许指定 VPC 和子网中创建资源避免权限过大带来安全风险。4.2 本地环境要求ParallelClusterMaker 的安装方式取决于项目自身的实现。从常见的 CLI toolkit 项目惯例看不外乎两种通过pip安装如果是 Python 项目从 GitHub Clone 后本地安装或直接执行脚本。因此本地环境通常需要一个支持 Bash 的终端Linux、macOS或者 Windows 上的 WSLPython 3.8 以上版本以项目实际要求为准已安装并配置好 AWS CLI v2网络可以正常访问 AWS API 和 GitHub。下面是安装工具的示意步骤具体命令以项目 README 为准# 示例通过 git 克隆项目假设项目托管在 GitHub git clone https://github.com/your-org/parallelclustermaker.git cd parallelclustermaker # 创建并激活 Python 虚拟环境避免污染系统环境 python3 -m venv .venv source .venv/bin/activate # 安装依赖 pip install -r requirements.txt # 如果工具提供了 setup.py / pyproject.toml也可以直接安装为可执行命令 pip install -e .4.3 验证 AWS CLI 配置无论使用什么工具最终它都要调用 AWS API。因此第一步是确认aws命令已经能正常工作aws sts get-caller-identity预期输出类似{ UserId: AIDAXXXXXXXXXXXXXXXX, Account: 123456789012, Arn: arn:aws:iam::123456789012:user/your-user }如果这一步失败先检查~/.aws/credentials和~/.aws/config文件确认密钥、区域和输出格式配置正确。4.4 配置 AWS ParallelClusterParallelCluster 本身需要初始化。以官方工具为例可以通过命令初始化配置存储具体初始化方式可能因版本而异3.x 系列通常使用pcluster configure或手动准备配置文件pcluster configure这条命令会引导你设置区域、S3 bucket用于存放集群配置和日志、VPC 和子网等信息。完成之后pcluster就有了基本的运行环境。需要注意的是ParallelClusterMaker 可能会在更高层接管这些配置。如果它已经内置了“自动选择区域和子网”的逻辑你就不需要单独运行pcluster configure但这要求工具本身有足够的 AWS 权限来列举对应资源。5. 核心流程拆解一个 HPC 集群的完整生命周期无论工具的命令细节是什么管理一个 ParallelCluster 栈的完整生命周期通常包含六个阶段。下面按阶段拆解并说明每一步的关键点和风险。5.1 第一步准备集群配置文件配置文件是整个流程的核心。一个典型的 ParallelCluster 配置文件YAML 格式至少包含以下部分Region集群部署区域Image节点使用的系统镜像可以是官方 AMI 或自定义 AMIHeadNode登录节点的实例类型、网络配置Scheduling调度器类型如 Slurm计算队列和计算资源的规格SharedStorage共享存储的挂载配置。这一步的难点不是写配置而是理解每个配置项对成本和性能的影响。例如计算节点的MinCount和MaxCount决定了集群的弹性范围MinCount太高会浪费钱MaxCount太小会在作业高峰时排队。ParallelClusterMaker 在这里通常会提供配置模板或校验命令帮助你提前发现错误。5.2 第二步校验配置在真正创建集群之前强烈建议先校验配置。ParallelCluster 原生命令中可以通过pcluster dry-run或pcluster validate-config类命令检查配置文件的正确性具体命令取决于版本。ParallelClusterMaker 一般会把这类检查包装成更简单的命令比如parallelclustermaker validate --cluster demo这条命令会读取约定目录下的配置文件执行语法检查和资源存在性检查然后输出校验结果。如果子网 ID 写错、AMI 不存在、安全组跨 VPC 等问题都会在这一步被发现而不是等到 CloudFormation 创建到一半才报错。这一步的价值在于把故障提前到成本最低的阶段。一个 CloudFormation 创建失败通常会留下部分资源需要人工清理浪费的时间和金钱都更多。5.3 第三步创建集群配置校验通过后就可以创建集群了。底层仍然调用 ParallelCluster 的创建逻辑但工具层会处理命名、标签、日志路径等细节。parallelclustermaker create --cluster demo创建过程通常需要 10 到 20 分钟。工具可能会轮询状态并输出进度也可能只是提交后返回。如果工具支持阻塞模式建议等待结果如果只返回任务 ID则需要通过后续的状态命令确认。注意创建过程中最容易出现的问题包括IAM 权限不足无法创建某些资源子网没有足够的 IP 地址所选 AMI 与实例类型不兼容共享存储如 EFS创建超时。5.4 第四步查看状态创建提交后需要随时查看集群栈的状态。状态通常包括CREATE_IN_PROGRESS、CREATE_COMPLETE、UPDATE_IN_PROGRESS、UPDATE_COMPLETE、DELETE_IN_PROGRESS、DELETE_COMPLETE和CREATE_FAILED等。parallelclustermaker status --cluster demo如果工具支持还可以输出更详细的信息如 HeadNode 的公网 IP、计算节点数量、存储 ID 等。5.5 第五步日常运维与更新集群运行后经常需要调整配置。比如计算节点数量要临时扩容、实例类型要升级、AMI 要更新补丁。这些操作对应 ParallelCluster 的更新流程。ParallelClusterMaker 会有对应的更新命令例如parallelclustermaker update --cluster demo --config path/to/new-config.yml这里有一个容易被忽略的坑ParallelCluster 的更新不是所有配置项都能在线完成。某些变更比如更换调度器、修改 VPC 子网可能要求删除集群后重建。工具可以在更新前做兼容性判断减少失败概率但使用的人也应该清楚哪些参数可以“热更新”哪些必须重建。5.6 第六步销毁集群销毁是很多团队最不重视、但最容易出问题的一步。如果直接删除栈而不检查可能出现挂载在 EFS 上的持久数据被误删取决于存储的 DeletionPolicy弹性 IP 未释放持续产生费用安全组和网络接口残留导致后续创建集群时资源冲突。ParallelClusterMaker 的销毁命令通常会封装“删除前确认”和“清理关联资源”的逻辑parallelclustermaker delete --cluster demo --force这里建议在自动化脚本中显式指定--force之前先确认确实不需要该集群的数据。删除是不可逆操作任何封装都无法替代人工判断。6. 完整示例从零管理一个模拟计算集群为了让整个过程更具体下面用一个最小示例演示 ParallelClusterMaker 管理集群栈的完整链路。这里采用典型的项目布局。6.1 示例场景假设团队需要创建一个名为demo-cfd的集群用于计算流体力学CFD仿真。要求如下使用官方 Amazon Linux 2 镜像HeadNode 使用较小实例类型计算节点使用计算优化型实例调度器为 Slurm计算节点数量范围 0 到 4按需扩缩容挂载一个共享存储目录/shared。6.2 项目目录与配置文件推荐的项目结构parallelcluster-demo/ ├── configs/ │ ├── demo-cfd.yaml │ └── demo-gpu.yaml ├── scripts/ │ └── bootstrap.sh └── README.mdconfigs/demo-cfd.yaml内容示意Region: ap-northeast-1 Image: Os: alinux2 HeadNode: InstanceType: c5.xlarge Networking: SubnetId: subnet-0abc123def4567890 Ssh: KeyName: your-key-pair Scheduling: Scheduler: slurm SlurmQueues: - Name: compute Networking: SubnetIds: - subnet-0abc123def4567890 ComputeResources: - Name: c5n InstanceType: c5n.2xlarge MinCount: 0 MaxCount: 4 Efa: Enabled: false SharedStorage: - Name: shared-fs MountDir: /shared StorageType: Efs这里的关键点MinCount: 0意味着没有作业时不会启动计算节点可以有效控制空闲成本Efa.Enabled: false表示不使用 Elastic Fabric Adapter适合对节点间通信要求不高的场景KeyName指定 SSH 密钥用于登录 HeadNode。6.3 集群生命周期命令假设 ParallelClusterMaker 提供以下命令接口具体名称以项目 README 为准# 1. 校验配置 parallelclustermaker validate --cluster demo-cfd # 2. 创建集群栈阻塞直到创建完成或失败 parallelclustermaker create --cluster demo-cfd # 3. 查看状态 parallelclustermaker status --cluster demo-cfd # 4. 列出集群下所有并行集群 parallelclustermaker list运行validate成功时预期输出类似[OK] demo-cfd configuration is valid. [OK] Subnet subnet-0abc123def4567890 exists. [OK] Key pair your-key-pair exists.运行create成功时预期输出类似[INFO] Creating stack for cluster demo-cfd... [INFO] Stack creation started: arn:aws:cloudformation:ap-northeast-1:123456789012:stack/demo-cfd/xxxx [INFO] Waiting for stack creation to complete... [SUCCESS] Cluster demo-cfd is ready. [INFO] HeadNode public IP: 54.xxx.xxx.xxx6.4 与 CI/CD 脚本集成CLI 工具的最大价值之一是能在无人值守的环境中运行。下面是一个 Shell 脚本示例用于在代码合并到主分支后自动创建测试集群#!/usr/bin/env bash set -euo pipefail CLUSTER_NAMEtest-${GIT_BRANCH//\//-} CFG_FILEconfigs/${CLUSTER_NAME}.yaml # 如果配置不存在则使用默认模板生成 if [[ ! -f $CFG_FILE ]]; then echo Configuration $CFG_FILE not found, skip. exit 0 fi # 校验并创建 parallelclustermaker validate --cluster $CLUSTER_NAME parallelclustermaker create --cluster $CLUSTER_NAME # 输出状态 parallelclustermaker status --cluster $CLUSTER_NAME脚本中使用set -euo pipefail任何一个命令失败都会立即退出避免 CI 中出现“明明创建失败却标记为成功”的误判。变量GIT_BRANCH来自 CI 环境变量可以根据实际 CI 系统调整。7. 运行结果与效果验证完成集群创建后绝不能只看命令输出就认为万事大吉。需要从三个层面验证集群是否真正可用。7.1 验证 CloudFormation 栈状态通过 AWS CLI 查看栈状态aws cloudformation describe-stacks \ --stack-name demo-cfd \ --query Stacks[0].StackStatus \ --output text预期输出为CREATE_COMPLETE如果状态是CREATE_FAILED则说明资源创建过程中出现了无法自动恢复的错误需要进一步查看 CloudFormation 事件。7.2 验证 ParallelCluster 状态使用官方pcluster命令检查集群状态pcluster describe-cluster --cluster-name demo-cfd在输出中关注cloudFormationStackStatus和clusterStatus字段。如果两者都是正常状态说明 ParallelCluster 层的资源协调完成。7.3 验证登录节点 SSH 连通性通过 SSH 登录 HeadNodessh -i ~/.ssh/your-key.pem ec2-user54.xxx.xxx.xxx登录成功后检查调度器是否可用sinfo预期输出会显示计算节点的状态。如果sinfo输出空白或报错说明 Slurm 配置可能存在问题需要检查 HeadNode 上的调度器服务日志。7.4 验证共享存储挂载登录 HeadNode 后检查共享目录df -h /shared如果共享存储没有挂载会提示目录不存在或在/shared上挂载了本地磁盘。这时需要返回配置检查SharedStorage部分。7.5 提交一个简单作业创建一个测试作业文件test.sbatch#!/bin/bash #SBATCH --job-nametest #SBATCH --outputtest_%j.out #SBATCH --ntasks1 srun hostname提交sbatch test.sbatch然后等待作业执行查看输出文件cat test_*.out预期会看到计算节点的 hostname。这个验证非常关键因为集群创建成功不代表作业能正常调度——只有跑通实际作业才说明计算节点、调度器、网络和共享存储整个链路是通的。8. 常见问题与排查思路在实际使用中ParallelCluster 集群栈的管理会遇到很多具体问题。这里整理了一些高频场景和排查思路。问题现象可能原因排查方式解决方案创建集群时 CloudFormation 栈失败IAM 权限不足或资源冲突查看 CloudFormation 事件和错误日志检查 IAM 策略确认有权限创建 EC2、EFS、安全组等资源配置文件校验报“子网不存在”子网 ID 写错或所在区域与配置不符检查 config 中 Region 与 SubnetId确认子网 ID 属于配置的 Region并核对 VPC 环境集群创建成功但无法 SSH 登录 HeadNode安全组未放行 22 端口或密钥对不对检查 EC2 安全组入站规则在配置中显式指定允许 SSH 的 CIDR或通过 Session Manager 登录排查sinfo看不到计算节点Slurm 服务未启动或节点注册失败查看 HeadNode 上 slurmctld 日志重启 slurmctld并检查节点是否处于 DOWN 状态作业提交后一直 PENDING计算节点 MaxCount 太小或镜像不可用执行squeue和sinfo -R调整 MaxCount或者检查计算节点是否因配额受限无法启动删除集群后 EFS 数据被误删存储的 DeletionPolicy 配置不当查看 EFS 控制台确认文件系统状态对持久数据使用独立存储或在删除前备份更新配置后集群进入不稳定状态修改了不允许动态变更的参数查看pcluster update-cluster的兼容性提示对关键变更采用“先删除、再重建”策略保证环境干净需要特别说明的是删集群前如果挂载的是 AWS EFS默认行为通常是在集群删除后保留文件系统具体取决于配置。但如果使用了其他存储类型或自定义脚本清理资源则存在数据丢失风险。任何删除操作都建议先做一次备份或快照再执行清理。9. 最佳实践与工程建议9.1 命名规范集群名称会直接映射到 CloudFormation 栈名称和部分资源名称因此建议从一开始就建立统一命名规范。一个可参考的模式是{环境}-{项目}-{用途}-{序号}例如dev-cfd-test-01prod-cfd-solver-01test-gpu-train-01规范的命名至少带来三个好处日志和成本账单更容易归类多团队共同使用同一账号时不会冲突自动清理脚本可以按前缀批量识别过期资源。9.2 配置管理ParallelCluster 的配置文件是最重要的基础设施资产不能散落在个人电脑里。建议把配置目录纳入 Git 仓库并遵循以下原则环境差异用不同配置文件或模板变量表达避免复制粘贴大段 YAML配置文件合并请求必须经过至少一位同事 Review在 CI 中加入配置校验步骤不允许未通过校验的配置合入主干。如果 ParallelClusterMaker 支持模板变量例如按环境替换子网、实例规格尽量使用模板而不是为每个环境维护一份完整副本。这样能减少因“某个环境改了参数、另一个环境忘了同步”导致的不一致问题。9.3 权限最小化生产环境中应避免给每个开发者都分配完整的 ParallelCluster 管理权限。更合理的做法是开发人员只能操作dev-前缀的集群只有运维或平台组可以操作prod-前缀的集群销毁命令单独授权可以在 IAM 策略中限制删除特定资源的能力。这里有一个务实的建议先让工具在一个受限测试账号中完整跑通确认它具体调用哪些 AWS API再按实际使用的 API 列表收紧 IAM 策略。直接给AdministratorAccess虽然省事但一旦密钥泄露攻击者可以操纵整个 AWS 账号。9.4 成本控制HPC 集群非常容易产生成本尤其是 GPU 实例和存储。三个实用的手段计算节点MinCount设为 0让集群在没有作业时缩容到零为开发环境设置定时自动销毁脚本例如每晚 10 点删除非生产集群使用预算告警AWS Budgets当集群费用超过阈值时发送通知。ParallelClusterMaker 如果支持标签注入建议为每个集群添加成本中心标签例如CostCenter: research-cfd、Owner: zhangsan这样费用账单可以按标签分类分析。9.5 自动化与团队协作CLI 工具的真正威力在自动化中才能体现。建议从三个方向逐步推进定时巡检每天执行一次status脚本检查所有集群是否处于预期状态资源回收对标记为“临时”的集群定时删除自助申请以 ParallelClusterMaker 为基础封装一个更友好的自助平台让算法工程师通过 Web 界面或 ChatOps 申请集群而不需要直接操作 AWS。顺带提醒一点自动化程度越高对安全边界的关注也要越高。删除脚本一定要加多重确认最好在测试环境验证过再上线。10. 总结与后续学习方向ParallelClusterMaker 这类 CLI toolkit 本身并不神秘它做的是一次“工程化封装”把 AWS ParallelCluster 栈的创建、校验、更新、查询、销毁变成更贴近团队协作和自动化需求的命令集合。它的价值不取决于代码量而取决于它是否能把团队在 HPC 基础设施管理上的最佳实践固化下来。如果你正在搭建自己的 HPC 平台我建议先不急着写复杂的脚本而是把下面几件事做扎实读一遍 AWS ParallelCluster 官方文档理解配置文件的每一项含义手动创建、销毁一个最小集群体验完整生命周期再引入 ParallelClusterMaker 或自己写一层薄封装把经常重复的操作变成命令最后把配置纳入版本控制接入 CI 校验再加定时回收策略。后续值得继续深入的方向包括自定义 AMI 与 Bootstrap 脚本的标准化、EFS/FSx 存储的备份策略、GPU 集群的调度参数调优、以及把 ParallelCluster 与 Step Functions 或 Airflow 等任务编排系统结合。记住一句话工具的最终目标不是让你更频繁地创建集群而是让每一次创建都更可靠、更可控、更可预期。