Sync: update nexus knowledgebase content
This commit is contained in:
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "CTP Topic 29 Cloud Monitoring – SaaS LZ accounts"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Monitoring
|
||||
- SaaS
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-29-cloud-monitoring-saas-lz-accounts]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS 云监控解决方案 OpsBridge Cloud Monitoring，覆盖多账户多区域的云原生监控架构
|
||||
- 问题域：企业级 AWS 多账户环境下，如何实现跨账户、跨区域的统一云监控和可观测性
|
||||
- 方法/机制：Micro Focus OpsBridge 的 Cloud Monitoring 功能，通过 IAM Role 信任关系实现只读跨账户 CloudWatch 数据采集；使用 Vertica 作为分析型数据库支撑性能仪表盘；基于标签的监控策略自动化
|
||||
- 结论/价值：单一 OpsBridge 实例即可监控多个 AWS 账户和区域，降低运维复杂度；与 OpsBridge 产品团队协作持续演进，新增报表功能预计在下一版本发布
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Micro Focus OpsBridge Cloud Monitoring 通过 IAM Role 信任关系实现跨账户只读访问，无需在被监控账户安装任何服务器或共享 Access Key
|
||||
- 基于标签的监控（Tag-based Monitoring）是最佳实践，自动化识别缺失标签的资源和合规问题
|
||||
- 单一 OpsBridge 实例可同时监控多个 AWS 账户和多个区域，降低监控基础设施的运维成本
|
||||
- 数据消费通过事件仪表盘、拓扑视图和性能仪表盘三种维度呈现，满足不同角色的监控需求
|
||||
- 该方案与 OpsBridge 产品研发团队协作开发，报表功能在下一版本中将持续增强
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud Monitoring is enabled within OpsBridge, requiring a one-time IAM role setup in customer accounts for read-only access." — 核心安全设计原则：最小权限只读访问
|
||||
|
||||
> "Tag-based monitoring is emphasized as a best practice, with automation to identify missing tags." — 标签驱动是监控策略的核心，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中的标签安全理念一致
|
||||
|
||||
> "The solution uses a single instance to monitor multiple accounts and regions." — 架构优势：简化运维，降低成本
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud Monitoring（AWS）]]：通过 CloudWatch 采集 AWS 托管服务的指标数据，是云原生监控的基础
|
||||
- [[Tag-Based Monitoring]]：将 AWS 标签作为监控和资源配置的元数据，实现自动化策略应用
|
||||
- [[Vertica]]：Micro Focus OpsBridge 用于存储和分析监控数据的列式分析型数据库
|
||||
- [[OpsBridge]]：Micro Focus 的混合 IT 运维管理平台，支持物理、虚拟和云环境统一监控
|
||||
- [[ITOM（IT Operations Management）]]：IT 运维管理，OpsBridge 所属的产品领域
|
||||
|
||||
## Key Entities
|
||||
- [[Micro Focus OpsBridge]]：企业级 IT 运维监控平台，Cloud Monitoring 是其 AWS 云监控组件
|
||||
- [[AWS CloudWatch]]：AWS 原生监控服务，OpsBridge Cloud Monitoring 的数据来源
|
||||
- [[AWS Landing Zone]]：AWS 多账户治理框架，SaaS LZ 是生产环境的 Landing Zone 实现
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] ← relates_to ← [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]
|
||||
- Topic 8 聚焦 OBM 基础架构部署（OBM 应用/RDS/Agent 三层），Topic 29 聚焦 SaaS LZ 账户架构下的 Cloud Monitoring 功能扩展，两者共同构成 OpsBridge AWS 监控的完整方案
|
||||
- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]
|
||||
- 两者共享"基于标签的安全与监控"理念，Topic 10 从安全角度（SCP 强制标签），Topic 29 从监控角度（自动化标签合规识别）两个维度落地
|
||||
- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← context ← [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]
|
||||
- SaaS Landing Zone 的账户架构为 Cloud Monitoring 提供了多账户监控的落地场景
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] 的账户架构设计存在视角差异：
|
||||
- Topic 8 描述：Agent 通过 AWS Management Pack 利用 IAM Role 信任关系，OBM AWS Account 部署 OBM 应用 + Postgres RDS + Operation Agent 三层组件
|
||||
- Topic 29 描述：Cloud Monitoring 容器化部署在 EKS 上，支持监控 20+ AWS 数据服务，数据存储在 Optic Data Lake（Vertica）
|
||||
- 当前观点：Topic 29 的 Cloud Monitoring 功能可能是 OpsBridge 的新增模块，在 Topic 8 描述的基础架构之上扩展了容器化部署和更丰富的数据服务覆盖能力
|
||||
- 对方观点：Topic 8 是更基础的架构描述，涵盖完整的 OBM 组件栈，两者描述的是同一方案的不同层面
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- EKS
|
||||
- Kubernetes
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date: 2026-04-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 AWS Lab Landing Zone 中通过 Terraform/Terragrunt 自动化部署 EKS 集群，解决 Octane（Micro Focus SaaS 应用）IP 地址池不足的难题
|
||||
- 问题域：Micro Focus 网络环境下的 AWS Lab Landing Zone 网络地址空间受限，无法满足 EKS Pod 大量 IP 地址需求
|
||||
- 方法/机制：
|
||||
- 在独立私有子网（非主 VPC 子网）中部署 EKS，由 EKS 模块自定义网络标志控制 IP 分配
|
||||
- 通过 Terraform/Terragrunt 模块调用 EKS 模块，指定子网和联邦账户/角色映射
|
||||
- Pod 规范中设置 `hostNetwork: true` 使 Pod 直接使用宿主机网络
|
||||
- IAM 角色映射实现集群访问和 AWS Console 可视化
|
||||
- 结论/价值：即使在受限网络环境下，通过 EKS 自定义网络功能 + IaC 自动化仍可成功部署 EKS，无需 Atlantis（Jenkins + Terragrunt 模块替代方案）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- EKS 模块提供自定义网络配置标志，可控制 Pod IP 地址分配策略
|
||||
- 在受限 Lab 网络环境下，创建独立私有子网（非主 VPC 子网）为 EKS Pod 提供充足 IP 地址池
|
||||
- Terraform/Terragrunt 模块可封装 EKS 集群的完整部署逻辑，支持跨账户角色映射
|
||||
- Atlantis 目前无法部署 EKS 集群，需通过 Jenkins + Terragrunt 模块替代
|
||||
- Pod 网络规范设置 `hostNetwork: true` 后，Pod 可同时访问内部 Micro Focus 网络和外部资源
|
||||
- IAM 角色映射使用户可连接集群并在 AWS Console 中查看 EKS 组件
|
||||
- 节点组数量当前硬编码，未来版本将支持可配置参数
|
||||
|
||||
## Key Quotes
|
||||
> "The problem was that this wasn't supported in the EKS sort of solution that was given to us." — Spencer，描述 IP 池不足问题在标准 EKS 方案中不受支持的困境
|
||||
|
||||
> "Within the spec configuration, we basically have to put host network equals true." — Guy，描述让 Pod 访问内部网络的关键配置
|
||||
|
||||
## Key Concepts
|
||||
- [[Amazon EKS]]：AWS 托管 Kubernetes 服务，完全托管控制平面，支持 IAM RBAC 最小权限
|
||||
- [[Kubernetes Custom Networking]]：EKS 自定义网络功能，允许控制 Pod IP 分配策略，解决 VPC CIDR 限制
|
||||
- [[Terraform-Terragrunt Module]]：封装 EKS 部署逻辑的基础设施即代码模块，支持跨账户部署
|
||||
- [[IAM Role Mapping (EKS)]]：通过 AWS IAM 角色映射实现集群访问控制和 AWS Console 可视化
|
||||
- [[Host Network Mode (Pod)]]：Pod 使用宿主机网络栈，`hostNetwork: true` 使 Pod 可访问底层网络资源
|
||||
- [[Container Hardening]]：容器安全加固标准，与安全团队协作实施的容器安全措施
|
||||
|
||||
## Key Entities
|
||||
- [[Octane-Hub]]：Software Factory 团队，Micro Focus 云转型计划一部分，主导 SaaS 应用容器化迁移，CTO 为 Holger Rode；本文档中 Octane 作为 EKS 部署的实际业务驱动方（IP 密集型 SaaS 应用）
|
||||
- [[Spencer]]：AWS Lab Landing Zone EKS 实施分享人
|
||||
- [[Guy]]：AWS Lab Landing Zone EKS 实施技术细节讲解人
|
||||
- [[Terragrunt]]：Terraform 的 wrapper 工具，用于管理跨账户基础设施部署
|
||||
- [[Atlantis]]：Terraform GitOps 工具，当前不支持 EKS 集群部署
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]] ← depends_on ← [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
- Topic 39 解决了 EKS 在受限网络环境下的 IP 分配技术难题，为 Topic 70 的 IaC 部署实践提供底层支撑
|
||||
- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related ← [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
- 两者均讨论 EKS 可靠性，两者互补：Topic 39 侧重网络架构，Topic 59 侧重 SLA/SLO 保障
|
||||
- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← depends_on ← [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
- Labs LZ 的多账户架构和 Terraform/Terragrunt 管理模式是 Topic 39 EKS 部署的基础设施上下文
|
||||
- [[ctp-topic-14-octane-hub-on-aws]] ← related ← [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
- 两者均涉及 Octane 的 AWS 迁移，但 Topic 14 聚焦 Octane Hub 整体迁移，Topic 39 聚焦 EKS 网络解决方案
|
||||
|
||||
## Contradictions
|
||||
- 无发现与现有 Wiki 页面的直接冲突
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Grafana
|
||||
- Observability
|
||||
- Hyperscale
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Grafana 实现 AWS 超大规模可观测性监控
|
||||
- 问题域：云原生监控体系、Grafana 企业版功能、Dashboard as Code 实践
|
||||
- 方法/机制：Grafana 与多种数据源集成、Terraform 模块自动化供给告警配置、资源标签化管理、Optic DR 数据采集
|
||||
- 结论/价值：推动从开源版 Grafana 迁移至企业版以释放全部潜力；Terraform 模块使产品团队自助消费监控能力；默认指标不产生额外成本，自定义指标可能产生费用
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Grafana 企业版相比开源版提供了更完整的功能集，应作为监控体系的升级目标
|
||||
- Terraform 模块通过声明式配置自动化创建 Grafana 组织、用户、文件夹、IAM 角色和仪表板
|
||||
- Optic DR 作为内部监控插件，是将数据导入 Grafana 仪表板的关键数据源
|
||||
- 资源标签化是实现成本核算和资源有效管理的基础
|
||||
- Grafana 告警系统支持灵活配置多种通知渠道，可转发至 Opsbridge 创建工单
|
||||
|
||||
## Key Quotes
|
||||
> "Grafana's ability to provision infrastructure and applications using Terraform modules (dashboard as code) is highlighted" — Dashboard 即代码的核心价值体现
|
||||
> "Optic DR, an internal monitoring solution and plugin of VaticaDB, is crucial for pulling data into Grafana dashboards" — 内部数据源与 Grafana 的集成方式
|
||||
> "Default metrics do not incur additional costs, but custom metrics may" — 成本影响的关键说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Hyperscale Observability]]：超大规模可观测性——针对大规模云环境的多维度监控能力
|
||||
- [[Dashboard as Code]]：通过 Terraform 模块声明式定义 Grafana 资产，实现监控配置的版本控制和自动化部署
|
||||
- [[Grafana Alert System]]：Grafana 告警系统——支持灵活配置通知渠道，可与 Opsbridge 等工单系统集成
|
||||
- [[Resource Tagging]]：资源标签化——通过标签对 AWS 资源进行分类管理，是成本核算和安全策略的基础
|
||||
- [[Instance Monitoring]]：实例监控——识别资源利用率，帮助优化成本和性能
|
||||
- [[Event Tracking]]：事件追踪——监控由 OpsBridge AWS 监控解决方案触发的日常活跃事件
|
||||
|
||||
## Key Entities
|
||||
- [[Vinay]]：演讲者，代替休假中的 Sashi 主持本次学习会议
|
||||
- [[Optic DR]]：内部监控解决方案，VaticaDB 的插件，用于将数据导入 Grafana 仪表板
|
||||
- [[Opsbridge]]：*Opsbridge 监控解决方案，使用仪表板展示监控系统触发的事件
|
||||
- [[VaticaDB]]：提供 Optic DR 插件的内部监控平台
|
||||
- [[Grafana]]：开源可观测性平台，支持多种数据源集成、可视化和告警
|
||||
- [[Terraform]]：基础设施即代码工具，用于自动化 Grafana 资源配置
|
||||
|
||||
## Connections
|
||||
- [[Grafana]] ← uses ← [[Optic DR]]
|
||||
- [[Grafana]] ← integrates_with ← [[Opsbridge]]
|
||||
- [[Grafana]] ← provisioned_by ← [[Terraform]]
|
||||
- [[ctp-topic-60]] ← extends ← [[Grafana Enterprise]]
|
||||
- [[AWS Landing Zone]] ← monitored_by ← [[Grafana]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-8-obm-cloud-monitoring]] 存在互补而非冲突关系：
|
||||
- 冲突点：无冲突，两者针对不同监控层面
|
||||
- 当前观点：Topic 60 聚焦 Grafana 和 AWS 原生监控能力
|
||||
- 对方观点：Topic 8 聚焦 Micro Focus Operations Bridge Manager (OBM) 的跨云统一监控
|
||||
68
wiki/sources/ctp-topic-70-eks-deployment-using-iac.md
Normal file
68
wiki/sources/ctp-topic-70-eks-deployment-using-iac.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: "CTP Topic 70 EKS deployment using IAC"
|
||||
type: source
|
||||
tags: [AWS, EKS, IaC, Kubernetes, CTP]
|
||||
sources: [raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：EKS（Amazon Elastic Kubernetes Service）集群通过 IaC（基础设施即代码）方式部署，涵盖容器与 VM 的对比、EKS 特性详解、Terraform 和 Service Catalog 两种部署方式，以及 EKS 集群与容器监控方案。
|
||||
- 问题域：如何在企业 AWS Landing Zone 中通过标准化 IaC 流程部署和管理 EKS 集群，实现容器化工作负载的统一治理。
|
||||
- 方法/机制：
|
||||
- **两种部署方式**：Terraform（使用 `tera-grant.scl` 文件定义集群参数）+ AWS Service Catalog（通过产品组合模块化部署）
|
||||
- **自定义网络**：EMI（ENI Multi-IP）解决 Pod IP 分配 CIDR 限制问题
|
||||
- **自动扩缩容**：Kubernetes Cluster Autoscaler 根据资源需求自动扩缩 Worker Node
|
||||
- **监控栈**：CloudWatch Agent + FluentBit（DaemonSet）+ Container Insights + AWS OpenTelemetry + Grafana
|
||||
- 结论/价值：通过 SRE EKS 模块集成 Terraform/Service Catalog 两种 IaC 路径，实现 EKS 集群的标准化、可审计、可重复部署；配合 CloudWatch + Grafana 实现全栈可观测性。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Kubernetes 相比 VM 具有更快的启动速度、更高的内存效率和更强的可移植性
|
||||
- EKS 提供完全托管的控制平面，实现 Worker Node 的零停机滚动部署
|
||||
- IAM RBAC Mapping 通过最小权限原则控制 EKS 集群访问
|
||||
- SRE EKS 模块集成 ALB Ingress Controller 实现流量管理
|
||||
- EMI 自定义网络通过虚拟 ENI 为 Pod 分配 IP 地址，解决 VPC CIDR 限制
|
||||
- Kubernetes Cluster Autoscaler 根据资源需求自动扩缩 Worker Node
|
||||
- CloudWatch Agent + FluentBit 以 DaemonSet 方式部署，负责日志和指标收集
|
||||
|
||||
## Key Quotes
|
||||
> "Kubernetes is a framework for running distributed systems resiliently, automating rollouts/rollbacks, load balancing, and horizontal pod scaling." — 核心定义
|
||||
> "EKS offers fully managed control planes and autoscaling worker nodes." — EKS 核心价值
|
||||
> "Zero downtime rolling deployments for worker node updates" — EKS 高可用特性
|
||||
> "IAM RBAC mapping for least privilege access" — EKS 安全模型
|
||||
> "Service Catalog allows creating, organizing, and governing AWS resources with permission control." — Service Catalog 定位
|
||||
|
||||
## Key Concepts
|
||||
- [[Kubernetes]]：容器编排框架，用于分布式系统的弹性运行，支持自动化部署/回滚、负载均衡和 Pod 水平扩缩容
|
||||
- [[Amazon EKS]]（Amazon Elastic Kubernetes Service）：AWS 托管的 Kubernetes 服务，提供完全托管的控制平面和自动扩缩的 Worker Node
|
||||
- [[Infrastructure as Code]]（IaC）：通过代码定义和管理基础设施，实现标准化、可审计、可重复的部署
|
||||
- [[AWS Service Catalog]]：AWS 服务，允许组织创建、管理和组织云资源产品，并进行权限控制
|
||||
- [[IAM RBAC]]：基于角色的访问控制，通过最小权限原则管理 EKS 集群访问
|
||||
- [[Cluster Autoscaler]]：Kubernetes 组件，根据资源需求自动扩缩 Worker Node
|
||||
- [[EMI]]（ENI Multi-IP）：EKS 自定义网络方案，通过虚拟弹性网络接口为 Pod 分配额外 IP 地址，解决 VPC CIDR 限制
|
||||
- [[ALB Ingress Controller]]：AWS Load Balancer Controller，负责管理 ALB Ingress 资源，实现 Kubernetes 服务的七层负载均衡
|
||||
- [[CloudWatch Container Insights]]：AWS 监控服务，收集容器级别的指标和日志并发布到 CloudWatch
|
||||
- [[FluentBit]]：开源日志处理器，以 DaemonSet 方式部署于每个节点，负责收集容器日志
|
||||
- [[AWS OpenTelemetry]]：AWS 的可观测性数据收集方案，支持指标、日志和追踪的统一采集
|
||||
|
||||
## Key Entities
|
||||
- [[Kubernetes]]（entity）：容器编排框架，EKS 的底层技术，Google 开源，CNCF 托管
|
||||
- [[Amazon]]（entity）：AWS/EKS 的提供商
|
||||
|
||||
## Connections
|
||||
- [[Amazon EKS]] ← 基于 ← [[Kubernetes]]
|
||||
- [[Terraform]] ← 用于 ← [[Infrastructure as Code]]
|
||||
- [[AWS Service Catalog]] ← 用于 ← [[Infrastructure as Code]]
|
||||
- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← 相关 ← [[Amazon EKS]]
|
||||
- [[ctp-topic-64-scaling-out-with-amazon-eks]] ← 相关 ← [[Cluster Autoscaler]]
|
||||
- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← 相关 ← [[Amazon EKS]]
|
||||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← 相关 ← [[AWS OpenTelemetry]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]] 可能存在内容重叠：
|
||||
- 冲突点：两篇均涉及 EKS 特性，但侧重点不同
|
||||
- 当前观点：Topic 70 侧重 IaC 部署方法和网络/监控机制
|
||||
- 对方观点：Topic 59 侧重 EKS 可靠性保证和最佳实践
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - EKS Optimization Part 1 of 3 - Compute Optimization with Karpenter"
|
||||
type: source
|
||||
tags: [AWS, EKS, Karpenter, Cost-Optimization, Kubernetes, Spot-Instance]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS EKS 计算成本优化，聚焦 Karpenter 与 Cluster Autoscaler 的对比及 Karpenter 的核心能力
|
||||
- 问题域：传统 Cluster Autoscaler 在 Kubernetes 节点自动伸缩方面的局限性（延迟高、集成浅、功能分散）
|
||||
- 方法/机制：Karpenter 直接与 EC2 Fleet API 通信，结合 Node Pools 和 Node Classes 实现智能工作负载放置与节点整合
|
||||
- 结论/价值：Karpenter 将节点组管理、Spot 中断处理、AMI 生命周期管理整合为统一数据平面，大幅降低 EKS 计算成本和运维复杂度
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Karpenter 通过直接调用 EC2 Fleet API 降低节点供给延迟，相比 Cluster Autoscaler 减少调度等待时间
|
||||
- Karpenter 原生集成 Kubernetes 调度约束（node selectors/affinity/taints/tolerations/topology spread），无需额外组件即可实现精细化工作负载放置
|
||||
- Karpenter 内置 Spot 中断处理能力，通过 EventBridge + SQS 监听 spot interruption/instance rebalance/health events，无需单独部署 node termination handler
|
||||
- Karpenter 通过 Consolidation 策略自动整合低利用率节点，支持细粒度中断预算控制和峰值时段豁免
|
||||
- Karpenter 支持 AMI 自动滚动升级，可从 Parameter Store 获取对应 EKS 控制面版本的最新优化 AMI，支持版本锁定和自定义 AMI
|
||||
|
||||
## Key Quotes
|
||||
> "Carpenter has native integration with Kubernetes and it complements the native Kubernetes spot pod scheduling constraints that is available for your workloads." — 强调 Karpenter 与原生 K8s Spot Pod Disruption Budget 的互补关系
|
||||
|
||||
> "Carpenter not only does the auto-scaling bit, but it also removes the pain points of working with node groups." — 核心价值：Karpenter 不仅做扩缩容，更消除了节点组管理的所有痛点
|
||||
|
||||
## Key Concepts
|
||||
- [[Karpenter]]：AWS 开源的 Kubernetes 节点自动伸缩器，直接与 EC2 Fleet API 通信，实现智能节点供给与整合
|
||||
- [[Node-Pool]]：Karpenter 的核心概念，定义调度约束和容量限制，控制哪些 Pod 可以调度到哪些节点
|
||||
- [[Node-Class]]：Karpenter 的核心概念，定义实例配置细节（子网、节点角色、AMI），相当于实例模板
|
||||
- [[Spot-Interruption-Handling]]：Karpenter 内置的 Spot 实例中断处理，通过 EventBridge + SQS 监听中断信号并自动驱逐 Pod
|
||||
- [[Consolidation]]：Karpenter 的节点整合策略，自动识别低利用率节点并将其 Pod 驱逐整合到更少节点
|
||||
- [[AMI-Rolling-Upgrade]]：Karpenter 的 AMI 生命周期管理，支持从 Parameter Store 自动获取最新 EKS 优化 AMI 并滚动升级
|
||||
- [[EC2-Fleet-API]]：Karpenter 直接调用的 AWS API，绕过 ASG 实现更快的节点供给
|
||||
- [[Topology-Spread-Constraints]]：K8s 拓扑分布约束，Karpenter 支持基于可用区的 Pod 分布调度
|
||||
|
||||
## Key Entities
|
||||
- [[Amazon EKS]]：托管 Kubernetes 服务，Karpenter 的运行平台
|
||||
- [[AWS EC2]]：Karpenter 调度计算资源的目标平台
|
||||
- [[Amazon EventBridge]]：Karpenter 监听 Spot 中断事件的 AWS 事件总线
|
||||
- [[Amazon SQS]]：Karpenter 接收 Spot 中断通知的队列服务
|
||||
- [[AWS Systems Manager Parameter Store]]：Karpenter 获取 EKS 优化 AMI 版本的配置存储服务
|
||||
- [[Prometheus]]：Karpenter 发布指标的开源监控系统
|
||||
- [[Cluster Autoscaler]]：Karpenter 的对标竞品，K8s 生态传统节点自动伸缩方案
|
||||
|
||||
## Connections
|
||||
- [[Amazon EKS]] ← 平台 ← [[Karpenter]]
|
||||
- [[Cluster Autoscaler]] ← 替代升级 ← [[Karpenter]]
|
||||
- [[Spot-Interruption-Handling]] ← 依赖 ← [[Amazon EventBridge]] + [[Amazon SQS]]
|
||||
- [[AMI-Rolling-Upgrade]] ← 依赖 ← [[AWS Systems Manager Parameter Store]]
|
||||
- [[Consolidation]] ← 关联 ← [[Cost-Optimization]]
|
||||
- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← 系列后续 ← [[Karpenter]]（Part 3 覆盖 EKS Auto Mode，内含 Karpenter Controller）
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]] ← 关联 ← [[Amazon EKS]]（部署方法）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-70-eks-deployment-using-iac]] 可能存在视角差异：
|
||||
- 冲突点：节点扩缩容方案选型
|
||||
- 当前观点（Part 1）：推荐 Karpenter，强调其原生集成和简化数据平面管理的能力
|
||||
- 对方观点（Topic 70）：重点介绍 Cluster Autoscaler 作为扩缩容方案
|
||||
- 说明：两者并非互斥——Topic 70 聚焦 EKS IaC 部署流程中的 Cluster Autoscaler 集成；Part 1 聚焦计算优化专题，强调从 Cluster Autoscaler 迁移至 Karpenter 的收益。可并存作为迁移路径参考。
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - EKS Optimization Part 3 of 3 - Introduction to EKS Auto Mode"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-03-04
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：EKS Auto Mode — AWS 将 EKS 数据平面管理责任扩展至计算节点托管
|
||||
- 问题域：EKS 集群运维复杂度高（实例管理、OS 补丁、安全更新）
|
||||
- 方法/机制：Carpenter Controller 负责节点生命周期管理；Bottlerocket OS 提供最小化安全操作系统；AWS Load Balancer Controller 处理 ingress；EBS CSI Controller 支持有状态工作负载；Pod Identity Associations 替代 K8s RBAC 进行 Pod 级 IAM 权限控制；12% 实例费用溢价覆盖自动管理成本
|
||||
- 结论/价值：EKS Auto Mode 大幅降低 K8s 运维负担，用户只需关注 VPC 配置、集群配置和 workload 配置；数据平面升级自动化（控制面升级后 Carpenter 自动触发滚动升级）；与标准 Kubernetes 工作负载完全兼容
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- EKS Auto Mode 将数据平面管理责任从用户扩展至 AWS 服务，覆盖实例、OS、补丁和安全更新
|
||||
- EKS Auto Mode 默认提供两个节点池（General Purpose 和 System）和一个节点类（NodeClass）
|
||||
- General Purpose 节点池锁定 AMD64 架构，Custom 节点池可指定 Graviton 实例类型
|
||||
- System 节点池的节点带有 taint，系统 add-on 必须配置对应 tolerations
|
||||
- EKS Auto Mode 包含核心集群能力：计算（Carpenter）、网络（AWS LB Controller）、存储（EBS CSI）、安全（Pod Identity Associations）
|
||||
- Prefix Delegation 默认启用，优化 Pod 网络 IP 分配
|
||||
- 数据平面升级由控制面版本升级触发，Carpenter Controller 自动识别并执行滚动升级
|
||||
- 每个 Auto Mode 实例收取 12% 溢价，覆盖自动化管理成本
|
||||
- 可观测性通过 CloudWatch Agent、ADOT（AWS Distro for OpenTelemetry）或第三方收集器实现
|
||||
|
||||
## Key Quotes
|
||||
> "With Auto Mode, a majority of the operational concerns are being managed by the ECS service." — EKS Auto Mode 将大多数运维职责托管至 AWS
|
||||
> "Once the control plane version gets upgraded, then the compute controller... will try to pull the current AMI version for that new control plane version." — 数据平面自动升级机制
|
||||
|
||||
## Key Concepts
|
||||
- [[EKS Auto Mode]]：AWS EKS 的半托管模式，将计算节点的生命周期管理（实例采购、OS 补丁、安全更新）托管给 AWS，适用于希望降低 K8s 运维复杂度同时保留标准 K8s API 兼容性的团队
|
||||
- [[Carpenter Controller]]：EKS Auto Mode 的计算控制器，负责节点池生命周期管理、AMI 版本管理和滚动升级编排
|
||||
- [[Bottlerocket OS]]：Amazon 开发的容器专用最小化 Linux 操作系统，专为 EKS Auto Mode 设计，自动应用安全补丁
|
||||
- [[AWS Load Balancer Controller]]：Auto Mode 特有的 LoadBalancer 类（eks.aws/alb），管理 ALB/NLB ingress 资源
|
||||
- [[EBS CSI Controller]]：EKS Auto Mode 的存储控制器，提供 EBS 卷的动态供给，支持有状态工作负载（需配置 StorageClass 引用 eks-aws-ebs provisioner）
|
||||
- [[Pod Identity Associations]]：AWS 提供的 Pod 级 IAM 权限控制机制，替代传统的 K8s RBAC + ServiceAccount IAM Role 模式，无需修改 ServiceAccount annotation
|
||||
- [[Prefix Delegation]]：VPCCNI 的一个特性，为 Pod 分配 /28 前缀 IP 块而非单 IP，优化网络地址利用率，默认在 Auto Mode 中启用
|
||||
- [[CoreDNS]]：K8s 集群 DNS 服务，在 Auto Mode 中作为系统服务打包至每个节点
|
||||
- [[Kube Proxy]]：K8s 网络代理，在 Auto Mode 中以 IPtables 模式运行
|
||||
- [[VPCCNI]]：Amazon VPC CNI 网络插件，在 Auto Mode 中作为系统服务运行
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：Amazon Web Services，EKS Auto Mode 的云服务提供商
|
||||
- [[Amazon EKS]]：AWS 托管 Kubernetes 服务，Auto Mode 扩展了其托管范围至数据平面
|
||||
|
||||
## Connections
|
||||
- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]] ← extends ← [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]
|
||||
- [[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]] ← extends ← [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]
|
||||
- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related_to ← [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]
|
||||
- [[ctp-topic-64-scaling-out-with-amazon-eks]] ← related_to ← [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]] ← related_to ← [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突内容
|
||||
Reference in New Issue
Block a user