使用 Kiro 辅助 Amazon EKS 集群升级实践

摘要：本文介绍如何借助 Kiro（AI Agent）与亚马逊云科技开源 MCP Server，把 Amazon EKS 升级的官方最佳实践与企业内部运维经验编排为可复用的 Skill 与 Steering，用自然语言驱动一次安全、可控、可审计的集群版本升级，从而降低人工操作复杂度与误操作风险。

一、背景与挑战

1.1 Kubernetes 与 EKS 版本生命周期

Kubernetes 持续快速演进，不断带来新特性、设计更新与缺陷修复，社区平均每约四个月发布一个新的次要版本（minor version），Amazon EKS 紧跟上游的发布与弃用节奏。因此 AWS 建议主动将集群升级到最新可用版本——按官方说法：建议使用 EKS 支持的最新可用 Kubernetes 版本创建集群；若应用需要特定版本，也可选择较旧版本；可以在标准支持或扩展支持涵盖的任意版本上创建新集群。

在生命周期方面，每个次要版本在 EKS 上拥有 14 个月的标准支持（Standard Support），标准支持结束后进入为期 12 个月的扩展支持（Extended Support），二者合计 26 个月。运行在扩展支持版本上的集群需要按集群小时额外付费。

[图 1：EKS Kubernetes 版本生命周期]

1.2 扩展支持带来的额外成本

以亚马逊云科技中国区为例，标准支持下每个 EKS 集群控制面的费用为 ¥0.688/小时；而运行在扩展支持版本上的集群，费用为 ¥4.128/小时（已包含 ¥0.688 的基础费用）。也就是说，长期停留在旧版本不仅有安全与兼容性风险，单集群每小时成本约为标准支持的 6 倍。对于拥有大量集群的企业，及时升级带来的成本节省相当可观。

注：以上价格引自亚马逊云科技中国区 EKS 定价页，具体以官网最新公布为准。

1.3 集群升级的复杂度与风险

EKS 升级并非单次操作即可完成，它牵涉多个存在版本约束与顺序依赖的环节：

• 控制面只能逐个次要版本 +1 升级，不可跳级、不可降级；跨多个版本时需要连续多次升级。
• 升级前必须识别并整改已被目标版本移除的 API（Deprecated / Removed API），否则工作负载会在升级后失效。
• Add-on（vpc-cni、kube-proxy、coredns）不会随控制面自动升级，且彼此存在升级顺序依赖。
• 节点组需要单独升级；从 Amazon Linux 2（AL2）迁移到 Amazon Linux 2023（AL2023）涉及 UserData、IMDS、nodeadm 等一系列改造。
• 升级过程中要保障工作负载可用性（PDB、副本数、节点驱逐顺序），并具备回退预案。

这些知识分散在 AWS 官方文档、社区经验和企业内部规范中，依赖个人经验手工执行，既低效又容易出错。我们希望把这些「运维知识」沉淀下来，让它可复用、可审计、可被 AI Agent 直接驱动执行。

二、方案概述

本文实践了使用 Kiro 配合亚马逊云科技开源 MCP Server 辅助 EKS 升级的方案。核心思路是：把 AWS 官方的 EKS 升级最佳实践、常见问题排查方法，以及企业内部沉淀的运维规范，汇总编码为 Kiro 的 Skill 与 Steering；再通过 MCP Server 赋予 Agent 直接操作 AWS / EKS / Kubernetes 的能力。用户只需用自然语言描述升级意图，Agent 即可按照既定规范完成升级前检查、控制面升级、Add-on 升级、节点组蓝绿替换与升级后验证等全流程。

通过这种方式，我们把「升级前检查、升级步骤、升级最佳实践」标准化、流程化，在保证安全的前提下支持快速升级，显著减少人为操作复杂度以及由此带来的操作纰漏。

[图 2：方案整体架构]

三、方案详解

3.1 Kiro CLI 简介

Kiro 是一款 AI Agent，开发者可以通过 kiro chat 命令在本地终端与之交互。Kiro 通过两类「知识载体」来约束和指导自身行为：

• Steering：通过 .kiro/steering/ 目录下的 markdown 文件为 Kiro 提供关于项目的持久知识，无需在每次对话中重复说明，从而确保 Kiro 始终遵循既定的规范、库与标准。
• Skill：遵循开放 Agent Skills 标准的可移植指令包，把指令、脚本与模板打包成可复用的包，Kiro 在与当前任务相关时激活；启动时仅加载元数据（名称与描述），完整内容按需加载。

二者配合 MCP（Model Context Protocol）工具，使 Agent 既遵循既定规范，又具备实际操作能力。

3.2 MCP 协议与亚马逊云科技开源 MCP Server

MCP（Model Context Protocol）是一套让大语言模型安全调用外部工具与数据源的开放协议。亚马逊云科技提供了一系列开源 MCP Server（Open Source MCP Servers for AWS），本方案配置了其中三个：

eks-mcp-server

提供对 EKS / Kubernetes 资源的操作能力，包括列举 K8s 资源、查询 API 版本、读取 EKS Insights、查询 VPC 配置、读取 IAM 角色策略、获取 CloudWatch 指标与日志、查看 Pod 日志和 K8s 事件，以及节点组、Add-on 等写操作。它是升级流程中检查与执行的主力工具。

aws-api-mcp-server

提供执行 AWS CLI 命令的能力（如 ec2、autoscaling、ssm、eks 等），用于跨区只读查询、获取 SSM 中的 AL2023 AMI、创建 Launch Template 与节点组等场景。eks-mcp-server 不接收 region 参数（跟随启动时的环境变量），跨区操作正是通过 aws-api-mcp-server 完成的。

aws-documentation-mcp-server

提供查阅 AWS 文档的能力。在中国区需设置 AWS_DOCUMENTATION_PARTITION=aws-cn，且仅 read_documentation 与 get_available_services 可用，用于在升级过程中实时核对官方文档与版本说明。

3.3 升级知识的编排：Steering 与 Skill

本项目把升级知识组织在 .kiro/ 目录下，按「全局约束 + 领域知识 + 按需细则」分层。目录结构与各文件作用如下：

.kiro/
├── settings/
│   └── mcp.json                    # MCP Server 配置（autoApprove 仅含只读操作）
├── skills/
│   └── eks-upgrade/                # EKS 升级 Skill（启动仅加载元数据，内容按需加载）
│       ├── SKILL.md                # 升级流程主编排（前置→预检→执行→验证）
│       ├── rules-aws-official.md   # AWS 官方硬性规则（子网 IP/版本偏差/Add-on 顺序）
│       ├── rules-internal.md       # 企业内部规范（蓝绿替换/命名/Add-on 时机/AL2023）
│       ├── cluster-inventory.md    # 快照采集内容与输出规范
│       ├── kubent-check.md         # 废弃 API 扫描方法
│       ├── al2023-migration.md     # AL2→AL2023 迁移必改项与校验点
│       └── scripts/                # 配套脚本
│           ├── snapshot.sh         # 单集群快照
│           ├── snapshot-all.sh     # 批量快照某区全部集群
│           ├── run-kubent.sh       # kubent 包装脚本（首次自动下载二进制）
│           ├── kubent-results.txt  # 废弃 API 扫描结果输出
│           └── inventory/          # 快照输出目录
└── steering/
    ├── overview.md                 # 全局红线：规则优先级、默认只读、快照 diff
    └── china-region.md             # 中国区差异：分区、版本确认、文档 MCP 限制

需要说明的是：eks-upgrade 目录下的所有 md 文件与脚本都属于同一个 Skill，只是不会同时全部加载——启动时仅加载 SKILL.md 的元数据，rules-internal.md、al2023-migration.md 等规则与细则、以及脚本，只在升级流程实际需要时才按需读取或执行，从而减少上下文占用。而 steering/ 下的两个文件则每次对话都会加载，作为始终生效的全局约束。

3.4 升级思路与核心优势

沉淀 AWS 官方最佳实践

rules-aws-official.md 摘录了官方文档中的硬性前提与建议，例如：控制面一次只能升一个次要版本；升级时子网需有 ≥5 个可用 IP；升级前必须整改已移除 API；Add-on 升级顺序为 vpc-cni → kube-proxy → coredns 等。这些被标注为「硬性」的条目是不可逾越的前提。

融入企业内部最佳实践

rules-internal.md 记录了与官方「建议性」做法不同的企业约定。本项目示例中的核心约定包括：节点组采用「蓝绿替换」而非原地升级、节点组命名规范 ng-<role>-v<version>、Add-on 在控制面全部升完后统一升一次、AL2→AL2023 随节点组蓝绿替换同步完成等。当企业规范与官方建议冲突时，以企业规范优先——除非违反官方硬性前提。

规范化的升级前检查

升级前的只读预检被固化为流程，包括：废弃 API 扫描（按最终目标版本扫整段跨度）、EKS Upgrade Insights、Add-on 兼容矩阵、组件版本偏差、控制面升级硬性前提（子网 / 安全组 / IAM）、PDB 与副本数核对、节点组 AMI / LT / labels / taints 记录，以及 Launch Template endpoint 一致性检查。

MCP 的安全性：默认只读

这是本方案的安全基石。MCP 配置中的 autoApprove 列表只加入只读操作（如 list_k8s_resources、get_eks_insights、get_eks_vpc_config、read_documentation、suggest_aws_commands 等）；任何写操作（update-cluster、update-addon、创建 / 删除节点组、call_aws 执行变更命令）都不在自动批准列表中，必须经过用户显式确认。这样既保留了 Agent 自动化带来的效率，又将所有变更性操作的决策权保留在运维人员手中。

全流程管控：先规划、设检查点、人工确认

• 先规划后执行：用户描述升级意图后，Agent 先输出分步计划（版本确认 → 预检 → 执行计划），而非直接动手。
• 关键步骤设人工检查点：节点组蓝绿替换中，在「新节点就绪后（驱逐前）」和「驱逐完成后（缩容前）」两处暂停，等待用户确认后再继续。
• 逐版本复查：控制面每升一个版本，复查一次 EKS Insights。

集群配置快照落地到本地 inventory

升级前后各做一次只读快照，输出到本地 inventory/<region>/<cluster>/<date>-<pre|post>.json，内容涵盖集群版本、Add-on 版本与 configurationValues、节点组 AMI/LT/labels/taints 等。升级后对 pre / post 两份快照做 diff，确认自定义配置（如 coredns 自定义 corefile、vpc-cni 环境变量）被完整保留，整个过程可追溯、可审计。

AL2023 迁移细则按需加载

AL2→AL2023 迁移涉及 IMDS hop limit、UserData 改 nodeadm（MIME multipart）、kubelet 参数传递方式、AMI family 选择等较多细节。这部分被单独拆到 al2023-migration.md，仅在确实需要迁移时才加载，避免无关内容占用上下文——这是一种按需加载、控制上下文规模的设计取舍。

Launch Template endpoint 一致性检查

控制面升级后，API server endpoint 可能发生变化。新建 Launch Template 时必须从 aws eks describe-cluster 实时获取最新的 endpoint 与 certificateAuthority 写入 nodeadm 配置，否则新节点将无法注册到集群。该问题容易被忽视，却会导致节点组虽创建成功、节点却无法进入 Ready 状态，本方案将其固化为预检项。

四、升级流程与 Skill 实现

SKILL.md 把整个升级编排为五个阶段，每个阶段都对应具体的 MCP 工具调用或脚本执行：

[图 3：EKS 升级五阶段流程]

阶段 0：前置清理与预检

本阶段在执行任何写操作之前完成全部只读准备工作，包括前置清理、版本核对与兼容性 / 前提检查：

• 前置清理：检查并删除上一轮升级遗留、已缩容为 0 的旧节点组，避免版本偏差阻塞本次控制面升级。
• 目标版本核对：用 aws eks describe-cluster-versions 确认目标版本在当区已 GA，并评估升级后的支持窗口。
• 废弃 API 兼容性检查：用 run-kubent.sh 按最终目标版本扫整段跨度，识别 REMOVED / DEPRECATED API。
• 控制面升级硬性前提：核对子网可用 IP（≥5）、安全组放通、IAM 角色 / KMS 权限。
• Add-on 兼容矩阵、组件版本偏差（kube-proxy / kubelet）、PDB 与副本数核对、节点组配置与 LT endpoint 一致性记录。

Skill 实现：先执行升级前快照（snapshot.sh <cluster> <region> pre），再依次完成上述只读检查；只有清理旧节点组属于写操作，需用户确认后执行。

阶段 1：控制面升级

按次要版本逐级升级至目标版本（如 1.31 → 1.32 → 1.33 → 1.34），每完成一个版本复查一次 EKS Insights。Skill 实现：逐版本执行 update-cluster（写操作，需确认）；全程不可降级，失败自动回滚到原版本。

阶段 2：Add-on 升级

控制面全部升完后，统一升级 Add-on，串行顺序为 vpc-cni → kube-proxy → coredns，等前一个 ACTIVE 再升下一个。Skill 实现：从快照取出 configurationValues，update-addon 时显式带 –configuration-values 与 –resolve-conflicts，保留 coredns 自定义 corefile、vpc-cni 环境变量等自定义配置。

阶段 3：节点组蓝绿替换

本阶段的做法完全来自企业内部升级实践（rules-internal.md）：不做原地 update-nodegroup-version，而是新建目标版本节点组替换旧组，并同步完成 AL2→AL2023 迁移。该方式支持回退、可同步迁移操作系统，是与 AWS 官方「建议性」做法不同的公司约定。具体步骤如下：

1. 新建：根据旧节点组信息自动创建新 Launch Template（目标版本 AMI + AL2023 + nodeadm userdata）与新节点组，保留 labels、容量类型、tags、安全组、IMDS 配置。
2. 【检查点 1，人工确认】新节点全部 Ready 后，校验 OS、kubelet 版本、IMDS、labels、LT endpoint 一致性。
3. 给旧节点打 NoSchedule taint，阻止新 Pod 调度到旧节点。
4. 逐节点 cordon + drain 驱逐，遵守 PDB，分批迁移 Pod 到新节点。
5. 【检查点 2，人工确认】确认旧节点上无非 DaemonSet Pod、副本数达标、Pod 健康后，再缩容。
6. 缩容旧节点组到 0 并保留，作为回退模板；下一轮升级前再删除。

阶段 4：验证

生成升级后快照，与升级前快照 diff，确认配置保留；核对节点 Ready、核心 Add-on 正常、关键工作负载健康。

人工检查点清单

检查点 1 —— 新节点就绪后（驱逐前）：

• 新节点全部 Ready；OS 为 AL2023；kubelet 版本 = 目标版本。
• IMDS HopLimit = 2、HttpTokens = required；Labels / maxPods 与预期一致。
• LT 中 apiServerEndpoint 与集群当前 endpoint 一致。

检查点 2 —— 驱逐完成后（缩容前）：

• 旧节点上无非 DaemonSet Pod；所有 Deployment / StatefulSet 副本数达标。
• 所有 Pod 状态为 Running / Completed；关键服务可达。

五、部署与配置

5.1 依赖项

方案依赖以下工具，安装方式参见各自官网：

5.2 基础配置

配置 AWS 凭证（需 EKS / EC2 / IAM / ASG 读写权限），并更新 kubeconfig：

# 配置凭证；中国区 region: cn-north-1（北京）或 cn-northwest-1（宁夏）
aws configure

# 配置 kubeconfig
aws eks update-kubeconfig --name <cluster> --region <region>

把项目解压到工作目录，确保 .kiro/ 位于项目根下，其中 .kiro/settings/mcp.json 已配置好三个 MCP Server。关键在于 autoApprove 只包含只读操作：

"awslabs.eks-mcp-server": {
  "command": "uvx",
  "args": ["awslabs.eks-mcp-server@latest", "--allow-sensitive-data-access"],
  "autoApprove": [
    "list_k8s_resources", "list_api_versions", "get_eks_insights",
    "get_eks_vpc_config", "get_policies_for_role", "get_cloudwatch_metrics",
    "get_cloudwatch_logs", "get_k8s_events", "get_pod_logs"
  ]
}

配置完成后，在项目根目录运行 kiro chat 即可开始。完整项目（Skill / Steering / 脚本）的 GitHub 链接见文末「资源链接」。

六、开始使用：一次完整升级演练

下面是在宁夏区测试集群 estore-prod-cnn1 上，从 1.31 升级到 1.34（跨 3 个次要版本）的一次真实演练，展示各阶段关键的中文提示词与代表性输出（灰底代码块）。流程中的人工检查点在本次演练中由操作者确认放行。Agent 在每个阶段结束后都会给出建议的下一步操作，引导整个升级有序推进。以下是一次常规升级过程的记录与关键输出。

步骤 1　描述升级意图，生成规划

用户提示词：在宁夏区有一个集群 estore-prod-cnn1，帮我升级到 1.34，先规划步骤

关键输出

Agent 先确认目标版本可用性，识别跨度，并给出分阶段计划：

$ aws eks describe-cluster-versions --region cn-northwest-1 \
    --query "clusterVersions[?clusterVersion=='1.34']"
[{ "v": "1.34", "status": "STANDARD_SUPPORT",
   "eosd": "2026-12-02T00:00:00+00:00", "default": "eks.23" }]
# → 1.34 已 GA；当前 1.31，需逐版本连升 1.31→1.32→1.33→1.34

步骤 2　阶段 0：前置清理与预检

用户提示词：先做升级前快照和预检，检查废弃 API、子网和 Insights，旧的空节点组清理掉

关键输出

升级前快照、子网可用 IP、EKS Insights、废弃 API 扫描依次完成：

$ bash scripts/snapshot.sh estore-prod-cnn1 cn-northwest-1 pre
已写入并校验 inventory/cn-northwest-1/estore-prod-cnn1/20260604-pre.json

$ bash scripts/run-kubent.sh 1.34
INF Target K8s version is 1.34.0
INF Retrieved 44 resources from collector name=Cluster
# 无 DEPRECATED/REMOVED 命中

$ aws eks list-insights --cluster-name estore-prod-cnn1 --region cn-northwest-1
{ "name": "Amazon Linux 2 compatibility",
  "category": "UPGRADE_READINESS", "status": "ERROR" }

$ aws eks delete-nodegroup --cluster-name estore-prod-cnn1 \
    --nodegroup-name ng-old-v130 --region cn-northwest-1
{ "nodegroup": { "nodegroupName": "ng-old-v130", "status": "DELETING" } }

步骤 3　阶段 1：控制面逐版本升级

用户提示词：开始控制面升级，逐个小版本升到 1.34

关键输出

逐版本 +1 连续升级，每版约 7–10 分钟，期间不可降级、失败自动回滚：

$ aws eks update-cluster-version --name estore-prod-cnn1 \
    --kubernetes-version 1.32 --region cn-northwest-1
{ "update": { "id": "3ed841b8-...", "status": "InProgress",
               "type": "VersionUpdate" } }
# 轮询：09:00 UPDATING 1.31 ... 09:07 ACTIVE 1.32（约 7 分钟）
# 同法连升 1.33、1.34；最终：
$ aws eks describe-cluster ... --query 'cluster.[version,platformVersion,status]'
[ "1.34", "eks.23", "ACTIVE" ]

步骤 4　阶段 2：Add-on 升级

用户提示词：控制面升完了，按顺序升级 add-on

关键输出

先查 1.34 推荐版本，vpc-cni 已是最新（保持不动），kube-proxy、coredns 串行升级：

# 当前版本 vs 1.34 推荐版本
vpc-cni     v1.22.1-eksbuild.2   = 1.34 最新   → 兼容，不动
kube-proxy  v1.31.14-eksbuild.18 → v1.34.6-eksbuild.2
coredns     v1.11.4-eksbuild.39  → v1.12.4-eksbuild.10

$ aws eks update-addon --addon-name kube-proxy \
    --addon-version v1.34.6-eksbuild.2 --resolve-conflicts OVERWRITE ...
kube-proxy  ACTIVE  v1.34.6-eksbuild.2
coredns     ACTIVE  v1.12.4-eksbuild.10

说明：本环境 add-on 无自定义 configurationValues，故用 OVERWRITE；若有自定义 corefile 或 vpc-cni 环境变量，需带 –configuration-values（从快照取）并视情况用 PRESERVE。

步骤 5　阶段 3：新建 AL2023 节点组（蓝绿替换）

用户提示词：通过 SSM 获取 1.34 的 AL2023 AMI，生成 nodeadm userdata，新建 1.34 节点组

关键输出

获取 AMI 与集群实时 endpoint/CA，生成带 IMDS 设置的 nodeadm（MIME multipart）UserData，创建新 LT 与新节点组：

$ aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.34/\
    amazon-linux-2023/x86_64/standard/recommended/image_id --query Parameter.Value
"ami-0f614d851d082060d"

# nodeadm userdata（endpoint/CA 实时获取，保证一致性）；LT IMDS: HttpTokens=required, HopLimit=2
$ aws ec2 create-launch-template --launch-template-name estore-prod-cnn1-lt-v134 ...
{ "LaunchTemplateId": "lt-0be05f2da1f757f86" }

$ aws eks create-nodegroup --nodegroup-name ng-app-v134 \
    --launch-template id=lt-0be05f2da1f757f86,version=1 ...
{ "status": "CREATING" }   # 09:29 → ACTIVE

步骤 6　检查点 1 + 驱逐 + 检查点 2

用户提示词：检查新节点，没问题就开始驱逐旧节点

检查点 1（新节点就绪后）

$ kubectl get nodes -o wide
NAME            STATUS  VERSION               OS-IMAGE
ip-10-0-0-24    Ready   v1.34.8-eks-3385e9b   Amazon Linux 2023.11.20260526  # 新
ip-10-0-1-148   Ready   v1.34.8-eks-3385e9b   Amazon Linux 2023.11.20260526  # 新
ip-10-0-0-117   Ready   v1.31.13-eks-ecaa3a6  Amazon Linux 2                 # 旧
ip-10-0-1-74    Ready   v1.31.13-eks-ecaa3a6  Amazon Linux 2                 # 旧
# OS=AL2023、kubelet=1.34、新节点成功注册（endpoint 一致）→ 放行

驱逐（打 taint → 逐节点 drain，遵守 PDB）

$ kubectl taint node ip-10-0-0-117... node.kubernetes.io/upgrade=pending:NoSchedule
node/ip-10-0-0-117.cn-northwest-1.compute.internal modified

$ kubectl drain ip-10-0-0-117... --ignore-daemonsets --delete-emptydir-data
pod/checkout-d64fb784f-ks4hp evicted
pod/ui-75b54bd4d5-7wrq8 evicted
pod/coredns-5ff4c8c677-zkzhr evicted
node/ip-10-0-0-117.cn-northwest-1.compute.internal drained

检查点 2（驱逐完成后）

# 旧节点上的非 DaemonSet pod（应为空）
[]
[]

$ kubectl get deploy -n default
carts 2/2   catalog 2/2   checkout 2/2   orders 2/2   ui 2/2 ...
# 全部 Running、副本达标 → 放行缩容

步骤 7　缩容旧节点组 + 阶段 4 验证

用户提示词：缩容旧节点组，做升级后快照并和升级前对比

关键输出

$ aws eks update-nodegroup-config --nodegroup-name ng-app-v131 \
    --scaling-config minSize=0,maxSize=1,desiredSize=0 ...
{ "update": { "status": "InProgress", "type": "ConfigUpdate" } }

$ diff <pre> <post>
<   "version": "1.31",  "platformVersion": "eks.60"
>   "version": "1.34",  "platformVersion": "eks.23"
<   kube-proxy v1.31.14 / coredns v1.11.4
>   kube-proxy v1.34.6  / coredns v1.12.4   (vpc-cni v1.22.1 不变)
<   ng-old-v130 (AL2, 1.30)
>   ng-app-v134 (CUSTOM/AL2023, 1.34, LT=lt-0be05f2...)

终态确认

$ kubectl get nodes
ip-10-0-0-24    Ready  v1.34.8-eks-3385e9b  Amazon Linux 2023
ip-10-0-1-148   Ready  v1.34.8-eks-3385e9b  Amazon Linux 2023
# 旧 AL2 节点已随缩容终止，仅余 2 个 AL2023 / 1.34 节点

$ kubectl get pods -n default | awk '{print $3}' | sort | uniq -c
  17 Running

至此，控制面、Add-on、节点组（含 AL2→AL2023）全部升级到 1.34，升级前后快照 diff 确认配置保留、工作负载健康，整个流程约 50 分钟（含控制面连升约 22 分钟）。

七、定制：根据企业需求调整规则

不同企业的升级策略不尽相同。本方案把「会因团队而异」的约定集中在 rules-internal.md，便于按需修改，而不必改动主流程编排。以下是常见的定制项。

7.1 调整现有企业规范

7.2 可扩展的升级前检查项

除现有规则外，可根据自身架构在 rules-internal.md 或 SKILL.md 的预检部分增加更多检查项，例如：

• 备份：必要时用 Velero 备份集群资源（注意其不覆盖 IAM 等 AWS 资源）。
• 节点升级策略：结合 Cluster Autoscaler / Karpenter 的节点伸缩与升级策略，避免与蓝绿替换相互干扰。
• 容量预检：蓝绿替换期间新旧节点组并存，确认子网 IP、实例配额、可用区容量充足。
• 应用状态确认：定义关键工作负载的健康判定与自动确认标准（如副本数达标、就绪探针通过），作为检查点放行依据。

把这些检查项写入规则文件后，Agent 会在预检与检查点阶段自动核对并报告，进一步降低升级风险。

八、总结

本文展示了如何用 Kiro 配合亚马逊云科技开源 MCP Server，把 EKS 升级的官方与企业最佳实践编码为 Skill 与 Steering，实现升级流程的半自动化执行。其价值在于：把分散的运维知识沉淀为可复用资产，用「默认只读 + 关键步骤人工确认」守住安全底线，用「先规划、设检查点、前后快照 diff」保证过程可控、可审计。对于需要频繁、批量升级集群的团队，这套方法既能提升效率，又能把人为纰漏降到最低。

➡️ 下一步行动：

相关文章：

• 用 Kiro Skill 打造你的专属 AI 工作流：以会议纪要自动生成为例
• 用 Kiro CLI 自动搭建 FluentBit 日志采集方案：两种 EKS 埋点数据落地 S3 Parquet 的实战对比
• 构建无服务器Kiro调度平台：用Kiro CLI + EventBridge + ECS Fargate实现定时AI任务
• 从 SDLC 到 AIDLC：CI&T 对 AI 驱动软件开发模式的探索及Kiro最佳实践
• AI 时代的 EKS 升级范式：用 Kiro-cli 让 Agent 接管识别、升级与排障

九、资源链接

• 本项目（eks-upgrade Skill / Steering / 脚本）
• Open Source MCP Servers for AWS
• eks-mcp-server
• aws-api-mcp-server
• EKS Kubernetes 版本生命周期
• EKS 定价（含扩展支持）
• Kiro

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用