作者把同一套 Node.js 应用从家庭 k3s 服务器迁到 Amazon EKS，应用代码、容器镜像、Helm chart 与 GitOps 交付模型全部原样保留，但平台层暴露了三个家庭环境不存在的假设：网络、工作节点规格与 AWS 访问。
测试用 Terraform 创建了最小环境：一个 EKS 1.36 集群、一个托管 AMD64 工作节点、两个跨可用区公共子网、AWS Load Balancer Controller 与 Argo CD Core。控制平面创建耗时 5 分 51 秒，CI 检查 13 秒完成，Argo CD 部署两个健康副本，并在 5 秒内纠正了一次手动扩缩容漂移（k3s 上同类测试为 42 秒）。
过程中踩了三个坑：工作节点因私有访问未开启无法加入集群；计划中的 t3.medium 被 AWS 拒绝，改用 c7i-flex.large（2 vCPU / 4 GiB）；交互式登录刷新不稳定，临时创建角色完成剩余操作后清理。预估环境成本约 0.24-0.27 美元/小时，清理脚本在测试后完整执行。
结论清晰：Kubernetes 让工作负载可移植，但网络、实例选择、身份与负载均衡集成仍需 AWS 特定工程。家庭 k3s 仍是日常学习环境，EKS 只作为短期验证目标。
#开发者 #工具 #Kubernetes #EKS #ArgoCD #Terraform #GitOps #k3s #AWS #Helm
@DevToolboxHub