云服务器K8s集群滚动更新自动化运维指南

在云服务器上部署K8s集群时，如何既保证应用持续可用，又实现版本平滑迭代？滚动更新（Rolling Update）作为Kubernetes的核心功能之一，正是解决这一问题的关键。本文将从方案准备到自动化运维，拆解滚动更新的全流程实践。

滚动更新的核心价值

区别于传统的全量停机更新，滚动更新采用"逐步替换"策略：每次仅更新部分实例，待新版本验证稳定后再替换剩余实例。这意味着更新过程中始终有旧版本实例提供服务，真正实现"零中断"。对于电商大促、金融交易等对可用性要求极高的场景，这种特性尤为重要。

前期准备三要素

要顺利实施滚动更新，需完成三项基础工作：

• 云服务器环境：确保已搭建稳定的K8s集群，控制平面（Control Plane）与节点（Node）通信正常，集群状态显示"Ready"。


• 镜像准备：新版本Docker镜像需提前推送至镜像仓库（如Harbor、Docker Hub），并确认镜像标签（Tag）可被K8s正确识别。


• 工具配置：本地或运维终端安装Kubectl工具（Kubernetes命令行客户端），并通过kubeconfig文件完成集群认证，执行`kubectl cluster-info`验证连接状态。

Deployment文件的关键配置

Deployment是K8s管理应用副本的核心资源，其配置直接影响滚动更新效果。以下是包含滚动策略的典型YAML示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deploy
spec:
  replicas: 5  # 总副本数
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app-container
        image: registry.example.com/web-app:v2  # 新版本镜像
        ports:
        - containerPort: 8080
  strategy:  # 滚动更新策略
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 20%  # 最多额外创建20%副本（即1个）
      maxUnavailable: 1  # 最多允许1个副本不可用

重点关注`strategy`字段：`maxSurge`控制更新时的最大额外副本数（支持百分比或固定值），避免资源过载；`maxUnavailable`限制不可用副本上限，保障服务容量。建议电商等高并发场景将`maxUnavailable`设为0，确保更新期间全量副本可用。

自动化运维脚本实战

手动执行更新命令易出错且效率低，通过Shell脚本可实现"一键触发+状态追踪"。以下是常用脚本模板：

#!/bin/bash
set -e  # 出错即终止

定义变量

DEPLOY_NAME="web-app-deploy"
NEW_IMAGE="registry.example.com/web-app:v2"

触发滚动更新

echo "开始更新镜像至${NEW_IMAGE}..."
kubectl set image deployment/${DEPLOY_NAME} app-container=${NEW_IMAGE}

轮询更新状态（超时设置为10分钟）

TIMEOUT=600
START_TIME=$(date +%s)
while true; do
  STATUS=$(kubectl rollout status deployment/${DEPLOY_NAME} --watch=false)
  if [[ $STATUS == *"successfully rolled out"* ]]; then
    echo "滚动更新完成！"
    exit 0
  fi
  CURRENT_TIME=$(date +%s)
  if (( CURRENT_TIME - START_TIME > TIMEOUT )); then
    echo "更新超时，尝试回滚..."
    kubectl rollout undo deployment/${DEPLOY_NAME}
    exit 1
  fi
  sleep 10
done

脚本包含三大功能：变量化配置提升复用性、实时追踪更新状态、超时自动回滚。实际使用中可扩展日志记录（如将输出重定向至文件），方便后续审计。

监控与回滚的双保险

即使配置了自动化脚本，人工监控仍不可少。建议通过云服务器提供的监控面板，重点关注：

• Pod状态：通过`kubectl get pods`检查是否有`CrashLoopBackOff`等异常状态。


• 流量指标：观察负载均衡（如Ingress）的请求成功率、延迟，确认新版本性能达标。


• 资源使用率：CPU、内存是否因新版本特性出现突增（如某些Java应用升级后GC频率增加）。

若发现异常，可执行`kubectl rollout undo deployment/web-app-deploy`快速回滚至前一稳定版本。需注意，K8s默认保留最近10次版本记录（可通过`revisionHistoryLimit`调整），长期未操作的旧版本会被自动清理。

掌握这套从策略配置到自动化执行的流程后，在云服务器上运行K8s集群的滚动更新将更高效可控。实际部署时，可根据业务流量波动调整`maxSurge`和`maxUnavailable`参数——大促前调小`maxUnavailable`保障容量，日常迭代时调大`maxSurge`加速更新，真正实现"灵活运维"。