把 Kubernetes 工作负载从 AWS EKS 迁移到 Google Kubernetes Engine（GKE），难点从来不只是把 YAML 中的字段换个名字。身份、网络入口、镜像仓库、节点供给和有状态数据都带有云平台语义；如果直接让通用大模型批量改写 Terraform 和清单，得到的配置往往“看起来合理”，却可能包含不存在的属性、过期 API，或者悄悄漏掉关键安全规则。
GKE agentic migration 的价值在于把 AI 放进一条受约束的迁移流水线：模型负责需要推理的翻译工作，确定性工具负责精确映射和离线验证，所有结果通过 Pull Request 进入现有 GitOps 审批流程，而不是直接修改生产集群。
AI 可以写代码，但不能独自决定目标状态
这套方法将迁移视为一次“编译”，而不是一次聊天：
- 扫描 EKS 代码仓库或现有集群，建立资源清单和依赖关系。
- 识别架构不兼容项，为阻塞问题分配负责人和解决日期。
- 明确 GKE 落地区设计，例如 Autopilot 或 Standard、网络边界和组织策略。
- 由 AI 生成 Terraform、Kubernetes 清单和迁移说明。
- 对身份、镜像地址等精确映射执行确定性转换。
- 离线运行 Terraform 和清单验证。
- 生成 Pull Request，等待人工审查和 CI/CD 放行。
这里的关键不是模型能力有多强，而是模型没有绕过治理的路径。迁移状态被持久化后，平台团队可以先建立 landing zone，应用团队再从各自的工作区迁移服务；长期迁移不会因为换人、换机器或一次对话结束而丢失上下文。
云资源不是简单的一对一替换
一些转换有明确方向，但仍需要平台决策。
IRSA 到 Workload Identity
EKS ServiceAccount 可能通过 IRSA 关联 IAM Role：
apiVersion: v1
kind: ServiceAccount
metadata:
name: orders-api
namespace: orders
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/orders-api
迁移到 GKE 后，可以将其改为指向 Google Cloud 服务账号。运行前应替换项目 ID 和服务账号名称：
apiVersion: v1
kind: ServiceAccount
metadata:
name: orders-api
namespace: orders
annotations:
iam.gke.io/gcp-service-account: orders-api@PROJECT_ID.iam.gserviceaccount.com
这只是 Kubernetes 侧配置。还必须在 Google Cloud IAM 中授予相应身份绑定和最小权限角色。一个安全的迁移器不能仅替换注解，然后假定授权已经完成；它应同时生成 Terraform 变更或明确的待办项。
ALB、Karpenter 与镜像仓库
其他映射更像架构重设计：
- AWS Load Balancer Controller 管理的 ALB Ingress，可以迁移到 GKE Gateway API，但监听器、健康检查、证书和安全策略并不保证一一对应。
- Karpenter NodeClaim 可以映射到 GKE Node Auto Provisioning，或在需要明确硬件约束时使用 Custom Compute Classes。
- ECR 镜像地址可以迁移到 Artifact Registry，但镜像复制、摘要核验和部署身份授权必须单独处理。
- GPU 节点迁移需要重新检查机型可用区、驱动、配额和切分策略，不能只转换资源 requests。
因此，AI 适合提出目标配置草案，确定性规则适合处理可证明的映射，而平台工程师必须批准那些涉及成本、可靠性和安全边界的选择。
可以这样实践：在仓库里建立迁移状态和离线门禁
下面是一个可改造的最小目录。它不是该插件的固定目录约定，而是展示如何把迁移状态、生成结果和验证脚本放进同一 GitOps 仓库：
migration/
├── migration-state.yaml
├── source-eks/
├── target-gke/
│ ├── terraform/
│ └── kubernetes/
└── scripts/
└── preflight.sh
用结构化文件记录边界、阻塞项和审批状态，避免关键决定只留在聊天记录中：
migrationId: orders-prod
phase: assessment
source:
platform: eks
region: us-east-1
target:
platform: gke
projectId: replace-me
region: us-central1
mode: standard
blockers:
- id: NET-001
description: Confirm private egress and NAT design
owner: platform-team
targetDate: "2026-04-15"
status: open
- id: DATA-001
description: Select an approved database migration method
owner: data-team
targetDate: "2026-04-22"
status: open
approvals:
platformBoundary: pending
applicationTranslation: pending
然后在 scripts/preflight.sh 中设置离线验证。运行前需要安装 terraform 和 kubectl，并把目录改成自己的仓库结构：
#!/usr/bin/env bash
set -euo pipefail
ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
TF_DIR="$ROOT/target-gke/terraform"
K8S_DIR="$ROOT/target-gke/kubernetes"
command -v terraform >/dev/null || {
echo "terraform is required" >&2
exit 1
}
command -v kubectl >/dev/null || {
echo "kubectl is required" >&2
exit 1
}
echo "==> Checking Terraform formatting"
terraform -chdir="$TF_DIR" fmt -check -recursive
echo "==> Initializing without a remote backend"
terraform -chdir="$TF_DIR" init -backend=false -input=false
echo "==> Validating Terraform"
terraform -chdir="$TF_DIR" validate
echo "==> Parsing Kubernetes manifests without applying them"
while IFS= read -r -d '' file; do
echo "Checking $file"
kubectl apply --dry-run=client --validate=false -f "$file" >/dev/null
done < <(find "$K8S_DIR" -type f \( -name '*.yaml' -o -name '*.yml' \) -print0)
echo "Preflight checks passed"
执行方式：
chmod +x migration/scripts/preflight.sh
./migration/scripts/preflight.sh
kubectl --dry-run=client --validate=false 只能发现 YAML 解析和部分对象结构问题，不能替代服务端准入控制、CRD Schema、策略引擎或真实集群测试。生产流水线还应加入固定版本的 Schema 校验器、组织策略检查、安全扫描以及 Terraform plan 审批。
为什么必须通过 Pull Request 交付
迁移工具直接调用集群 API 看似省事，却会制造新的事实来源：Git 里是一套配置，集群里是另一套配置，回滚时也难以确认哪些资源是人工修改、脚本修改还是控制器生成。
PR 工作流保留了几个重要属性：
- 每次转换都有可读差异和提交记录。
- CODEOWNERS 可以让网络、IAM 和应用团队分别审批自己的边界。
- CI 可以重复执行相同验证，而不是依赖操作者本地环境。
- 合并和部署相互分离，可以使用既有的发布窗口和回滚机制。
- AI 生成内容与人工修改都进入同一审计链。
人工审批不应只是点击“Approve”。审查者至少要核对身份权限是否扩大、网络是否意外暴露、存储类和可用区语义是否改变，以及扩缩容策略是否会造成成本突增。
数据迁移要与配置翻译分开
基础设施翻译和数据搬运的风险模型不同。迁移插件可以为数据库、对象存储和持久卷生成上下文相关的 runbook，但不应擅自传输生产数据。
实际执行时，可以让配置 PR 创建目标数据库连接、Secret 引用和网络路径，再由数据团队使用具备 SLA、校验和重试能力的专用服务完成传输。例如数据库可以评估 Database Migration Service，对象数据可以评估 Storage Transfer Service。切换前还要定义停写窗口、增量同步、校验方法和回退条件。
落地前的检查清单
采用 AI 辅助迁移时，建议坚持以下边界：
- Git 是目标配置的唯一事实来源，工具不得绕过 PR 直接变更集群。
- 所有阻塞项必须有负责人、截止日期和明确状态。
- AI 输出必须通过 Terraform、Kubernetes Schema、策略和安全扫描。
- IRSA、Ingress、节点供给和 GPU 配置按架构变更审查，不按字符串替换审查。
- 平台团队与应用团队使用隔离目录和独立审批边界。
- 数据传输使用专用服务，并单独设计一致性验证与回滚。
- Autopilot、Standard、NAP 或 CCC 等决策应记录依据，而不是由模型默认选择。
这类插件并没有消除迁移复杂度，而是把复杂度变成可见的状态、可执行的验证和可审计的决策。AI 缩短编写与分析时间；确定性工具、GitOps 和人工审批则负责让速度不会以生产风险为代价。