Auto-sync: update nexus workspace

wiki/concepts/ALB-Ingress-Controller.md

@@ -0,0 +1,29 @@
+---
+title: "ALB Ingress Controller"
+type: concept
+tags: [AWS, Kubernetes, EKS, networking, ingress, load-balancing]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+AWS Load Balancer Controller（原名 ALB Ingress Controller）是运行在 Kubernetes 集群中的控制器，通过 Kubernetes Ingress 资源动态管理 AWS Application Load Balancer（ALB）的生命周期。它将 Ingress 规则转换为 ALB 配置（目标组、监听规则、路径路由），实现外部流量到集群内 Pod 的自动路由，是 EKS 集群入口流量管理的标准方案。
+
+## Key Mechanisms
+
+- **Ingress 驱动**：用户定义 Kubernetes Ingress 资源声明路由规则，控制器自动创建/更新对应 ALB
+- **多层路由**：支持基于主机名（host-based）和路径（path-based）的路由规则
+- **AWS WAF 集成**：ALB 可关联 AWS WAF Web ACL，实现 L7 安全防护
+- **健康检查自动化**：自动配置目标组健康检查指向 Pod 健康端点
+- **多种 Ingress 类**：支持公开（internet-facing）和私有（internal）ALB
+
+## Relationship with Kubernetes Ingress
+
+AWS Load Balancer Controller 扩展了 Kubernetes Ingress API 的 AWS 后端实现：
+- 标准 Kubernetes Ingress 定义路由规则
+- 控制器解释规则并调用 AWS API 创建/配置 ALB
+- 替代手动 ALB 管理，实现声明式基础设施
+
+## Sources
+- [[ctp-topic-70-eks-deployment-using-iac]]
+- [[ctp-topic-59-achieving-reliability-with-amazon-eks]]

wiki/concepts/API-Server-Priority-and-Fairness.md

@@ -0,0 +1,38 @@
+---
+title: "API Server Priority and Fairness"
+type: concept
+tags:
+  - Kubernetes
+  - EKS
+  - API-Server
+  - Performance
+  - Multi-Tenancy
+sources:
+  - ctp-topic-64-scaling-out-with-amazon-eks
+last_updated: 2026-04-28
+---
+
+## Definition
+API Server Priority and Fairness（PPF）是 Kubernetes 1.20+ 引入的 API Server 配置特性，通过优先级类别（Priority Class）和并发限制（Flow Schema）管理 API 请求的调度和限流，确保关键工作负载在高负载下的 API 访问稳定性。
+
+## Key Mechanisms
+- **Priority Class**：为 API 请求分配优先级（整数越大优先级越高）
+- **Flow Schema**：定义请求匹配规则，将请求路由到对应的 Flow
+- **Concurrency Limit**：每个 Flow 的并发请求数限制
+- **Request Limiting**：超出限制的请求进入等待队列或被拒绝
+
+## Why Enable PPF
+- 多租户 EKS 集群中，防止单个租户/工作负载耗尽 API Server 资源
+- 在扩缩容期间（大量 HPA/Controller 并发请求）保护关键 API 调用
+- 提升 API Server 在高负载下的可预测性和稳定性
+
+## Configuration
+- 通过 kube-apiserver 启动参数 `--enable-priority-and-fairness=true` 启用
+- Flow Schema 和 Priority Level 通过 kube-apiserver 配置或 admission webhook 管理
+
+## Relationship with Scaling
+- 在大规模集群扩缩容时，HPA、Cluster Autoscaler、Custom Controller 等大量并发 API 请求可能压垮 API Server
+- PPF 确保关键扩缩容操作的 API 请求优先处理
+
+## Sources
+- [[ctp-topic-64-scaling-out-with-amazon-eks]]

wiki/concepts/AWS-Service-Catalog.md

@@ -0,0 +1,29 @@
+---
+title: "AWS Service Catalog"
+type: concept
+tags: [AWS, IaC, self-service, governance, EKS]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+AWS Service Catalog 是 AWS 托管的服务，允许组织创建和管理已批准在 AWS 上使用的产品（Products）目录。这些产品本质上是 CloudFormation 模板或 Terraform 模块的受控版本，通过 Portfolio（产品组合）组织，并可授予特定用户或团队访问权限。Service Catalog 为终端用户提供自助服务界面，无需深入了解底层 IaC 模板即可部署标准化的基础设施，同时保证安全与合规。
+
+## Key Mechanisms
+
+- **产品（Products）**：预定义的 CloudFormation 模板或 Terraform 模块，代表标准化的基础设施配置
+- **产品组合（Portfolio）**：产品的逻辑分组，可关联到团队或项目
+- **访问控制**：通过 IAM 角色向终端用户授予产品访问权限，实现最小权限原则
+- **版本管理**：支持同一产品的多版本管理，可逐步升级
+- **EKS 部署集成**：SRE EKS 模块通过 Service Catalog 提供 EKS 集群部署界面，支持版本选择和节点类型配置
+
+## Relationship with IaC
+
+Service Catalog 封装底层 IaC 模板（Terraform/CloudFormation），为非技术用户提供受控的自助服务入口：
+- IaC 模板由平台团队维护（在 Git 仓库中通过 CI/CD 管理）
+- Service Catalog 充当面向终端用户的治理层，控制可部署的产品范围
+- 相比直接 Terraform 部署，Service Catalog 提供更细粒度的权限控制
+
+## Sources
+- [[ctp-topic-70-eks-deployment-using-iac]]
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]]

wiki/concepts/CloudWatch-Agent.md

@@ -0,0 +1,31 @@
+---
+title: "CloudWatch Agent"
+type: concept
+tags: [AWS, monitoring, EKS, logging, metrics, CloudWatch]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+CloudWatch Agent 是 AWS 提供的统一代理程序，用于从 EC2 实例和 EKS 集群收集系统级指标和日志，并将其发布到 Amazon CloudWatch。它支持收集标准系统指标（CPU/内存/磁盘/网络）以及自定义应用指标，是 EKS 监控栈的核心组件之一。
+
+## Key Mechanisms
+
+- **指标收集**：CPU、内存、磁盘、网络等系统级指标，以及自定义应用指标
+- **日志收集**：从文件系统或容器日志收集日志数据
+- **配置灵活性**：通过 SSM Parameter Store 或配置文件管理代理配置
+- **EKS 集成**：在 EKS 中作为 DaemonSet 部署在每个节点上，与 Container Insights 协同工作
+- **Container Insights**：启用后自动发布容器级指标（CPU/内存/磁盘/网络/容器进程）
+
+## Relationship with Other Monitoring Components
+
+CloudWatch Agent 是 EKS 监控数据采集层：
+- CloudWatch Agent → 收集原始指标/日志
+- FluentBit → 处理并转发日志到 CloudWatch Logs 或 OpenSearch
+- Container Insights → 聚合容器指标到 CloudWatch
+- Grafana → 从 CloudWatch/OpenSearch 可视化展示
+
+## Sources
+- [[ctp-topic-70-eks-deployment-using-iac]]
+- [[ctp-topic-42-grafana-observability-dashboard]]
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]

wiki/concepts/Cluster-Autoscaler.md

@@ -1,30 +1,39 @@
----
-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 级别的垂直扩缩容
+---
+title: "Cluster Autoscaler"
+type: concept
+tags:
+  - Kubernetes
+  - EKS
+  - Autoscaling
+  - Node
+  - AWS
+  - ASG
+sources:
+  - ctp-topic-64-scaling-out-with-amazon-eks
+  - ctp-topic-70-eks-deployment-using-iac
+last_updated: 2026-04-28
+---
+
+## Definition
+Cluster Autoscaler 是 Kubernetes 官方的节点（Node）级别扩缩容组件，通过联动 AWS Auto Scaling Group（ASG）或托管节点组（Managed Node Group），根据集群内 Pending Pod 的数量和资源请求自动调整节点数量。
+
+## Key Mechanisms
+- **扩缩容决策依据**：集群内 Pending Pod 的数量（而非直接基于资源利用率）
+- **资源请求感知**：考虑 Pod 的 CPU/内存 requests，不仅仅是当前实际使用量
+- **ASG/节点组联动**：更新 ASG 或托管节点组的期望容量（Desired Capacity）
+- **Auto-discovery 模式**：推荐使用，自动发现和管理 ASG
+- **Mixed Instances Policy**：支持在同一 ASG 中混合使用多种 EC2 实例类型
+- **配置变更**：min/max 配置变更应在 ASG/托管节点组层面操作，而非直接修改 Cluster Autoscaler
+
+## Relationship with Karpenter
+- **Cluster Autoscaler**：基于节点组间接扩缩容，响应相对较慢
+- **Karpenter**：直接与 EC2 API 交互，响应更快速灵活，是 Cluster Autoscaler 的演进方案
+
+## Limitations
+- 依赖预配置的 ASG/节点组，灵活性受限
+- 扩容速度受 ASG 启动新实例的速度限制
+- 无法处理需要特殊实例类型的工作负载
+
+## Sources
+- [[ctp-topic-64-scaling-out-with-amazon-eks]]
+- [[ctp-topic-70-eks-deployment-using-iac]]

wiki/concepts/Container-Insights.md

@@ -0,0 +1,29 @@
+---
+title: "Container Insights"
+type: concept
+tags: [AWS, EKS, monitoring, metrics, CloudWatch, containers]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+Container Insights 是 Amazon CloudWatch 的容器监控功能，专门用于收集、整理和汇总 EKS 和 ECS 集群中容器化工作负载的指标和日志。它通过 CloudWatch Agent（DaemonSet）和 CloudWatch Embedded Metric Format 自动收集容器级指标，使运维团队无需额外配置即可获得集群运行状况的可见性。
+
+## Key Mechanisms
+
+- **自动指标收集**：容器 CPU/内存/网络/磁盘使用率，Pod 级别聚合
+- **日志收集**：容器标准输出日志自动采集至 CloudWatch Logs
+- **预构建仪表板**：提供集群、节点、Pod、服务级别的可视化仪表板
+- **性能告警**：自动发现高负载资源并生成 CloudWatch 告警
+- **Embedded Metric Format**：应用可直接输出结构化指标，无需额外 SDK
+
+## Relationship with CloudWatch Agent
+
+Container Insights 建立在 CloudWatch Agent 之上：
+- CloudWatch Agent（DaemonSet）是数据采集代理
+- Container Insights 是指标组织和聚合逻辑（通过 CloudWatch Agent 配置实现）
+- 用户启用 Container Insights 后，CloudWatch Agent 自动开始发布容器指标
+
+## Sources
+- [[ctp-topic-70-eks-deployment-using-iac]]
+- [[ctp-topic-42-grafana-observability-dashboard]]

wiki/concepts/CoreDNS-Scaling.md

@@ -0,0 +1,35 @@
+---
+title: "CoreDNS Scaling"
+type: concept
+tags:
+  - Kubernetes
+  - EKS
+  - DNS
+  - Scaling
+  - Networking
+sources:
+  - ctp-topic-64-scaling-out-with-amazon-eks
+last_updated: 2026-04-28
+---
+
+## Definition
+CoreDNS Scaling 是 EKS 集群中 CoreDNS（Kubernetes 默认 DNS 服务）的水平扩缩容策略和优化实践，确保在高密度 Pod 环境下 DNS 查询的高可用性和低延迟。
+
+## Problem Statement
+- EKS 集群规模增长时，Pod 间的 DNS 查询量呈指数增长
+- 默认 CoreDNS 配置可能无法应对大规模集群的 DNS 负载
+- DNS 查询延迟直接影响应用启动时间和运行时性能
+
+## Optimization Strategies
+- **HPA 扩缩容**：为 CoreDNS Deployment 配置 HPA，基于 DNS 查询 QPS 或 CPU/内存利用率自动调整副本数
+- **Node Local DNS Cache**：在每个节点部署本地 DNS 缓存（node-local-dns-cache 或 nodelocaldns），减少跨节点 DNS 查询
+- **性能调优**：调整 CoreDNS 的 `cores-per-second` 和 `max-concurrent-queries` 参数
+- **副本数规划**：建议 CoreDNS 副本数不低于集群节点数的 10-20%
+
+## Relationship with Node Local DNS Cache
+- Node Local DNS Cache 通过在每节点运行本地 DNS 缓存 DaemonSet，拦截并缓存 Pod 的 DNS 查询
+- 减少跨节点 DNS 查询流量，降低 DNS 查询延迟
+- 与 CoreDNS HPA 扩缩容配合使用效果最佳
+
+## Sources
+- [[ctp-topic-64-scaling-out-with-amazon-eks]]

wiki/concepts/EKS-Custom-Networking.md

@@ -0,0 +1,56 @@
+---
+title: "EKS Custom Networking"
+type: concept
+tags:
+  - AWS
+  - EKS
+  - Kubernetes
+  - Networking
+  - VPC
+  - IPAM
+sources:
+  - ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone
+last_updated: 2026-04-28
+---
+
+## Overview
+EKS Custom Networking 是 AWS EKS 提供的一项功能，允许用户绕过默认的 VPC CNI（Amazon VPC CNI plugin for Kubernetes）行为，自定义 Pod 的网络 IP 分配策略。这在 IP 地址受限或需要特殊网络配置的环境中尤为重要。
+
+## Definition
+EKS 自定义网络（Custom Networking）通过以下机制实现：
+- 通过 EKS 模块的自定义网络配置标志（flag）启用
+- 支持指定自定义的弹性网络接口（ENI）配置
+- 允许 Pod 使用独立于默认 VPC 子网的 IP 地址池
+
+## Use Case: AWS Lab Landing Zone
+在 AWS Lab Landing Zone 环境中，Micro Focus 网络的 IP 地址池有限，无法满足 EKS 集群中大量 Pod 的 IP 分配需求。通过自定义网络配置：
+1. 在独立私有子网（非主 VPC 子网）创建 EKS 集群
+2. 启用 EKS 模块的自定义网络标志
+3. EKS 使用指定的子网和 IP 范围分配 Pod 地址
+
+## Core Mechanism
+```
+EKS Module (Terraform)
+  └── custom_networking_enabled = true
+       ├── subnet_ids = [custom_subnet_ids]
+       └── additional_eni_config = ...
+```
+
+## Key Benefits
+- **突破 VPC CIDR 限制**：在受限网络环境中仍可部署大规模 Pod
+- **IP 地址灵活性**：使用专用 IP 池，无需消耗 VPC 主网络地址
+- **网络隔离**：独立子网提供额外的网络安全边界
+
+## Limitations
+- 需要 Terraform/Terragrunt 模块支持自定义网络标志
+- Atlantis 当前不支持 EKS 集群部署（需使用 Jenkins + Terragrunt）
+- 容器安全加固需额外考虑网络隔离
+
+## Related Concepts
+- [[Amazon-EKS]]：应用自定义网络技术的容器编排平台
+- [[Host-Network-Mode]]：Pod 规范层面的网络模式配置
+- [[EMI-Elastic-Network-Interface]]：ENI 多 IP 分配（EMI）在 EKS 中的应用
+- [[IPAM]]：IP 地址管理，与自定义网络协同
+
+## Related Sources
+- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]

wiki/concepts/EMI-Elastic-Network-Interface.md

@@ -0,0 +1,29 @@
+---
+title: "EMI (Elastic Network Interface) Multi-IP"
+type: concept
+tags: [AWS, EKS, networking, VPC, CIDR, pod-networking]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+EMI（Elastic Network Interface Multi-IP，弹性网络接口多 IP）是 AWS 提供的网络扩展机制，通过为 Pod 分配额外的弹性网络接口（ENI）及其上的辅助 IP 地址，解决 EKS 集群中 VPC CIDR 地址空间不足的问题。每个 ENI 允许附加多个辅助 IP，每个 IP 可分配给一个 Pod，相比默认的 AWS VPC CNI 插件可大幅增加单个节点可运行的 Pod 数量。
+
+## Key Mechanisms
+
+- **ENI 附加**：为工作节点附加额外 ENI 以增加可用 IP 数量
+- **IP 分配**：每个 ENI 上的辅助 IP 分配给 Pod，实现 Pod 级 IP 直接寻址
+- **CIDR 扩展**：不依赖 VPC 主 CIDR 范围，通过 ENI 附加 IP 绕过 VPC 地址空间限制
+- **安全组绑定**：ENI 及其上的 Pod IP 继承安全组配置
+- **与 AWS VPC CNI 插件的关系**：AWS VPC CNI 是默认插件，EMI 是其增强模式，支持 Prefix Delegation
+
+## Problem Solved
+
+VPC CIDR 限制导致大型 EKS 集群 Pod 数量受限于可用 IP 地址：
+- 标准 AWS VPC CNI 每个 ENI 最多约 10-15 个 IP（受实例类型限制）
+- EMI 通过 ENI 附加更多辅助 IP，显著提升 Pod 密度
+- 特别适用于 IP 密集型工作负载（如微服务架构）
+
+## Sources
+- [[ctp-topic-70-eks-deployment-using-iac]]
+- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]

wiki/concepts/FedRAMP.md

@@ -0,0 +1,35 @@
+---
+title: "FedRAMP"
+type: concept
+tags:
+  - Compliance
+  - Cloud-Security
+  - Government
+  - Certification
+last_updated: 2026-04-14
+---
+
+# FedRAMP (Federal Risk and Authorization Management Program)
+
+## Definition
+美国政府级的云安全认证项目，为云服务和云产品提供统一的安全评估和授权标准。FedRAMP 基于 [[ISO-27001]] 和 NIST SP 800-53 控制框架。
+
+## Purpose
+- 为联邦机构提供标准化的云服务安全评估方法
+- 减少重复安全评估，降低成本
+- 确保云服务提供商达到政府级别的安全标准
+
+## Business Value for OpenText
+- **市场准入**：FedRAMP 认证使 OpenText 能够向联邦政府机构销售云服务
+- **多垂直市场覆盖**：持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场
+- **差异化优势**：证明安全成熟度，增强客户信心
+
+## Relationship to Other Concepts
+- 基于 [[ISO-27001]] 构建
+- 与 [[Global Information Security Policy (GISP)]] 配合，满足政策层面的合规要求
+- 与 [[Third-Party-Penetration-Testing]] 配合，通过第三方验证满足认证要求
+
+## Connections
+- [[ISO-27001]]：框架基础
+- [[Global Information Security Policy (GISP)]]：政策支撑
+- [[OpenText]]：持有该认证的组织

wiki/concepts/FluentBit.md

@@ -0,0 +1,31 @@
+---
+title: "Fluent Bit"
+type: concept
+tags: [AWS, EKS, logging, monitoring, CNCF, Fluentd]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+Fluent Bit（CNFC 开源项目）是轻量级日志处理器和转发器，设计用于边缘和容器环境，作为 DaemonSet 部署在每个 Kubernetes 节点上。它从容器运行时（containerd/Docker）收集标准输出（stdout/stderr）日志，处理后转发到 CloudWatch Logs、OpenSearch、Elasticsearch 等后端存储系统，是 EKS 可观测性架构中日志采集的标准组件。
+
+## Key Mechanisms
+
+- **日志采集**：通过容器运行时接口收集容器标准输出日志
+- **多后端输出**：支持 CloudWatch Logs、OpenSearch、Elasticsearch、Kafka 等多种输出目标
+- **日志处理**：支持过滤（filter）、解析（parser）、路由（router）等处理管道
+- **轻量高效**：相比 Fluentd 更小的资源占用，适合边缘/容器环境
+- **Kubernetes DaemonSet 模式**：每个节点运行一个实例，自动采集所有容器日志
+
+## Relationship with Fluentd and CloudWatch Agent
+
+Fluent Bit 是 Fluentd 的轻量替代（同一项目家族）：
+- Fluentd：功能更全面，适合复杂日志处理场景，资源占用更高
+- Fluent Bit：轻量快速，专为边缘和容器优化
+- CloudWatch Agent：侧重指标收集，Fluent Bit 侧重日志收集
+- 在 EKS 监控栈中：Fluent Bit → CloudWatch Logs/OpenSearch → Grafana/OpenSearch Dashboards
+
+## Sources
+- [[ctp-topic-70-eks-deployment-using-iac]]
+- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]

wiki/concepts/Global-Information-Security-Policy-GISP.md

@@ -0,0 +1,32 @@
+---
+title: "Global Information Security Policy (GISP)"
+type: concept
+tags:
+  - OpenText
+  - Security-Policy
+  - Governance
+last_updated: 2026-04-14
+---
+
+# Global Information Security Policy (GISP)
+
+## Definition
+OpenText 的最高纲领性安全政策，是所有其他安全政策的根基。GISP 由全球信息安全团队（GIS）制定和支持，定期（每季度）接受领导层审查。
+
+## Scope
+- 定义企业"需要做什么"（what），同时为"如何实施"（how）提供灵活性
+- 支持性政策（Supporting Policies）围绕 GISP 构建
+- 鼓励反馈以实现持续改进
+
+## Relationship to Other Concepts
+- 基于 [[ISO-27001]] 姿态框架
+- 与 [[Security-Awareness-Training]] 配合提升全员安全意识
+- 与 [[Third-Party-Penetration-Testing]] 配合验证政策有效性
+
+## Key Quote
+> "Policies define what needs to be done, while providing flexibility for how it is implemented." — GIS Policy Framework
+
+## Connections
+- [[Global Information Security Team (GIS)]]：制定与维护团队
+- [[ISO-27001]]：框架基础
+- [[OpenText]]：所属组织

wiki/concepts/Horizontal-Pod-Autoscaler.md

@@ -0,0 +1,36 @@
+---
+title: "Horizontal Pod Autoscaler (HPA)"
+type: concept
+tags:
+  - Kubernetes
+  - EKS
+  - Autoscaling
+  - Pod
+  - Metrics
+sources:
+  - ctp-topic-59-achieving-reliability-with-amazon-eks
+  - ctp-topic-64-scaling-out-with-amazon-eks
+last_updated: 2026-04-28
+---
+
+## Definition
+Horizontal Pod Autoscaler (HPA) 是 Kubernetes 标准的工作负载水平扩缩容机制，通过监测 Pod 的资源使用指标（CPU、内存或自定义指标）自动调整 Pod 副本数，以满足应用负载需求。
+
+## Key Mechanisms
+- **指标采集**：通过 Metrics Server 获取 CPU/内存利用率指标
+- **副本计算**：基于目标阈值计算所需 Pod 副本数
+- **稳定性配置**：通过 `stabilizationWindowSeconds` 和 `periodSeconds` 防止震荡（flapping）
+- **自定义/外部指标**：支持通过 Custom Metrics API 和 External Metrics API 集成负载均衡器并发连接数、消息中间件队列深度等业务指标
+- **Pod 级而非容器级**：当前 HPA 仅考虑 Pod 整体资源消耗，不支持容器级别的独立扩缩
+
+## Relationship with VPA
+- **HPA**：水平扩展（增加/减少 Pod 副本数）
+- **VPA (Vertical Pod Autoscaler)**：垂直扩展（调整单个 Pod 的资源请求）
+- 两者可互补使用：HPA 应对流量波动，VPA 优化资源分配
+
+## Relationship with KEDA
+- KEDA 可通过 **Publishes Metrics 模式** 为 HPA 供数，实现指标驱动与事件驱动的混合扩缩容
+
+## Sources
+- [[ctp-topic-59-achieving-reliability-with-amazon-eks]]
+- [[ctp-topic-64-scaling-out-with-amazon-eks]]

wiki/concepts/Host-Network-Mode.md

@@ -0,0 +1,50 @@
+---
+title: "Host Network Mode"
+type: concept
+tags:
+  - Kubernetes
+  - Networking
+  - Pod-Networking
+  - AWS
+  - EKS
+sources:
+  - ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone
+last_updated: 2026-04-28
+---
+
+## Overview
+Host Network Mode 是 Kubernetes Pod 规范中的一种网络配置选项（`hostNetwork: true`），使 Pod 共享宿主机的网络命名空间，直接使用宿主机的网络接口和 IP 地址，而不是通过 Kubernetes 的虚拟网络。
+
+## Definition
+在 Pod spec 中设置 `hostNetwork: true` 后，Pod 将：
+- 使用宿主机的网络命名空间
+- 直接获得宿主机网络接口上的 IP 地址
+- 可以绑定宿主机的端口（如 80、443）
+- 可直接访问宿主机所在网络上的资源
+
+## Use Case: EKS Lab Landing Zone
+在 AWS Lab Landing Zone 的 EKS 部署中，Octane 等 IP 密集型应用需要大量可用 IP。通过自定义网络模式，Pod 无需通过 VPC CNI 分配 IP，而是直接使用宿主机网络的 IP 地址，从而绕开 AWS Lab 环境 IP 地址池受限的问题。
+
+```yaml
+spec:
+  hostNetwork: true
+  containers:
+    - name: octane
+      image: octane:latest
+```
+
+## Trade-offs
+| 优点 | 缺点 |
+|------|------|
+| 突破 Pod IP 数量限制 | Pod 之间端口冲突风险 |
+| 直接访问宿主机网络资源 | 安全性降低（Pod 可访问宿主机所有网络） |
+| 简化网络路径 | 违反 Kubernetes 网络隔离原则 |
+| 适合特殊网络需求场景 | 难以在不同环境中移植 |
+
+## Related Concepts
+- [[Amazon-EKS]]：使用 Host Network Mode 的容器编排平台
+- [[IPAM]]：IP 地址管理，与 Host Network Mode 在 IP 分配上形成互补
+- [[Kubernetes-Tagging]]：Pod 标记策略
+
+## Related Sources
+- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]

wiki/concepts/IPv6-in-EKS.md

@@ -0,0 +1,39 @@
+---
+title: "IPv6 in EKS"
+type: concept
+tags:
+  - AWS
+  - EKS
+  - IPv6
+  - Networking
+  - IP-Address-Exhaustion
+sources:
+  - ctp-topic-64-scaling-out-with-amazon-eks
+last_updated: 2026-04-28
+---
+
+## Definition
+IPv6-in-EKS 是 Amazon EKS 集群解决 IP 地址耗尽（IP Exhaustion）问题的网络架构方案，通过部署 IPv6 或双栈（Dual-Stack）VPC，实现大规模容器工作负载的 IP 地址可持续供给。
+
+## Problem Statement
+- 每个 EKS 节点上的 ENI（Elastic Network Interface）附带可分配的 IP 地址数量有限
+- VPC CIDR 块大小固定，Pod 数量增长导致可用 IP 耗尽
+- 自定义网络（Custom Networking）和 Prefix Delegation 可缓解但不能根本解决
+
+## Solution: IPv6 Dual-Stack VPC
+- **双栈架构**：VPC 同时支持 IPv4 和 IPv6 地址
+- **节点双协议栈**：EKS 节点同时持有 IPv4 和 IPv6 地址
+- **Pod 仅 IPv6**：Pod 仅分配 IPv6 地址（节省 IPv4 空间）
+- **NAT 映射**：IPv6 Pod 与 IPv4 目标通信时，通过双层 NAT 映射转换
+
+## Alternative: Carrier-Grade NAT (CGNAT)
+- 如无法迁移至 IPv6，可使用 CGNAT 方案
+- 通过自定义网络 + NAT 网关聚合多个 Pod 的出站流量
+
+## Benefits
+- IP 地址空间近乎无限（解决耗尽问题）
+- 简化网络配置（无需管理大量 IPv4 地址）
+- 符合云原生网络发展趋势
+
+## Sources
+- [[ctp-topic-64-scaling-out-with-amazon-eks]]

wiki/concepts/ISO-27001.md

@@ -0,0 +1,40 @@
+---
+title: "ISO-27001"
+type: concept
+tags:
+  - Security-Framework
+  - Compliance
+  - Information-Security
+last_updated: 2026-04-14
+---
+
+# ISO-27001
+
+## Definition
+国际认可的信息安全管理体系（ISMS）标准，由国际标准化组织（ISO）和国际电工委员会（IEC）发布。ISO 27001 是企业信息安全管理的基准框架。
+
+## OpenText Implementation
+- 作为 OpenText 安全姿态框架（Posture Framework）的基础
+- 2022 年更新，新增 11 个控制方面（control aspects）
+- 支撑 [[Global Information Security Policy (GISP)]] 的框架基础
+- 支撑 [[FedRAMP]] 等行业认证
+
+## Key Controls
+- 信息安全组织（Information Security Organization）
+- 人力资源安全（Human Resource Security）
+- 资产管理（Asset Management）
+- 访问控制（Access Control）
+- 加密（Cryptography）
+- 物理与环境安全（Physical and Environmental Security）
+- 操作安全（Operations Security）
+- 通信安全（Communications Security）
+- 系统获取、开发和维护（System Acquisition, Development and Maintenance）
+- 供应商关系（Supplier Relationships）
+- 信息安全事件管理（Information Security Incident Management）
+- 业务连续性管理（Business Continuity Management）
+- 合规性（Compliance）
+
+## Connections
+- [[Global Information Security Policy (GISP)]]：基于 ISO 27001 构建
+- [[FedRAMP]]：基于 ISO 27001 之上
+- [[OpenText]]：采用该标准的企业

wiki/concepts/KEDA.md

@@ -0,0 +1,36 @@
+---
+title: "KEDA (Kubernetes Event-Driven Autoscaling)"
+type: concept
+tags:
+  - Kubernetes
+  - EKS
+  - Autoscaling
+  - Event-Driven
+  - Serverless
+sources:
+  - ctp-topic-64-scaling-out-with-amazon-eks
+last_updated: 2026-04-28
+---
+
+## Definition
+KEDA（Kubernetes Event-Driven Autoscaling）是一个基于外部事件驱动的 Kubernetes 扩缩容框架，通过 ScaledObject 自定义资源定义（CRD）实现细粒度的事件驱动扩缩容，支持将应用从零副本扩展到任意规模。
+
+## Key Mechanisms
+- **ScaledObject CRD**：定义扩缩规则，指定 Scaler 和目标副本数范围
+- **事件源（Scalers）**：支持 50+ 种事件源（Kafka、RabbitMQ、AWS SQS、Azure Queue、HTTP 等）
+- **零扩展（Scale to Zero）**：支持将应用缩容至零副本，降低空闲资源成本
+- **Publishes Metrics 模式**：可向 HPA 发布指标，实现事件驱动与指标驱动的混合扩缩容
+- **声明式配置**：通过 YAML 配置文件定义扩缩行为，与 GitOps 工作流兼容
+
+## Relationship with HPA
+- KEDA 可独立工作，也可作为 HPA 的指标提供者
+- 组合模式：KEDA 监听外部事件 → 发布指标 → HPA 基于指标调整副本数
+
+## Use Cases
+- 事件驱动微服务（消息队列消费者）
+- 批处理作业（按需触发）
+- 突发流量场景（限时促销、实时事件）
+- 无服务器化改造（零扩展降低成本）
+
+## Sources
+- [[ctp-topic-64-scaling-out-with-amazon-eks]]

wiki/concepts/Karpenter.md

@@ -0,0 +1,30 @@
+---
+title: "Karpenter"
+type: concept
+tags: [AWS, Kubernetes, EKS, autoscaling, node-provisioning]
+last_updated: 2026-04-28
+---
+
+## Definition
+
+Karpenter 是 AWS 开源的 Kubernetes 节点自动配置工具（Node Auto-Provisioner），通过动态创建最优实例类型来响应未调度 Pod 的资源需求，替代传统的 Cluster Autoscaler。相比 Cluster Autoscaler 基于节点组（Node Group）的扩缩容模式，Karpenter 直接与 EC2 API 交互，根据 Pod 规格（CPU/内存/GPU 需求）即时选择最合适的 EC2 实例类型，实现更快的扩容速度和更低的资源浪费。
+
+## Key Mechanisms
+
+- **即时节点供给**：监听未调度 Pod 事件，秒级启动新节点，无需等待节点组预配置
+- **最佳实例选择**：根据 Pod 资源请求从 EC2 实例类型池中选择最优匹配
+- **多样化实例类型**：支持多种 EC2 类型（CPU/GPU/Spot/On-Demand），灵活利用 Spot 实例节省成本
+- **标签驱动配置**：通过 `NodeTemplate` 定义标签/要求，自动匹配特定 Pod 到特定节点
+- **与 Cluster Autoscaler 的区别**：Cluster Autoscaler 依赖节点组规模调整，Karpenter 直接控制 EC2 实例创建，响应更快速灵活
+
+## Relationship with Cluster Autoscaler
+
+Karpenter 是 Cluster Autoscaler 的替代/演进方案：
+- Cluster Autoscaler 通过调整节点组规模间接扩缩节点
+- Karpenter 直接与 EC2 API 交互创建/终止节点，更快速灵活
+- EKS Auto Mode（Part 3 of 3）已集成 Karpenter 作为 Carpenter Controller 组件
+
+## Sources
+- [[ctp-topic-70-eks-deployment-using-iac]]
+- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]]
+- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]

wiki/concepts/Metrics-Server.md

@@ -0,0 +1,40 @@
+---
+title: "Metrics Server"
+type: concept
+tags:
+  - Kubernetes
+  - EKS
+  - Metrics
+  - Monitoring
+  - Autoscaling
+sources:
+  - ctp-topic-64-scaling-out-with-amazon-eks
+last_updated: 2026-04-28
+---
+
+## Definition
+Metrics Server 是 Kubernetes 集群级别的指标采集组件（Metrics API Provider），负责从 kubelet 收集 CPU/内存等资源使用指标，为 HPA、VPA 和 `kubectl top` 命令提供标准化的指标数据。
+
+## Key Mechanisms
+- **Metrics API**：实现 `metrics.k8s.io` API，提供 Pod 和 Node 的资源指标
+- **数据采集**：定期从各节点的 kubelet 获取指标数据
+- **内存高效**：采用流式处理，仅保留最近 5 分钟的指标数据
+- **HPA 依赖**：HPA 的标准资源指标（CPU/内存）完全依赖 Metrics Server
+
+## Deployment
+- 通过 Deployment 部署单个副本（非高可用）
+- 通常随 EKS 集群自动安装（EKS Add-on 或 eks-charts）
+- 监控指标：Pod CPU/内存利用率、Node CPU/内存容量
+
+## Limitations
+- 仅支持标准资源指标（CPU、内存）
+- 不支持自定义/外部指标（需要 Custom Metrics API）
+- 单副本部署，非高可用设计
+
+## Relationship with HPA
+- HPA 通过 Metrics Server 获取 Pod 的 CPU/内存利用率
+- 计算公式：`desiredReplicas = ceil(sum(podMetricValue) / targetValue)`
+- 目标阈值（targetValue）通常设置为 70-80%，保留缓冲空间
+
+## Sources
+- [[ctp-topic-64-scaling-out-with-amazon-eks]]

wiki/concepts/Security Awareness Training.md

@@ -0,0 +1,36 @@
+---
+title: "Security Awareness Training"
+type: concept
+tags:
+  - Security
+  - Human-Factor
+  - Training
+last_updated: 2026-04-14
+---
+
+# Security Awareness Training
+
+## Definition
+通过系统化的培训和演练提升组织内所有成员（从员工到高管）对安全威胁的认知和应对能力。
+
+## Components
+- **月度安全通讯**：定期向全员推送安全信息和最佳实践
+- **网络钓鱼演练**：模拟钓鱼攻击测试员工识别能力
+- **关键指标**：衡量有多少人报告可疑活动（而非仅关注点击率）
+
+## Goals
+- 将安全意识融入组织文化
+- 建立"全员参与"的安全防线
+- 持续改进安全态势
+
+## Key Quote
+> "The focus is on how many people report suspicious activity." — GIS Security Awareness Program
+
+## Relationship to [[Global Information Security Policy (GISP)]]
+- GISP 是政策框架，Security Awareness Training 是执行层的安全意识落地
+- 两者共同构成"政策+人"的安全治理闭环
+
+## Connections
+- [[Global Information Security Policy (GISP)]]：政策基础
+- [[Global Information Security Team (GIS)]]：执行团队
+- [[OpenText]]：实施组织

wiki/concepts/Third Party Penetration Testing.md

@@ -0,0 +1,37 @@
+---
+title: "Third-Party Penetration Testing"
+type: concept
+tags:
+  - Security
+  - Testing
+  - Penetration-Testing
+  - Red-Team
+last_updated: 2026-04-14
+---
+
+# Third-Party Penetration Testing
+
+## Definition
+由独立第三方安全机构执行的渗透测试和红队演练，用于客观评估组织的安全态势，发现内部视角可能忽略的漏洞。
+
+## Components
+- **年度第三方测试**：由独立机构执行年度安全评估
+- **桌面演练（Tabletop Exercises）**：模拟安全事件和违规场景，测试响应流程
+- **红队演练（Red Team Exercises）**：在事先不知情的情况下评估组织安全
+- **高级威胁评估（Advanced Threat Assessments）**
+- **内部/第三方渗透测试**：定期进行，发现技术漏洞
+- **客户审计（Customer Audits）**：有时会引发补救活动
+
+## Key Metrics
+- 桌面演练：测试事件和违规准备就绪程度
+- 红队演练：在无预警情况下测试组织安全
+- OpenText 持续在第三方测试中处于"顶级梯队"
+
+## Key Quote
+> "OpenText conducts annual third-party tests, including tabletop exercises for incident and breach readiness, consistently scoring in the top tier." — GIS Team
+
+## Connections
+- [[ISO-27001]]：框架要求
+- [[Global Information Security Policy (GISP)]]：政策支撑
+- [[Threat-Intelligence]]：结合使用
+- [[OpenText]]：实施组织

wiki/concepts/Threat-Intelligence.md

@@ -0,0 +1,37 @@
+---
+title: "Threat Intelligence"
+type: concept
+tags:
+  - Security
+  - Intelligence
+  - SIEM
+last_updated: 2026-04-14
+---
+
+# Threat Intelligence
+
+## Definition
+通过收集、分析和传播关于现有和新兴威胁的信息，使组织能够主动防御安全威胁。
+
+## Components
+- **威胁情报 feeds**：从多个来源收集威胁数据
+- **工具组件（Tool Components）**：主动监控环境
+- **检测与威胁狩猎（Detection & Threat Hunting）**：主动发现潜在威胁
+- **SIEM（安全信息与事件管理）**：大规模日志处理
+
+## OpenText Scale
+- 大规模 SIM（安全信息管理）实现
+- 月处理 **2250 亿条日志**（225 billion log rugs）
+- 月分诊约 **350 个案例**
+- 利用 [[BrightCloud]] 作为威胁情报 feed 来源
+
+## Relationship to Other Concepts
+- 与 [[Third-Party-Penetration-Testing]] 配合，形成"情报+测试"的主动防御体系
+- 支撑 [[Global Information Security Policy (GISP)]] 的监控和响应要求
+- 与 [[ISO-27001]] 的运营安全（Operations Security）控制相一致
+
+## Connections
+- [[BrightCloud]]：威胁情报工具
+- [[Global Information Security Team (GIS)]]：运营团队
+- [[ISO-27001]]：框架基础
+- [[OpenText]]：实施组织