1. EKS平台工程全景
在云原生平台工程中，Amazon EKS 并不是一个孤立的托管 Kubernetes 服务，而是把 AWS 的 IAM、VPC、EC2、ELB、CloudWatch、EBS、EFS 等基础设施能力，与 Kubernetes 的声明式 API、调度、控制器模型组合起来的一层“平台底座”。平台工程团队真正交付的，不是某个集群本身，而是一套可复用、可审计、可升级、可观测的运行环境，让业务团队通过标准接口自助获得命名空间、工作负载、存储、入口、密钥和发布能力。
理解 EKS 的第一步，是分清控制面与数据面的职责边界。EKS 控制面由 AWS 托管，运行 API Server、etcd、调度器和各类控制器，负责接收声明、存储期望状态、执行调度与协调；数据面则由用户负责，通常由托管节点组、自管节点或 Fargate 承载，运行 kubelet、容器运行时、CNI 插件和实际业务 Pod。控制面决定“应该运行什么”，数据面决定“实际怎么运行”。平台工程的核心工作，正是围绕这条边界设计抽象：控制面侧通过 IAM、RBAC、准入控制、策略引擎约束“谁能提交什么”；数据面侧通过节点池、Karpenter、CNI、存储类、可观测代理决定“工作负载如何落地”。
平台工程与 SRE、DevOps 的关系，可以用“责任分层”来理解。DevOps 强调开发与运维协作、缩短交付周期；SRE 强调用工程手段管理可靠性，关注 SLO、错误预算、容量与故障响应；平台工程则把这两者的共性需求沉淀为内部平台产品。EKS 平台团队通常同时承担三种角色：为 DevOps 提供 CI/CD 与 GitOps 的落点，为 SRE 提供可观测、可扩缩、可恢复的运行时，为安全与合规提供统一入口和策略边界。三者不是替代关系，而是同一交付链上的不同关注面。
本课程以一个贯穿式实战项目为主线：在 AWS 上构建一套面向多团队的 EKS 平台。项目从账号与网络规划开始，逐步落地集群创建、节点供给、入口与 DNS、存储、密钥、镜像仓库、GitOps 发布、可观测、策略、成本与多环境隔离。工具链围绕这条主线组织，而不是零散罗列。
| 层次 | 核心对象 | 典型工具 | 平台交付物 |
|---|---|---|---|
| 基础设施 | VPC、子网、IAM、ECR | Terraform / AWS CDK | 可复用的账号与网络基线 |
| 集群 | EKS 控制面、节点组、Karpenter | eksctl / Terraform / Helm | 标准化集群与节点池 |
| 运行时 | CNI、CSI、Ingress、DNS | AWS Load Balancer Controller、ExternalDNS、EBS CSI | 网络、入口、存储能力 |
| 交付 | Git 仓库、Helm、Kustomize | Argo CD / Flux | 声明式发布流水线 |
| 治理 | RBAC、OPA、Kyverno、配额 | Gatekeeper、Kyverno、Kubecost | 策略、合规与成本边界 |
| 可观测 | 指标、日志、追踪、告警 | Prometheus、Grafana、Fluent Bit、CloudWatch | 统一观测与 SLO 基线 |
一个常见的教学示例参数如下：集群名 platform-dev，区域 ap-southeast-1，VPC 网段 10.20.0.0/16，三个可用区各一个私有子网，节点组初始容量 3 × m6i.large，开启 cluster-autoscaler 或 Karpenter 作为弹性供给。平台团队为业务团队提供 team-a、team-b 两个命名空间，分别绑定资源配额与网络策略。业务团队只需提交 Helm Chart 或 Kustomize 目录，由 Argo CD 同步到对应命名空间。这个示例不追求生产级规模，但足以覆盖平台工程的关键接口。
从职责边界看，控制面侧的平台工作重点是“入口与规则”：IAM 角色映射、RBAC 授权、准入策略、审计日志、版本升级窗口。数据面侧的平台工作重点是“供给与观测”：节点池设计、Pod 密度、CNI 地址规划、存储类、日志采集、指标暴露。两侧通过 Kubernetes API 和控制器模式解耦，平台团队不需要修改业务代码，业务团队也不需要理解底层节点细节。
课程后续会围绕这条主线逐步展开：先建立账号、网络与集群基线，再接入节点弹性、入口、存储与密钥，随后引入 GitOps、策略、可观测和成本治理，最后完成多环境隔离与故障演练。每一章都会给出可执行的配置片段、参数示例和判断依据，帮助你把“平台工程”从概念落到可运行的系统上。