企业官网建设流程全解析

• 文档
• 教程
• 知识库

EKS（Elastic Kubernetes Service）是 AWS 提供的托管 Kubernetes 服务，它把 Kubernetes 控制平面（control plane）的运行、升级、打补丁和高可用交给 AWS 负责，而你只需聚焦数据平面的工作节点，或直接使用 Fargate 运行无服务器 Pod。本文以 developer-roadmap 仓库中 AWS 学习路径的 EKS 主题为核心，结合仓库内 ECS、Fargate、IAM、VPC、自动扩缩容等相关文档，系统讲解 EKS 的核心概念、架构组成、运维模型，以及它与标准 Kubernetes 生态和其他 AWS 容器服务的关系，帮助你建立起从"会用 Kubernetes"到"会用 AWS 上的 Kubernetes"的完整认知。

EKS 是什么：被托管的 Kubernetes 控制平面

关联文档 给出了 EKS 的准确定义：

EKS (Elastic Kubernetes Service) 是一个托管的 Kubernetes 服务，它在 AWS 上运行 Kubernetes 控制平面。AWS 负责控制平面的升级、补丁和高可用，而你负责管理工作节点，或使用 Fargate 运行无服务器 Pod。

这一定义揭示了三层关键信息：

1. 控制平面在 AWS 上运行：etcd、API Server、Controller Manager、Scheduler 等控制平面组件由 AWS 全权托管，你不必为这些组件准备 EC2 实例，也不必亲自运维它们。
2. AWS 承担运营责任：控制平面的版本升级、安全补丁、多可用区高可用（HA）均由 AWS 处理，这与你手动搭建 kubeadm 集群时需要自己操心升级链路完全不同。
3. 数据平面由你掌控：真正的计算资源——承载业务 Pod 的工作节点——仍由你规划，你可以选择 EC2 实例节点组，也可以选择 Fargate 无服务器模式。

在仓库的 AWS 学习路径中，EKS 与 ECS（Elastic Container Service） 共同构成了 AWS 容器编排服务的核心话题：ECS 是 AWS 自有的容器编排体系，而 EKS 则是"原生 Kubernetes 托管版"，两者共用 EC2/Fargate 作为底层计算资源。

托管控制平面：升级、补丁与高可用的责任划分

"托管"二字是理解 EKS 的钥匙。在 EKS 中，责任模型可以简单概括为：

这种"控制平面归平台、数据平面归用户"的划分，与仓库中 共享责任模型 的主题一脉相承：AWS 负责"云的安全"（控制平面、底层基础设施），你负责"云中的安全"（工作负载、网络策略、IAM 权限）。

从运维实践看，托管控制平面带来的直接收益是：

• 免维护 etcd：etcd 是 Kubernetes 的状态中枢，自建集群需要为它做备份、加密、跨可用区冗余；EKS 将这些全部内置。
• 平滑升级：EKS 的版本升级由 AWS 推动，你可以先在工作节点和测试环境验证兼容性，再按计划升级控制平面，升级过程遵循 Kubernetes 版本支持节奏。
• 高可用默认化：控制平面组件跨多个可用区（Availability Zone）部署，单可用区故障不会导致控制平面不可用。

数据平面的两种选择：工作节点与 Fargate

EKS 支持两种 Pod 运行方式，这也是规划集群时首先要做的决策。

方式一：EC2 工作节点（Managed Node Groups）

你创建由 EC2 实例组成的工作节点组，Pod 调度到这些节点上运行。你需要关注：

• 实例选型：根据工作负载的 CPU/内存/GPU 需求选择合适的 实例类型，这与规划普通 EC2 实例的逻辑一致。
• 节点组扩缩容：EKS 的托管节点组可以与 自动扩缩容组（Auto Scaling Groups） 联动——实际上，该文档 中给出的最佳实践参考链接正是来自 EKS 官方文档，说明在 EKS 语境下节点与 Pod 的弹性伸缩是必须一起考虑的话题：节点层面用 Cluster Autoscaler / Karpenter 这类组件配合 ASG 扩缩节点，Pod 层面由 Kubernetes HPA 决定副本数。
• 集群内优化：合理设置节点污点（taint）、亲和性（affinity）、Pod 资源请求（requests/limits），提高节点利用率。

方式二：Fargate 无服务器 Pod

仓库中的 Fargate 文档 明确指出：Fargate 是用于在 ECS 中部署容器的技术，它完全消除了管理 EC2 实例的需求——不必操心选择正确的 EC2 实例类型、不必决定何时扩缩集群、也不必优化集群装箱（packing）。

在 EKS 中使用 Fargate（通过 Fargate Profile 实现）时，Pod 直接运行在 AWS 托管的无服务器基础设施上，每个 Pod 按需获得独立资源配额。它的核心价值是：

• 零节点运维：没有节点组、没有实例池，天然不需要为"节点选型"和"集群装箱"花费精力；
• 按 Pod 计费与隔离：Fargate 为每个 Pod 分配独立的虚拟隔离边界，按实际运行的 vCPU/内存计费；
• 聚焦应用：如 Fargate 文档所强调的，它让你专注于"设计和构建应用"而非"管理基础设施"。

两种模式的取舍

很多生产集群采用"混合模式"：默认命名空间跑在节点组上承载有状态或 GPU 工作负载，测试/突发工作负载通过 Fargate Profile 隔离运行。

与标准 Kubernetes 生态的完全兼容

关联文档特别强调：EKS 与标准的 Kubernetes 工具和 API 完全兼容。这是它区别于 ECS 私有编排体系的核心卖点，意味着：

• 你可以继续使用kubectl、helm、kustomize等日常工具，学习曲线为零；
• 社区生态（Ingress Controller、Operator、Service Mesh、监控告警如 Prometheus/Grafana）可以原样迁移到 EKS；
• 你在本地或自建集群上写好的 YAML 清单，几乎不需要改动即可部署到 EKS；
• CNCF 认证的 Kubernetes 知识与技能可直接复用，这就是为什么 developer-roadmap 的 AWS 路径将 EKS 作为重要一环——它既属于"容器编排"领域，也属于"Kubernetes 生态"领域。

EKS 与 ECS：AWS 容器编排的两种思路

在 AWS 学习路径中，EKS 与 ECS 常常被放在一起学习，两者的对比能帮你理解 AWS 容器生态的全貌：

• ECS：AWS 自有的容器编排服务，在 EC2 集群或 Fargate 上运行 Docker 容器，负责调度、扩缩容以及与其他 AWS 服务的集成，API 风格是 AWS 原生风格；
• EKS：托管的 Kubernetes，API 与社区 Kubernetes 完全一致，适合已经掌握或希望采用标准 Kubernetes 生态的团队。

从仓库文档看，两者共享同一批底层资源：EC2 实例、Fargate、VPC 网络、IAM 权限体系。选择哪个，本质上是选择"AWS 原生编排"还是"Kubernetes 标准生态"。

在 AWS 服务栈中理解 EKS 的周边依赖

EKS 不是孤立存在的，生产级集群必然牵涉 AWS 的众多服务。仓库的 AWS 学习路径提供了完整的上下文，建议按以下脉络串联：

• 网络层：集群运行在 VPC 内，节点分布在 子网（Subnets） 中，通过 安全组（Security Groups） 控制流量进出；
• 权限层：EKS 依赖 IAM 完成认证与授权——集群角色（Cluster Role）、节点角色（Node Role）、IRSA（IAM Roles for Service Accounts）都是 EKS 权限模型的重要组成部分；
• 流量入口：面向用户的流量通常经过 Elastic Load Balancers（NLB 用于四层、ALB 配合 Ingress 用于七层）再进入集群；
• 弹性：节点弹性依赖 Auto Scaling Groups（EKS 官方最佳实践亦指向该主题），Pod 弹性依赖 Kubernetes 原生 HPA；
• 区域与架构：集群的多可用区设计遵循 AWS 全球基础设施 的可用区概念，高可用设计可对照 Well-Architected Framework 的可靠性支柱来审视。

这种"网络 → 权限 → 负载 → 弹性"的依赖链，正是 AWS 学习路径将 EKS 与 IAM、VPC、Auto Scaling 等主题编排在同一路线中的原因。

学习与实践建议

结合仓库内容，掌握 EKS 的推荐路径是：

1. 先修 Kubernetes 基础：理解 Pod、Deployment、Service、Ingress、ConfigMap 等核心对象，因为 EKS 的 API 与社区完全一致；
2. 理解托管边界：熟读 共享责任模型，分清 AWS 管什么、你管什么；
3. 在 AWS 语境中实操：用eksctl创建集群（它会自动创建 VPC、节点组和必要的 IAM 角色），用kubectl部署应用；
4. 对比学习 ECS/Fargate：对照 ECS 文档 与 Fargate 文档，体会两种编排模型的差异，理解 Fargate 如何在 EKS 与 ECS 两个体系中都提供无服务器能力；
5. 把弹性与安全纳入设计：结合 Auto Scaling Groups 规划节点伸缩，结合 IAM 设计最小权限，结合 安全组 规划南北向与东西向流量。

小结

EKS 的核心价值可以浓缩为一句话：把 Kubernetes 最沉重、最易出错的控制平面运维交给 AWS，把决定业务上限的工作负载设计留给自己。通过本仓库的 AWS 学习路径，你既能从 EKS 文档 掌握托管服务的本质，也能从 ECS、Fargate、IAM、VPC 等关联主题建立起完整的 AWS 容器生态认知——这正是从"会用 Kubernetes"走向"会设计 AWS 上的 Kubernetes 生产架构"的关键一步。

• 文档
• 教程
• 知识库