AWS Kubernetes 工作坊：Kubernetes 集群升级实践指南

屈心可

于 2025-06-20 10:14:24 发布

阅读量386

点赞数 3

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/gitblog_00558/article/details/148784174

AWS Kubernetes 工作坊：Kubernetes 集群升级实践指南

aws-workshop-for-kubernetes AWS Workshop for Kubernetes 项目地址: https://gitcode.com/gh_mirrors/aw/aws-workshop-for-kubernetes

前言

在 Kubernetes 生产环境中，集群升级是一项关键但复杂的运维任务。AWS 提供的 kops 工具极大地简化了这一过程。本文将深入探讨两种主流的 Kubernetes 集群升级方法：原地升级(In-place Upgrade)和蓝绿升级(Blue/Green Upgrade)，帮助您根据业务需求选择最适合的升级策略。

集群升级基础概念

为什么需要升级？

Kubernetes 社区每季度发布新版本，每个版本都包含：

安全补丁
性能优化
新功能特性
废弃旧API

定期升级可确保集群安全稳定运行，同时获得最新功能。

升级前的准备工作

备份关键数据：etcd 数据、应用数据等
检查兼容性：API版本、插件兼容性
规划维护窗口：升级可能导致短暂服务中断
测试环境验证：先在非生产环境验证升级流程

方法一：原地升级(In-place Upgrade)

原地升级是直接对现有集群进行版本更新的方法，适合中小规模集群。

步骤1：创建初始集群

我们首先创建一个 Kubernetes 1.6.10 版本的集群：

kops create cluster \
  --name example.cluster.k8s.local \
  --master-count 3 \
  --master-zones ${AWS_AVAILABILITY_ZONES} \
  --node-count 5 \
  --zones ${AWS_AVAILABILITY_ZONES} \
  --kubernetes-version=1.6.10 \
  --yes

关键参数说明：

master-count 3：3个master节点确保高可用
master-zones：跨可用区部署
node-count 5：5个工作节点
kubernetes-version：指定初始版本

步骤2：验证集群状态

使用以下命令验证集群健康状况：

kops validate cluster --name example.cluster.k8s.local

检查节点版本：

kubectl get nodes

应显示所有节点均为 v1.6.10。

步骤3：修改集群配置

编辑集群配置准备升级到1.7.4：

kops edit cluster example.cluster.k8s.local

找到 kubernetesVersion 字段，将值从 1.6.10 改为 1.7.4，保存退出。

步骤4：应用配置变更

应用配置变更并启动滚动升级：

kops update cluster example.cluster.k8s.local --yes
kops rolling-update cluster example.cluster.k8s.local --yes

注意事项：

升级过程可能需要30-45分钟
期间避免对集群进行其他操作
系统会逐个替换节点，确保服务不中断

步骤5：验证升级结果

升级完成后，再次验证集群状态和节点版本：

kubectl get nodes

应显示所有节点已升级到 v1.7.4。

方法二：蓝绿升级(Blue/Green Upgrade)

蓝绿升级是更保守的升级策略，适合对可用性要求极高的生产环境。

核心思想

创建全新的1.7.4版本集群（绿色环境）
保持原有1.6.10集群（蓝色环境）继续运行
逐步将流量迁移到新集群
验证新集群稳定性后，下线旧集群

实施步骤

创建新集群：

kops create cluster \
  --name new-example.cluster.k8s.local \
  --kubernetes-version=1.7.4 \
  ...其他参数与旧集群相同...
  --yes

配置迁移工具：
- 使用Velero进行资源迁移
- 或手动重新部署应用到新集群
DNS切换：
- 逐步将流量导向新集群
- 使用权重控制流量比例
监控验证：
- 监控新集群各项指标
- 验证业务功能完整性
清理资源：
- 确认无误后下线旧集群

升级策略对比

| 特性 | 原地升级 | 蓝绿升级 | |------|---------|---------| | 资源消耗 | 低（复用现有资源） | 高（需要额外资源） | | 升级速度 | 较快 | 较慢 | | 回滚难度 | 困难 | 容易（直接切回旧集群） | | 适用场景 | 开发/测试环境、小规模生产 | 大规模关键业务生产环境 | | 复杂度 | 中等 | 高 |