AI 时代的 EKS 升级范式：用 Kiro-cli 让 Agent 接管识别、升级与排障

eks-rolling-upgrade-skill/
├── SKILL.md                          # 主入口（含 YAML metadata）
└── references/
    ├── version-changes.md            # 每个 K8s 版本变更速查
    ├── troubleshooting.md            # 故障决策树
    └── risk-scoring.md               # 5 维度评分框架

---
name: eks-rolling-upgrade
description: |
  Performs in-place rolling upgrades of Amazon EKS clusters across multiple
  Kubernetes major versions. Encodes hard-won lessons about kubectl drain
  --disable-eviction bypassing EKS managed eviction API, PDB anti-patterns,
  and PVC AZ binding constraints.
---

工程师 → 命令 → AWS API

工程师 → 意图 → Agent → 命令 → AWS API
                  ↓
               读取 Skill
                  ↓
               主动 sanity check
                  ↓
               遇错查询 troubleshooting.md

┌─────────────────────────────────────────────────────────────┐
│  Skill 层（知识）                                             │
│  - SKILL.md：5 Critical Rules + 6 步 Workflow                │
│  - version-changes.md：每个 K8s 版本变更                     │
│  - troubleshooting.md：故障决策树                            │
│  - risk-scoring.md：5 维度评分框架                           │
└─────────────────────────────────────────────────────────────┘
                            ↑ 按需加载
┌─────────────────────────────────────────────────────────────┐
│  Agent 层（行为）                                             │
│  ~/.kiro/agents/eks-upgrade-expert.json                      │
│  - prompt：人格 + 操作原则                                    │
│  - tools / allowedTools：可用工具白名单                       │
│  - toolsSettings：命令级别的安全约束                          │
│  - hooks：会话生命周期钩子                                    │
└─────────────────────────────────────────────────────────────┘
                            ↓ 调用
┌─────────────────────────────────────────────────────────────┐
│  工具层（能力）                                                │
│  - aws-mcp（AWS API 调用、AWS 文档语义检索、Skill 检索）       │
│  - kubectl / helm / eksctl（本地 shell 工具）                 │
│  - Kiro CLI 内置工具（fs_read/fs_write/grep/glob/code）       │
└─────────────────────────────────────────────────────────────┘

1. 一次只升一个 minor 版本（EKS 控制平面无法跨版本升级）
2. 必须先在非生产跑过相同配置的演练
3. 升级前必查 PDB / AZ / 兼容性 / PVC 绑定
4. StatefulSet PVC 必须 EBS snapshot
5. 升级中不要直接 delete StatefulSet pod，让 drain 处理

Step 0: Discover and Confirm（采集集群当前状态、与用户对齐目标）
Step 1: Pre-flight Validation（含 6 个子检查：Insights / PDB / PVC AZ / 失败 addon / 快照 / 配置）
Step 2: Upgrade Control Plane（约 7-12 分钟）
Step 3: Upgrade Add-ons to Target K8s Version
Step 4: Roll Nodes（关键步骤，含主动 drain 模式）
Step 5: Validate
Step 6: Multi-Hop Loop

{
  "name": "eks-upgrade-expert",
  "description": "Amazon EKS rolling upgrade specialist...",
  "prompt": "You are an Amazon EKS rolling upgrade specialist.\n\n# Operating Principles\n1. ALWAYS read the eks-rolling-upgrade skill BEFORE touching any cluster.\n2. EKS only supports one minor version jump at a time.\n3. NEVER run aws eks update-nodegroup-version without first running pre-flight checks.\n4. When stuck on PodEvictionFailure, use the proactive kubectl drain --disable-eviction pattern.\n5. For destructive operations, always show the plan and wait for user confirmation.\n...",
  "tools": ["fs_read", "fs_write", "execute_bash", "use_aws", "@aws"],
  "allowedTools": [
    "fs_read", "grep", "glob",
    "@aws/search_documentation",
    "@aws/retrieve_skill",
    "@aws/get_tasks"
  ],
  "toolsSettings": {
    "execute_bash": {
      "allowedCommands": ["kubectl get *", "helm list *", "aws eks describe-*", "..."],
      "autoAllowReadonly": true
    }
  },
  "resources": [
    "skill://~/.kiro/skills/eks-rolling-upgrade-skill/SKILL.md",
    "skill://~/.kiro/skills/eks-rolling-upgrade-skill/references/version-changes.md",
    "skill://~/.kiro/skills/eks-rolling-upgrade-skill/references/troubleshooting.md",
    "skill://~/.kiro/skills/eks-rolling-upgrade-skill/references/risk-scoring.md"
  ],
  "hooks": {
    "agentSpawn": [
      {"command": "kubectl version --client && eksctl version && aws --version"}
    ]
  }
}

几个值得注意的设计：

安全把关：写操作（fs_write、execute_bash、use_aws 中的写类调用）不在 allowedTools 里，每次都需要用户确认。只读操作（describe-*、list-*、get-*）通过 autoAllowReadonly: true 自动放行。

Skill 加载方式：skill:// URI 启动时只把 metadata（name + description）加载到 context（约 100 tokens），完整内容由 agent 按需加载。这样既保证 agent 知道这个 skill 存在，又不浪费 context。

hooks 自检：agentSpawn 钩子在 agent 启动时跑一次工具版本检查，立刻让用户知道环境是否就绪。

3.4 工具层：aws-mcp

aws-mcp 是一个 Model Context Protocol 服务器，提供 13+ 个 AWS 相关工具。本博客最常用的几个：

agent 在升级过程中会大量使用 call_aws（触发 EKS update / 查 status）、run_script（聚合 add-on 兼容版本）、search_documentation（查 K8s 1.34 release notes 等）。

四、场景一：AI 驱动的风险识别

4.1 传统模式

工程师打开两个浏览器标签：

• 一边查 K8s 1.35 的 release notes
• 一边查 14 个 EKS 官方 Add-on 的 EKS 文档兼容矩阵

然后打开 Excel 或 Google Sheets，手工建一张表，给每个组件打分。这个过程通常耗时 30–60 分钟，且非常容易漏项（比如忘了检查 cluster-autoscaler 与 K8s minor 版本绑定的特殊性）。

4.2 AI 驱动模式

用户打开 Kiro-cli，切换到 EKS 升级专家 agent，输入一句话：

> kiro-cli chat --agent eks-upgrade-expert
[Welcome] EKS Upgrade Expert ready. Tell me the cluster name, region, current
version, and target version — I'll plan the upgrade path and pre-flight checks
before touching anything. The eks-rolling-upgrade skill is loaded; I'll cite
specific steps as I go.

> 我有个集群叫 satest-eks-132，在 us-west-2，当前是 1.32，想升到 1.35。先帮我做风险识别。

Agent 自动执行下列动作（用户什么都不需要做）：

1. 加载 SKILL.md 与 risk-scoring.md（按需懒加载）
2. 调用 aws_eks_describe_cluster / list_addons / helm list -A 取真实当前状态
3. 调用 aws_eks_describe_addon_versions --kubernetes-version 1.35 查每个 add-on 的目标版本
4. 应用 5 维度评分框架给每个组件打分
5. 聚合输出”必升 / 建议升 / 可缓”三类清单

整个过程在测试集群上耗时约 30 秒。Agent 的输出（取自真实运行）：

✅ 已采集集群基线：

• Cluster: satest-eks-132 (us-west-2), K8s 1.32 ACTIVE
• Nodegroup: ng-default, 2× m5.large, AZ b/c
• 8 个 EKS Add-on（全部 ACTIVE）
• 5 个 Helm release，覆盖监控/扩缩容组件

⚠️ 立即需处理：

1. 节点当前只覆盖 AZ b/c、desiredSize=2，但 3 个有状态 PVC 分布在 b/b/c → 升级前必须扩到 ≥3 并保证跨 AZ，否则 PVC AZ 锁会导致 drain 失败
2. 3 个有状态 PVC（prometheus / thanos-storegateway / thanos-compactor）尚无快照 → 升级前必须 EBS snapshot

是否继续生成升级实施计划？

注意 agent 的输出不是套模板——它真的去查了 PVC AZ 分布发现与 nodegroup 节点 AZ 覆盖不匹配、查了有状态 PVC 缺少快照。这两个问题如果工程师手工评估很容易漏掉。

4.3 价值对比

4.4 风险识别的关键产物：有状态 vs 无状态组件清单

5 维度评分里的 D3（有状态） 是决定升级策略的分水岭——它直接驱动后面第 5 章 pre-flight 中”快照 PVC、扩 AZ”这些动作。agent 在风险识别阶段会把组件先拆成两类：

4.4.1 无状态组件（升级较简单，可随 K8s 滚动）

无状态组件升级建议：保证 ≥2 副本 + 合理 PDB（maxUnavailable=1），随节点滚动；升级前用 aws eks describe-addon-versions --kubernetes-version <目标> 核对兼容版本号即可。

4.4.2 有状态组件（带持久卷/外部存储，需重点保护）

对有状态组件，agent 会在 pre-flight 强制执行以下 6 条（对应 SKILL.md Critical Rules）：

1. 升级前快照（必做）：对所有有状态 PVC 做 EBS snapshot；Thanos 额外开启 S3 版本控制防误删/覆盖。
2. 解决 PVC 的 AZ 锁：EBS 卷绑定单一 AZ，Pod 只能调度到该 AZ 节点——确保每个有状态 PVC 所在 AZ 都有 ≥1 个可调度节点，即 desiredSize ≥ AZ 数。
3. 修复 PDB 反模式而非绕过：单副本 + minAvailable=1 → disruptionsAllowed=0 永久锁死；正确做法是副本提到 ≥2，或确需单副本时改 maxUnavailable=1。kubectl drain --disable-eviction 直接 DELETE Pod 会绕过 PDB 的可用性保护，仅作已快照后的兜底逃生通道，不应作为有状态服务的默认手段。
4. 用 StatefulSet 控制器有序滚动：升级中不要手动 delete StatefulSet pod，让 drain/controller 处理，保证 PV 重挂顺序正确。
5. 升级后验证数据连续性：Prometheus 确认 TSDB 持续写入无空洞；Thanos 确认继续向 S3 读写 block、compactor 正常压缩。
6. 回滚预案：有状态组件靠 helm rollback + 从 EBS snapshot 恢复 PVC；控制面升级成功后不可降级，快照是有状态数据唯一的安全网。

五、场景二：AI 驱动的升级执行

5.1 传统模式

升级 EKS 1.32 → 1.35 需要 3 跳，每跳 4 步（控制面 → addon → 节点 → 验证）。工程师拿着 runbook 一行行执行：

# 1.32 → 1.33
aws eks update-cluster-version --name X --kubernetes-version 1.33
# 等 12 分钟
aws eks update-addon --addon-name kube-proxy --addon-version v1.33...
aws eks update-addon --addon-name coredns ...
# 等 add-on ACTIVE
aws eks update-nodegroup-version --nodegroup-name ng-default
# 等 15-20 分钟，期间盯着 kubectl get nodes
# ... 验证 ...

# 1.33 → 1.34
# ... 重复上面 ...

# 1.34 → 1.35
# ... 重复上面 ...

每一步都要工程师盯着输出、判断状态、决定何时进入下一步。中间任何一步漏掉 sanity check 都可能踩坑。

我们在真实测试集群上第一次跑这个流程时（无 AI 辅助），1.32 → 1.33 单跳就花了约 4 小时——80% 的时间在 troubleshoot 第一次踩到的隐性约束。

5.2 AI 驱动模式

用户在 agent 中确认了风险评估后，直接说：

> 按你的逻辑滚动升级到 1.35

Agent 主动执行：

第 0 阶段：升级前准备（约 5 分钟）

Agent 输出：

按 SKILL.md Step 1 执行 pre-flight：

1️⃣ Cluster Insights 扫描
   → aws eks list-insights：[] 无阻断项 ✓

2️⃣ 给关键工作负载加 PDB（注意：使用 maxUnavailable=1 避免单副本锁死）
   → 已为 prometheus / thanos-query / kube-state-metrics / coredns-extra 创建 4 个 PDB
   → 共 10 个 PDB 全部 allow=1

3️⃣ PVC AZ 检查：prometheus / thanos-compactor 在 AZ b，thanos-storegateway-0 在 AZ c
   → 节点当前只在 AZ b/c，存在 AZ 覆盖不足风险

4️⃣ nodegroup desiredSize 从 2 → 3（保证跨 3 AZ 各 1 节点）
   → 33 秒后 ACTIVE，AZ a 节点起来

5️⃣ 3 个有状态 PVC 做 EBS snapshot
   → prometheus → snap-0f6ed85152f5c5028
   → thanos-storegateway → snap-040728e2619c840e0
   → thanos-compactor → snap-0897d1cc6f60dba68

6️⃣ nodegroup updateConfig.maxUnavailable=1
   → Successful

✅ Pre-flight 完成。是否开始第 1 跳：1.32 → 1.33？

这一步里的几项检查都对应着官方文档：兼容性检查（废弃 API、升级阻断项）以 EKS Cluster Insights / Upgrade Insights 为权威来源，叠加 集群升级总览 的 version skew 约束与 集群升级最佳实践；Skill 在此之上额外编码了文档未串联的隐性约束（PVC AZ 覆盖、PDB 反模式）。

第 1 跳：1.32 → 1.33

开始 1.32 → 1.33...

[控制面] 触发 update-cluster-version
  0s | UPDATING
  408s | ✓ 1.33 ACTIVE（耗时 6 分 48 秒）

[Add-on] 升级到 1.33 兼容版本
  - coredns: v1.11.4 → v1.12.4
  - kube-proxy: v1.32.13 → v1.33.10
  - 其他 6 个：已是最新或向后兼容
  ✓ 全部 ACTIVE（耗时 14 秒）

[节点组] 触发 update-nodegroup-version
  → 触发 EKS update
  → 等 90s 让 3 个 surge 节点（跨 3 AZ）起来
  → 主动 kubectl drain --disable-eviction（按 SKILL.md Step 4.3）
  → 迁移 prometheus-0 / thanos-storegateway-0 / thanos-compactor 等有状态 Pod（带 PVC）
  → 老节点全部 drained
  → 等 EKS terminate 老实例 + 完成 update（约 7 分钟）

[验证]
  ✓ 3 个节点全部 1.33，跨 3 AZ
  ✓ 33 个 Pod 全部 Running
  ✓ Prometheus 持续上报数据，未中断
  ✓ Thanos 持续上传到 S3

第 1 跳完成（总耗时约 16 分钟）。建议观察 ≥30 分钟稳定后进入第 2 跳。是否继续？

第 2 跳与第 3 跳

由于 pre-flight 已经完成、该模式已验证，第 2 跳变成纯流水线；第 3 跳则意外踩到一个 Skill 尚未编码的全新坑：

1.33 → 1.34: 控制面 7m17s + addon 14s + 节点 surge/drain ~9m = 约 16 分钟（零失败）
1.34 → 1.35: 控制面 6m46s + addon 45s + 节点 ~9m，但前两次 nodegroup update
             因 surge 节点 Ready=False 失败回滚 → SSM 诊断定位到全新坑
             （vpc-cni v1.21+ 节点 IAM 缺 AmazonEKS_CNI_Policy）→ 总计约 60 分钟

第 3 跳的”全新坑”正是本文 6.x 与第七章讨论的 Pitfall 8——它没有被 Skill v1.0 编码，但 agent 借助 Skill 内置的”SSM 5 步诊断法”在 30 分钟内定位到真因，并把这条知识反哺回 Skill 形成 v1.1。

5.3 关键差异：从”托管 drain”到”主动 drain”

传统模式下，awseks update-nodegroup-version 内部使用 K8s 驱逐 API（eviction API），严格遵守 PDB。任何瞬时的 PDB 不满足都会导致重试，超过重试阈值后整个 update 失败回滚。

agent 在 SKILL.md Step 4.3 中显式编码了这套”主动 drain、绕过托管驱逐”的做法：

# 1. 触发 EKS update（EKS 开始拉起新版本的 surge 节点）
aws eks update-nodegroup-version --cluster-name $C --nodegroup-name $NG

# 2. 等 surge 节点 Ready（约 90s）
sleep 90

# 3. 主动 drain 所有旧版本节点（$OLD_NODES 由 kubectl 按 kubelet 版本筛选得到）
#    --disable-eviction 走 DELETE pod，绕过 PDB（关键）
for n in $OLD_NODES; do
  kubectl drain $n --ignore-daemonsets --delete-emptydir-data \
    --disable-eviction --grace-period=30 --timeout=600s &
done
wait

# 4. 节点被腾空后，EKS 自动 terminate 旧实例并标记 update 完成

这个方法在第一次升级（无 Skill 辅助）时我们花了约 3 小时才摸索出来；加载 Skill 后 agent 在第 1 跳就直接应用了，省下了所有摸索时间。

控制平面与数据平面检查的官方出处：控制面升级流程（约 7-12 分钟、不可回滚、健康检查失败自动回滚）见 Step 3 更新控制平面；本节描述的托管节点组驱逐行为——PodEvictionFailure、15 分钟驱逐超时、Aggressive PDB、force 不遵守 PDB——其权威来源是 理解节点更新的各阶段 与 更新托管节点组。官方明确写了”Rolling update 遵守 PDB、Force update 不遵守 PDB”——这也是为什么单靠 --force 重试无法解决 PDB 锁死，必须改用主动 drain。

5.4 价值对比（真实数据）

下表对比同一集群两次完整升级的逐跳实测耗时——两次都由 AI agent 执行命令，唯一变量是是否加载 Skill（数据与第 10.1 节总表一致）：

注意 1.34 → 1.35 在 Record 2 反而更慢——因为踩到 Record 1 没踩到的全新坑（vpc-cni v1.21+ 节点 IAM 权限）。但 agent 借助 Skill 内置的”SSM 5 步诊断法”在 30 分钟内定位真因（vs 同类未知坑在 Record 1 平均 80 分钟），并把这条知识沉淀进 Skill v1.1——下次同样的坑会被自动预防。这正说明 Skill 的价值不只在”快”，更在”系统性消除踩坑成本 + 知识可累积”。

六、场景三：AI 驱动的故障排查

6.1 传统模式

故障：节点组升级到一半，EKS 报：

PodEvictionFailure: Reached max retries while trying to evict pods from
nodes in node group ng-default

工程师的典型反应路径：

1. 看到错误 → 觉得是网络问题 → 重试      [失败]
2. 加 --force flag → 重试                 [失败]
3. google "EKS PodEvictionFailure"       [信息混乱]
4. 看 EKS 文档 → 节点更新行为页讲了 PodEvictionFailure 与 Aggressive PDB，但没说"PDB + PVC AZ + 托管驱逐"会三者纠缠
5. 找内部 Slack → 找到一个老员工的笔记
6. 才知道要查 PDB / PVC AZ / drain --disable-eviction

我们的真实测试中，这一段花了约 3-4 小时。

6.2 AI 驱动模式

故障发生时，agent 主动调用 troubleshooting.md 决策树：

检测到 PodEvictionFailure。按 troubleshooting.md 决策树定位：

1️⃣ 检查 PDB 是否阻塞？
   → kubectl get pdb -A 显示：
     monitoring/prometheus-pdb minAvailable=1, replicas=1, allowed=0  ❌
     monitoring/thanos-query-pdb minAvailable=1, replicas=1, allowed=0 ❌
   → 命中"PDB minAvailable + replicas=N 反模式"

2️⃣ 检查 PVC AZ vs Node AZ？
   → Prometheus PVC 在 us-west-2a，节点也在 a ✓
   → Thanos PVC 在 us-west-2c，节点也在 c ✓
   → 此项 OK

3️⃣ 应用主动 drain 模式？
   → 由于 PDB 严格性，直接用 kubectl drain --disable-eviction 绕过

修复建议：
   1. 把 PDB 从 minAvailable=1 改为 maxUnavailable=1（保留单副本可驱逐性）
   2. 或者把 Prometheus / Thanos 的 replicas 提到 ≥2
   3. 然后用 kubectl drain --disable-eviction 主动 drain 老节点

是否执行修复方案 1 + 主动 drain？

整个诊断 + 修复耗时约 5 分钟。Agent 直接命中真因（PDB 反模式），并给出已经验证过的修复方法。

6.3 troubleshooting.md 决策树（节选）

PodEvictionFailure
│
├── Step 1: kubectl get pdb -A → 找 disruptionsAllowed=0 的
│   ├── Yes → "PDB 反模式"，改 maxUnavailable
│   └── No  → 进 Step 2
│
├── Step 2: PVC AZ vs Node AZ
│   ├── 不匹配 → "AZ 锁"，扩 desiredSize
│   └── 匹配 → 进 Step 3
│
└── Step 3: 套用 kubectl drain --disable-eviction
    └── 始终能解

6.4 价值对比

关键发现：第二次实战（Skill v1.0 已就位）时，agent 在 1.34→1.35 阶段又踩到了 Skill 里没有的全新坑（节点 IAM 缺 AmazonEKS_CNI_Policy 导致 vpc-cni v1.21+ 给 ENI 打 tag 失败 → 节点永远 NotReady）。这种未知坑没有现成文档记录、Skill 也未编码，但因为 Skill 已经沉淀了”SSM 5 步诊断法”作为通用方法论，agent 30 分钟就定位到真因（vs 第一次踩同类坑的 80 分钟）。这说明 Skill 不只是”已知问题数据库”，更是”诊断方法论的载体”——哪怕遇到第一次的新问题，方法论本身就让排查更快。

七、运维流程的范式转移

7.1 从”人 → 命令”到”人 → 意图 → Agent → 命令”

传统模式：工程师每天的大量精力花在”把业务意图拆解为具体命令”上：把业务意图（”集群升级到 1.35″）翻译成几十条具体命令。这个翻译过程消耗大量脑力，且每个工程师翻译质量差异很大。

AI 模式让 agent 承担”翻译”工作。工程师停留在”意图层”——他只需要描述想要什么、确认 agent 的方案，至于具体执行什么命令、何时执行，由 agent 自动决策。

工程师的角色从”逐条执行命令”升级为”审批方案与把控决策”。

7.2 知识沉淀：每次踩坑后 Skill 迭代

传统模式下，工程师踩坑解决问题后，知识停留在他的笔记里。换个工程师、换个时间，同样的坑也许还会被踩一遍。

AI 模式下，工程师把踩坑发现写进 SKILL.md 或 troubleshooting.md，拉取最新版 Skill 后即可获得。Skill 像代码一样可以版本控制（git）、可以 PR review、可以多人协作。团队整体能力随时间上升。

7.2.1 真实案例：Pitfall 8 的演进

第一次实战时（注意：第一次也用了 kiro-cli + aws-mcp，只是没加载 Skill——agent 接管命令执行，但每个失败都靠工程师人工诊断后告诉 agent 怎么修复），团队记录下了 7 个 Pitfall（PDB 反模式 / PVC AZ 锁 / drain –disable-eviction 等），整理成 Skill v1.0。一周后我们用同样的工具链 + 加载 Skill v1.0 跑第二次实战，agent 在 1.34→1.35 节点滚动阶段又遇到一个全新问题：节点 IAM 缺 AmazonEKS_CNI_Policy 导致 vpc-cni v1.21+ 给 ENI 打 tag 失败 → 节点永远 NotReady → EKS 等不到 Ready 直接 terminate surge 节点回滚。

这个坑：

• 节点角色需要 AmazonEKS_CNI_Policy 这一点在建节点角色文档里有，但升级文档完全没提示”缺它会导致 surge 节点 NotReady→回滚”——跨页关联缺失
• eksctl 默认 withAddonPolicies 配置没加（它假定 vpc-cni 走 IRSA）
• 第一次实战时没踩到（旧 nodegroup 用了不同的 AMI / IAM 配置）
• Skill v1.0 里没编码

但 agent 用 Skill v1.0 里的”SSM 5 步诊断法”在 30 分钟内定位到真因（grep 节点上的 ipamd.log 看到 UnauthorizedOperation: ec2:CreateTags），修复后立即把这条知识写回 Skill：

SKILL v1.0 → SKILL v1.1
新增：
- Pitfall 8: 节点 IAM 缺 AmazonEKS_CNI_Policy（症状/真因/修复/预防）
- Step 1.4b: 节点 IAM policy 完整性 pre-flight 检查（CRITICAL）
- references/troubleshooting.md: PodEvictionFailure 5 步法 + 三种 IPAMD 失败模式

下次任何团队成员调用这个 Skill，agent 在 Step 1.4b 阶段就会自动检测节点 IAM，发现缺 policy 主动修复——这条知识零成本传给所有人。

这个对比的精妙之处：第一次实战是”agent + 工程师人工辅助”，遇到隐性坑要靠人脑诊断；第二次实战是”agent + Skill”，agent 用 Skill 里编码的诊断方法论自主排查。两次都是 AI 工具，差别只在 Skill——这证明 Skill 才是 agent 在专业领域真正起作用的”知识引擎”。

7.2.2 Skill 的成长曲线

[图1]

Skill 化的知识每次实战都会有所增长，不会因人员流动而退化。

7.3 决策权依然在人

这是必须强调的点：Agent 不是”自动驾驶”。设计时通过两个机制确保人始终掌控决策：

1. Prompt 层 Critical Rule 5：明确写入”destructive operations always need explicit user confirmation”
2. toolsSettings 层：写操作不在 allowedTools 中，每次都需要人工 y/n 确认

我们在真实测试中明确感受到这一点：agent 升级集群时，每次 destructive 操作（删 add-on、改 PDB、滚节点、删集群）都会暂停等待用户确认，不会自己做决定。

7.4 这套范式可推广到哪里

EKS 升级只是一个起点。任何具备以下特征的运维场景都适合迁移到 AI 模式：

我们计划继续把这个范式应用到 RDS 主版本升级、VPC IPv6 迁移、合规扫描自动化等场景。

八、动手部署：把这套能力搬到你的环境

8.1 前置条件

• macOS / Linux（Windows 需 WSL2）
• 已安装 Kiro CLI 与 aws-mcp
• AWS CLI 已配置 credentials
• 目标集群已经能用 kubectl 访问

8.2 安装工具链

# 安装 kubectl / helm / eksctl
brew install kubernetes-cli helm eksctl

# 验证
kubectl version --client
helm version --short
eksctl version

8.3 部署 Skill

把 skill 文件夹拷到 Kiro 识别的位置：

# 全局（所有项目可用）
mkdir -p ~/.kiro/skills
cp -r /path/to/eks-rolling-upgrade-skill ~/.kiro/skills/

# 验证文件就位
ls ~/.kiro/skills/eks-rolling-upgrade-skill/
# SKILL.md  references/

8.4 创建 Agent 配置

新建 ~/.kiro/agents/eks-upgrade-expert.json，内容参考第 3.3 节给出的完整 JSON。

# 校验
kiro-cli agent validate --path ~/.kiro/agents/eks-upgrade-expert.json
# ✓ valid

# 列出 agent 应能看到
kiro-cli agent list | grep eks-upgrade-expert

8.5 第一次会话验证

kiro-cli chat --agent eks-upgrade-expert

切换时会自动跑 agentSpawn hook 打印工具版本。然后你可以输入：

> 我有个集群 satest-eks-132，us-west-2，1.32，先做风险识别

agent 会自动执行场景一中描述的流程。

8.6 把 Skill 共享给团队

Skill 是普通的 Markdown 文件，自然适合 git 管理。建议团队建一个 team-skills 仓库：

team-skills/
├── eks-rolling-upgrade-skill/
├── rds-major-version-upgrade-skill/
└── vpc-ipv6-migration-skill/

每个 SRE 在自己机器上 git clone 后 symlink 到 ~/.kiro/skills/。Skill 迭代通过 PR review 进行——任何踩坑发现都可以变成社区资产。

九、常见问题

Q1: AI 决策可信吗？会不会乱执行命令？

不会。Agent 设计时通过三层把关：

• Skill 层：Critical Rule 5 明确写”destructive 操作必须人工确认”
• Agent 层：写工具不在 allowedTools 中
• Kiro CLI 层：所有非自动批准的工具调用都会弹出 y/n/t 提示

我们在真实测试中明确观察到 agent 每次 destructive 操作（删 addon / 改 PDB / 滚节点 / 删集群）都会暂停等待用户输入。

Q2: Skill 怎么维护、怎么版本管理？

Skill 是普通 Markdown 文件，git 管理即可。每次踩坑后写一个 PR：

• 加 Critical Rule（如果是新发现的硬约束）
• 加 Pitfall 条目（如果是新踩到的坑）
• 加 troubleshooting 决策树分支
• 加 version-changes 条目（如果是新 K8s 版本）

每个 PR 都要在测试集群上验证有效，再 merge。

Q3: 团队多个 SRE 怎么共享同一个 agent 配置？

两种方式：

• Workspace agent：把 agent.json 放在项目仓库 .kiro/agents/ 中，团队所有人 clone 仓库就能用
• Global agent：放在 ~/.kiro/agents/，需要 SRE 各自维护本地副本

我们推荐 Workspace + Skill 通过中央仓库管理。

Q4: 跟 AWS Trusted Advisor / EKS Cluster Insights 是什么关系？

互补关系：

• Cluster Insights：AWS 官方服务，提供基础的升级前阻断检查
• 本方案：在 Insights 之上增加自管理组件评估、隐性约束检测、自动化执行、故障排查决策树

我们的 agent 第一步就会调用 aws eks list-insights 把 Insights 结果纳入风险评估。

Q5: 升级失败的回滚也靠 AI 吗？

部分。agent 可以自动执行：

• Add-on 降级（update-addon --addon-version <旧版>）
• Helm rollback（helm rollback <release> <revision>）
• Nodegroup launch template 回滚

但控制面升级 EKS 不支持回滚，agent 会明确告知用户。

Q6: 节点组升级卡在 PodEvictionFailure 怎么办？

按 troubleshooting.md 决策树：先查 PDB（最常见原因）→ 查 PVC AZ 覆盖 → 套用 kubectl drain --disable-eviction。Agent 会自动执行这套流程。

Q7: 为什么 --force 不起作用？

--force 只在节点已经 NotReady 时跳过 drain 等待，不绕过驱逐 API 路径的 PDB 检查。所以对”PDB 锁死单副本”这类场景 --force 无效。

Q8: bitnami helm chart 拉镜像失败怎么办？

bitnami 在 2026 年初把公共 Docker Hub 镜像迁到了付费的 bitnamisecure/。装 thanos/redis 等 chart 会出现 ImagePullBackOff。修复：override image.registry=quay.io + 设 global.security.allowInsecureImages=true。Agent 在 troubleshooting.md 中编码了这条修复方法。

十、总结

10.1 价值对比表（基于两次完整实战的实测数据）

下表对比同一集群、同一组件清单、**同一 AI 工具链（kiro-cli + aws-mcp）**下两次完整跑通 1.32 → 1.35 升级的实测耗时——唯一变量是是否加载 Skill：

口径说明：Record 1 的原始记录里，”集群创建”约 60 分钟已包含 14 个 Add-on 与 6 个 Helm 组件的安装，并非创建与安装两段相加；为与 Record 2（创建/安装分段记录）对齐，上表合并为一行。需要强调的是，集群创建与组件安装这两件事与”是否加载升级 Skill”基本无关——真正能体现 Skill 价值的是”升级三跳小计”这一行（节省 69%）；”总耗时节省 60%”包含了与 Skill 无关的建栈时间，仅供整体参考。

重要说明：两组数据都是 AI Agent 完成的——Record 1 不是”传统手工”，而是”Agent 跑命令但工程师必须实时介入诊断”。这意味着上表的差距不是”AI vs 人工”的差距，而是”Agent 有没有 Skill”的差距。换句话说：Agent 工具本身只是把命令自动化；真正让 agent 在专业领域产生 10× 效率的是 Skill 知识库。

专项指标

关键洞察：1.34 → 1.35 在 Record 2 反而比 Record 1 更慢（60 分钟 vs 22 分钟），是因为踩到了 Record 1 没踩到的全新坑（vpc-cni v1.21+ 节点 IAM 权限）——但 agent 借助 Skill 内置的”SSM 5 步诊断法”在 30 分钟内定位到真因（vs 同类未知坑在 Record 1 平均 80 分钟）。这恰恰证明 Skill 价值不只在”快”，而在”系统性消除踩坑成本 + 知识可累积”。第二次踩到的新坑被自动反哺回 Skill 形成 v1.1，下次第三次实战这个坑也会被预防——能力在跨实战间单调上升。

注：核心价值不是”快”，而是**”消除工程师反复介入诊断 + 知识沉淀可传承”**。Record 1 中 agent 虽然跑命令但每次失败都需要工程师停下来诊断，相当于”agent + 人工调试”的杂交模式；Record 2 中 agent 自主按 Skill workflow 执行，工程师仅在 destructive 操作时拍板。新人不再依赖老员工带教就能独立做。

10.2 适用场景

• 长期未升级、跨多个 K8s 大版本需要追赶的 EKS 集群
• 自管理可观测性组件较多的 EKS 集群
• 团队 SRE 经验参差不齐、希望降低对个人 know-how 依赖
• 计划逐步把运维知识从”人脑”搬到”机器”的组织

10.3 后续延伸

同一套 Skill + Agent 范式可以迁移到：

• RDS 主版本升级（PostgreSQL 16 → 17、Aurora MySQL 3 → 4 等）
• VPC IPv6 迁移
• 合规扫描自动化（CIS / PCI-DSS / SOC2）
• 跨账号灾备演练

每个领域只需建立对应的 Skill 知识库 + Agent 配置，就能复制本博客描述的”识别 / 执行 / 排障”工作流。

10.4 Skill 是会成长的资产

普通文档写完就不更新；Skill 像代码一样持续迭代。

每次踩坑都让团队整体能力底线上升一格——这是组织层面的资产累积，不是个人层面的经验积累。投资是一次性的（写 Skill），回报是持续的（每次升级都用上）。

10.5 一句话总结

EKS 升级这件事不应该再让运维人员靠记忆完成。Skill 化的知识 + Agent 化的执行 + 人主导的决策，是云运维在 AI 时代的新范式。

➡️ 下一步行动：

相关产品：

• Amazon EKS — 托管式 Kubernetes 服务
• Amazon IAM — 身份管理和访问权限
• Amazon EBS — 高性能数据块存储
• Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
• Amazon VPC — 隔离云网络

相关文章：

• 用 Kiro Skill 打造你的专属 AI 工作流：以会议纪要自动生成为例
• 当 Kiro 遇上 OpenClaw：AI Agent 双向协作的实践探索
• 用 Kiro CLI 自动搭建 FluentBit 日志采集方案：两种 EKS 埋点数据落地 S3 Parquet 的实战对比
• 以Kiro快速部署云上Agent：只需几个小时，从业务需求到部署于Amazon Bedrock Agentcore落地
• 用 Kiro构建 AI：基于 AWS 基础设施快速构建企业级 Agentic AI 平台

十一、参考资源

11.1 EKS 升级与版本兼容（兼容性检查）

• Amazon EKS 集群版本与生命周期
• 更新集群到新 Kubernetes 版本（含 version skew 约束）
• Amazon EKS Cluster Insights — 升级前的诊断工具
• EKS 集群升级最佳实践
• Kubernetes 版本与 Version Skew 策略（上游）
• Kubernetes 废弃 API 迁移指南（上游）

11.2 节点组与驱逐行为（数据平面检查）

• 理解节点更新的各阶段（PodEvictionFailure / 15 分钟驱逐超时 / Aggressive PDB / force 行为）
• 更新托管节点组（Rolling vs Force update 对 PDB 的处理）
• PodDisruptionBudget（上游）
• 节点 IAM 角色与所需策略（Pitfall 8 关联）

11.3 Add-on 与存储

• Amazon Linux 2023 on Amazon EKS
• VPC CNI 推荐版本 · CoreDNS · kube-proxy
• EBS 卷与 Availability Zone 绑定特性（PVC AZ 锁根因）

11.4 工具链与方法论

• Kiro CLI 官方文档
• Model Context Protocol（MCP）规范
• Agent Skills 设计指南
• Kubernetes 1.33 / 1.34 / 1.35 Release Notes

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

本篇作者

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