Auto-sync: update nexus workspace

wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md

@@ -6,61 +6,63 @@ tags:
   - EKS
   - Kubernetes
   - Landing-Zone
+  - Terraform
+  - Terragrunt
   - CTP
-date: 2026-04-24
+date: 2026-04-14
+sources: []
+last_updated: 2026-04-28
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md]]
+- [[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 地址需求
+- 核心主题：在 AWS Lab Landing Zone 中实现 EKS（Elastic Kubernetes Service），解决 Microfocus Octane SaaS 应用的 IP 地址不足问题
+- 问题域：AWS Lab 网络环境中 IP 地址池受限，无法满足 EKS 集群中 Pod 的 IP 分配需求
 - 方法/机制：
-  - 在独立私有子网（非主 VPC 子网）中部署 EKS，由 EKS 模块自定义网络标志控制 IP 分配
-  - 通过 Terraform/Terragrunt 模块调用 EKS 模块，指定子网和联邦账户/角色映射
-  - Pod 规范中设置 `hostNetwork: true` 使 Pod 直接使用宿主机网络
-  - IAM 角色映射实现集群访问和 AWS Console 可视化
-- 结论/价值：即使在受限网络环境下，通过 EKS 自定义网络功能 + IaC 自动化仍可成功部署 EKS，无需 Atlantis（Jenkins + Terragrunt 模块替代方案）
+  - 在独立私网子网（非主 subnet）内创建 EKS 集群，提供大量可用 IP
+  - 使用 Terraform + Terragrunt 模块化部署 EKS
+  - 通过 EKS 模块的自定义网络配置标志（flag）控制 IP 分配
+  - 在 Pod spec 中设置 `hostNetwork: true`，使 Pod 使用宿主机网络
+  - 通过角色映射（role mapping）实现跨账户连接集群和 AWS Console 可视化
+- 结论/价值：成功在受限网络环境中部署 EKS，支持访问内部 Microfocus 网络资源和外部资源；Atlantis 当前无法部署 EKS，改用 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 组件
-- 节点组数量当前硬编码，未来版本将支持可配置参数
+- Spencer 和 Guy 在 AWS Lab Landing Zone 中为 Microfocus Octane SaaS 应用（IP 密集型）成功部署了 EKS
+- 标准 EKS 部署方案不支持在独立私网子网中分配大量 IP，需启用 EKS 模块的自定义网络配置标志
+- 在 Pod spec 中配置 `hostNetwork: true` 后，Pod 可直接使用宿主机网络 IP，实现与内部 Microfocus 网络的通信
+- Atlantis 当前无法部署 EKS 集群，改用 Jenkins 上的 Terragrunt 模块实现自动化部署
+- 通过角色映射（federated account/role mapping）实现跨账户连接 EKS 集群并在 AWS Console 中查看 EKS 组件
+- Node group 数量目前硬编码，未来版本将支持可配置化
+- 容器安全加固已与安全团队讨论并实施
 
 ## 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 访问内部网络的关键配置
+> "The problem was was that this wasn't supported in the EKS sort of solution that was given to us." — Spencer，描述标准 EKS 方案在独立私网环境中的限制
+> "Within the spec configuration, we basically have to put host network equals true." — Guy，描述 Pod 如何使用宿主机网络实现 IP 访问
+> "Atlantis cannot currently deploy EKS clusters; a Terragrunt module on Jenkins is used instead." — 关于 EKS 部署工具链的说明
 
 ## 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]]：容器安全加固标准，与安全团队协作实施的容器安全措施
+- [[AWS Landing Zone]]：AWS 多账户基础设施架构框架，提供基础网络、安全、合规框架
+- [[EKS Custom Networking]]：EKS 提供的自定义网络配置，允许控制 Pod IP 分配，不依赖 VPC CNI 默认行为
+- [[Host Network Mode]]：Kubernetes Pod 配置项（hostNetwork: true），使 Pod 共享宿主机的网络命名空间
+- [[Terraform Terragrunt]]：Terragrunt 作为 Terraform 的 wrapper，支持模块化和跨账户基础设施部署
+- [[Kubernetes Pod Networking]]：Pod 网络模型，决定 Pod 如何获取 IP 及与集群内外通信
 
 ## 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 集群部署
+- [[Spencer]]：OpenText/Micro Focus SRE，负责 AWS Lab Landing Zone 架构设计
+- [[Guy]]：OpenText/Micro Focus 技术专家，参与 EKS 部署实现
+- [[Octane]]：Micro Focus SaaS 应用，IP 地址密集型 workload，是本次 EKS 部署的驱动用例
+- [[Micro Focus]]：公司名称，现为 OpenText 旗下
+- [[Atlantis]]：基于 Terraform 的 Pull Request 自动化工具，当前不支持 EKS 部署
+- [[Jenkins]]：CI/CD 平台，用于执行 Terragrunt 模块部署 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 网络解决方案
+- [[CTP Topic 10 AWS Landing Zone LZ Data Collection Tagging Related Security]] ← relates_to ← [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]]
+- [[CTP Topic 70 EKS Deployment Using IAC]] ← extends ← [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]]
+- [[Public Cloud Learning Sessions EKS Optimization Part 1 of 3 Compute Optimization with Karpenter]] ← extends ← [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]]
+- [[CTP Topic 64 Scaling Out with Amazon EKS]] ← extends ← [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]]
+- [[CTP Topic 59 Achieving Reliability with Amazon EKS]] ← extends ← [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]]
 
 ## Contradictions
-- 无发现与现有 Wiki 页面的直接冲突
+- （暂无已知冲突内容）

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 数值）本文档未涉及
+  - 当前观点：聚焦工程实践和机制设计层面
+  - 对方观点：可能包含可靠性指标的量化定义

wiki/sources/ctp-topic-70-eks-deployment-using-iac.md

@@ -1,68 +1,81 @@
 ---
 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
+tags:
+  - AWS
+  - EKS
+  - IaC
+  - Kubernetes
+  - CTP
+last_updated: 2026-04-28
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac.md]]
 
 ## Summary（用中文描述）
-- 核心主题：EKS（Amazon Elastic Kubernetes Service）集群通过 IaC（基础设施即代码）方式部署，涵盖容器与 VM 的对比、EKS 特性详解、Terraform 和 Service Catalog 两种部署方式，以及 EKS 集群与容器监控方案。
-- 问题域：如何在企业 AWS Landing Zone 中通过标准化 IaC 流程部署和管理 EKS 集群，实现容器化工作负载的统一治理。
+- 核心主题：通过基础设施即代码（IaC）部署 Amazon EKS 集群，涵盖容器与虚拟机对比、EKS 特性、Terraform/Service Catalog 两种部署方式、自定义网络与自动扩缩容、以及监控体系。
+- 问题域：企业如何在 AWS 云中使用 IaC 工具标准化、可重复地部署和管理 Kubernetes 集群。
 - 方法/机制：
-  - **两种部署方式**：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 实现全栈可观测性。
+  - **Terraform 部署**：通过 `tera-grant.scl` 文件定义环境变量、EKS 版本和工作节点类型（CPU/GPU/default），集成 AWS Secrets Manager 发送通知。
+  - **Service Catalog 部署**：提供版本选择和工作节点类型配置，对安全与权限有更多控制。
+  - **自定义网络（EMI）**：为 Pod 分配弹性网络接口以解决 CIDR 限制。
+  - **集群自动扩缩容**：Kubernetes Cluster Autoscaler 根据资源需求自动扩缩工作节点。
+  - **监控体系**：CloudWatch Agent + FluentBit（DaemonSet）+ Container Insights + Grafana 集中可视化。
+- 结论/价值：SRE EKS 模块提供企业级 Kubernetes 部署方案，通过 IaC 实现标准化，通过 ALB Ingress Controller 实现流量管理，通过自定义 EMI 解决网络限制，通过集中监控实现主动告警。
 
 ## 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 方式部署，负责日志和指标收集
+- 容器相比虚拟机：启动时间更短、内存效率更高、更易于跨环境迁移。
+- Kubernetes 提供分布式系统运行框架，具备零停机滚动部署、负载均衡和水平 Pod 扩缩容能力。
+- EKS 提供完全托管的控制平面和工作节点自动扩缩，支持零停机滚动更新和 IAM RBAC 最小权限映射。
+- SRE EKS 模块通过 Terraform 或 Service Catalog 两种方式部署，Service Catalog 提供更细粒度的安全控制。
+- 自定义 EMI 网络为 Pod 分配 IP 地址，解决 VPC CIDR 限制问题。
+- Kubernetes Cluster Autoscaler 自动根据资源需求扩缩工作节点。
+- 监控方案：CloudWatch Agent + FluentBit（DaemonSet）+ Container Insights 发布指标至 CloudWatch，配合集中式 Grafana 仪表板可视化。
 
 ## 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 定位
+> "EKS, a managed Kubernetes service by Amazon, offers features like fully managed control planes and autoscaling worker nodes." — EKS 托管服务核心价值
+
+> "Zero downtime rolling deployments for worker node updates and IAM RBAC mapping for least privilege access are implemented." — SRE EKS 模块核心安全实践
+
+> "Service Catalog allows creating, organizing, and governing AWS resources with permission control." — Service Catalog 在 EKS 部署中的角色
+
+> "Custom networking for pods addresses CIDR limitations by adding a virtual EMI to assign IP addresses to pods." — EMI 自定义网络机制
+
+> "Monitoring is achieved using CloudWatch agent and FluentBit deployed as daemon sets." — EKS 监控架构
 
 ## 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 的可观测性数据收集方案，支持指标、日志和追踪的统一采集
+- [[Container]]：轻量级虚拟化技术，相比虚拟机具有更快的启动速度、更高的内存效率和更好的可移植性。
+- [[Kubernetes]]：分布式系统运行框架，提供自动化部署、扩缩容、负载均衡和滚动更新能力。
+- [[Amazon-EKS]]：AWS 托管的 Kubernetes 服务，提供完全托管的控制平面和工作节点自动扩缩。
+- [[Infrastructure-as-Code-IaC]]：通过声明式配置管理云基础设施，实现标准化、可重复的部署流程。
+- [[Terraform]]：HashiCorp 出品的云无关 IaC 工具，用于定义和部署 EKS 集群。
+- [[AWS-Service-Catalog]]：AWS 服务目录，允许用户通过预定义产品创建 EKS 集群，具备权限控制能力。
+- [[ALB-Ingress-Controller]]：AWS 负载均衡器入口控制器，用于 EKS 集群的流量管理。
+- [[EMI-Elastic-Network-Interface]]：弹性网络接口，用于为 EKS Pod 分配 IP 地址以解决 VPC CIDR 限制。
+- [[Cluster-Autoscaler]]：Kubernetes 组件，根据资源需求自动扩缩工作节点。
+- [[Karpenter]]：AWS 开源的 Kubernetes 节点自动配置工具，基于 Pod 需求动态创建最佳实例类型（未来替代 Cluster Autoscaler 的方案）。
+- [[CloudWatch-Agent]]：AWS 监控代理，用于收集 EKS 集群和容器的日志与指标。
+- [[FluentBit]]：开源日志处理器，作为 DaemonSet 部署在每个节点上收集容器日志。
+- [[Container-Insights]]：EKS 监控功能，发布容器指标至 CloudWatch。
+- [[AWS-Open-Telemetry]]：可观测性框架，可用于 EKS 监控数据采集。
+- [[Grafana]]：开源可视化平台，通过模板化仪表板展示 EKS 集群和容器指标。
 
 ## Key Entities
-- [[Kubernetes]]（entity）：容器编排框架，EKS 的底层技术，Google 开源，CNCF 托管
-- [[Amazon]]（entity）：AWS/EKS 的提供商
+- [[AWS]]：Amazon Web Services，提供 EKS 托管 Kubernetes 服务。
+- [[HashiCorp]]：Terraform 开发商，提供云无关 IaC 工具。
+- [[SRE]]：Site Reliability Engineering 团队，负责 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]]
+- [[Amazon-EKS]] ← uses ← [[Infrastructure-as-Code-IaC]]
+- [[Amazon-EKS]] ← deployed_by ← [[Terraform]]
+- [[Amazon-EKS]] ← deployed_by ← [[AWS-Service-Catalog]]
+- [[Amazon-EKS]] ← manages_traffic_with ← [[ALB-Ingress-Controller]]
+- [[Amazon-EKS]] ← networking_extended_by ← [[EMI-Elastic-Network-Interface]]
+- [[Amazon-EKS]] ← scales_with ← [[Cluster-Autoscaler]]
+- [[Amazon-EKS]] ← monitors_with ← [[CloudWatch-Agent]] + [[FluentBit]] + [[Container-Insights]]
+- [[Grafana]] ← visualizes ← [[Amazon-EKS]] monitoring data
+- [[Amazon-EKS]] ← extends ← [[Kubernetes]]
 
 ## Contradictions
-- 与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]] 可能存在内容重叠：
-  - 冲突点：两篇均涉及 EKS 特性，但侧重点不同
-  - 当前观点：Topic 70 侧重 IaC 部署方法和网络/监控机制
-  - 对方观点：Topic 59 侧重 EKS 可靠性保证和最佳实践
+- （本主题未发现与其他 Wiki 页面的直接冲突，与相关 EKS 主题形成互补关系）

wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md

@@ -7,7 +7,7 @@ tags:
   - Bottlerocket
   - Container OS
   - Cloud-Native
-date: 2026-04-24
+date: 2026-04-14
 ---
 
 ## Source File

wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md

@@ -34,9 +34,9 @@ date: 2026-04-14
 ## Key Concepts
 - [[Global Information Security Policy (GISP)]]：最高纲领性政策，季度审查
 - [[ISO-27001]]：姿态框架基础，2022 年更新，新增 11 个控制方面
-- [[Security-Awareness-Training]]：月度安全通讯 + 网络钓鱼演练
-- [[Third-Party-Penetration-Testing]]：年度桌面演练 + 红队演练
-- [[Threat-Intelligence]]：结合 BrightCloud 等工具的威胁情报体系
+- [[Security Awareness Training]]：月度安全通讯 + 网络钓鱼演练
+- [[Third Party Penetration Testing]]：年度桌面演练 + 红队演练
+- [[Threat Intelligence]]：结合 BrightCloud 等工具的威胁情报体系
 - [[FedRAMP]]：政府级云安全认证
 
 ## Key Entities
@@ -51,5 +51,5 @@ date: 2026-04-14
 
 ## Contradictions
 - 与 [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Related-Security]] 存在视角互补而非冲突：
-  - 冲突点：两者均涉及安全治理，但 Topic 10 聚焦于 AWS 层面的标签化安全策略（SCP/Checkpoint），Topic 41 聚焦于企业级安全政策框架（ISO 27001/GISP）
+  - 冲突点：两者均涉及安全治理，但 Topic 10 聚焦于 AWS 层面的标签化安全策略（SCP/Checkpoint），本主题聚焦于企业级安全政策框架（ISO 27001/GISP）
   - 当前观点：两者互补——GISP 定义全局政策纲领，AWS Landing Zone 层面通过标签和 SCP 实现技术落地