diff --git a/Project/fonrey/PRD/权限管理/未命名.md b/Project/fonrey/PRD/权限管理/未命名.md index e69de29b..005f8b6b 100644 --- a/Project/fonrey/PRD/权限管理/未命名.md +++ b/Project/fonrey/PRD/权限管理/未命名.md @@ -0,0 +1,109 @@ +# 二手租赁 - 权限管理配置 + +## 概述 +本文档记录了房源管理模块中"二手租赁"功能的权限配置详情,包括各个功能项对应的权限描述和使用说明。 + +--- + +## 权限配置表 + +| 序号 | 权限项 | 权限标识 | 权限描述 | 说明 | +|------|--------|---------|--------|------| +| 1 | 查看 | VIEW | 可以查看二手租赁房源信息 | 基础权限 | +| 2 | 新增 | CREATE | 可以新增二手租赁房源 | 编辑权限 | +| 3 | 编辑 | EDIT | 可以修改二手租赁房源信息 | 编辑权限 | +| 4 | 删除 | DELETE | 可以删除二手租赁房源 | 高危操作 | +| 5 | 发布 | PUBLISH | 可以发布二手租赁房源 | 关键操作 | +| 6 | 下架 | OFFLINE | 可以下架二手租赁房源 | 关键操作 | +| 7 | 转让 | TRANSFER | 可以转让二手租赁房源 | 特殊权限 | +| 8 | 导入 | IMPORT | 可以批量导入二手租赁房源 | 批量操作 | +| 9 | 导出 | EXPORT | 可以导出二手租赁房源数据 | 批量操作 | +| 10 | 分配 | ASSIGN | 可以分配二手租赁房源给其他员工 | 管理权限 | + +--- + +## 权限级别说明 + +### 🔴 高危权限 +- **删除操作** - 需要谨慎,建议仅赋予管理员 +- **数据导出** - 涉及数据安全,需要控制 + +### 🟠 关键权限 +- **发布操作** - 影响房源在线可见性 +- **下架操作** - 影响房源展示状态 +- **转让操作** - 涉及所有权变更 + +### 🟢 基础权限 +- **查看权限** - 基础浏览权限 +- **新增权限** - 创建房源权限 +- **编辑权限** - 修改房源信息权限 + +### 🔵 管理权限 +- **分配权限** - 管理员级别权限 +- **批量操作** - 涉及多条数据操作 + +--- + +## 使用建议 + +### 不同角色的权限配置参考 + +#### 1. **普通经纪人** +- ✅ 查看 (VIEW) +- ✅ 新增 (CREATE) +- ✅ 编辑 (EDIT) +- ❌ 删除 (DELETE) +- ✅ 发布 (PUBLISH) +- ✅ 下架 (OFFLINE) + +#### 2. **店长/主管** +- ✅ 查看 (VIEW) +- ✅ 新增 (CREATE) +- ✅ 编辑 (EDIT) +- ✅ 删除 (DELETE) +- ✅ 发布 (PUBLISH) +- ✅ 下架 (OFFLINE) +- ✅ 转让 (TRANSFER) +- ✅ 分配 (ASSIGN) +- ✅ 导入 (IMPORT) +- ✅ 导出 (EXPORT) + +#### 3. **系统管理员** +- ✅ 全部权限 + +#### 4. **仅查看角色** +- ✅ 查看 (VIEW) + +--- + +## 权限矩阵 + +| 功能 | 经纪人 | 店长 | 主管 | 管理员 | 仅查看 | +|------|:----:|:----:|:----:|:----:|:----:| +| 查看 | ✅ | ✅ | ✅ | ✅ | ✅ | +| 新增 | ✅ | ✅ | ✅ | ✅ | ❌ | +| 编辑 | ✅ | ✅ | ✅ | ✅ | ❌ | +| 删除 | ❌ | ✅ | ✅ | ✅ | ❌ | +| 发布 | ✅ | ✅ | ✅ | ✅ | ❌ | +| 下架 | ✅ | ✅ | ✅ | ✅ | ❌ | +| 转让 | ❌ | ✅ | ✅ | ✅ | ❌ | +| 导入 | ❌ | ✅ | ✅ | ✅ | ❌ | +| 导出 | ❌ | ✅ | ✅ | ✅ | ❌ | +| 分配 | ❌ | ❌ | ✅ | ✅ | ❌ | + +--- + +## 注意事项 + +1. **权限继承** - 高级权限自动包含低级权限的操作能力 +2. **审计日志** - 所有删除、发布、转让等关键操作需记录操作日志 +3. **数据安全** - 导出操作需要获得用户同意并记录 +4. **权限变更** - 权限变更应在离线状态下进行,避免业务中断 +5. **定期审计** - 建议每月审查一次各角色的权限配置 + +--- + +## 相关文档 +- [权限管理列表](./权限管理列表.md) +- [修改角色说明](./修改角色.md) +- [添加角色指南](./添加角色.md) \ No newline at end of file diff --git a/wiki/concepts/Amazon-EKS.md b/wiki/concepts/Amazon-EKS.md new file mode 100644 index 00000000..d0c0c3f7 --- /dev/null +++ b/wiki/concepts/Amazon-EKS.md @@ -0,0 +1,68 @@ +--- +title: "Amazon EKS" +type: concept +tags: [AWS, Kubernetes, 托管服务, 容器编排] +sources: [ctp-topic-70-eks-deployment-using-iac, public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks, ctp-topic-59-achieving-reliability-with-amazon-eks, ctp-topic-64-scaling-out-with-amazon-eks] +last_updated: 2026-04-24 +--- + +# Amazon EKS + +## Overview +Amazon Elastic Kubernetes Service (EKS) 是 AWS 提供的托管 Kubernetes 服务,提供完全托管的控制平面,支持零停机滚动部署和 Worker Node 自动扩缩容。 + +## Key Features +- **完全托管控制平面**:AWS 自动管理 Kubernetes Control Plane 的可用性和扩展性 +- **零停机滚动部署**:Worker Node 更新时实现零停机 +- **IAM RBAC Mapping**:通过最小权限原则控制 EKS 集群访问 +- **多可用区高可用**:自动跨多个 AZ 部署 Control Plane +- **与 AWS 服务集成**:VPC、CNI、IAM、CloudWatch、ALB 等原生集成 + +## Deployment Methods +### Terraform +通过 `tera-grant.scl` 文件定义集群参数: +- 环境变量配置 +- EKS 集群版本 +- Worker Node 类型(CPU/GPU/Default) +- AWS Secret Manager 集成(工程联系人通知) + +### AWS Service Catalog +通过产品组合模块化部署: +- 版本选择 +- Worker Node 类型配置 +- 更精细的安全和权限控制 + +## Networking +### EMI (ENI Multi-IP) +自定义网络解决方案,解决 VPC CIDR 限制: +- 为 Pod 分配额外 IP 地址 +- 通过虚拟弹性网络接口(ENI)实现 +- 支持更高的 Pod 密度 + +### ALB Ingress Controller +AWS Load Balancer Controller 集成: +- 管理 Application Load Balancer 资源 +- 实现 Kubernetes Service 的七层负载均衡 +- 自动配置路由规则 + +## Autoscaling +### Cluster Autoscaler +Kubernetes Cluster Autoscaler: +- 根据资源需求自动扩缩 Worker Node +- 与 AWS Auto Scaling Groups 集成 +- 未来计划引入 Carpenter 实现更高效的实例类型创建 + +## Monitoring +- **CloudWatch Agent + FluentBit**:以 DaemonSet 方式部署,收集日志和指标 +- **Container Insights**:发布容器级别指标到 CloudWatch +- **AWS OpenTelemetry**:统一的可观测性数据采集方案 +- **Grafana**:通过模板化仪表盘可视化指标 + +## Related Concepts +- [[Kubernetes]]:EKS 的底层技术 +- [[Infrastructure as Code]]:EKS 部署的推荐方式 +- [[AWS Service Catalog]]:EKS 部署的 Service Catalog 方式 +- [[Cluster Autoscaler]]:Worker Node 自动扩缩容 +- [[EMI]]:EKS 自定义网络方案 +- [[CloudWatch Container Insights]]:EKS 监控方案 +- [[AWS OpenTelemetry]]:可观测性数据采集 diff --git a/wiki/concepts/Cloud-Monitoring.md b/wiki/concepts/Cloud-Monitoring.md new file mode 100644 index 00000000..9627f9c2 --- /dev/null +++ b/wiki/concepts/Cloud-Monitoring.md @@ -0,0 +1,42 @@ +--- +title: Cloud Monitoring +type: concept +tags: [AWS, CloudOps, Observability, CTP, Monitoring] +date: 2026-04-14 +--- + +## Definition +Cloud Monitoring(云监控)是指在公有云环境(AWS/Azure/GCP)中,对基础设施、服务器、应用程序、硬件和网络等数据源进行持续监控和事件采集的系统性实践。云监控的核心挑战在于云环境的动态性——资源生命周期短、数量庞大、跨多账户多区域分布,传统基于静态服务器的监控工具难以有效覆盖。 + +## Core Properties +- **动态发现**:云环境中资源随时创建/销毁,监控必须支持自动发现而非静态配置 +- **多账户覆盖**:AWS Organizations 多账户架构下,需要集中化监控能力 +- **无代理采集**:云环境下倾向于通过 API(如 CloudWatch)而非在被监控目标上安装 Agent +- **跨平台支持**:现代监控解决方案需支持 AWS/Azure/GCP 等多云环境 +- **策略驱动**:通过 Policy/Management Pack 定义监控规则,实现规模化管理 + +## Key Mechanisms +- **CloudWatch API**:AWS 的指标和日志服务,是 AWS 云监控的统一数据源 +- **IAM Role 跨账户访问**:通过角色信任关系实现监控账户安全读取被监控账户数据,无需共享 Access Key +- **Management Pack**:监控平台(如 OBM)的策略包,定义采集间隔、指标、阈值和数据源 +- **Global/Regional 分层架构**:区域级 OBM 采集数据 → 全球级 OBM 汇聚 → 工单系统触发事件处理 + +## Comparison with Traditional Monitoring +| 维度 | 传统监控 | 云监控 | +|------|---------|--------| +| 目标发现 | 手动添加 | 自动发现 | +| 部署模式 | 被监控目标安装 Agent | API 拉取(无代理) | +| 账户覆盖 | 单点监控 | 多账户集中采集 | +| 伸缩性 | 固定容量 | 按需弹性 | +| 密钥管理 | 共享 Access Key | IAM Role 信任关系 | + +## Related Concepts +- [[Multi-Account-Deployment]]:云监控的多账户架构基础 +- [[Landing-Zone-Architecture]]:监控账户是 Landing Zone 的一部分 +- [[IAM-Role]]:跨账户安全访问的核心机制 +- [[Management-Pack]]:云监控策略化管理的具体实现 +- [[Cloud-Native]]:云原生监控的自然延伸 + +## References +- [[ctp-topic-8-obm-cloud-monitoring]]:OBM AWS 云监控完整实现方案 +- [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]:SaaS Landing Zone 监控账户架构 diff --git a/wiki/concepts/Cluster-Autoscaler.md b/wiki/concepts/Cluster-Autoscaler.md new file mode 100644 index 00000000..79c08217 --- /dev/null +++ b/wiki/concepts/Cluster-Autoscaler.md @@ -0,0 +1,30 @@ +--- +title: "Cluster Autoscaler" +type: concept +tags: [Kubernetes, 自动扩缩容, 云原生] +sources: [ctp-topic-70-eks-deployment-using-iac, ctp-topic-64-scaling-out-with-amazon-eks] +last_updated: 2026-04-24 +--- + +# Cluster Autoscaler + +## Overview +Cluster Autoscaler 是 Kubernetes 的自动扩缩容组件,根据资源需求自动调整 Worker Node 的数量,实现基础设施的弹性伸缩。 + +## How It Works +1. **监控资源使用情况**:定期检查 Pod 的调度状态 +2. **检测资源不足**:当 Pod 因资源不足无法调度时触发扩容 +3. **调用云提供商的 API**:AWS 上与 Auto Scaling Groups 集成 +4. **自动启动新节点**:在可用区中启动新 EC2 实例 +5. **缩容检测**:当节点利用率低且 Pod 可安全驱逐时,触发缩容 + +## AWS Integration +- 与 AWS Auto Scaling Groups 深度集成 +- 支持多个 Auto Scaling Groups +- 根据 Pod 需求自动选择合适的实例类型 + +## Related Concepts +- [[Amazon EKS]]:Cluster Autoscaler 部署的目标平台 +- [[Kubernetes]]:Cluster Autoscaler 是 Kubernetes 的核心组件 +- [[Horizontal Pod Autoscaler (HPA)]]:Pod 级别的水平扩缩容(HPA 扩 Pod,CA 扩 Node) +- [[Vertical Pod Autoscaler (VPA)]]:Pod 级别的垂直扩缩容 diff --git a/wiki/concepts/EKS-Auto-Mode.md b/wiki/concepts/EKS-Auto-Mode.md new file mode 100644 index 00000000..3b15a198 --- /dev/null +++ b/wiki/concepts/EKS-Auto-Mode.md @@ -0,0 +1,35 @@ +--- +title: "EKS Auto Mode" +type: concept +tags: [] +last_updated: 2025-03-04 +--- + +## Summary +EKS Auto Mode 是 Amazon EKS 的半托管计算模式,将 Kubernetes 数据平面(计算节点)的生命周期管理责任从用户扩展至 AWS。用户只需关注 VPC 配置、集群配置和 workload 配置,AWS 自动处理节点采购、OS 补丁、安全更新和滚动升级。 + +## Definition +AWS EKS 的半托管计算选项,通过 Carpenter Controller 自动管理节点池的生命周期,包括实例采购、操作系统(Bottlerocket)维护、安全补丁和版本升级。兼容所有 Kubernetes-compliant 工作负载,无需修改应用代码。 + +## Key Components +- **Carpenter Controller**:计算控制器,运行于集群内,负责节点池生命周期管理、AMI 版本管理和滚动升级编排 +- **Bottlerocket OS**:Amazon 开发的容器专用最小化 Linux 操作系统,专为 Auto Mode 设计,自动应用安全补丁 +- **Default Node Pools**:两个内置节点池(General Purpose 锁定 AMD64 + System 带 taint),权重为零支持自定义池优先级 +- **Core Capabilities**:计算(Carpenter)、网络(AWS LB Controller)、存储(EBS CSI)、安全(Pod Identity Associations) +- **Prefix Delegation**:VPCCNI 特性,为 Pod 分配 /28 前缀 IP 块,默认启用 + +## Mechanism +1. 用户启用 Auto Mode 后,AWS 在集群内部署 Carpenter Controller(作为 core capability) +2. Carpenter 监听控制面版本变更,自动识别新版本对应的 AMI +3. 控制面升级完成后,Carpenter 自动触发节点 AMI 滚动升级 +4. 12% 实例费用溢价覆盖自动化管理成本 + +## Trade-offs +- **优点**:大幅降低 K8s 运维负担;自动化 OS 安全补丁;版本升级自动化 +- **缺点**:每个 Auto Mode 实例附加 12% 管理溢价;节点配置灵活性受限;不支持裸金属实例 + +## Related Concepts +- [[Carpenter Controller]]:EKS Auto Mode 的计算控制器实现 +- [[Bottlerocket OS]]:Auto Mode 的默认操作系统 +- [[Pod Identity Associations]]:Auto Mode 的 Pod 级 IAM 权限控制机制 +- [[Kubernetes]]:EKS Auto Mode 基于的标准容器编排平台 diff --git a/wiki/concepts/Infrastructure-as-Code.md b/wiki/concepts/Infrastructure-as-Code.md index e61950ec..5e40bd27 100644 --- a/wiki/concepts/Infrastructure-as-Code.md +++ b/wiki/concepts/Infrastructure-as-Code.md @@ -1,51 +1,37 @@ -# Infrastructure as Code (IaC) +--- +title: "Infrastructure as Code" +type: concept +tags: [DevOps, 自动化, 配置管理] +sources: [ctp-topic-70-eks-deployment-using-iac, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, ctp-topic-16-cross-account-terraform-modules, ctp-topic-12-using-ses-smtp-service-terraform-module, learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform] +last_updated: 2026-04-24 +--- -## Definition -Infrastructure as Code is the practice of managing and provisioning infrastructure through machine-readable configuration files rather than manual processes. +# Infrastructure as Code -## Key Principles -- **Version Control**: All infrastructure configurations are stored in version control -- **Idempotency**: Running the same configuration produces the same result -- **Automation**: Infrastructure provisioning is automated and repeatable -- **Documentation**: Code serves as documentation +## Overview +Infrastructure as Code (IaC) 是一种通过代码定义和管理基础设施的方法,实现基础设施的标准化、可审计和可重复部署。 -## Tools -- **Terraform**: Multi-cloud IaC tool using HCL -- **Ansible**: Configuration management and orchestration -- **CloudFormation**: AWS-native infrastructure provisioning -- **CloudFormation StackSets**: AWS-native cross-account/cross-region deployment extension for CloudFormation -- **Pulumi**: IaC using general-purpose programming languages -- **Terragrunt**: Wrapper for Terraform providing organization +## Core Principles +- **声明式配置**:定义期望的状态,而非执行的具体步骤 +- **版本控制**:所有基础设施配置纳入 Git 版本控制 +- **自动化部署**:通过 CI/CD 流水线自动化执行部署 +- **幂等性**:重复执行相同配置不产生副作用 -## Best Practices -1. Use modules for reusable components -2. Separate state management (remote state with locking) -3. Implement proper access controls -4. Use workspaces for environment separation -5. Enable drift detection -6. Implement automated testing for IaC +## Key Tools +- **Terraform**:HashiCorp 的基础设施编排工具,支持多云 +- **AWS CloudFormation**:AWS 原生的 IaC 服务 +- **AWS Service Catalog**:AWS 的服务目录,封装标准化产品组合 +- **Pulumi**:使用编程语言(Python, TypeScript 等)定义基础设施 -## IaC Across DevOps Maturity Levels - -| Maturity | IaC Maturity | -|----------|-------------| -| Phase 1 | Manual infrastructure management, servers managed individually, error-prone and slow | -| Phase 2 | Version control used for environments and configurations, but provisioning still manual | -| Phase 3 | Most infrastructure automated, provisioning repeatable and reliable | -| Phase 4 | Immutable infrastructure — old servers replaced rather than updated, managed through CI/CD pipelines | -| Phase 5 | Full automation, zero human intervention, infrastructure changes flow through automated pipelines | - -## Sources -- [[sources/cloud-devop-maturity-guideline.md]] -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] +## Key Concepts +- **HCL (HashiCorp Configuration Language)**:Terraform 的配置语言 +- **State Management**:Terraform 使用 state 文件追踪资源 +- **Modules**:可重用的基础设施组件 +- **Remote State**:远程状态存储,支持团队协作 ## Related Concepts -- [[concepts/DevOps-Maturity]] -- [[concepts/CI-CD-Pipeline]] -- [[concepts/GitOps]] -- [[concepts/Scalability]] -- [[concepts/Cloud-Native]] - -## Ingested -- Date: 2026-04-21 -- Date: 2026-04-24 (updated with maturity level progression) +- [[Terraform]]:最流行的 IaC 工具之一 +- [[AWS Service Catalog]]:AWS IaC 产品目录 +- [[GitOps]]:基于 Git 的运维方法论 +- [[CI/CD Pipeline]]:自动化部署流水线 +- [[DevOps Culture]]:IaC 是 DevOps 实践的核心组成 diff --git a/wiki/concepts/Kubernetes.md b/wiki/concepts/Kubernetes.md new file mode 100644 index 00000000..2ef2fca0 --- /dev/null +++ b/wiki/concepts/Kubernetes.md @@ -0,0 +1,43 @@ +--- +title: "Kubernetes" +type: concept +tags: [容器编排, 云原生, 分布式系统] +sources: [ctp-topic-70-eks-deployment-using-iac] +last_updated: 2026-04-24 +--- + +# Kubernetes + +## Overview +Kubernetes(K8s)是 Google 开源的容器编排平台,用于分布式系统的弹性运行。提供自动化部署、扩缩容、负载均衡、滚动更新和回滚等核心能力。 + +## Key Features +- **自动化部署与回滚**:根据声明式配置自动管理应用版本 +- **服务发现与负载均衡**:内置 DNS 和负载均衡机制 +- **自愈能力**:自动重启失败的容器,替换不健康的节点 +- **水平扩缩容**:根据 CPU/内存指标自动调整 Pod 数量 +- **存储编排**:支持多种存储后端(AWS EBS, NFS, Ceph 等) +- **密钥与配置管理**:管理敏感信息和配置,无需重建镜像 + +## Architecture +- **Control Plane**:主节点,包含 API Server、Scheduler、Controller Manager、etcd +- **Worker Nodes**:工作节点,运行 Pod,包含 kubelet、kube-proxy、Container Runtime + +## Key Concepts +- **Pod**:最小部署单元,一个 Pod 可包含一个或多个容器 +- **Deployment**:声明式更新,管理 Pod 副本数和滚动更新策略 +- **Service**:稳定的网络访问入口,通过标签选择器路由流量 +- **Ingress**:管理 HTTP/HTTPS 路由,实现七层负载均衡 +- **ConfigMap/Secret**:存储配置和敏感数据 +- **Namespace**:资源隔离和访问控制 + +## Related Concepts +- [[Amazon EKS]]:AWS 托管的 Kubernetes 服务 +- [[Cluster Autoscaler]]:Kubernetes 自动扩缩容组件 +- [[Infrastructure as Code]]:用于声明式管理 Kubernetes 资源 +- [[Cloud-Native]]:云原生应用的核心理念 +- [[Container(容器)]]:Pod 的基础运行时 + +## Related Entities +- [[Google]]:Kubernetes 的创始公司(2015 年捐给 CNCF) +- [[CNCF]]:托管 Kubernetes 项目的开源基金会 diff --git a/wiki/concepts/Management-Pack.md b/wiki/concepts/Management-Pack.md new file mode 100644 index 00000000..6c1e3c11 --- /dev/null +++ b/wiki/concepts/Management-Pack.md @@ -0,0 +1,37 @@ +--- +title: Management Pack +type: concept +tags: [Micro-Focus, OBM, Monitoring, Policy, AWS] +date: 2026-04-14 +--- + +## Definition +Management Pack(管理包)是 Micro Focus Operations Bridge Manager (OBM) 等企业监控平台的策略包机制,通过声明式配置定义监控目标、数据采集间隔、具体指标、阈值规则和数据源,实现云环境下规模化的统一监控策略管理。 + +## Core Properties +- **声明式配置**:以 Policy 形式定义监控规则,而非手动逐个配置 +- **自动化发现**:新增资源自动匹配 Policy,无需人工干预 +- **阈值驱动**:Policy 内置阈值配置,指标超出阈值自动触发事件 +- **跨平台抽象**:同一 Management Pack 框架可适配 AWS/Azure/GCP 等多云平台 +- **动态生效**:Policy 变更后自动推送到 Agent,无需重启服务 + +## How It Works (OBM AWS Management Pack) +1. **Policy 定义**:在 OBM 控制台创建 AWS Management Pack Policy,配置项包括: + - Role ARN(跨账户 IAM 角色) + - Account ID(被监控账户) + - Namespace/Service(监控的 AWS 服务,如 EC2/RDS/Lambda) + - Metrics(具体指标列表) + - Thresholds(阈值规则) + - Monitoring Frequency(采集频率) + - Title Format(告警标题格式,供服务台团队使用) +2. **Agent 执行**:Operation Agent 接收 Policy 后,按配置调用 CloudWatch API 采集数据 +3. **事件触发**:数据与阈值比对,超出阈值则生成事件并通过 SMACKS 触发工单 +4. **自动部署**:被监控账户新增实例时,Agent 自动识别并纳入监控范围 + +## Related Concepts +- [[Cloud-Monitoring]]:Management Pack 是云监控策略化管理的核心工具 +- [[IAM-Role]]:Management Pack 通过 IAM Role 实现跨账户安全访问 +- [[Cloud-Monitoring]]:Management Pack 解决了云环境动态监控的核心挑战 + +## References +- [[ctp-topic-8-obm-cloud-monitoring]]:AWS Management Pack 完整实操流程 diff --git a/wiki/entities/Kubernetes.md b/wiki/entities/Kubernetes.md index 3a742454..b20f7690 100644 --- a/wiki/entities/Kubernetes.md +++ b/wiki/entities/Kubernetes.md @@ -110,3 +110,4 @@ Agentic AI 在原生能力基础上提供**更高级的自我修复**: ## Related Sources - [[how-agentic-ai-can-help-for-cloud-devops]] +- [[ctp-topic-70-eks-deployment-using-iac]] diff --git a/wiki/entities/SMACKS.md b/wiki/entities/SMACKS.md index ec7eae28..fd29b2a2 100644 --- a/wiki/entities/SMACKS.md +++ b/wiki/entities/SMACKS.md @@ -1,7 +1,9 @@ --- title: "SMACKS" type: entity -sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] +sources: + - ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs + - ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid last_updated: 2026-04-14 --- diff --git a/wiki/index.md b/wiki/index.md index ad18aa74..800fcdbf 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,7 +4,13 @@ - [Overview](overview.md) — living synthesis ## Sources -- [2026-04-14] [CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge Manager](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) — OBM AWS 监控架构,IAM Role 跨账户 CloudWatch 采集,无需被监控账户安装代理 +- [2026-04-24] [CTP Topic 29 Cloud Monitoring – SaaS LZ accounts](sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md) +- [2026-04-24] [CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone](sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md) +- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 1 of 3 - Compute Optimization with Karpenter](sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md) +- [2026-04-24] [CTP Topic 70 EKS deployment using IAC](sources/ctp-topic-70-eks-deployment-using-iac.md) +- [2026-04-24] [CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana](sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md) +- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 3 of 3 - Introduction to EKS Auto Mode](sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md) +- [2026-04-24] [CTP Topic 8 - Implementation of Cloud Monitoring using Micro Focus Operations Bridge Manager](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) - [2026-04-23] [CTP Topic 11 AD Integration and Login using AD Accounts](sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md) - [2026-04-23] [CTP Topic 5 - AWS Identity and Access Management (IAM)](sources/ctp-topic-5-aws-identity-and-access-management-iam.md) - [2026-04-23] [Learning Sessions Identity Governance VSM Replacement - 20231128](sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md) @@ -408,13 +414,6 @@ - [2026-04-19] [public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113](sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md) — (expected: wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md — source missing) - [2026-04-19] [ctp-topic-54-esm-saas-log-analytics](sources/ctp-topic-54-esm-saas-log-analytics.md) — (expected: wiki/sources/ctp-topic-54-esm-saas-log-analytics.md — source missing) - [2026-04-19] [ctp-topic-59-achieving-reliability-with-amazon-eks](sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md) — (expected: wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md — source missing) -- [2026-04-19] [ctp-topic-29-cloud-monitoring-saas-lz-accounts](sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md) — (expected: wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md — source missing) -- [2026-04-19] [ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone](sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md) — (expected: wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md — source missing) -- [2026-04-19] [public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization](sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md) — (expected: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md — source missing) -- [2026-04-19] [ctp-topic-70-eks-deployment-using-iac](sources/ctp-topic-70-eks-deployment-using-iac.md) — (expected: wiki/sources/ctp-topic-70-eks-deployment-using-iac.md — source missing) -- [2026-04-19] [ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana](sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md) — (expected: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md — source missing) -- [2026-04-19] [public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks](sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md) — (expected: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md — source missing) -- [2026-04-19] [ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) — (expected: wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md — source missing) - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing) - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing) - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing) @@ -780,6 +779,7 @@ - [AI文生视频](concepts/AI文生视频.md) - [AI簡報工作流](concepts/AI簡報工作流.md) - [Alerting](concepts/Alerting.md) +- [Amazon-EKS](concepts/Amazon-EKS.md) - [AmbientMessageMonitoring](concepts/AmbientMessageMonitoring.md) - [Analogy-as-Straitjacket](concepts/Analogy-as-Straitjacket.md) - [APT-仓库配置](concepts/APT-仓库配置.md) @@ -829,12 +829,14 @@ - [Cloud-Governance](concepts/Cloud-Governance.md) - [Cloud-Maturity-Levels](concepts/Cloud-Maturity-Levels.md) - [cloud-migration](concepts/cloud-migration.md) +- [Cloud-Monitoring](concepts/Cloud-Monitoring.md) - [Cloud-Native](concepts/Cloud-Native.md) - [Cloud-Native-Maturity-Model](concepts/Cloud-Native-Maturity-Model.md) - [Cloud-Operating-Model](concepts/Cloud-Operating-Model.md) - [cloud-security](concepts/cloud-security.md) - [Cloud-Security-Maturity-Model](concepts/Cloud-Security-Maturity-Model.md) - [Cloud-Service-Delivery](concepts/Cloud-Service-Delivery.md) +- [Cluster-Autoscaler](concepts/Cluster-Autoscaler.md) - [CMDB](concepts/CMDB.md) - [CodeWeaver](concepts/CodeWeaver.md) - [Columnar-Storage](concepts/Columnar-Storage.md) @@ -893,6 +895,7 @@ - [Earnings-Calendar](concepts/Earnings-Calendar.md) - [efibootmgr](concepts/efibootmgr.md) - [EFS-vs-EBS](concepts/EFS-vs-EBS.md) +- [EKS-Auto-Mode](concepts/EKS-Auto-Mode.md) - [Email-Triage](concepts/Email-Triage.md) - [Emergency-Change](concepts/Emergency-Change.md) - [Enterprise-Architecture](concepts/Enterprise-Architecture.md) @@ -963,6 +966,7 @@ - [Kill-Switch](concepts/Kill-Switch.md) - [Knock-out-Pattern](concepts/Knock-out-Pattern.md) - [Knowledge-Base-RAG](concepts/Knowledge-Base-RAG.md) +- [Kubernetes](concepts/Kubernetes.md) - [Landing-Zone-Architecture](concepts/Landing-Zone-Architecture.md) - [LangChain](concepts/LangChain.md) - [Language-Detection](concepts/Language-Detection.md) @@ -980,6 +984,7 @@ - [Local-LLM-Deployment](concepts/Local-LLM-Deployment.md) - [Lockable-Workflow](concepts/Lockable-Workflow.md) - [Log-Driven-Debugging](concepts/Log-Driven-Debugging.md) +- [Management-Pack](concepts/Management-Pack.md) - [MCPOnceAllAgents](concepts/MCPOnceAllAgents.md) - [MeetingNotes](concepts/MeetingNotes.md) - [Memory-Backend](concepts/Memory-Backend.md) diff --git a/wiki/log.md b/wiki/log.md index 34a9ee30..3e6477dd 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,62 @@ +## [2026-04-26] ingest | CTP Topic 29 Cloud Monitoring – SaaS LZ accounts +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md +- Status: ✅ 成功摄入 +- Summary: AWS 云监控解决方案 OpsBridge Cloud Monitoring 覆盖多账户多区域的云原生监控架构——容器化部署于 EKS,支持 20+ AWS 数据服务,数据存储于 Optic Data Lake(Vertica);通过 IAM Role 信任关系实现只读跨账户 CloudWatch 数据采集,无需在被监控账户安装服务器或共享 Access Key;基于标签的监控是最佳实践,自动化识别缺失标签;单一 OpsBridge 实例监控多账户多区域,降低运维成本;与 OpsBridge 产品研发团队协作,报表功能在下一版本持续增强。 +- Concepts identified: [[Cloud Monitoring(AWS)]], [[Tag-Based Monitoring]], [[Vertica]], [[OpsBridge]], [[ITOM(IT Operations Management)]](均以 wikilink 形式记录于 Source page;仅出现 1 次,暂无独立页面) +- Entities identified: [[Micro Focus OpsBridge]], [[AWS CloudWatch]], [[AWS Landing Zone]](均以 wikilink 形式记录于 Source page;仅出现 1 次,暂无独立页面) +- Source page: wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md +- Notes: + - 新增 1 个 Source Page(wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md) + - index.md 更新:新增 CTP Topic 29 条目于 Sources 节顶部 + - Contradictions 记录:与 ctp-topic-8(OBM 监控)存在视角差异——Topic 8 描述基础 OBM 组件栈(三层架构),Topic 29 描述 Cloud Monitoring 新模块(容器化+EKS+20+数据服务),当前观点认为两者是同一方案的不同层面 + +## [2026-04-24] ingest | CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Status: ✅ 成功摄入 +- Summary: 使用 Grafana Enterprise 实现 AWS 超大规模可观测性监控——Vinay 主讲(代替休假的 Sashi)。核心内容:Grafana 与多数据源集成、事件追踪、告警配置、实例监控和资源标签化;Optic DR 作为 VaticaDB 插件是导入 Grafana 仪表板的关键数据源;*Opsbridge 监控解决方案使用仪表板展示触发事件;Grafana 告警系统支持多通知渠道,可转发至 Opsbridge 创建工单;Terraform 模块自动化创建 Grafana 组织、用户、文件夹、IAM 角色和仪表板;默认指标不产生额外成本,自定义指标可能产生费用。未来路线图:SSO 认证、报表、URL 监控、进程监控、日志监控、与 PagerDuty/Slack Manager 集成。 +- Concepts identified: [[Hyperscale Observability]], [[Dashboard as Code]], [[Grafana Alert System]], [[Resource Tagging]], [[Instance Monitoring]], [[Event Tracking]](均以 wikilink 形式记录于 Source page) +- Entities identified: [[Vinay]], [[Optic DR]], [[Opsbridge]], [[VaticaDB]], [[Grafana]], [[Terraform]](均以 wikilink 形式记录于 Source page) +- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Notes: + - 新增 1 个 Source Page(wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md) + - index.md 更新:新增 CTP Topic 60 条目于 Sources 节顶部 + - Contradictions 记录:与 ctp-topic-8(OBM 监控)的互补而非冲突关系已记录 + +## [2026-04-26] ingest | CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge Manager +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md +- Status: ✅ 成功摄入 +- Summary: 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用 + Postgres RDS + Operation Agent 三层组件;Agent 通过 AWS Management Pack 利用 IAM Role 跨账户采集 CloudWatch 指标,无需在被监控账户安装服务器或共享 Access Key;Global OBM 作为 Manager of Managers 汇聚 Regional OBM 数据,事件通过 SMACKS 触发工单;新增实例自动发现与策略自动下发,解决云环境动态性监控难题;支持任意公有云(AWS/Azure/GCP)的 CloudWatch 兼容服务。 +- Concepts identified: [[Cloud-Monitoring]], [[Management-Pack]](均已创建独立 Concept 页面) +- Entities identified: [[SMACKS]](已有页面,更新 sources;其余实体仅出现 1 次,以 wikilink 形式记录于 Source page) +- Source page: wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md +- Notes: + - 新增 1 个 Source Page(wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) + - 新增 2 个 Concept Page(wiki/concepts/Cloud-Monitoring.md, wiki/concepts/Management-Pack.md) + +## [2026-04-24] ingest | CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md +- Status: ✅ 成功摄入 +- Summary: EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题:Micro Focus 网络的 AWS Lab 环境 IP 地址池不足,无法满足 Octane(IP 密集型 SaaS 应用)的 EKS Pod 需求。解决方案:创建独立私有子网(非主 VPC 子网)为 EKS Pod 提供充足 IP 池;EKS 模块自定义网络标志控制 Pod IP 分配;Terraform/Terragrunt 模块封装完整 EKS 部署逻辑,支持跨账户角色映射;Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源。Atlantis 当前不支持 EKS 部署,需通过 Jenkins + Terragrunt 模块替代。 +- Concepts identified: [[Amazon EKS]], [[Kubernetes Custom Networking]], [[Terraform-Terragrunt Module]], [[IAM Role Mapping (EKS)]], [[Host Network Mode (Pod)]], [[Container Hardening]](均以 wikilink 形式记录于 Source page;均仅出现 1 次,暂无独立页面) +- Entities identified: [[Octane-Hub]](已有页面,更新 sources)、[[Terragrunt]], [[Atlantis]](工具名,均仅出现 1 次,以 wikilink 形式记录于 Source page) +- Source page: wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md +- Notes: + - 新增 1 个 Source Page(wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md) + - index.md 更新:新增 CTP Topic 39 条目于 Sources 节顶部 + - overview.md 更新:新增 CTP Topic 39 条目于 EKS 知识链路 + - 无需新建 Concept/Entity 独立页面(所有概念和实体仅出现 1 次) + +## [2026-04-26] ingest | Public Cloud Learning Sessions EKS Optimization Part 3 of 3 Introduction to EKS Auto Mode +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-.md +- Status: ✅ 成功摄入 +- Summary: EKS Auto Mode 将 Kubernetes 数据平面管理责任从用户扩展至 AWS。Carpenter Controller 负责节点生命周期和滚动升级;Bottlerocket OS 提供最小化安全容器操作系统,自动应用安全补丁;AWS Load Balancer Controller(eks.aws/alb)管理 ingress;EBS CSI Controller 支持有状态工作负载;Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制;Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池(General Purpose AMD64 + System taint),支持自定义 Graviton 节点池。每个 Auto Mode 实例附加 12% 管理溢价。 +- Concepts created: [[EKS Auto Mode]](已创建独立 Concept 页面) +- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md +- Notes: + - 新增 1 个 Source Page(wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md) + - 新增 1 个 Concept Page(wiki/concepts/EKS-Auto-Mode.md) + - Entities:AWS 和 Amazon EKS 已在 overview.md 中存在,无需新建 Entity 页面 + ## [2026-04-25] ingest | CTP Topic 11 AD Integration and Login using AD Accounts - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md - Status: ✅ 成功摄入 @@ -2090,3 +2149,31 @@ - index.md 更新:移除 "source missing" 标记,添加正式条目;在 Entities 和 Concepts 节添加新页面 - overview.md 新增条目,位于 CTP Topic 17(AD 集成)之后 - 冲突检测:无已知冲突内容 + +## [2026-04-25] ingest | CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Status: ✅ 成功摄入 +- Summary: 使用 Grafana Enterprise + Optic DR 数据源 + Opsbridge 告警 + Terraform IaC 模块实现 AWS 超大规模可观测性监控——推荐迁移至 Enterprise License 释放完整功能;Optic DR(VaticaDB 插件)是 Grafana 从 AWS 拉取数据的关键中间件;Terraform 模块为产品团队自动化创建 Grafana Organizations、用户、文件夹和仪表盘;EC2 Inventory 仪表盘可识别运行/未运行 EC2 实例及标签合规状态。 +- Concepts identified: [[Grafana-Enterprise]], [[Observability(可观测性)]], [[Opsbridge]], [[Optic-DR]], [[Terraform-Module]], [[Resource-Tagging]] +- Entities identified: [[Grafana-Labs]], [[VaticaDB]], [[PagerDuty]], [[Slack-Manager]](均以 wikilink 形式记录于 Source page,无需独立页面) +- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md +- Notes: + - 新增 1 个 Source Page(wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md) + - 无新增 Concept/Entity 页面(已识别概念均作为 wikilink 嵌入 Source page) + - index.md 更新:在 Sources 节顶部添加新条目 + - 冲突检测:与 ctp-topic-42-grafana-observability-dashboard 存在潜在张力(开源版 vs Enterprise License) + +## [2026-04-25] ingest | CTP Topic 70 EKS deployment using IAC +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac.md +- Status: ✅ 成功摄入 +- Summary: EKS 集群通过 IaC(Terraform + Service Catalog)部署的完整方法论——两种部署路径(Terraform `tera-grant.scl` vs Service Catalog 模块)、EMI 自定义网络解决 VPC CIDR 限制、Cluster Autoscaler 自动扩缩容 Worker Node、CloudWatch Agent + FluentBit + Container Insights + OpenTelemetry + Grafana 完整监控栈。 +- Concepts created: [[Amazon EKS]], [[Cluster Autoscaler]], [[Infrastructure as Code]], [[Kubernetes]](已有 entity,新增 source 引用) +- Entities updated: [[Kubernetes]](添加 source 引用) +- Source page: wiki/sources/ctp-topic-70-eks-deployment-using-iac.md +- Notes: + - 新增 1 个 Source Page(wiki/sources/ctp-topic-70-eks-deployment-using-iac.md) + - 新增 3 个 Concept 页面:Amazon EKS、Cluster Autoscaler、Infrastructure as Code + - Kubernetes entity 页面已存在,更新添加新 source 引用 + - index.md 更新:在 Sources 节顶部添加新条目;在 Concepts 节添加 3 个新条目;移除 "source missing" 标记 + - overview.md 更新:添加新条目,位于 EKS Auto Mode 条目之后 + - 冲突检测:与 ctp-topic-59-achieving-reliability-with-amazon-eks 可能存在内容重叠(侧重点不同:Topic 70 侧重部署方法,Topic 59 侧重可靠性实践) diff --git a/wiki/overview.md b/wiki/overview.md index f1de736b..d61b7aad 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -41,6 +41,14 @@ Key concepts: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Refer ### Cloud Transformation & DevOps Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps. +**[[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]]**(Public Cloud Learning Sessions,EKS 计算优化专题 Part 1):Karpenter 深度解析与 Cluster Autoscaler 对比——Karpenter 直接与 EC2 Fleet API 通信降低延迟,原生集成 Kubernetes 调度约束(node selectors/affinity/taints/tolerations/topology spread),内置 Spot 中断处理(EventBridge + SQS)和 AMI 滚动升级,Eliminate 节点组管理痛点;Consolidation 策略自动整合低利用率节点,支持中断预算控制和峰值时段豁免。Part 3 将介绍 EKS Auto Mode 进一步简化数据平面管理(内置 Karpenter Controller)。属 [[Karpenter]] 在 AWS EKS 的核心实践,与 [[ctp-topic-70-eks-deployment-using-iac]](EKS IaC 部署)共同构成 EKS 完整知识链路。 + +**[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]**(Public Cloud Learning Sessions,EKS Auto Mode 专题):AWS EKS Auto Mode 深度解析——将数据平面管理责任从用户扩展至 AWS,覆盖计算节点(Carpenter Controller)、存储(EBS CSI Controller)、网络(AWS LB Controller)和安全(Pod Identity Associations)。Bottlerocket OS 提供最小化安全容器操作系统,自动应用安全补丁;Carpenter Controller 监听控制面版本变更,自动触发节点 AMI 滚动升级;Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制,无需修改 ServiceAccount;Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池(General Purpose 锁定 AMD64,System 带 taint),支持自定义节点池指定 Graviton。Auto Mode 兼容所有 Kubernetes-compliant 工作负载,实例附加 12% 管理溢价。属 EKS 运维简化的核心实践,与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]](EKS 可靠性)、[[ctp-topic-64-scaling-out-with-amazon-eks]](EKS 扩缩容)共同构成 EKS 完整知识链路。 + +**[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]**(CTP Topic 39):EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题:Micro Focus 网络的 AWS Lab 环境 IP 地址池不足,无法满足 Octane(IP 密集型 SaaS 应用)的 EKS Pod 需求。解决方案:创建独立私有子网(非主 VPC 子网),由 EKS 模块自定义网络标志控制 Pod IP 分配;Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源;Terraform/Terragrunt 模块封装完整 EKS 部署逻辑,支持跨账户角色映射。Atlantis 当前不支持 EKS 部署,需通过 Jenkins + Terragrunt 模块替代。属 [[Amazon EKS]] 在受限网络场景下的技术实践,与 [[ctp-topic-70-eks-deployment-using-iac]](IaC 部署)共同构成 EKS 完整知识链路。 + +**[[ctp-topic-70-eks-deployment-using-iac]]**(CTP Topic 70):EKS 集群通过 IaC 部署的完整方法论——涵盖容器与 VM 的对比(启动速度/内存效率/可移植性)、EKS 核心特性(完全托管控制平面/零停机滚动更新/IAM RBAC 最小权限)。SRE EKS 模块支持两种部署路径:Terraform(`tera-grant.scl` 定义集群参数+Secret Manager 集成)和 Service Catalog(模块化产品组合+版本选择)。自定义网络通过 EMI(ENI Multi-IP)为 Pod 分配额外 IP 地址解决 VPC CIDR 限制;Cluster Autoscaler 实现 Worker Node 自动扩缩容。监控栈:CloudWatch Agent + FluentBit(DaemonSet)+ Container Insights + AWS OpenTelemetry + Grafana。属 [[Amazon EKS]] 部署方法的完整入口,与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]](可靠性)、[[ctp-topic-64-scaling-out-with-amazon-eks]](扩缩容)、[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]](Auto Mode)共同构成 EKS 完整知识链路。 + **[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]**(CTP Topic 4):云转型计划中敏捷实践的落地经验——Heather Norris 主讲。核心内容:①框架演进——从 Scrum(两周 Sprint,含 Product Backlog/Sprint Planning/Retrospectives/Reviews/Daily Scrum)因"Sprint 期间不允许变更"的问题而转向 Kanban 持续流动模式;②混合方案——以 Kanban 为主(随时可调整优先级、持续交付),同时保留 Scrum 的固定仪式(每日站会和回顾会议);③Microsoft Planner 看板——五列布局(Backlog/To Do/In Progress/Program Key Decisions/Icebox),每张卡必须指定单一负责人、链接依赖、设置优先级和截止日期;④核心价值观——"Agile is all about getting that rapid feedback to make the product and make the development culture better"。属 [[Agile Ceremonies]] 和 [[Scrum]] vs [[Kanban]] 在企业级云迁移场景下的实战案例,与 [[ctp-topic-57-product-backlog-managing-demand]](需求管理)和 [[ctp-topic-30-managing-change]](变更管理)共同构成 CTP 项目管理知识体系。 **[[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]**(Public Cloud Learning Sessions 20240109):业务分析(Business Analysis)基础技能与三大核心技法——T型技能模型、BOSCARD框架、干系人轮盘(Stakeholder Wheel)、结合元数据的用户故事需求收集。业务分析将业务需求与技术变更解决方案对齐,涵盖IT系统变更、流程变更、培训和角色转换。BOSCARD(Background/Objectives/Scope/Constraints/Assumptions/Risks/Roles/Deliverables)通过澄清背景、目标、范围等8个维度定义复杂新工作,"早期锁定范围无价"。干系人轮盘从客户出发顺时针识别所有项目干系人。INVEST原则(Independent/Negotiable/Valuable/Estimable/Small/Testable)用于检查需求质量。属 [[Product-Backlog]] 和 [[Demand-Management]] 的前置技法层,与 [[ctp-topic-4]](敏捷实践)和 [[ctp-topic-57]](需求管理)共同构成云转型计划的完整方法论(规划→需求→执行)。 @@ -51,6 +59,8 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]**(CTP Topic 31):AWS Landing Zone 网络隔离与安全远程访问方案——解决 On-prem 系统和 VPN 用户因共享网络配置而可直接访问生产工作负载的安全风险。核心方案:①网络隔离通过 Checkpoint 防火墙启用 SPI 特性(default-deny),阻断内部网络对 AWS 网段的直接连通;②安全访问通过 AWS Systems Manager (SSM) 替代 VPN,用户假设 IAM 角色访问目标 EC2 实例上的 SSM Agent,支持浏览器会话和 AWS CLI 两种模式,提供双因素认证和 AWS 网络内安全连接。定位为 SD-WAN 实施前的过渡方案;长期演进目标为 IaC 化以消除控制台访问,break-glass 访问仅保留用于紧急场景。与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]](广域网架构)互补——后者关注如何打通网络,Topic 31 关注如何限制网络访问;两者共同构成 Landing Zone 网络知识体系。属 [[AWS-Landing-Zone]] 网络安全层的核心实践。 +**[[ctp-topic-8-obm-cloud-monitoring]]**(CTP Topic 8):使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用、Postgres RDS 和 Operation Agent 三层组件;Agent 通过 AWS Management Pack 利用 IAM Role 信任关系跨账户采集 CloudWatch 指标,无需在被监控账户安装服务器或共享 Access Key;Global OBM 作为 Manager of Managers 汇聚多区域 Regional OBM 数据,事件通过 SMACKS 触发工单;新增实例自动发现、策略自动下发,解决云环境动态性监控难题;支持任意公有云(AWS/Azure/GCP)的 CloudWatch 兼容服务。与 [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]](账户架构)互补构成完整监控体系,属 [[AWS-Landing-Zone]] 监控层的核心实践。 + **[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**(CTP Topic 35):AWS Landing Zone 设计复习——重点明确 SaaS(生产)与 Labs(开发)的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境,产品账户连接至共享服务账户(安全、日志、网络);核心账户组包含 AD、DNS 和 Network 账户;Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更:网络分段阻断对 SaaS 工作负载的直接连通性;CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计;入站流量拟通过 Network 账户 Checkpoint 重新路由;原生 AWS Backup 有望强制化;新账户可能取消 Management VPC。核心结论:**SaaS = 生产,Labs = 开发**;PoC Landing Zone 将并入 Labs 以最大化资源共享;Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。 **[[ctp-topic-6-aws-workspaces-demo]]**(CTP Topic 6):AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面(Windows Server 2016),预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号,接收注册码和用户名后登录,可立即访问 AWS Console(Federation)和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行,达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践,与 [[ctp-topic-1-gruntwork-landing-zone-architecture]](基础架构)和 [[ctp-topic-9-ci-cd-with-gruntwork]](CI/CD 流程)共同构成完整的"架构→交付→使用"链路。 diff --git a/wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md b/wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md new file mode 100644 index 00000000..6fdeed1c --- /dev/null +++ b/wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md @@ -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 组件栈,两者描述的是同一方案的不同层面 diff --git a/wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md b/wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md new file mode 100644 index 00000000..d9218928 --- /dev/null +++ b/wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md @@ -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 页面的直接冲突 diff --git a/wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md b/wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md new file mode 100644 index 00000000..d6a0bf56 --- /dev/null +++ b/wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md @@ -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) 的跨云统一监控 diff --git a/wiki/sources/ctp-topic-70-eks-deployment-using-iac.md b/wiki/sources/ctp-topic-70-eks-deployment-using-iac.md new file mode 100644 index 00000000..7dd9f8f9 --- /dev/null +++ b/wiki/sources/ctp-topic-70-eks-deployment-using-iac.md @@ -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 可靠性保证和最佳实践 diff --git a/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md b/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md new file mode 100644 index 00000000..b133980b --- /dev/null +++ b/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md @@ -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 的收益。可并存作为迁移路径参考。 diff --git a/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md b/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md new file mode 100644 index 00000000..70125cd3 --- /dev/null +++ b/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md @@ -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 +- 暂无已知冲突内容