集群可观测性

应用可观测性（Metrics / Logs / Traces）在 observability-essentials 已建立三支柱思维；集群可观测性 额外覆盖 控制平面、节点、工作负载调度事件——否则 Pod Pending、节点 NotReady、APIServer 慢时无从查起。本课衔接 traces、observability-engines 与 Prometheus 栈。

学习目标

• 列出 K8s 集群层必看信号：apiserver、etcd、scheduler、kubelet、容器
• 区分 DaemonSet Agent、Sidecar、Operator 三种采集部署模式
• 为 CodeRoadMap 集群画一条「指标 + 日志 + 事件」数据流

观测分层

应用层     Spring Actuator、traceId（见 obs-spring、obs-traces）
平台层     kube-state-metrics、cAdvisor、node_exporter
控制平面   apiserver latency、etcd、scheduler queue（托管部分由云提供）
事件层     kubectl get events、Kubernetes Event exporter

入门部署见 k8s-practice；进阶要 每 Node 有 Agent、每 scrape 目标有 SLO。

指标：与 Prometheus 衔接

组件	典型指标来源
容器 / Pod	cAdvisor、kubelet /metrics
Deployment 期望 vs 实际	kube-state-metrics
节点 CPU/内存/磁盘	node_exporter DaemonSet
业务 RED	Pod annotation + ServiceMonitor CR（prom-scrape）

Prometheus Operator 用 CRD 声明 scrape（k8a-crds）；Helm 安装见 prometheus-essentials 与 helm-install。

日志

• 容器 stdout/stderr 仍是默认；DaemonSet（Fluent Bit / Promtail）采集 → Loki / ES
• 结构化 JSON 与 traceId 字段与 obs-logs 一致
• 审计日志（谁删了 Deployment）在 APIServer 审计策略，合规场景单独存储

链路（Traces）

服务网格 Sidecar 或 OTel SDK 上报；K8s 本身 不 替代 APM——需在 Deployment 注入 OTEL_EXPORTER_OTLP_ENDPOINT 或 mesh 配置。跨 Pod 调用链见 obs-traces；Ingress 入口 span 与 k8s-ingress 配合。

Kubernetes Events

kubectl get events -n backend --sort-by='.lastTimestamp'

Event 适合解释 SchedulingFailed、FailedMount、Unhealthy；长期留存需 Event exporter 进监控系统，避免 etcd 仅短期保存 Event 的局限。

可观测「引擎」选型（概念）

模式	特点
自管 Prometheus + Grafana	灵活，运维成本自担
云托管 AMP / GMP / Azure Monitor	与托管 K8s 集成（k8a-managed）
Observability 一体化 SaaS	Agent 少，账单按 ingest

CodeRoadMap 小团队路径：kube-prometheus-stack Helm chart + 应用 ServiceMonitor，Dashboard 从 obs-dashboards RED 模板起步。

练习

• 画集群指标流：Pod → kubelet → Prometheus → Grafana
• 列三条「只有集群监控才能发现」的故障（非应用日志能单独发现）
• 写 ServiceMonitor 应 select 哪两个 label 字段（概念）

小结

应用三支柱 + 集群 kube-state/node 指标，排障才闭环。 下一课聚焦资源使用监控与成本优化。