Auto-sync: update nexus workspace

wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md

@@ -1,67 +1,84 @@
 ---
 title: "CTP Topic 59 Achieving reliability with Amazon EKS"
 type: source
-tags:
-  - AWS
-  - EKS
-  - Kubernetes
-  - Reliability
-  - CTP
+tags: [AWS, EKS, Kubernetes, Reliability, CTP]
 date: 2026-04-14
+sources: []
+last_updated: 2026-04-28
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks]]
 
-## Summary（用中文描述）
-- 核心主题：Amazon EKS（Elastic Kubernetes Service）的可靠性最佳实践，涵盖容器服务选型、应用层可靠性、控制平面可靠性和数据平面可靠性四个维度。
-- 问题域：Kubernetes 在 AWS 上的生产级可靠性保障，涉及 shared responsibility model 下 AWS 与客户的责任边界划分。
-- 方法/机制：通过 Pod 反亲和性、拓扑分布约束、HPA/VPA 扩缩容、探针配置、PodDisruptionBudget 等机制实现故障检测、优雅降级、自愈和按需扩缩；控制平面通过监控、认证加固、准入 Webhook 管理、集群升级策略保障；数据平面通过节点问题检测、资源预留、QoS、资源配额和 Pod 优先级机制保障。
-- 结论/价值：EKS 可靠性需要在应用、控制平面、数据平面三个层面综合设计，结合 AWS shared responsibility model 明确责任边界，并通过多样性部署策略（Rolling/Blue-Green/Canary）实现安全升级。
+## Summary
 
-## Key Claims（用中文描述）
-- ECS 推荐给容器化初学者，提供简单界面和原生 AWS 集成；EKS 适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。
-- 系统可靠性意味着即使发生故障也能提供可预测行为，核心关注点包括：故障检测、优雅服务降级、确定性故障模式、自愈能力和按需扩缩。
-- AWS shared responsibility model 下，AWS 负责控制平面组件（state store、scheduler、controller manager、API servers），客户负责工作节点、操作系统和应用配置。
-- Fargate 模式下客户无需管理节点、补丁或升级工作。
-- 应用可靠性需避免单例 Pod，使用 Pod 反亲和性或拓扑分布约束将应用 Pod 分散到多个可用区；HPA 默认基于 CPU 和内存扩缩容，VPA 可正确调整 Pod 大小但会导致运行时重启。
-- 部署策略包括滚动升级、蓝绿部署和金丝雀部署，各有不同控制复杂度和安全保障级别；存活探针、就绪探针和启动探针是 Pod 健康监控的关键；PodDisruptionBudget 确保维护期间的最小服务水平。
-- 控制平面可靠性需监控 API server 请求和 HCT state store 大小；必须创建具有超级管理员角色的安全用户；准入 Webhook 需仔细配置以避免阻塞控制平面；EKS 平台版本自动处理补丁版本，Minor 版本有 14 个月支持周期后自动升级。
-- 数据平面可靠性需使用节点问题检测器、预留系统资源、实现 QoS、配置资源配额和限制范围；Pod 优先级控制抢占。
+- **核心主题**：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
-> "ECS is a more AWS opinionated way of running containers." — ECS 与 EKS 的核心区别概述
-> "Reliability in a system means it offers predictable behavior even when failures occur." — 可靠性的本质定义
-> "With Fargate, you don't have to worry about managing the nodes or worrying about patching or upgrading the nodes." — Fargate 对 shared responsibility model 的影响
+
+> "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（系统可靠性）]]：系统在发生故障时仍能提供可预测行为的能力，包含故障检测、优雅降级、确定性故障模式、自愈和按需扩缩五个核心关注点。
-- [[Application Reliability（应用可靠性）]]：通过避免单例 Pod、AZ 分散、HPA/VPA 扩缩容、部署策略（Rolling/Blue-Green/Canary）、健康探针和 PodDisruptionBudget 实现。
-- [[Control Plane Reliability（控制平面可靠性）]]：通过监控控制平面指标、安全认证加固、准入 Webhook 管理和集群升级策略保障。
-- [[Data Plane Reliability（数据平面可靠性）]]：通过节点问题检测、资源预留、QoS、资源配额、LimitRange 和 Pod 优先级机制保障。
-- [[Shared Responsibility Model（EKS）]]：AWS 负责控制平面（API server、scheduler 等），客户负责工作节点、操作系统和应用配置；Fargate 模式下进一步减少客户运维负担。
-- [[Pod Anti-Affinity]]：通过反亲和性规则将 Pod 分散到不同节点或可用区，避免单点故障。
-- [[Topology Spread Constraints]]：提供比 Pod 反亲和性更细粒度的工作负载分布控制。
-- [[Horizontal Pod Autoscaler (HPA)]]：基于 CPU 利用率和内存消耗的默认扩缩容机制，支持自定义/外部指标。
-- [[Vertical Pod Autoscaler (VPA)]]：根据实际资源使用情况自动调整 Pod 的大小配置，但运行时调整会导致 Pod 重启。
-- [[Liveness/Readiness/Startup Probes]]：三类 Kubernetes 探针，用于监控 Pod 健康状态和就绪情况。
-- [[PodDisruptionBudget]]：在自愿中断（如节点维护）期间保证最小数量或比例的 Pod 持续运行。
-- [[Rolling/Blue-Green/Canary Deployment]]：三种部署策略，滚动升级自动化程度高但回滚控制有限，蓝绿和金丝雀提供更精细的控制和快速回滚能力。
+
+- [[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
-- [[Surav Paul]]：AWS 高级解决方案架构师（Senior Solutions Architect），本场演讲的主讲人。
-- [[Amazon EKS]]：AWS 托管的 Kubernetes 服务，适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。
-- [[Amazon ECS]]：AWS 原生容器服务，推荐给容器化初学者，提供简单界面和原生 AWS 集成。
-- [[AWS Fargate]]：无服务器容器运行平台，使用 Fargate 时客户无需管理节点、补丁或升级工作。
+
+- [[AWS]]：Amazon Web Services，云服务提供商，负责 EKS 控制平面
+- [[Amazon-ECS]]：Elastic Container Service，AWS 容器服务之一，与 EKS 对比
+- [[AWS-Fargate]]：无服务器计算引擎，EKS 可选计算选项，无需管理节点
+- [[Surav-Paul]]：AWS 高级解决方案架构师，本次演讲讲师
 
 ## Connections
-- [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]] ← topic_overlap ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（均涉及 EKS 部署实践，本 Topic 聚焦可靠性设计，Topic 39 聚焦网络/IP 问题解决）
-- [[CTP Topic 64 Scaling out with Amazon EKS]] ← topic_overlap ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（均涉及 EKS 扩缩容，Topic 64 聚焦扩缩机制，Topic 59 聚焦可靠性全栈设计）
-- [[CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana]] ← complements ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（Grafana 监控可用于 Topic 59 中的控制平面和数据平面指标监控）
-- [[Public Cloud Learning Sessions EKS Optimization Part 3 of 3 Introduction to EKS Auto Mode]] ← extends ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（Auto Mode 是 EKS 可靠性自动化的进一步演进，涵盖 Fargate 集成和自动扩缩容）
+
+- [[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
-- 与 [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]] 的潜在视角差异：
-  - 冲突点：Topic 39 描述 EKS 部署中的 IP 资源挑战，强调自定义网络配置（hostNetwork）和独立私有子网；Topic 59 侧重标准 EKS 可靠性机制，较少涉及网络约束场景。
-  - 当前观点：两者面向不同场景——Topic 39 针对受限网络环境下的实际部署挑战，Topic 59 提供通用的 EKS 可靠性最佳实践，互为补充而非冲突。
-  - 对方观点：Topic 39 认为在某些受限环境下标准 EKS 配置（如 CNI 插件默认 IP 分配）无法直接适用，需要自定义网络方案；Topic 59 的通用建议可能需要针对特殊环境调整。
+
+- 与 [[ReliabilityBaseline]] 潜在交叉：
+  - 冲突点：可靠性基线的具体量化指标（如 SLO/SLI 数值）本文档未涉及
+  - 当前观点：聚焦工程实践和机制设计层面
+  - 对方观点：可能包含可靠性指标的量化定义