Sync: add kubernetes observability notes

2026-04-24 11:35:04 +08:00
parent ca96e409be
commit 989ec86c77
23 changed files with 1350 additions and 9 deletions
--- a/wiki/sources/ctp-topic-42-grafana-observability-dashboard.md
+++ b/wiki/sources/ctp-topic-42-grafana-observability-dashboard.md
@@ -0,0 +1,54 @@
+---
+title: "CTP Topic 42 Grafana Observability Dashboard"
+type: source
+tags:
+  - Grafana
+  - Observability
+  - Dashboard
+  - AWS
+  - Terraform
+  - EKS
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-42-grafana-observability-dashboard]]
+
+## Summary（用中文描述）
+- 核心主题：企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与落地实践
+- 问题域：AWS Landing Zone 多产品团队账户的集中监控与可视化需求
+- 方法/机制：Grafana + IAM 跨账户角色 + Terraform IaC 自动化 + Prometheus 网络监控
+- 结论/价值：Grafana 统一替代 Micro Focus 工具实现端到端监控，支持动态仪表盘和告警通知
+
+## Key Claims（用中文描述）
+- Grafana 通过 IAM 角色策略从监控账户访问各产品团队 AWS 账户，实现跨账户统一监控
+- Terraform 模块化封装 Grafana 数据源和组织结构，实现新产品组自动化接入
+- Prometheus 作为 Checkpoint 和防火墙的网络监控数据源，支持 SNMP 协议采集
+- Grafana 用户管理将逐步从数据库模式迁移至 LDAP 或 SSO 统一认证
+
+## Key Quotes
+> "Grafana does not exist differently data source by itself. It needs to be expressed from the data, all kinds of data sources." — Grafana 本身不存储数据，数据必须来自外部数据源
+
+> "We would like to build application specific dashboards which can basically give us key insight with respect to our applications that are running over there." — 未来目标是构建应用级仪表盘，提供关键业务洞察
+
+## Key Concepts
+- [[Observability（可观测性）]]：通过外部输出（Metrics/Logs/Traces）推断系统内部状态的能力
+- [[Grafana]]：开源数据可视化平台，支持多数据源的图表和仪表盘
+- [[Terraform]]：HashiCorp 基础设施即代码工具，用于自动化资源供给
+- [[Prometheus]]：开源时序数据库和监控告警系统，用于网络设备指标采集
+- [[SNMP（Simple Network Management Protocol）]]：网络设备监控协议，用于采集 Checkpoint 防火墙指标
+- [[IAM Role（跨账户角色）]]：AWS IAM 角色机制，实现跨账户资源安全访问
+
+## Key Entities
+- [[AWS CloudWatch]]：AWS 托管监控服务，Grafana 的主要数据源之一
+- [[AWS Landing Zone]]：AWS 多账户架构框架，产品团队账户通过 IAM 角色被监控账户访问
+- [[Micro Focus Operations Bridge Manager]]：将被 Grafana 替代的传统监控工具
+
+## Connections
+- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]] ← extends ← [[ctp-topic-42-grafana-observability-dashboard]]
+- [[ctp-topic-54-esm-saas-log-analytics]] ← related ← [[ctp-topic-42-grafana-observability-dashboard]]
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← related ← [[ctp-topic-42-grafana-observability-dashboard]]
+- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] ← replaced_by ← [[ctp-topic-42-grafana-observability-dashboard]]
+
+## Contradictions
+- 无明显冲突。本视频与 [[ctp-topic-60]] 均介绍 Grafana，视角互补（Grafana 本身 vs Hyperscale 场景），与 [[ctp-topic-67]] 同属可观测性专题，共同构成完整监控知识体系
--- a/wiki/sources/ctp-topic-54-esm-saas-log-analytics.md
+++ b/wiki/sources/ctp-topic-54-esm-saas-log-analytics.md
@@ -0,0 +1,64 @@
+---
+title: "CTP Topic 54 ESM SaaS Log Analytics"
+type: source
+tags:
+  - Log-Analytics
+  - SaaS
+  - ESM
+  - EKS
+  - ELK
+  - OpenSearch
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-54-esm-saas-log-analytics]]
+
+## Summary（用中文描述）
+- 核心主题：企业级日志分析解决方案（ESM SaaS），涵盖 ELK/OpenSearch 技术栈架构、区域部署、安全加固及主流方案对比
+- 问题域：多 VPC 环境下的日志集中采集、传输安全、合规存储（GDPR）及成本控制
+- 方法/机制：BEATS（Filebeat）采集 → Logstash 处理 → Elasticsearch/OpenSearch 存储 → Kibana 可视化；Redis 作为缓冲层防止 Logstash 过载；VPC 间私有流量传输
+- 结论/价值：AWS OpenSearch 性价比最优（~$1,500/月 vs Logz.io ~$4,000/月），推荐起步用 Logz.io 试用，后续迁移 AWS OpenSearch
+
+## Key Claims（用中文描述）
+- ELK 栈（Elasticsearch + Logstash + Kibana）是开源日志分析标准方案，OpenSearch 为 AWS 托管替代
+- 应用通过 BEATS（Filebeat）采集日志，Logstash 解析日志字段后存入 Elasticsearch/OpenSearch
+- 双 VPC 架构：应用 VPC 运行 Filebeat 容器持续推送日志至日志 VPC 的 Logstash
+- Redis 作为可选缓冲层防止 Logstash 过载
+- 出于 GDPR 合规要求，农场按区域分割（美国俄勒冈、欧洲）
+- 供应通过 CloudFormation 或 Terraform 实现，但安全加固和持续优化是主要挑战
+- 静态加密采用加密节点和 NVMe 设备硬件级加密；传输加密使用 TLS 1.2；VPC 间流量走私有网络
+- 基于索引的访问控制和 RBAC 实现不同用户角色隔离
+- 方案对比：Logz.io（托管 ELK，$4,000/月，SLA 99.8%）、AWS OpenSearch（$1,500/月，SLA 99.9%，自动快照 DR）、自托管 ELK（成本低但维护复杂）、Microfocus OBA（商业成熟，支持列级访问控制）
+
+## Key Quotes
+> "The application collects your log, it's called the BEATS." — Jackie，解释 BEATS 组件在日志采集中的核心作用
+> "We have already built up all the farms." — Jackie，表示区域农场已完成部署
+> "Recommendations for starting with Log Analytics include beginning with Logz.io for its trial period, then transitioning to AWS OpenSearch or self-hosted options for more control." — 最佳起步路径建议
+
+## Key Concepts
+- [[ELK Stack]]：Elasticsearch + Logstash + Kibana 开源日志分析技术栈
+- [[OpenSearch]]：Elasticsearch 分支，AWS 托管版本，提供类似 Elasticsearch 的全文搜索和日志分析能力
+- [[Logstash]]：日志采集管道，负责解析和转换日志字段
+- [[Kibana]]：日志可视化前端
+- [[BEATS]]：轻量级日志采集代理家族，其中 Filebeat 常用作容器日志采集器
+- [[Redis]]：可选缓冲层，防止 Logstash 过载
+- [[GDPR]]：欧盟通用数据保护条例，推动日志农场按区域分割部署
+- [[RBAC]]：基于角色的访问控制，用于日志系统的用户权限管理
+- [[TLS 1.2]]：传输层加密标准，确保日志数据在传输过程中的安全性
+
+## Key Entities
+- [[Jackie]]：ITOM ESM SAS 架构师，本视频主讲人
+- [[AWS OpenSearch]]：AWS 托管的 OpenSearch 服务，日志分析推荐方案
+- [[Logz.io]]：托管 ELK SaaS 解决方案
+- [[Micro Focus Operations Bridge]]：企业级 IT 运维监控套件，OBA 为其日志分析组件
+- [[Elasticsearch]]：开源分布式搜索和分析引擎，ELK 栈核心组件
+
+## Connections
+- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] ← related_to ← [[ctp-topic-54-esm-saas-log-analytics]]
+- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]] ← extends ← [[ctp-topic-54-esm-saas-log-analytics]]
+- [[ctp-topic-70-eks-deployment-using-iac]] ← uses ← [[CloudFormation]] (供应工具)
+- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] ← similar_architecture ← (双 VPC 隔离架构)
+
+## Contradictions
+- 暂无发现与现有 Wiki 页面的冲突内容
--- a/wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md
+++ b/wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md
@@ -0,0 +1,67 @@
+---
+title: "CTP Topic 59 Achieving reliability with Amazon EKS"
+type: source
+tags:
+  - AWS
+  - EKS
+  - Kubernetes
+  - Reliability
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md]]
+
+## Summary（用中文描述）
+- 核心主题：Amazon EKS（Elastic Kubernetes Service）的可靠性最佳实践，涵盖容器服务选型、应用层可靠性、控制平面可靠性和数据平面可靠性四个维度。
+- 问题域：Kubernetes 在 AWS 上的生产级可靠性保障，涉及 shared responsibility model 下 AWS 与客户的责任边界划分。
+- 方法/机制：通过 Pod 反亲和性、拓扑分布约束、HPA/VPA 扩缩容、探针配置、PodDisruptionBudget 等机制实现故障检测、优雅降级、自愈和按需扩缩；控制平面通过监控、认证加固、准入 Webhook 管理、集群升级策略保障；数据平面通过节点问题检测、资源预留、QoS、资源配额和 Pod 优先级机制保障。
+- 结论/价值：EKS 可靠性需要在应用、控制平面、数据平面三个层面综合设计，结合 AWS shared responsibility model 明确责任边界，并通过多样性部署策略（Rolling/Blue-Green/Canary）实现安全升级。
+
+## Key Claims（用中文描述）
+- ECS 推荐给容器化初学者，提供简单界面和原生 AWS 集成；EKS 适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。
+- 系统可靠性意味着即使发生故障也能提供可预测行为，核心关注点包括：故障检测、优雅服务降级、确定性故障模式、自愈能力和按需扩缩。
+- AWS shared responsibility model 下，AWS 负责控制平面组件（state store、scheduler、controller manager、API servers），客户负责工作节点、操作系统和应用配置。
+- Fargate 模式下客户无需管理节点、补丁或升级工作。
+- 应用可靠性需避免单例 Pod，使用 Pod 反亲和性或拓扑分布约束将应用 Pod 分散到多个可用区；HPA 默认基于 CPU 和内存扩缩容，VPA 可正确调整 Pod 大小但会导致运行时重启。
+- 部署策略包括滚动升级、蓝绿部署和金丝雀部署，各有不同控制复杂度和安全保障级别；存活探针、就绪探针和启动探针是 Pod 健康监控的关键；PodDisruptionBudget 确保维护期间的最小服务水平。
+- 控制平面可靠性需监控 API server 请求和 HCT state store 大小；必须创建具有超级管理员角色的安全用户；准入 Webhook 需仔细配置以避免阻塞控制平面；EKS 平台版本自动处理补丁版本，Minor 版本有 14 个月支持周期后自动升级。
+- 数据平面可靠性需使用节点问题检测器、预留系统资源、实现 QoS、配置资源配额和限制范围；Pod 优先级控制抢占。
+
+## Key Quotes
+> "ECS is a more AWS opinionated way of running containers." — ECS 与 EKS 的核心区别概述
+> "Reliability in a system means it offers predictable behavior even when failures occur." — 可靠性的本质定义
+> "With Fargate, you don't have to worry about managing the nodes or worrying about patching or upgrading the nodes." — Fargate 对 shared responsibility model 的影响
+
+## Key Concepts
+- [[Reliability（系统可靠性）]]：系统在发生故障时仍能提供可预测行为的能力，包含故障检测、优雅降级、确定性故障模式、自愈和按需扩缩五个核心关注点。
+- [[Application Reliability（应用可靠性）]]：通过避免单例 Pod、AZ 分散、HPA/VPA 扩缩容、部署策略（Rolling/Blue-Green/Canary）、健康探针和 PodDisruptionBudget 实现。
+- [[Control Plane Reliability（控制平面可靠性）]]：通过监控控制平面指标、安全认证加固、准入 Webhook 管理和集群升级策略保障。
+- [[Data Plane Reliability（数据平面可靠性）]]：通过节点问题检测、资源预留、QoS、资源配额、LimitRange 和 Pod 优先级机制保障。
+- [[Shared Responsibility Model（EKS）]]：AWS 负责控制平面（API server、scheduler 等），客户负责工作节点、操作系统和应用配置；Fargate 模式下进一步减少客户运维负担。
+- [[Pod Anti-Affinity]]：通过反亲和性规则将 Pod 分散到不同节点或可用区，避免单点故障。
+- [[Topology Spread Constraints]]：提供比 Pod 反亲和性更细粒度的工作负载分布控制。
+- [[Horizontal Pod Autoscaler (HPA)]]：基于 CPU 利用率和内存消耗的默认扩缩容机制，支持自定义/外部指标。
+- [[Vertical Pod Autoscaler (VPA)]]：根据实际资源使用情况自动调整 Pod 的大小配置，但运行时调整会导致 Pod 重启。
+- [[Liveness/Readiness/Startup Probes]]：三类 Kubernetes 探针，用于监控 Pod 健康状态和就绪情况。
+- [[PodDisruptionBudget]]：在自愿中断（如节点维护）期间保证最小数量或比例的 Pod 持续运行。
+- [[Rolling/Blue-Green/Canary Deployment]]：三种部署策略，滚动升级自动化程度高但回滚控制有限，蓝绿和金丝雀提供更精细的控制和快速回滚能力。
+
+## Key Entities
+- [[Surav Paul]]：AWS 高级解决方案架构师（Senior Solutions Architect），本场演讲的主讲人。
+- [[Amazon EKS]]：AWS 托管的 Kubernetes 服务，适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。
+- [[Amazon ECS]]：AWS 原生容器服务，推荐给容器化初学者，提供简单界面和原生 AWS 集成。
+- [[AWS Fargate]]：无服务器容器运行平台，使用 Fargate 时客户无需管理节点、补丁或升级工作。
+
+## Connections
+- [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]] ← topic_overlap ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（均涉及 EKS 部署实践，本 Topic 聚焦可靠性设计，Topic 39 聚焦网络/IP 问题解决）
+- [[CTP Topic 64 Scaling out with Amazon EKS]] ← topic_overlap ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（均涉及 EKS 扩缩容，Topic 64 聚焦扩缩机制，Topic 59 聚焦可靠性全栈设计）
+- [[CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana]] ← complements ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（Grafana 监控可用于 Topic 59 中的控制平面和数据平面指标监控）
+- [[Public Cloud Learning Sessions EKS Optimization Part 3 of 3 Introduction to EKS Auto Mode]] ← extends ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（Auto Mode 是 EKS 可靠性自动化的进一步演进，涵盖 Fargate 集成和自动扩缩容）
+
+## Contradictions
+- 与 [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]] 的潜在视角差异：
+  - 冲突点：Topic 39 描述 EKS 部署中的 IP 资源挑战，强调自定义网络配置（hostNetwork）和独立私有子网；Topic 59 侧重标准 EKS 可靠性机制，较少涉及网络约束场景。
+  - 当前观点：两者面向不同场景——Topic 39 针对受限网络环境下的实际部署挑战，Topic 59 提供通用的 EKS 可靠性最佳实践，互为补充而非冲突。
+  - 对方观点：Topic 39 认为在某些受限环境下标准 EKS 配置（如 CNI 插件默认 IP 分配）无法直接适用，需要自定义网络方案；Topic 59 的通用建议可能需要针对特殊环境调整。
--- a/wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md
+++ b/wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md
@@ -0,0 +1,64 @@
+---
+title: "CTP Topic 64 Scaling out with Amazon EKS"
+type: source
+tags: [AWS, EKS, Kubernetes, Scaling, HPA, KEDA, Karpenter, Cluster-Autoscaler]
+sources: [ctp-topic-64-scaling-out-with-amazon-eks]
+last_updated: 2026-04-25
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md]]
+
+## Summary（用中文描述）
+- 核心主题：Amazon EKS 工作负载水平扩展与容量扩展的完整方法论，涵盖 Pod 级别扩展（事件驱动 + 指标驱动）和 Node 级别扩展（ASG 联动 + 直接 API）
+- 问题域：传统 HPA 仅支持 CPU/内存指标，无法满足事件驱动型工作负载的零扩展需求；Cluster Autoscaler 依赖预配置 ASG 导致灵活性不足；EKS 集群 IP 地址耗尽问题；CoreDNS 等集群组件扩缩容被忽视
+- 方法/机制：HPA（标准指标扩展）→ KEDA（事件驱动扩展）→ Cluster Autoscaler（ASG 联动扩缩容）→ Karpenter/Carpenter（直接 API 扩缩容）→ IPv6 解决 IP 耗尽 → API Server PPF + CoreDNS 缓存优化集群稳定性
+- 结论/价值：EKS 扩缩容需 Pod 层（KEDA）和 Node 层（Karpenter/Carpenter）双管齐下，HPA 负责 Pod 副本数调节，容量层通过原生云工具或第三方工具解决 IP 耗尽问题，集群组件扩缩容是生产部署常被忽视但至关重要的环节
+
+## Key Claims（用中文描述）
+- HPA 通过拉取 Metrics Server 的 CPU/内存指标计算应用工作负载所需的 Pod 副本数，默认支持标准资源指标，自定义/外部指标（如负载均衡器并发连接数、消息中间件队列深度）可通过 Custom Metrics API 扩展
+- KEDA 通过 ScaledObject CRD 实现事件驱动扩缩容，可将应用从零副本扩展，支持 Publishes Metrics 模式为 HPA 供数，实现指标驱动与事件驱动的混合扩展
+- Cluster Autoscaler 的扩缩容决策基于集群内 Pending Pod 的数量，联动 ASG/托管节点组调整期望容量，同时考虑 Pod 的 CPU/内存 requests，支持 Mixed Instances Policy，推荐使用 Auto-discovery 模式，min/max 配置变更应在 ASG/托管节点组层面操作
+- Karpenter 是 AWS 开源的 Kubernetes 原生容量扩缩器，直接与 EC2 API 通信，支持动态按需供给（无需预配置节点组），通过 Provisioner 定义 EC2 实例需求并与工作负载的 node selector/affinity 匹配，默认禁用回收（需启用 TTL 或集群整合）
+- 为解决 IP 地址耗尽问题，推荐切换至 IPv6（双栈 VPC，节点双协议栈，Pod 仅 IPv6）；若无法切换，可使用 Carrier-Grade NAT（CGNAT）配合自定义网络；IPv6 Pod 与 IPv4 目标的交互通过双层 NAT 映射配置
+- CoreDNS 扩缩容和 Node Local DNS Cache 安装是 EKS 生产部署的重要优化项
+
+## Key Quotes
+> "The horizontal pod autoscaler is going to pull the metrics and it is going to calculate how many replicas are required for your application workload." — HPA 的核心机制：拉取指标 → 计算所需副本数
+>
+> "The scaling decision that is made by the cluster auto scaler, it is done on the number of pending pods in the cluster." — Cluster Autoscaler 的决策依据：Pending Pod 数量
+>
+> "Carpenter has native integration with Kubernetes and it complements the native Kubernetes spot pod scheduling constraints that is available for your workloads." — Karpenter/Carpenter 与原生 K8s Spot Pod Disruption Budget 的互补关系
+>
+> "The EKS best practices guides, specifically the scalability section." — 演讲者推荐的学习资源：EKS Best Practices Guides
+
+## Key Concepts
+- [[Horizontal Pod Autoscaler (HPA)]]：Kubernetes 标准 Pod 水平扩缩容机制，通过 CPU/内存指标或自定义/外部指标计算副本需求，支持 stabilization window 和 period seconds 配置防止震荡
+- [[KEDA]]（Kubernetes Event-Driven Autoscaling）：基于外部事件驱动的 K8s 扩缩容框架，通过 ScaledObject CRD 定义扩缩规则，支持从零副本扩展，可 Publish Metrics 给 HPA 实现混合扩展模式
+- [[Cluster Autoscaler]]：Kubernetes 官方节点扩缩容组件，联动 AWS ASG/托管节点组，根据 Pending Pod 数量和资源 requests 调整 Node 数量，推荐 Auto-discovery 模式
+- [[Karpenter]]：AWS 开源的 Kubernetes 原生容量扩缩器，直接与 EC2 API 通信，通过 Provisioner 匹配工作负载需求，支持动态按需供给，默认禁用回收（需启用 TTL 或 Consolidation）
+- [[IPv6-in-EKS]]：EKS 集群解决 IP 地址耗尽的方案，推荐双栈 VPC 架构（节点双协议栈，Pod 仅 IPv6），IPv6 Pod 与 IPv4 目标通过 NAT 映射通信
+- [[API-Server-Priority-and-Fairness]]：EKS API Server 的优先级和公平性配置，用于在高负载下保护关键工作负载的 API 访问
+- [[CoreDNS-Scaling]]：EKS 集群 CoreDNS 的水平扩缩容策略，配合 Node Local DNS Cache 降低 DNS 查询延迟
+- [[Metrics-Server]]：Kubernetes 的 CPU/内存指标采集组件，HPA 依赖其提供标准资源指标
+
+## Key Entities
+- [[Suravpul]]：AWS 高级解决方案架构师（Senior Solutions Architect），CTP Topic 64 和 Topic 59、Topic 67 的讲师，专注 EKS 可靠性、可观测性和扩缩容实践
+- [[Amazon EKS]]：托管 Kubernetes 服务，本 Source Page 的目标平台
+- [[AWS]]：Amazon Web Services，EKS 及相关扩缩容工具（KEDA、Karpenter）的云服务提供商
+- [[Kubernetes]]：开源容器编排平台，HPA、Cluster Autoscaler、KEDA 的上游项目
+
+## Connections
+- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← 相关 ← [[Horizontal Pod Autoscaler (HPA)]]（Topic 59 涵盖 HPA 和 VPA 在 EKS 可靠性中的作用）
+- [[ctp-topic-70-eks-deployment-using-iac]] ← 相关 ← [[Cluster Autoscaler]]（Topic 70 提及 Cluster Autoscaler 实现 Worker Node 自动扩缩容）
+- [[ctp-topic-70-eks-deployment-using-iac]] ← depends_on ← [[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容是 IaC 部署后的运维关注点）
+- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]] ← 关联 ← [[Karpenter]]（Part 1 深度对比 Karpenter 与 Cluster Autoscaler）
+- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← 关联 ← [[Karpenter]]（Part 3 介绍 EKS Auto Mode，内置 Karpenter Controller）
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← 相关 ← [[Suravpul]]（同一讲师的可观测性专题）
+
+## Contradictions
+- 与 [[ctp-topic-70-eks-deployment-using-iac]] 无实质冲突：
+  - 冲突点：无
+  - 当前观点：Topic 64 提供扩缩容的完整方法论（HPA/KEDA/Carpenter + IPv6 解决 IP 耗尽）
+  - 对方观点：Topic 70 仅简述 Cluster Autoscaler 实现 Worker Node 自动扩缩容，侧重 IaC 部署流程
+  - 注：两者互补而非冲突，Topic 70 是部署入口，Topic 64 是扩缩容深化
--- a/wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md
+++ b/wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md
@@ -0,0 +1,73 @@
+---
+title: "CTP Topic 67 Cloud native observability using OpenTelemetry"
+type: source
+tags:
+  - OpenTelemetry
+  - Observability
+  - Cloud-Native
+  - CTP
+  - AWS
+  - EKS
+  - ECS
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-67-cloud-native-observability-using-opentelemetry]]
+
+## Summary（用中文描述）
+- 核心主题：AWS EKS/ECS 环境下的云原生可观测性实践，以 AWS Distro for OpenTelemetry (ADOT) 为核心工具实现统一监控。
+- 问题域：云原生环境下系统复杂度激增，如何通过标准化的可观测性方案实现主动式故障排查与性能优化。
+- 方法/机制：OpenTelemetry 提供厂商无关的代码插桩库和 Collector 组件（Receivers → Processors → Exporters），ADOT 在此基础上增加 AWS 专用组件和 SIGV4 认证扩展；三种观测信号（Traces/Metrics/Logs）贯穿应用层与基础设施层，通过 Correlation ID 实现跨信号关联。
+- 结论/价值：ADOT 是 AWS EKS/ECS 生产级可观测性的推荐方案，支持 Sidecar/独立任务/DaemonSet/HA Replicas 等多种部署模式，可对接 CloudWatch/X-Ray/Prometheus/Grafana 等多种后端。
+
+## Key Claims（用中文描述）
+- 可观测性是管理云原生系统复杂度的必要手段——通过收集 Traces/Metrics/Logs 三种信号，实现反应式和主动式故障排查。
+- 构建可观测的应用是开发者的责任——开发者需要主动在代码中植入观测能力，而非依赖运维事后补救。
+- OpenTelemetry Collector 的核心架构由 Receivers（采集信号）、Processors（转换处理）和 Exporters（导出目的地）三部分组成，实现厂商无关的信号管道。
+- ADOT 在标准 OTEL Collector 基础上封装了 AWS 专用组件，包含 SIGV4 Auth Extension 实现对 AWS 服务的无缝集成。
+- Trace 捕获应用调用栈中各层的处理耗时，是性能瓶颈定位的核心手段。
+- 从应用层和基础设施层同时采集 Metrics 可获得完整的应用视图，包括业务级指标和 X-Ray 服务图。
+- Correlation ID（如 X-Ray Trace ID）使日志事件可深度链接至 Trace 视图，实现端到端的故障追踪。
+- ADOT 支持多种 EKS/ECS 部署模式，EKS Add-on 方式通过 Operator 和 Terraform 模块简化部署并提供预置 Grafana 仪表盘。
+
+## Key Quotes
+> "Observability is essential for managing complexity as systems evolve." — Surav, AWS
+
+> "Building observable applications is a developer responsibility." — Surav, AWS
+
+> "A trace captures the processing time taken at individual layers in your application call stack." — Surav, AWS
+
+## Key Concepts
+- [[OpenTelemetry]]：厂商无关的可观测性框架，提供跨语言的 SDK 和 Collector 组件
+- [[Observability（可观测性）]]：通过外部输出推断内部状态的能力，核心三信号为 Traces/Metrics/Logs
+- [[AWS Distro for OpenTelemetry (ADOT)]]：AWS 维护的 OpenTelemetry 生产级发行版，含 AWS 专用组件
+- [[Three Signals]]：Traces（调用链追踪）、Metrics（指标）、Logs（日志）
+- [[OTLP（OpenTelemetry Protocol）]]：OpenTelemetry 的标准传输协议
+- [[Fluent Bit]]：容器日志采集器，常与 OTEL Collector 配合使用
+- [[X-Ray]]：AWS 原生分布式追踪服务
+- [[Prometheus]]：开源时序数据库和监控告警系统
+- [[Grafana]]：开源可视化平台，常与 Prometheus/X-Ray 配合构建仪表盘
+- [[SIGV4 Auth Extension]]：OTEL Collector 的 AWS 认证扩展，用于访问 AWS 托管服务
+
+## Key Entities
+- [[Amazon EKS]]：AWS 托管 Kubernetes 服务，ADOT 的主要部署目标
+- [[Amazon ECS]]：AWS 容器编排服务，支持 ADOT Sidecar 和独立任务两种部署模式
+- [[AWS Distro for OpenTelemetry (ADOT)]]：AWS 官方的 OpenTelemetry 发行版
+- [[CloudWatch]]：AWS 原生监控服务，可作为 ADOT 的 Exporter 目标
+- [[Surav (AWS)]]：AWS 解决方案架构师，CTP Topic 67 讲师
+
+## Connections
+- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] ← same_topic ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
+  - 两篇均为 OpenTelemetry 主题，前者为 Jay Comer 主讲的 Learning Sessions 概述，后者为 Surav 主讲的 CTP Topic 深度实践
+- [[ctp-topic-42-grafana-observability-dashboard]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
+  - Grafana 是 ADOT 推荐的可视化后端
+- [[ctp-topic-54-esm-saas-log-analytics]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
+  - ESM SaaS 日志分析方案与 OTEL 日志采集互补，共同构成企业级可观测性视图
+- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
+  - EKS 可靠性实践需要可观测性支撑，监控是 SRE 可靠性的核心组成
+- [[ctp-topic-70-eks-deployment-using-iac]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
+  - EKS IaC 部署后需配置 ADOT Add-on 完成监控栈落地
+
+## Contradictions
+- 无已知冲突内容。
--- a/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md
+++ b/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md
@@ -0,0 +1,56 @@
+---
+title: "Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS"
+type: source
+tags:
+  - AWS
+  - EKS
+  - Bottlerocket
+  - Container OS
+  - Cloud-Native
+date: 2026-04-24
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]]
+
+## Summary（用中文描述）
+- 核心主题：Bottlerocket OS（火箭瓶）—— AWS 专为容器工作负载优化的最小化 Linux 发行版，用于 EKS 环境运行容器
+- 问题域：传统通用操作系统运行容器时存在体积臃肿、安全攻击面大、更新机制不可控等问题
+- 方法/机制：通过 Variant 机制实现最小化构建 + 分区镜像更新（Partition Updates）实现安全更新 + dm-verity 根文件系统验证 + SE Linux 强制模式
+- 结论/价值：Bottlerocket 将容器宿主 OS 的攻击面降至最低，提供生产级安全保证，是 EKS Auto Mode 的默认节点操作系统
+
+## Key Claims（用中文描述）
+- Bottlerocket 通过去除所有非必要组件（无包管理器、无默认 Shell、无默认 SSH），将容器宿主 OS 体积和攻击面降至最低
+- Bottlerocket 的 Variant 机制（平台+架构+工作负载组件组合）在构建时固定所需功能，支持 GPU/Metal 等特定工作负载定制，避免通用 OS 的臃肿
+- Bottlerocket 通过分区镜像更新（A/B 分区切换）在不停机前提下确保系统一致性，data volume 缓存容器镜像并支持快照预填充
+- Bottlerocket 的 dm-verity 对根文件系统进行加密验证，根文件系统默认只读，任何篡改均被检测
+- Bottlerocket 集成 EKS 的三种模式：自管理节点组（Self-Managed Node Groups）、托管节点组（Managed Node Groups）、Carpenter 节点池（Carpenter Node Pools）
+- Bottlerocket 提供专用 CIS benchmark 加固指南，实现企业级安全基线
+
+## Key Quotes
+> "A variant is basically a combination of platform, supported platform, the processor architecture and the necessary binary components that are supported by the processor architecture and any additional packages and drivers that are required for your specific workloads."
+> — Bottlerocket Variant 机制定义
+
+> "The root file system is by default immutable, you cannot change anything there."
+> — Bottlerocket 根文件系统不可变性说明
+
+## Key Concepts
+- [[Immutable-Root-Filesystem]]：根文件系统默认只读，任何运行时变更均被拒绝，必须通过镜像更新机制修改
+- [[dm-verity]]：内核级块设备完整性验证，通过加密哈希树检测根文件系统任何未授权变更
+- [[SE-Linux-Enforcing]]：SE Linux 默认启用 enforcing 模式，基于标签的强制访问控制（MAC）
+- [[Partition-Updates]]：A/B 双分区机制，在线下载新版本镜像到非活动分区，重启后切换，确保更新原子性
+- [[CIS-Benchmark]]：Bottlerocket 提供专用 CIS benchmark 安全加固指南
+
+## Key Entities
+- [[Bottlerocket]]：AWS 主导维护的容器专用开源 Linux OS，采用最小化设计，Bottlerocket 可运行于笔记本、工作站和数据中心
+- [[Amazon EKS]]：Bottlerocket 通过 eksctl、Carpenter 等工具集成，支持自管理节点组、托管节点组和 Carpenter 节点池三种部署模式
+- [[AWS]]：Bottlerocket 的核心维护者和赞助方，AWS 在 GitHub 上主导项目开发
+
+## Connections
+- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]] ← related_to ← [[Bottlerocket]]（EKS 优化系列 Part 1 - Karpenter 计算优化，Part 2 - Bottlerocket OS 节点运行时，Part 3 - EKS Auto Mode）
+- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← extends ← [[Bottlerocket]]（EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统）
+- [[Bottlerocket]] ← security_enforcement ← [[Immutable-Root-Filesystem]] + [[dm-verity]] + [[SE-Linux-Enforcing]]
+
+## Contradictions
+- 与 [[ctp-topic-70-eks-deployment-using-iac]]（EKS IaC 部署）不存在直接冲突，两者互补：Topic 70 聚焦 EKS 集群的 IaC 部署方法，本文聚焦容器运行时节点的操作系统选型，共同构成完整的 EKS 部署链路
+- 与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（EKS 可靠性）不存在冲突：Bottlerocket 的分区更新和只读根文件系统是实现 EKS 数据平面可靠性的关键机制之一
--- a/wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md
+++ b/wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md
@@ -0,0 +1,61 @@
+---
+title: "Public Cloud Learning Sessions - Observability with OpenTelemetry - 20240402"
+type: source
+tags:
+  - OpenTelemetry
+  - Observability
+  - AWS
+  - EKS
+date: 2024-04-02
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS OpenTelemetry 可观测性解决方案全景介绍，包括 OpenTelemetry 核心概念、AWS 发行版功能及 EKS 环境下的完整演示
+- 问题域：微服务架构下 observability 的挑战（系统复杂度增加、外部输出难以推断内部状态、Gartner 估计年均 87 小时停机时间、每小时 $42,000 成本）
+- 方法/机制：三信号可观测性模型（Metrics/Logs/Traces）、OpenTelemetry 统一 SDK（11 种语言支持）、OTLP 标准化协议、AWS Distribution for OpenTelemetry 自动注入、OpenTelemetry Collector 组件（Receivers/Processors/Exporters/Extensions）、Fluent Bit 日志采集 → OpenTelemetry → Amazon OpenSearch 端到端管道
+- 结论/价值：OpenTelemetry 提供 vendor-agnostic 的统一可观测性方案，AWS 发行版简化 EKS 环境部署，最新发布强化了安全合规、规模化、用户体验和日志支持
+
+## Key Claims（用中文描述）
+- 微服务架构导致可观测性挑战更加突出，因为系统复杂度随服务数量增加而指数增长
+- 三信号（Metrics/Logs/Traces）共同构成完整可观测性视图：Metrics 提供聚合统计、Logs 定位根因、Traces 呈现请求全链路
+- OpenTelemetry 通过统一数据格式和跨语言 SDK 解决了不同组件使用不同 SDK 和工具的碎片化问题
+- AWS Distribution for OpenTelemetry 提供统一代理，自动检测应用语言并创建预配置 Collector，实现零侵入式自动注入
+- Fluent Bit 将日志发送到 OpenTelemetry 容器（端口 55681），由 OpenTelemetry Collector 统一处理后导出至 OpenSearch
+- OpenSearch Dashboard 可按 trace group 展示延迟并通过应用组成图定位性能瓶颈
+
+## Key Quotes
+> "Observability is defined as a measure of how well internal states of a system can be inferred from knowledge of its external outputs." — Jay Comer，AWS 演讲开场定义
+> "OpenTelemetry aims to solve the problem of disparate SDKs and tooling for different components within the observability landscape by providing an instrumentation language with different SDKs per language." — OpenTelemetry 核心价值定位
+> "The output that Fluent Bit is sending the individual logs to is the Open Telemetry endpoint on the port 55681." — Demo 中的关键配置细节
+
+## Key Concepts
+- [[OpenTelemetry]]：云原生计算基金会（CNCF）项目，提供跨语言的统一遥测数据采集标准，包含 SDK（11 种语言）、OTLP 协议和 Collector 组件
+- [[Observability（可观测性）]]：通过系统外部输出（logs/metrics/traces）推断内部状态的能力，微服务架构的核心挑战
+- [[Three Signals（三信号）]]：Metrics（聚合统计）、Logs（根因定位）、Traces（全链路追踪），三者共同构成完整可观测性视图
+- [[OTLP（OpenTelemetry Protocol）]]：OpenTelemetry 的标准化数据传输协议，Collector 将数据导出至不同后端
+- [[OpenTelemetry Collector]]：标准化和转换遥测数据的组件，包含 Receivers（接收器）、Processors（处理器）、Exporters（导出器）和 Extensions（扩展）
+- [[AWS Distribution for OpenTelemetry]]：AWS 提供的 OpenTelemetry 统一代理，支持 Traces/Metrics/Logs 自动采集和 EKS Operator 自动注入
+- [[Fluent Bit]]：开源日志处理器和转发器，在 EKS 中采集容器日志并转发至 OpenTelemetry 端点
+
+## Key Entities
+- [[Jay Comer]]：AWS 解决方案架构师，主讲本次 OpenTelemetry 可观测性专题
+- [[Amazon EKS]]：AWS 托管 Kubernetes 服务，演示中运行示例应用的环境
+- [[Amazon OpenSearch Service]]：AWS 托管搜索和分析服务，演示中作为遥测数据后端存储
+- [[Amazon CloudWatch]]：AWS 原生监控服务，属于 AWS 可观测性生态但非本次演示重点
+- [[AWS X-Ray]]：AWS 原生分布式追踪服务，属于 AWS 可观测性生态但非本次演示重点
+- [[Grafana]]：开源可观测性平台，AWS 可观测性生态的重要组成部分
+- [[Prometheus]]：开源指标采集系统，AWS Managed Service Collector for Prometheus 提供无服务器的自动抓取能力
+- [[Fluent Bit]]：CNCF 毕业项目，轻量级日志处理器，用于 EKS 环境容器日志采集
+
+## Connections
+- [[ctp-topic-54-esm-saas-log-analytics]] ← related_to ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
+- [[Amazon EKS]] ← instrumented_by ← [[OpenTelemetry]]
+- [[Fluent Bit]] ← sends_logs_to ← OpenTelemetry Collector (port 55681)
+- [[OpenTelemetry Collector]] ← exports_to ← [[Amazon OpenSearch Service]]
+- [[OpenTelemetry]] ← is_standardized_by ← [[OTLP（OpenTelemetry Protocol）]]
+
+## Contradictions
+- （暂无检测到与其他 Wiki 页面的冲突内容）
--- a/wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md
@@ -0,0 +1,55 @@
+---
+title: "Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015"
+type: source
+tags:
+  - OpenText
+  - Security-Policies
+  - GIS
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 全球信息安全团队（GIS）安全策略全景介绍
+- 问题域：企业级安全治理与合规体系设计
+- 方法/机制：分层层级安全组织架构 + ISO 27001 姿态框架 + 三方渗透测试 + 安全意识培训
+- 结论/价值：政策是基础设施的基石，运营、工具和流程均构建在此框架之上
+
+## Key Claims（用中文描述）
+- OpenText 采用分层方法定义安全策略——与各团队协作定义"做什么"，与执行团队协作确定"怎么做"
+- OpenText 持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场销售
+- OpenText 每年进行第三方测试（桌面演练+红队演练），持续处于顶级梯队
+- 月处理 2250 亿条日志，每月分诊约 350 个案例
+- Global Information Security Policy（GISP）是最高纲领性政策，季度审查
+
+## Key Quotes
+> "Policies are foundational elements, with operations, tools, and processes built on that framework." — Mike & Ed, GIS Team
+
+> "The focus is on how many people report suspicious activity." — GIS Security Awareness Program
+
+> "Policies define what needs to be done, while providing flexibility for how it is implemented." — GIS Policy Framework
+
+## Key Concepts
+- [[Global Information Security Policy (GISP)]]：最高纲领性政策，季度审查
+- [[ISO-27001]]：姿态框架基础，2022 年更新，新增 11 个控制方面
+- [[Security-Awareness-Training]]：月度安全通讯 + 网络钓鱼演练
+- [[Third-Party-Penetration-Testing]]：年度桌面演练 + 红队演练
+- [[Threat-Intelligence]]：结合 BrightCloud 等工具的威胁情报体系
+- [[FedRAMP]]：政府级云安全认证
+
+## Key Entities
+- [[Mike]]：Global Information Security Team，主讲人
+- [[Ed]]：Global Information Security Team，主讲人
+- [[OpenText]]：企业主体，安全策略制定者
+- [[BrightCloud]]：OpenText 自有威胁情报工具
+
+## Connections
+- [[CTP-Topic-21-Supply-Chain-Security-in-Micro-Focus]] ← related_to ← [[GIS-Security-Policies]]（供应链安全同属安全治理范畴）
+- [[CTP-Topic-52-3-Lines-of-Defence]] ← extends ← [[GIS-Security-Policies]]（三道防线框架与 GIS 分层组织高度吻合）
+
+## Contradictions
+- 与 [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Related-Security]] 存在视角互补而非冲突：
+  - 冲突点：两者均涉及安全治理，但 Topic 10 聚焦于 AWS 层面的标签化安全策略（SCP/Checkpoint），Topic 41 聚焦于企业级安全政策框架（ISO 27001/GISP）
+  - 当前观点：两者互补——GISP 定义全局政策纲领，AWS Landing Zone 层面通过标签和 SCP 实现技术落地