使用K8s自动化运维：VPS服务器集群滚动升级脚本

在VPS服务器集群的日常运维中，如何高效完成升级是关键课题。Kubernetes（简称K8s）作为容器编排领域的“调度员”，能通过滚动升级功能实现边运行边更新，避免服务中断。本文将从原理到实操，拆解如何用K8s脚本实现VPS服务器集群的滚动升级。

为什么需要滚动升级？用电商大促场景理解

假设你运营一个电商平台，大促期间VPS服务器集群承载着每秒数千次的商品查询。若采用“一刀切”停机升级——比如凌晨2点全体服务器下线更新，用户可能在支付时遇到“页面无法访问”，直接影响订单转化。而滚动升级就像“修桥不封路”：每次只升级1-2台服务器，旧节点仍在处理请求，新节点启动验证后逐步接管流量，全程不中断服务。

滚动升级的底层逻辑：K8s的“接力赛”机制

K8s的滚动升级本质是“渐进替换”。以一个部署（Deployment）包含5个Pod副本为例：
1. 先创建1个新版本Pod（新副本）；
2. 确认新副本健康（如端口可访问、应用启动成功）；
3. 销毁1个旧版本Pod（旧副本）；
4. 重复上述步骤直至所有旧副本被替换。

整个过程中，K8s会确保可用副本数不低于“最小可用数”（默认是总副本数的75%），就像接力赛中始终有选手在赛道上奔跑。

手把手写滚动升级脚本：从命令到集成

假设你已有一个运行在VPS服务器集群上的K8s部署，现在要升级容器镜像（如从v1.0到v1.1），可按以下步骤编写脚本：

第一步：基础脚本框架

#!/bin/bash  # 声明为Bash脚本

自定义参数（需根据实际环境修改）

DEPLOYMENT_NAME="mall-frontend"  # K8s部署名称（如电商前端服务）
NEW_IMAGE="mall-frontend:v1.1"   # 新版本镜像（仓库地址+标签）

执行滚动升级

kubectl set image deployment/$DEPLOYMENT_NAME app-container=$NEW_IMAGE --record

监控升级状态（实时输出进度）

kubectl rollout status deployment/$DEPLOYMENT_NAME --watch

关键命令解析：
- `kubectl set image`：修改部署中的容器镜像，`app-container`是Pod内容器的名称（可通过`kubectl get deployment [名称] -o yaml`查看）；
- `--record`：自动记录本次升级的操作（如镜像版本），后续可通过`kubectl rollout history`查看历史；
- `--watch`：持续监控升级过程，直到所有副本更新完成或失败。

第二步：集成CI/CD实现自动化

实际运维中，可将脚本集成到Jenkins、GitLab CI等工具。例如在GitLab CI的`.gitlab-ci.yml`中添加：

stages:
  - deploy

k8s-rollout:
  stage: deploy
  script:
    - chmod +x k8s-rollupgrade.sh  # 赋予脚本执行权限
    - ./k8s-rollupgrade.sh         # 执行滚动升级脚本
  only:
    - main  # 仅主分支提交时触发

代码合并到主分支后，CI工具会自动运行脚本，实现“代码提交→镜像构建→滚动升级”全流程自动化。

遇到问题别慌：回滚与排查

即使脚本写得再严谨，也可能遇到新镜像启动失败（如配置错误、依赖缺失）。此时K8s会暂停升级，旧副本仍保持运行。你需要：
1. 查看失败原因：`kubectl describe pod [新Pod名称]` 或 `kubectl logs [新Pod名称]`；
2. 回滚到上一版本：`kubectl rollout undo deployment/$DEPLOYMENT_NAME`。

总结：VPS集群运维的“效率加速器”

通过K8s滚动升级脚本，VPS服务器集群的升级从“手动停机→逐台操作→验证”的小时级流程，缩短为“一键触发→自动替换→实时监控”的分钟级操作。无论是支撑电商大促的高并发集群，还是服务中小企业的业务系统，这种自动化运维方式都能显著降低人为失误，保障服务可用性。掌握这一技能，相当于为VPS服务器集群上了一道“动态维护”的保险栓。