Amazon DOP-C02: 容器和 Serverless 运维 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

属于 AWS DevOps Engineer Professional DOP-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

容器和无服务器改变了您在 AWS 上操作、扩展和发布应用程序的方式。本节将贯穿 Amazon ECS、AWS Fargate、Amazon EKS、Amazon ECR、AWS Lambda 和 Amazon API Gateway 的操作原语，以便您可以设计安全的部署、实施镜像治理、调整并发性，并在基于 EC2 和 Fargate 的容量之间做出一致的选择。本节重点关注任务和 Pod 调度模型、健康检查和部署控制、流量切换、跨账户镜像分发，以及 API 缓存和 Lambda 预置并发等性能特性。

Amazon ECS 和 AWS Fargate

ECS 任务定义声明了一个或多个容器以及调度器所需的所有运行时配置。关键要素包括 CPU/内存的预留和限制、portMappings、环境变量和密钥（来自 AWS Secrets Manager 或 Systems Manager Parameter Store）、Linux 参数和 ulimits、logConfiguration（awslogs、firelens 等）、ephemeralStorage 大小（对于 Fargate，为 20–200 GB）以及卷（包括 EFS）。使用任务执行角色进行镜像拉取和日志驱动；使用任务角色进行应用程序的 AWS API 访问。容器的 healthCheck 定义了命令、间隔、超时、重试次数和 startPeriod。与 dependsOn (condition=HEALTHY) 结合使用，健康检查可以强制执行 Sidecar 的启动顺序。

ECS 服务负责维持所需的任务数量，并可选择将任务注册到 ALB/NLB。服务的 deploymentConfiguration 通过 minimumHealthyPercent 和 maximumPercent 控制滚动更新。部署熔断器（启用/回滚）可以在任务健康检查失败时自动恢复失败的发布。服务自动扩展与 Application Auto Scaling 集成，可实现基于 CPU/内存的目标跟踪或基于 ALB RequestCountPerTarget 的扩展。服务发现 (AWS Cloud Map) 和 ECS Service Connect 简化了服务到服务的流量。

集群类型和容量：

• EC2 启动类型在自行管理的 EC2 实例上运行任务。可使用 Auto Scaling 组、放置约束/策略以及任何 networkMode（bridge/host/awsvpc）。支持守护任务和专用 AMI（例如 Bottlerocket）。
• Fargate 启动类型是用于容器的无服务器计算。它仅使用 awsvpc 网络模式，为每个任务提供自己的 ENI 和安全组。不支持守护任务；您需要依赖 Sidecar 或服务原生集成（例如 FireLens）。平台版本决定了可用的功能（请查看版本说明以了解对 EFS、临时存储和 exec 的支持）。Fargate Spot 可降低可中断任务的成本。在支持的组合中选择 CPU/内存（例如，从 0.25 vCPU/0.5–2 GB 到 16 vCPU/120 GB）。在私有子网中运行时，需为 ECR（api 和 dkr）、CloudWatch Logs 添加 VPC 接口端点，并为 S3 添加网关端点，以便在没有 NAT 的情况下拉取镜像和传送日志。

Fargate 和 EFS：在任务定义中定义 EFS 卷并通过 TLS 挂载；优先使用 EFS 接入点以实现最小权限和身份强制。这支持有状态需求，例如共享配置、模型权重或中间文件，而无需将它们烘焙到镜像中。

容器健康检查、滚动更新和蓝/绿部署：

• 健康检查发生在多个层面：容器（基于 CMD）、ECS 任务（聚合的容器状态）和负载均衡器目标健康状况（HTTP/TCP）。请对齐检查间隔和阈值，以便 ECS 能够在 ALB 注销目标之前平滑地替换不健康的任务。
• 滚动更新是 ECS 的默认设置。调整 minHealthy/maxPercent 来控制浪涌和容量安全。
• 蓝/绿部署使用 CodeDeploy 与 ECS（deploymentController 类型为

undefined

）。CodeDeploy 管理 ALB 后面的两个目标组，将测试流量切换到绿色环境 (AfterAllowTestTraffic)，运行自动化检查（例如通过 Lambda），然后切换生产流量。将 CloudWatch 告警与 5XX 峰值、延迟或自定义指标关联，以便触发回滚。这种模式可以隔离故障，并提供近乎零停机的快速回滚。

使用 ECR 进行镜像治理：

• 扫描：启用推送时扫描并采用 Amazon Inspector 增强型扫描，以实现持续的 CVE 覆盖和 SBOMs。使用管道检查，根据漏洞严重性来决定是否准许部署。
• 生命周期策略：根据数量/时间以及标签前缀来使旧的镜像标签过期。与标签不变性结合使用，可防止意外覆盖。
• 加密：使用 ECR 托管的加密或具有适当密钥策略的客户管理的 KMS 密钥。
• 跨账户：附加存储库资源策略，以授予其他账户或 CI 角色的拉取/推送权限。使用 ECR 复制规则将镜像复制到不同区域/账户，以实现数据本地化并减少爆炸半径。PrivateLink (VPC endpoints) 允许在没有互联网的情况下拉取镜像。

Amazon EKS 计算模型

EKS 将托管的控制平面与您的数据平面选项分离开来：

托管节点组 (MNG) 负责置备和生命周期管理 EC2 工作节点。它们与启动模板集成，用于选择 AMI (Amazon Linux 2, Bottlerocket)、实例类型和引导参数。MNG 通过浪涌容量 (surge capacity) 和自动的 cordon/drain 操作来处理滚动更新，以实现最小化的中断。使用节点污点/容忍 (taints/tolerations) 来引导特定的工作负载。结合 Cluster Autoscaler (或 Karpenter) 根据待处理的 pod 来合理调整节点容量。

自管理节点提供了对引导和操作系统的完全控制，但增加了运维开销；它们通常用于特殊的内核或小众硬件。

EKS on Fargate 无需管理节点即可运行 pod。Fargate profile 将命名空间/标签映射到 Fargate。每个 pod 都会获得自己的 ENI (awsvpc)，从而简化了网络隔离。其限制包括不支持 DaemonSet、主机网络/卷 (host networking/volumes)，以及对特权工作负载的约束。可观测性代理 (例如 Fluent Bit) 必须作为 sidecar 运行或使用托管的日志收集服务。该模型非常适合具有突发性、小资源占用或多租户特点的工作负载，这些工作负载能从按 pod 隔离和按 pod 付费的经济模型中受益。

运维附加组件：

• VPC CNI、CoreDNS 和 kube-proxy 是托管附加组件；请将其版本固定到与集群版本兼容的版本，并谨慎升级。
• IAM Roles for Service Accounts (IRSA) 为每个 pod 强制执行最小权限的 AWS 访问，并取代了节点角色凭证共享的方式。
• 通过 AWS Load Balancer Controller 实现的负载均衡支持用于 Service 和 Ingress 的 ALB/NLB；请确保正确的 IAM 和安全组规则，尤其是在混合使用 MNG 和 Fargate 时。
• 通过 CSI 驱动程序实现持久化存储 (EBS 用于按 pod 的块存储，EFS 用于共享的 POSIX 文件系统)。对于 Fargate，EFS 是用于共享状态的典型选项。

AWS Lambda 运维与并发

打包与配置：

• 部署包可以是 ZIP 归档文件 (包含语言运行时) 或最大 10 GB 的容器镜像。对于小型代码，ZIP 更轻量；容器镜像则统一了基于容器构建的工具链。
• 层 (Layer) 用于封装跨函数共享的库；应保持其最小化和版本化。一个函数最多可以包含五个层。
• 版本是不可变的快照；别名是指向版本的稳定指针，可以带有权重以实现流量切换。
• 临时存储默认为 512 MB，可提高至 10,240 MB，用于构建、临时文件或机器学习推理缓存。选择 x86_64 或 arm64 以在成本和性能之间进行权衡。使用环境变量进行配置，并与 Secrets Manager 或 Parameter Store 集成。

流量切换与安全性：

• 使用 CodeDeploy 进行金丝雀/线性部署，并通过 CloudWatch 警报 (例如 5XX、延迟或自定义应用指标) 实现自动回滚。或者，直接设置别名权重以实现简单的 A/B 路由。
• 使用结构化日志记录到 CloudWatch Logs，并创建指标筛选器，以便在不更改指标埋点的情况下，派生出按操作/版本/代码维度划分的指标。启用 X-Ray 进行端到端延迟追踪。

并发控制：

• 未预留并发从账户的区域池中获取。突发流量可能会饿死 (starve) 其他函数。
• 预留并发为函数设置了最大并发上限，并通过从区域池中划分容量来保证其可用性；这提供了与“吵闹邻居”的隔离。
• 预置并发为特定版本/别名保持执行环境的初始化状态，从而几乎消除了冷启动并稳定了延迟。使用 Application Auto Scaling 按时间或指标来扩展预置并发。
• 当函数达到其并发限制时会发生节流 (Throttling)；同步调用者会收到 429 错误，而异步调用会以指数退避方式重试，并在达到配置的尝试次数后进入死信队列。对于像 SQS 这样基于轮询的源，Lambda 会随着队列深度增加并发；请确保预留/预置并发和下游容量与最大处理中消息数相匹配，以避免积压增长。

API Gateway 设计与 ECR 跨账户访问

API Gateway REST API 与 HTTP API 对比：

• REST API 提供最丰富的功能集：请求/响应映射 (VTL)、使用计划和 API 密钥、授权方、WAF 以及阶段级缓存。当您需要高级转换、带配额的 API 密钥或成熟的生态系统集成时，请选择 REST API。
• HTTP API 具有更低的延迟和成本，可以更简单地路由到 Lambda 和 HTTP 后端（包括 ALB/NLB/私有集成）。它们支持 JWT 授权方和 IAM，但缺少许多 REST 功能，包括阶段级缓存和 VTL 转换。当需要以最小的开销进行直接代理时，请选择 HTTP API。

阶段与节流：

• 阶段将特定的部署绑定到一个 URL 路径。在阶段级别配置阶段变量、日志记录和节流。应用使用计划 (REST) 来强制执行每个 API 密钥的节流和配额。节流设置包括速率 (rate) 和突发 (burst)；它们与账户级别的限制相结合，因此请确保总流量不超过区域配额。启用结构化 JSON 格式的访问日志，并集成 WAF 来检查和阻止恶意请求。

缓存 (仅限 REST API)：

• 阶段级缓存可减少后端负载和延迟；按方法设置 TTL，启用加密，并考虑使用缓存键参数/标头以确保正确性。在更改响应结构或行为的部署后，使缓存失效。

私有连接：

• 选择终端节点类型：边缘优化 (REST，通过 CloudFront 全球分发)、区域性或私有 (VPC 终端节点)。通过 VPC Link 进行的私有集成可以连接到 VPC 中的 NLB/ALB 后端，而无需公开暴露。

ECR 跨账户访问：

• 使用存储库资源策略向其他账户中的主体（CI/CD 或运行时角色）授予拉取/推送权限。如果使用客户管理的 KMS 密钥，请相应地扩展密钥策略。对于多账户分发，定义 ECR 复制规则以指定目标账户/区域，并通过标签不变性和在部署中固定摘要来验证镜像完整性。

实际问题场景

Spotify 正在对其播放列表微服务栈进行现代化改造，以减少发布高峰期的延迟波动，并加强其跨多个 AWS 账户的镜像供应链。

1. 标准化镜像构建和治理

• 实施 ECR 存储库，启用推送时扫描 (scan-on-push) 和 Amazon Inspector 增强型扫描。添加标签不变性 (tag immutability) 和生命周期策略，以保留每个分支最新的 N 个版本并清理旧版本。配置从构建账户到生产和预发布账户的跨区域/账户复制。 原因：Inspector 确保了持续的 CVE 覆盖，标签不变性可防止标签被劫持，而复制功能通过本地化拉取操作来减少部署延迟和爆炸半径。

2. 在 ECS with Fargate 上提供无状态 API

• 定义 ECS 任务定义，使用 awslogs 和 FireLens 来处理结构化日志和指标。启用容器健康检查 (healthCheck) 并使其与 ALB 目标组的健康检查对齐。通过接入点挂载一个 EFS 卷，用于共享只读配置。使用混合 Fargate 和 Fargate Spot 的容量提供程序策略在 Fargate 上运行服务，以实现成本效益。 原因：Fargate 消除了节点管理，并为每个任务通过独立的 ENI 进行隔离；EFS 避免了将配置烘焙到镜像中，并支持配置的原子化回滚。

3. 使用蓝/绿部署和自动化测试进行安全部署

• 将 ECS 服务的部署控制器切换为 CodeDeploy。在 ALB 上配置两个目标组。使用带有 AfterAllowTestTraffic 钩子的金丝雀发布，调用一个 Lambda 测试运行器，在 5 分钟内对关键终端节点进行测试。附加关于 5XX 错误和 p90 延迟的 CloudWatch 警报以触发回滚。 原因：CodeDeploy 蓝/绿部署隔离了风险，测试挂钩在完全切换前验证了绿色环境，而警报则提供了自动、客观的回滚机制。

4. 在 Lambda 上处理延迟敏感操作并稳定冷启动

• 对于一个令牌化辅助 API，将函数及其精简的依赖项打包成 ZIP 文件。创建一个版本/别名，并启用与峰值流量匹配的预置并发。通过 Application Auto Scaling，使用跟踪发布窗口的每日计划来驱动预置并发。使用 CodeDeploy 金丝雀发布 (10%/15 分钟) 进行基于别名的流量切换，并与 CloudWatch 警报关联。 原因：预置并发消除了流量激增期间的冷启动；基于别名的金丝雀发布能够实现逐步暴露和快速回滚。

5. 通过 API Gateway 暴露外部 API 并保护私有后端

• 使用 API Gateway 作为 Lambda 和 ECS ALB 的前端。对 Lambda 代理使用 HTTP API 以最小化成本/延迟。对于需要请求/响应映射和为重度读取终端节点提供阶段缓存的 ECS ALB 路径，则使用 REST API。应用 WAF Web ACL 和阶段节流；启用结构化访问日志。 原因：根据需求匹配 API 类型可以优化成本和功能；缓存可以减少负载；WAF 和节流在事件流量尖峰时提供保护。

6. 无需互联网的跨账户运行时拉取

• 在运行时 VPC 中，为 ECR (api, dkr) 和 CloudWatch Logs 添加接口终端节点，并为 S3 添加网关终端节点。附加 ECR 存储库资源策略，允许生产账户的任务执行角色进行拉取。使用带有跨账户密钥策略的客户管理 KMS 密钥对镜像进行静态加密。 原因：私有镜像拉取避免了 NAT 成本和出口风险；明确的资源/密钥策略强制实施了最小权限的跨账户访问。

该设计减少了运维负担（无需管理节点），通过预置并发和与 ALB 健康检查对齐的部署提供了确定性的延迟，并通过 ECR 扫描、复制和标签不变性来端到端地强制执行镜像来源的追踪。

← 安全、合规性和治理 · 所有领域 · 高可用性、弹性和灾难恢复 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →