2026 年 5 月 30 日，ZStack Cloud 正式推出 5.5.22 版本。作为国产自研云平台的持续迭代，每一次小版本更新背后都藏着运维团队关心的东西——稳定性补丁、API 行为调整、资源调度策略变化。版本号看起来只是数字递增，但对正在跑生产环境的人来说，升级前后的差异才是真正要盯的。
这篇文章不逐条翻译发布公告，而是从实际运维角度拆解：拿到新版本后，你该验证什么、怎么验证、升级路径上有哪些坑要绕。
版本迭代的核心关注点
ZStack Cloud 的版本命名遵循 大版本.功能版本.补丁版本 的规则。5.5.22 属于 5.5 系列的补丁迭代，通常意味着：
- 已知缺陷修复：此前社区或客户反馈的崩溃、资源泄漏、API 返回异常等问题会被收敛。
- 性能微调：虚拟机调度、存储卷挂载、网络转发等路径上可能有延迟优化。
- 兼容性补丁：对底层 CentOS / Debian 宿主机内核版本、数据库版本（MySQL 8.x）的适配范围可能扩展。
这些改动不会像 5.6 那样引入全新功能模块，但恰恰是生产环境最需要的——不出事比出新功能重要。
升级前的环境自检清单
在动手升级之前，先跑一轮自检，避免升级过程中踩到已知前置条件：
| 检查项 | 命令 / 方法 | 期望结果 |
|---|---|---|
| ZStack 当前版本 | zstack-ctl status |
确认是 5.5.x 系列，跨大版本升级路径不同 |
| 数据库连接状态 | mysql -u root -p -e "SELECT VERSION();" |
MySQL 8.0+，连接无超时 |
| 宿主机内核版本 | uname -r |
在官方兼容列表内 |
| 管理节点磁盘余量 | df -h /var/lib/zstack |
至少预留 20GB 用于升级包与临时文件 |
| 虚拟机运行状态 | zstack-cli QueryVmInstance |
无处于 Migrating / Starting 等中间态的 VM |
如果任何一项不达标，先处理再升级。尤其是磁盘空间——升级包解压 + 数据库 schema 迁移会在 /var/lib/zstack 下产生临时文件，空间不足会直接中断升级流程。
实操：用 ZStack CLI 完成升级验证
升级完成后，第一件事不是去看新功能，而是确认原有行为没有被悄悄改掉。以下是一套可复制的验证脚本，覆盖最核心的云资源 CRUD 操作：
#!/bin/bash
# zstack-post-upgrade-check.sh
# 升级后的基础功能冒烟验证
# 使用前请修改 ZSTACK_URL 和 SESSION 变量
ZSTACK_URL="http://your-management-node:8080"
SESSION="your-session-token"
echo "=== 1. 管理节点健康检查 ==="
curl -s "${ZSTACK_URL}/zstack/v1/system/health-check" \
-H "Authorization: ${SESSION}" | python3 -m json.tool
echo "=== 2. 查询可用区列表 ==="
curl -s "${ZSTACK_URL}/zstack/v1/zones" \
-H "Authorization: ${SESSION}" | python3 -m json.tool
echo "=== 3. 查询集群与宿主机状态 ==="
curl -s "${ZSTACK_URL}/zstack/v1/clusters" \
-H "Authorization: ${SESSION}" | python3 -m json.tool
curl -s "${ZSTACK_URL}/zstack/v1/hosts" \
-H "Authorization: ${SESSION}" | python3 -m json.tool
echo "=== 4. 查询主存储与镜像存储连接状态 ==="
curl -s "${ZSTACK_URL}/zstack/v1/primary-storage" \
-H "Authorization: ${SESSION}" | python3 -m json.tool
curl -s "${ZSTACK_URL}/zstack/v1/backup-storage" \
-H "Authorization: ${SESSION}" | python3 -m json.tool
echo "=== 5. 创建并立即删除测试虚拟机（冒烟用） ==="
# 先查询可用镜像与计算规格
IMAGE_UUID=$(curl -s "${ZSTACK_URL}/zstack/v1/images" \
-H "Authorization: ${SESSION}" | python3 -c "
import sys, json
data = json.load(sys.stdin)
for i in data.get('inventories', []):
if i.get('status') == 'Ready':
print(i['uuid'])
break
")
OFFERING_UUID=$(curl -s "${ZSTACK_URL}/zstack/v1/vm-instances/offering" \
-H "Authorization: ${SESSION}" | python3 -c "
import sys, json
data = json.load(sys.stdin)
for o in data.get('inventories', []):
if o.get('state') == 'Enabled':
print(o['uuid'])
break
")
if [ -z "$IMAGE_UUID" ] || [ -z "$OFFERING_UUID" ]; then
echo "⚠️ 无可用镜像或计算规格，跳过 VM 冒烟测试"
exit 0
fi
echo "使用镜像: ${IMAGE_UUID}, 计算规格: ${OFFERING_UUID}"
echo "创建测试 VM..."
VM_UUID=$(curl -s -X POST "${ZSTACK_URL}/zstack/v1/vm-instances/create" \
-H "Authorization: ${SESSION}" \
-H "Content-Type: application/json" \
-d "{\"name\":\"smoke-test-vm\",\"instanceOfferingUuid\":\"${OFFERING_UUID}\",\"imageUuid\":\"${IMAGE_UUID}\"}" \
| python3 -c "import sys,json; print(json.load(sys.stdin).get('uuid',''))")
echo "测试 VM UUID: ${VM_UUID}"
sleep 30 # 等待 VM 进入 Running 状态
echo "销毁测试 VM..."
curl -s -X DELETE "${ZSTACK_URL}/zstack/v1/vm-instances/${VM_UUID}" \
-H "Authorization: ${SESSION}" | python3 -m json.tool
echo "=== 冒烟验证完成 ==="
使用前需要修改的地方：
ZSTACK_URL替换为你的管理节点实际地址。SESSION通过zstack-cli login或直接调用登录 API 获取 token。- 测试 VM 的创建依赖一个
Ready状态的镜像和Enabled状态的计算规格，确保环境中有这些资源。 sleep 30是保守等待时间，如果你的镜像较大或网络较慢，适当延长。
这套脚本不验证新功能，只验证旧功能还在正常工作。升级后最怕的不是新东西不好用，而是老东西变了行为你却不知道。
补丁版本升级的节奏建议
补丁版本（5.5.22 这类）的升级策略和大版本不同，核心原则是快进快出、低风险优先：
- 先升级管理节点，再逐台滚动升级宿主机。管理节点升级失败可以回退数据库；宿主机升级失败会直接影响上面跑的 VM。
- 选低负载时段。补丁升级通常不需要停机，但数据库 schema 迁移期间会有短暂的 API 不可用窗口（一般 30 秒到 2 分钟）。
- 升级后观察 48 小时。重点看管理节点日志中是否有新的
ERROR级别条目：grep ERROR /var/log/zstack/management-server.log | tail -100。 - 不要跳版本累积。5.5.20 → 5.5.22 是安全的；5.5.10 → 5.5.22 最好先查官方升级路径文档，中间可能有必须经过的里程碑版本。
写在最后
5.5.22 这类补丁版本看起来不起眼，但它解决的是日常运维中那些"说不清哪里不对但就是偶尔出问题"的痛点。升级本身不复杂，复杂的是升级后的验证——你得确认平台行为和升级前一致，才能放心让业务继续跑。
上面的冒烟脚本是一个起点，实际生产环境还需要加上网络连通性测试（VPC / 安全组规则是否生效）、存储 I/O 测试（卷挂载 / 快照创建是否正常）等环节。把这些验证步骤固化成 CI 流程里的一环，每次升级自动跑一遍，比人肉检查靠谱得多。