1. 课程导入与平台愿景
在开始动手创建第一个 EKS 集群之前，我们需要先建立一张"全局地图"。很多团队在容器化旅程中遇到的困境，并不是不会写 Dockerfile 或不会用 kubectl，而是把容器化当成"把应用塞进镜像"的一次性任务，结果在服务数量从 5 个增长到 200 个、团队从 1 个变成 8 个、环境从 1 套变成 4 套时，整个体系迅速失控。本课程要解决的，正是这种"从能跑到能规模化跑"的跃迁问题。
一、容器化应用平台的核心价值
容器化应用平台的价值可以拆成三个层次来理解。第一层是交付一致性：镜像把应用代码、运行时、依赖库和启动参数打包成一个不可变制品，同一镜像在开发机、测试环境和生产集群中行为一致，消除了"在我机器上是好的"这类问题。第二层是调度与弹性：Kubernetes 作为编排层，把"我要 6 个副本、每个 1 vCPU / 2 GiB"这样的声明式意图翻译成实际的 Pod 调度、健康检查与自动扩缩。第三层是平台化复用：当网络、日志、密钥、发布流水线、可观测性都被抽象为平台能力后，业务团队只需关注自己的镜像和配置，交付速度与安全基线同时提升。
在 AWS 上，这三层价值由一组具体服务承载：计算层用 EKS 托管控制面配合 EC2 托管节点组或 Karpenter 自动扩缩；网络层用 VPC、子网、安全组与 VPC CNI；入口层用 ALB Ingress Controller 或 Gateway API；镜像层用 ECR；密钥层用 Secrets Manager 与 IRSA；可观测性用 CloudWatch Container Insights 与 OpenTelemetry。理解这些组件的分工，是后续所有章节的基础。
二、规模化部署的真实挑战
规模化不是"把副本数调大"这么简单。当集群承载数十个命名空间、上千个 Pod 时，挑战会集中在几个具体位置：
- IP 地址耗尽：VPC CNI 默认为每个 Pod 分配一个 VPC 地址。若节点使用 /24 子网，可用地址约 251 个，扣除节点自身与保留地址后，单节点可调度 Pod 数会明显受限。常见做法是启用前缀委派（prefix delegation），让每个 ENI 分配 /28 前缀，把单节点 Pod 容量提升一个数量级。
- 调度与成本失衡：静态节点组容易出现"节点利用率 30% 但新 Pod 仍 Pending"的矛盾。引入 Karpenter 后，可按 Pod 的资源请求实时选择实例类型，并用 consolidation 回收低效节点。
- 多团队隔离：命名空间只是逻辑隔离，真正的隔离需要 RBAC、NetworkPolicy、ResourceQuota 与 LimitRange 组合使用，否则一个团队的失控 Pod 会拖垮整个集群。
- 发布风险放大：单服务发布失败影响有限，但平台级组件（Ingress Controller、CNI、CoreDNS）升级失败会波及全部业务。因此平台组件的变更必须走灰度与回滚预案。
三、整体架构分层
本课程把平台划分为四层，自下而上依次是：基础设施层（VPC、子网、IAM、ECR）、集群层（EKS 控制面、节点组、Karpenter、CNI、CoreDNS）、平台服务层（Ingress、证书、密钥、日志、监控、策略）、应用交付层（命名空间、工作负载、Helm/Kustomize、CI/CD）。每一层只依赖下一层暴露的接口，这样升级和替换才不会牵一发动全身。
四、学习路径与实战目标
本课程按"先建底座、再搭平台、后做规模化"的顺序推进。前段聚焦基础设施与集群搭建：创建 VPC 与子网、配置 IAM 角色、用 eksctl 或 Terraform 拉起 EKS 集群、接入托管节点组。中段进入平台服务：部署 ALB Ingress Controller、配置 IRSA 让 Pod 安全访问 AWS 服务、接入日志与监控、建立命名空间与配额体系。后段处理规模化议题：Karpenter 自动扩缩、多环境多集群管理、发布策略与故障演练。
为了让学习有明确的验收标准，我们设定一个贯穿全课程的实战目标：把一个包含前端、API 与后台任务的三服务应用，部署到一套具备自动扩缩、可观测、可灰度发布的 EKS 平台上，并能承受单节点故障而不中断服务。这个目标会在后续章节中逐步拆解为可执行的任务。
五、一个具体的容量估算示例
为了把"规模化"落到数字上，我们做一个示例估算（以下为教学假设值，非实测结果）。假设业务侧给出：API 服务 3 个副本，每副本请求 0.5 vCPU / 1 GiB；前端 2 个副本，每副本 0.25 vCPU / 512 MiB；后台任务 2 个副本，每副本 1 vCPU / 2 GiB。加上 DaemonSet（CNI、日志采集）每节点约 0.3 vCPU / 300 MiB 的开销。
总请求量：
CPU = 3×0.5 + 2×0.25 + 2×1.0 = 4.0 vCPU
内存 = 3×1 + 2×0.5 + 2×2 = 8.0 GiB
单节点可用（m6i.large，2 vCPU / 8 GiB，预留系统开销 0.5 vCPU / 1 GiB）：
可用 CPU ≈ 1.5 vCPU，可用内存 ≈ 7 GiB
按 CPU 计算所需节点数 = ceil(4.0 / 1.5) = 3
按内存计算所需节点数 = ceil(8.0 / 7) = 2
取较大值 → 至少 3 个节点，再保留 1 个冗余 → 建议 4 个节点起步这个估算说明了两件事：一是资源规划要同时看 CPU 和内存，取瓶颈项；二是必须预留冗余，否则单节点故障时剩余容量不足以承接被驱逐的 Pod。后续章节会用 Karpenter 把这种静态估算变成按需动态供给。