K8s AIOps 技术栈

你需要的是一套结构化、可落地、分阶段的 K8s AIOps 技术栈清单，我会按「数据层→分析层→工程层→场景层」梳理，覆盖从入门到高阶的全链路，每个层级都标注核心组件、算法和落地要点，方便你直接对标落地。

---

K8s AIOps 技术栈（全维度落地清单）

核心框架

K8s AIOps = 数据采集 + 异常检测 + 根因分析 + 自动化处置
整体技术栈按「基础必备→进阶AI→工程落地」分层，适配中小集群到大厂级集群的不同需求。

层级	核心目标	技术组件/算法	落地优先级
数据层	采集全维度可观测数据	Prometheus/Loki/ELK、kube-state-metrics、EventRouter、K8s Python Client	最高
基础分析层	解决80%高频故障	规则引擎、3σ/IQR、滑动窗口、Jaccard相似度、决策树	高
进阶AI层	解决复杂/偶发故障	孤立森林（PyOD）、Prophet/ARIMA、ADTK、DBSCAN、XGBoost、MIC	中
高阶智能层	精准根因+智能决策	PC算法/LiNGAM（因果）、知识图谱（Neo4j）、大模型（LLaMA/通义千问）、PageRank	低（大厂）
工程落地层	自动化+可视化+闭环	Flink/Spark、Grafana、Argo Workflows、AlertManager、WebHook	高

---

一、数据层（AIOps的“燃料”，必须优先落地）

1. 核心采集组件

数据类型	核心组件	采集内容
指标数据	Prometheus + 核心Exporter	kube-state-metrics（K8s资源指标）、node-exporter（节点指标）、cAdvisor（容器指标）、kubelet/APIServer指标
日志数据	Loki + FluentBit（轻量）/ELK（全量）	Pod日志、容器运行时日志（containerd/crio）、节点系统日志、CNI网络日志
事件数据	KubeEvents + EventRouter	Pod/Node/Deployment的事件（Evict、OOM、FailedScheduling、CrashLoopBackOff）
拓扑数据	K8s API + Neo4j（可选）	Pod→Node、Pod→Deployment、Service→Pod、Ingress→Service的依赖关系
调用链数据	Jaeger/Zipkin（可选）	微服务调用链路（定位跨Pod/服务的故障）

2. 落地要点

• 指标采集：核心指标保留15s粒度，非核心指标降采样为1min，避免Prometheus存储爆炸；
• 日志采集：用Loki的label过滤（按namespace/pod_name），只采集ERROR/WARN级日志，降低存储成本；
• 事件采集：将K8s Events转发到Kafka/ES，保留至少7天，用于故障回溯。

---

二、基础分析层（中小集群首选，快速见效）

1. 核心技术/算法

能力方向	技术/算法	落地场景
异常检测	静态阈值/动态阈值（3σ/IQR）	Pod内存使用率>90%、Node磁盘IO>95%、APIServer响应时间>500ms
告警降噪	时间窗聚合、Jaccard相似度	将5分钟内同一Node的雪崩式告警聚合为1条核心告警
根因分析	规则引擎、决策树	Pod重启→优先查OOM/Evict；Node NotReady→优先查kubelet/网络
趋势分析	滑动平均（MA/EMA）、时序差分	识别CPU/内存使用率的缓慢上涨趋势（提前预警）

2. 落地示例（规则引擎核心规则）

# Pod异常根因规则
- 故障现象: PodRestart
  排查规则:
    1. 检查容器状态 → 若OOMKilled → 根因：内存溢出
    2. 检查Pod事件 → 若Evicted → 根因：节点资源不足
    3. 检查镜像拉取状态 → 若ImagePullBackOff → 根因：镜像拉取失败
    4. 检查PVC状态 → 若Pending → 根因：存储卷未绑定

---

三、进阶AI层（中大型集群，AIOps核心）

1. 核心技术/算法

能力方向	技术/算法	落地场景
异常检测	孤立森林（PyOD）、ADTK（时序突变）	识别非规则类异常（如CPU使用率突增、网络延迟偶发飙升）
资源预测	Prophet/ARIMA、LSTM	预测24小时内Pod CPU/内存使用率，提前扩容避免OOM
告警聚类	TF-IDF + DBSCAN、LDA	将语义相似的告警（如“Service不通”“Pod不可用”）聚类，提取根告警
根因排序	XGBoost/LightGBM、MIC（互信息）	对故障特征（节点、指标、日志关键词）打分，输出根因Top5

2. 落地要点

• 异常检测：优先用PyOD的IForest处理高维指标（如同时分析CPU/内存/网络/磁盘）；
• 资源预测：Prophet适配K8s资源的周期性（如工作日9点流量高峰），比ARIMA更易调参；
• 根因排序：将K8s故障特征（如node=node-1、metric=disk_io=99%、log=OOM）输入XGBoost，通过特征重要性定位根因。

---

四、高阶智能层（大厂级落地）

1. 核心技术/算法

能力方向	技术/算法	落地场景
因果推断	PC算法、LiNGAM	区分“CPU高导致延迟高”还是“延迟高导致CPU高”，定位真正触发因素
知识图谱	Neo4j、规则推理	构建K8s故障图谱（实体：Node/Pod/Metric；关系：依赖/触发），推理根因
大模型增强	LLM + LangChain	解析非结构化日志、自然语言总结根因、生成排查命令（如kubectl describe pod）
拓扑推理	PageRank、信念传播	基于K8s拓扑依赖（如Ingress→Service→Pod），给根因节点打分

2. 落地要点

• 因果推断：先通过MIC做特征筛选，再用PC算法构建因果图，降低计算复杂度；
• 知识图谱：先沉淀高频故障的知识（如“OOM→Pod重启→Service不可用”），再扩展到全量故障；
• 大模型：优先用开源LLM（如Qwen-7B）本地化部署，避免日志/指标数据外泄。

---

五、工程落地层（将AIOps能力落地到生产）

1. 核心组件

能力方向	核心组件	作用
实时计算	Flink/Spark Streaming	处理秒级指标/事件，实时检测异常、聚合告警
可视化	Grafana	展示指标趋势、异常检测结果、根因TopN、故障链
自动化处置	Argo Workflows/Tekton	将排查步骤封装为Workflow，故障触发时自动执行（如自动扩容、重启Pod）
告警闭环	AlertManager + WebHook	根因分析结果自动回填到告警，推送给运维（钉钉/企业微信）
存储	Prometheus TSDB/ClickHouse	存储时序指标（Prometheus）、日志/事件（ClickHouse）

2. 落地架构示例

graph TD A[K8s集群] --> B[数据采集层<br/>Prometheus/Loki/EventRouter] B --> C[消息队列<br/>Kafka] C --> D[实时计算层<br/>Flink] D --> E[基础分析层<br/>规则引擎/3σ] D --> F[进阶AI层<br/>PyOD/Prophet/XGBoost] E --> G[工程落地层<br/>Grafana/Argo/AlertManager] F --> G F --> H[高阶智能层<br/>Neo4j/LLM] H --> G

---

总结

1. 中小集群：优先落地「数据层+基础分析层+工程落地层」，用规则+统计解决80%故障，成本低、见效快；
2. 中大型集群：叠加「进阶AI层」，重点落地异常检测（孤立森林）、资源预测（Prophet）、告警聚类（DBSCAN）；
3. 大厂级集群：落地「高阶智能层」，通过因果推断+知识图谱+大模型实现精准根因定位和智能处置；
4. 技术栈落地核心：先解决高频场景，再迭代复杂场景，避免一上来就堆砌高阶算法导致落地失败。

• 各层级技术栈的选型对比表（如Loki vs ELK、Prophet vs LSTM）；
• 「K8s AIOps 最小落地架构」的docker-compose部署脚本；
• 核心算法（如孤立森林、DBSCAN）在K8s场景的调参指南。