Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,67 +1,67 @@
|
||||
---
|
||||
title: "CTP Topic 59 Achieving reliability with Amazon EKS"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- EKS
|
||||
- Kubernetes
|
||||
- Reliability
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md]]
|
||||
|
||||
## 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）实现安全升级。
|
||||
|
||||
## 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 优先级控制抢占。
|
||||
|
||||
## 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 的影响
|
||||
|
||||
## 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]]：三种部署策略，滚动升级自动化程度高但回滚控制有限，蓝绿和金丝雀提供更精细的控制和快速回滚能力。
|
||||
|
||||
## Key Entities
|
||||
- [[Surav Paul]]：AWS 高级解决方案架构师（Senior Solutions Architect），本场演讲的主讲人。
|
||||
- [[Amazon EKS]]：AWS 托管的 Kubernetes 服务，适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。
|
||||
- [[Amazon ECS]]：AWS 原生容器服务，推荐给容器化初学者，提供简单界面和原生 AWS 集成。
|
||||
- [[AWS Fargate]]：无服务器容器运行平台，使用 Fargate 时客户无需管理节点、补丁或升级工作。
|
||||
|
||||
## 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 集成和自动扩缩容）
|
||||
|
||||
## 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 的通用建议可能需要针对特殊环境调整。
|
||||
---
|
||||
title: "CTP Topic 59 Achieving reliability with Amazon EKS"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- EKS
|
||||
- Kubernetes
|
||||
- Reliability
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md]]
|
||||
|
||||
## 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）实现安全升级。
|
||||
|
||||
## 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 优先级控制抢占。
|
||||
|
||||
## 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 的影响
|
||||
|
||||
## 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]]：三种部署策略，滚动升级自动化程度高但回滚控制有限，蓝绿和金丝雀提供更精细的控制和快速回滚能力。
|
||||
|
||||
## Key Entities
|
||||
- [[Surav Paul]]：AWS 高级解决方案架构师（Senior Solutions Architect），本场演讲的主讲人。
|
||||
- [[Amazon EKS]]：AWS 托管的 Kubernetes 服务，适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。
|
||||
- [[Amazon ECS]]：AWS 原生容器服务，推荐给容器化初学者，提供简单界面和原生 AWS 集成。
|
||||
- [[AWS Fargate]]：无服务器容器运行平台，使用 Fargate 时客户无需管理节点、补丁或升级工作。
|
||||
|
||||
## 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 集成和自动扩缩容）
|
||||
|
||||
## 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 的通用建议可能需要针对特殊环境调整。
|
||||
|
||||
Reference in New Issue
Block a user