---
title: "CTP Topic 59 Achieving reliability with Amazon EKS"
type: source
tags: [AWS, EKS, Kubernetes, Reliability, CTP]
date: 2026-04-14
sources: []
last_updated: 2026-04-28
---

## Source File
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks]]

## Summary

- **核心主题**：Amazon EKS 的可靠性最佳实践，涵盖应用层、控制平面和数据平面的可靠性设计
- **问题域**：容器化工作负载在 AWS EKS 上的生产级可靠性保障
- **方法/机制**：
  - 应用层：Pod 分布策略（anti-affinity / topology spread constraints）、弹性伸缩（HPA/VPA）、健康探针、部署策略
  - 控制平面：监控指标、安全认证、准入 webhook、集群升级策略
  - 数据平面：节点问题检测、资源预留、QoS、Pod 优先级
- **结论/价值**：EKS 可靠性需从应用、控制平面、数据平面三个维度系统性设计；AWS 与客户遵循共享责任模型，各自承担不同职责

## Key Claims

- **Surav Paul（AWS 高级解决方案架构师）** 通过展示 EKS 容器服务选项和可靠性实践，系统性讲解了三个可靠性维度的设计原则
- **容器服务选型**：ECS 适合容器化入门者（AWS 原生集成）；EKS 适合熟悉 Kubernetes 生态的用户（开放社区灵活性）
- **可靠性定义**：系统在发生故障时仍能提供可预测行为，包括故障检测、优雅降级、确定性故障模式、自愈能力和按需扩展
- **共享责任模型**：AWS 负责控制平面组件（状态存储、调度器、控制器管理器、API 服务器）；客户负责工作节点、操作系统和应用配置
- **Fargate 优势**：使用 Fargate 时无需管理节点或担忧节点补丁和升级
- **应用层可靠性**：避免单例 Pod，通过 pod anti-affinity 或 topology spread constraints 跨可用区分布应用 Pod
- **弹性伸缩**：HPA 默认基于 CPU 和内存，可使用自定义/外部指标；VPA 可调整 Pod 大小，但运行时调整会导致重启
- **部署策略**：滚动升级、蓝绿部署、灰度部署，复杂度和控制力逐级递增
- **控制平面可靠性**：监控 API 服务器请求和 etcd 状态存储大小；创建安全用户并分配超级管理员角色；谨慎配置和测试准入 webhook
- **集群升级**：控制平面和数据平面分阶段升级；EKS 平台版本透明处理补丁版本；次版本有 14 个月支持周期后自动升级
- **数据平面可靠性**：使用节点问题检测器、预留系统资源、实现 QoS、配置资源配额和限制范围；Pod 优先级控制抢占

## Key Quotes

> "Reliability in a system means it offers predictable behavior even when failures occur." — Surav Paul, AWS

> "ECS is a more AWS opinionated way of running containers." — Surav Paul, AWS

> "With Fargate, you don't have to worry about managing the nodes or worrying about patching or upgrading the nodes." — Surav Paul, AWS

## Key Concepts

- [[Reliability-Engineering]]：系统在故障时仍提供可预测行为的工程学科
- [[Kubernetes]]：开源容器编排平台，EKS 为其托管服务
- [[Amazon-EKS]]：AWS 托管的 Kubernetes 服务
- [[HPA]]：Horizontal Pod Autoscaler，根据 CPU/内存自动调整 Pod 副本数
- [[VPA]]：Vertical Pod Autoscaler，根据资源使用情况调整 Pod 资源请求
- [[Pod-Anti-Affinity]]：Pod 反亲和性，确保 Pod 分布在不同节点或可用区
- [[Topology-Spread-Constraints]]：拓扑分布约束，实现细粒度的工作负载分布控制
- [[Liveness-Probe]]：存活探针，检测 Pod 是否存活并决定是否重启
- [[Readiness-Probe]]：就绪探针，检测 Pod 是否准备好接收流量
- [[Startup-Probe]]：启动探针，检测应用启动完成前给予更长启动时间
- [[Pod-Disruption-Budget]]：Pod 中断预算，确保维护期间最小服务级别
- [[Admission-Webhook]]：准入控制器，在 API 请求到达对象存储前进行拦截和修改
- [[Node-Problem-Detector]]：节点问题检测器，检测节点级硬件和系统问题
- [[Quality-of-Service-QoS]]：服务质量等级，根据资源请求/限制划分 Pod 优先级
- [[Shared-Responsibility-Model]]：AWS 与客户各自承担不同可靠性职责的模型

## Key Entities

- [[AWS]]：Amazon Web Services，云服务提供商，负责 EKS 控制平面
- [[Amazon-ECS]]：Elastic Container Service，AWS 容器服务之一，与 EKS 对比
- [[AWS-Fargate]]：无服务器计算引擎，EKS 可选计算选项，无需管理节点
- [[Surav-Paul]]：AWS 高级解决方案架构师，本次演讲讲师

## Connections

- [[Amazon-EKS]] ← extends ← [[Kubernetes]]
- [[Amazon-EKS]] ← supports ← [[AWS-Fargate]]
- [[Amazon-ECS]] ← competes_with ← [[Amazon-EKS]]
- [[HPA]] ← scales ← [[Kubernetes]]
- [[VPA]] ← scales ← [[Kubernetes]]
- [[Reliability-Engineering]] ← applies_to ← [[Amazon-EKS]]

## Contradictions

- 与 [[ReliabilityBaseline]] 潜在交叉：
  - 冲突点：可靠性基线的具体量化指标（如 SLO/SLI 数值）本文档未涉及
  - 当前观点：聚焦工程实践和机制设计层面
  - 对方观点：可能包含可靠性指标的量化定义