C2-03-02-本章在整套-AWS-知识体系中的位置
本篇是《C2-03-容器Serverless与应用运行平台》的第1个分篇，主要包含：本章在整套-AWS-知识体系中的位置、719题中的粗略曝光度、容器基础与镜像、镜像仓库与编排基础。
1-本章在整套-AWS-知识体系中的位置
上一章建立的是：
Physical Server
↓
Virtualization
↓
Virtual Machine
↓
Amazon EC2
这解决了：代码在哪里运行？
但是现代应用还有另一个问题：是不是每个 Application、都需要一整台 Virtual Machine？
答案是否定的。
现代 AWS Compute 可以继续向上抽象：
Physical Server
↓
Virtual Machine
↓
Container
↓
Container Orchestration
↓
Serverless Container / Serverless Function
在 AWS 中可以先建立下面这张总图：
Compute
│
├── Virtual Machine
│ └── Amazon EC2
│
├── Container
│ ├── Amazon ECR ← 存 Container Image
│ ├── Amazon ECS ← AWS 原生容器编排
│ ├── Amazon EKS ← Managed Kubernetes
│ └── AWS Fargate ← 不自己管理容器服务器
│
├── Serverless Function
│ └── AWS Lambda
│
└── Managed Application Platform
└── AWS Elastic Beanstalk
当前 CLF-C02 官方范围中明确包括：
- Containers：Amazon ECR、Amazon ECS、Amazon EKS
- Serverless：AWS Fargate、AWS Lambda
- Compute：Amazon EC2、AWS Elastic Beanstalk、Amazon Lightsail、AWS Batch 等。
因此本章不是“额外的高级知识”，而是 CLF-C02 计算体系的核心组成。
2-719题中的粗略曝光度
按照本项目已经统一使用的统计口径：题干 + 所有选项、每道题同一服务最多计 1 次。
粗略得到：
| 服务 | 约涉及题数 |
|---|---|
| Amazon EC2 | 175 |
| AWS Lambda | 31 |
| AWS Fargate | 14 |
| Amazon ECS | 13 |
| Amazon EKS | 7 |
| Amazon ECR | 题库中几乎没有直接点名 |
| Elastic Beanstalk | 16 |
注意：曝光次数 ≠ 正确答案次数。
例如某服务可能经常作为干扰项出现。
C2 的目的也不是在这里逐题解析，而是先把这些技术真正理解清楚。
3-★★★★★-容器基础与镜像
3.1-为什么-Virtual-Machine-之后还会出现-Container？
先看传统 VM 的方式。
假设 GlobalShop 有三个服务：Product Service、Order Service、Payment Service。
如果每个服务都使用一台 VM：
VM 1
├── Linux
├── Node.js
└── Product Service
VM 2
├── Linux
├── Java
└── Order Service
VM 3
├── Linux
├── Java
└── Payment Service
这样当然可以运行。
但是问题是：每个 VM 都需要自己的：Guest OS、System Libraries、Runtime、Application。
其中 Guest OS 本身就占用：CPU、Memory、Disk、Boot Time。
如果一台物理服务器上运行很多小服务，重复的操作系统会带来额外开销。
于是人们开始思考：
能不能不为每一个应用都准备一整套 Guest OS，而只隔离“应用 + 它需要的运行环境”？
这就是 Container 思想的重要来源之一。
3.2-★★★★★-Container
Container。
中文通常翻译为：容器。
在软件运行环境里，它不是现实中的运输集装箱。
可以先理解成：
一个相对隔离的应用运行环境，把应用程序及其依赖打包在一起运行。
概念上：
Host OS
│
├── Container A
│ ├── Node.js
│ └── Product Service
│
├── Container B
│ ├── Java Runtime
│ └── Order Service
│
└── Container C
├── Python
└── Recommendation Service
与 VM 最大的学习层面区别是：
VM
通常包含完整 Guest OS
Container
通常共享 Host OS Kernel，
主要隔离应用进程、文件系统、网络等运行环境
CLF-C02 不要求深入研究：Linux Namespace、cgroups、OverlayFS、Container Runtime Interface。
但必须理解：
VM
隔离粒度更像“一台机器”
Container
隔离粒度更像“一个应用运行单元”
3.3-为什么叫-Container？
这个名字可以用现实世界的集装箱帮助理解。
传统运输：货物形状不同、包装方式不同、搬运方式不同。
集装箱出现以后：
货物
↓
装进标准 Container
↓
轮船 / 火车 / 卡车
都围绕标准 Container 搬运
软件中的 Container 也有类似思想：
Application
+
Runtime
+
Libraries
+
Configuration
↓
Container Image
↓
在不同 Container Runtime 上运行
重点不是
Container 真的等于运输集装箱。
而是
通过相对标准化的打包与运行方式，让应用更容易从开发环境移动到测试和生产环境。
3.4-VM-与-Container-的核心区别
先看 VM：
Physical Server
│
▼
Hypervisor
│
┌────┼────┐
▼ ▼ ▼
VM1 VM2 VM3
│ │ │
OS OS OS
│ │ │
App App App
再看 Container：
Physical / Virtual Server
│
▼
Host OS
│
▼
Container Runtime
│
┌──────┼──────┐
▼ ▼ ▼
Container Container Container
App App App
学习层面可以先记：
| 对比 | Virtual Machine | Container |
|---|---|---|
| 隔离单位 | 一台虚拟机器 | 一个应用运行环境 |
| OS | 通常每个 VM 有 Guest OS | 通常共享 Host Kernel |
| 启动 | 相对更重 | 通常更快、更轻 |
| 打包 | VM Image / AMI | Container Image |
| 常见 AWS | EC2 | ECS / EKS / Fargate |
| 控制能力 | 很高 | 更面向应用 |
但不能理解成：Container 永远比 VM 好。
它们解决的是不同层级的问题。
很多生产架构本身就是：
EC2
↓
Container
即：Container 最终仍然运行在某种 Compute 上。
3.5-★★★★-Docker
Docker。
不是 AWS 服务。
它是现代 Container 生态中非常重要的一套容器构建与运行工具。
学习 AWS 时经常看到：Docker Image、Docker Container、Dockerfile、docker build、docker push、docker pull。
CLF-C02 不要求会写 Dockerfile。
但需要知道：
Developer
│
│ build
▼
Container Image
│
│ push
▼
Container Registry
│
│ pull
▼
ECS / EKS / Fargate
│
▼
Running Container
AWS 题目如果写：Docker workload、containerized application、container image。
就应该立即想到：ECR、ECS、EKS、Fargate，而不是先想到 RDS、S3、Athena。
3.6-★★★★★-Container-Image
Container Image，中文为：容器镜像。
它可以理解为：
用来创建 Container 的只读应用模板。
例如 GlobalShop 的商品服务镜像：
globalshop/product-service:2026-09
包含：
Node.js Runtime
Application Code
Dependencies
Configuration Template
然后可以从同一份 Image 启动很多 Container：
Product Image
│
├── Container #1
├── Container #2
├── Container #3
└── Container #4
这与上一章的 AMI 有一点类似：
AMI
↓
EC2 Instance
Container Image
↓
Container
但二者不是同一个东西。
3.7-AMI-vs-Container-Image
| 对比 | AMI | Container Image |
|---|---|---|
| 主要创建对象 | EC2 Instance | Container |
| 抽象层 | Machine / VM | Application |
| 通常是否包含完整 OS | 更接近完整机器环境 | 通常只包含应用所需用户空间 |
| 典型服务 | EC2 | ECS / EKS / Fargate |
| 重点问题 | “服务器应该长什么样” | “应用运行包应该长什么样” |
可以这样记：
AMI
= Server Template
Container Image
= Application Runtime Package
4-★★★★★-镜像仓库与编排基础
4.1-Registry-是什么？
Registry，中文为：镜像注册表 / 镜像仓库服务。
开发者构建 Container Image 以后，需要一个地方存放。
不能只放在开发者电脑：
Developer Laptop
X
Production Cluster
更合理的是：
Developer
│
│ push
▼
Image Registry
│
│ pull
▼
Production
常见公共技术中有 Docker Hub。
AWS 自己提供：Amazon ECR。
4.2-★★★★-Amazon-ECR
[CURRENT-IN-SCOPE]。
正式名称：Amazon Elastic Container Registry。
简称：Amazon ECR。
中文可以理解为：Amazon 弹性容器镜像注册表。
名称拆解：
Elastic
弹性
Container
容器
Registry
注册表 / 镜像仓库
4.3-ECR-为什么存在？
如果 GlobalShop 有几十个微服务：product-service、order-service、payment-service、inventory-service、search-service、recommend-service。
每个服务都有多个版本：v21、v22、v23、...。
需要统一保存：Container Images。
ECR 就负责这一层：
Source Code
│
▼
Build Image
│
▼
Amazon ECR
│
├── product-service:v23
├── order-service:v41
└── payment-service:v18
然后 ECS / EKS 可以拉取这些 Image 来运行。
4.4-ECR-不负责运行-Container
这是一个非常重要的区分。
ECR
= 存 Image
ECS / EKS
= 编排 Container
Fargate / EC2
= 提供运行 Container 的 Compute
错误理解：
ECR
= 容器服务器
不对。
ECR 更像：Container Image Warehouse，而不是应用执行平台。
4.5-为什么需要-Container-Orchestration？
在开发机上运行一个 Container 很简单：docker run。
但是生产系统可能有：500 个 Product Container、300 个 Order Container、100 个 Payment Container这时问题变成：Container 放在哪台机器？
某台机器满了怎么办？
Container 挂了怎么办？
需要增加多少副本？
新版本怎么发布？
如何健康检查？
如何把网络流量送到正确 Container？
这些问题统称为：
Container Orchestration Orchestration。
原意：编排 / 协调。
就像乐团不是只有一件乐器，而是需要统一协调很多乐器。
Container Orchestration：
很多 Container
+
很多 Compute Node
+
Scheduling
+
Scaling
+
Health
+
Deployment
+
Networking
由一个系统统一协调。
AWS 中最重要的两个方向：Amazon ECS、Amazon EKS。