使用 Kiro 辅助 Amazon EKS 集群升级实践
内容提要
本文介绍用 Kiro AI Agent 配合 AWS 开源 MCP Server 辅助 Amazon EKS 集群升级。方案将官方最佳实践与企业运维规范编码为 Skill 和 Steering，通过自然语言驱动升级前检查、控制面逐版本升级、Add-on 升级、节点组蓝绿替换及升级后验证。采用默认只读、关键步骤人工确认、前后快照对比，降低操作复杂度与风险，实现安全可控可审计的升级。
延伸解读
扩展支持的成本压力：升级不只是技术问题
文章以中国区定价为例，标准支持集群控制面为每小时0.688元，而进入扩展支持后升至4.128元，约为前者的6倍。每个次要版本在EKS上享有14个月标准支持，之后进入12个月扩展支持，合计26个月。这意味着长期停留在旧版本不仅面临安全与兼容性风险，还会带来显著的成本增加。对于拥有大量集群的企业，及时升级本身就是一项可量化的成本优化措施。
安全边界设计：默认只读与人工检查点
方案将MCP配置中的autoApprove列表限定为只读操作，如列举K8s资源、查询EKS Insights、读取文档等；所有写操作如update-cluster、update-addon、创建或删除节点组均需用户显式确认。同时，在节点组蓝绿替换中设置两个人工检查点：新节点就绪后驱逐前、驱逐完成后缩容前。这种设计在保留Agent自动化效率的同时，把变更决策权留给运维人员，降低了误操作风险。
企业规范与官方建议的优先级处理
文章明确区分了AWS官方硬性规则与企业内部规范。官方硬性前提如控制面一次只能升一个次要版本、子网需至少5个可用IP、Add-on升级顺序为vpc-cni→kube-proxy→coredns等不可逾越。而企业约定如节点组采用蓝绿替换而非原地升级、Add-on在控制面全部升完后统一升级、AL2到AL2023随蓝绿替换同步完成等，则可在不违反官方硬性前提的情况下优先执行。这种分层让方案既合规又贴合企业实际。
快照与diff：让升级过程可追溯可审计
方案在升级前后各做一次只读快照，输出到本地inventory目录，内容涵盖集群版本、Add-on版本与configurationValues、节点组AMI、Launch Template、labels、taints等。升级后对pre和post两份快照做diff，可确认coredns自定义corefile、vpc-cni环境变量等自定义配置是否被完整保留。这一机制将升级从依赖个人经验的操作转变为有据可查、可回溯的流程，便于事后审计与问题定位。
Q&A
EKS 集群长期不升级会带来哪些成本和安全风险？
每个 Kubernetes 次要版本在 EKS 上享有 14 个月标准支持，之后进入 12 个月扩展支持。以中国区为例，标准支持集群控制面费用为 ¥0.688/小时，扩展支持为 ¥4.128/小时，约为标准支持的 6 倍。长期停留在旧版本不仅有安全与兼容性风险，单集群每小时成本也大幅增加。
Kiro 辅助 EKS 升级的方案整体是怎么运作的？
方案将 AWS 官方 EKS 升级最佳实践和企业内部运维规范编码为 Kiro 的 Skill 与 Steering，并通过 MCP Server 赋予 Agent 操作 AWS/EKS/Kubernetes 的能力。用户用自然语言描述升级意图，Agent 按既定规范完成升级前检查、控制面逐版本升级、Add-on 升级、节点组蓝绿替换及升级后验证。
Kiro 中的 Steering 和 Skill 有什么区别？
Steering 是 .kiro/steering/ 下的 markdown 文件，为 Kiro 提供持久项目知识，每次对话都会加载，作为全局约束。Skill 是遵循开放 Agent Skills 标准的可移植指令包，启动时仅加载元数据（名称与描述），完整内容按需加载，用于封装具体任务流程。
方案如何保证 EKS 升级操作的安全性？
MCP 配置中 autoApprove 只包含只读操作（如 list_k8s_resources、get_eks_insights 等），任何写操作（如 update-cluster、update-addon、创建/删除节点组）都必须经用户显式确认。此外，升级前先输出分步计划，关键步骤设人工检查点，升级前后做快照 diff，确保过程可控、可审计。
EKS 升级流程分为哪几个阶段？
SKILL.md 将升级编排为五个阶段：阶段 0 前置清理与预检（只读检查、快照、废弃 API 扫描等）；阶段 1 控制面逐版本升级；阶段 2 Add-on 升级（顺序 vpc-cni → kube-proxy → coredns）；阶段 3 节点组蓝绿替换（新建 AL2023 节点组替换旧组）；阶段 4 验证（快照 diff、节点与工作负载健康检查）。
节点组蓝绿替换的具体步骤和人工检查点是什么？
步骤：根据旧节点组创建新 Launch Template 和新节点组（AL2023 + nodeadm userdata），保留 labels 等配置；检查点 1（新节点全部 Ready 后）确认 OS、kubelet 版本、IMDS、LT endpoint 一致；给旧节点打 NoSchedule taint，逐节点 cordon+drain 驱逐；检查点 2（驱逐完成后）确认无非 DaemonSet Pod、副本数达标；缩容旧节点组到 0 并保留作为回退模板。
企业如何根据自身需求定制升级规则？
可将因团队而异的约定集中在 rules-internal.md 中修改，例如节点组升级方式（蓝绿替换或原地升级）、命名规范、Add-on 升级时机、AL2→AL2023 迁移策略、旧节点组保留策略、驱逐策略等。还可在预检部分增加备份、容量预检、应用状态确认等检查项，Agent 会在预检与检查点阶段自动核对。
