Aiops探索：我用Dify结合k8s的api做了一个非常简单的Aiops智能体

显示全部楼层

做Aiops智能体，一开始我们可以先从最简单、最容易落地的入手，然后一点一点增加新的功能，从而让智能体更强大。一上来就搞得太复杂，很有可能你因为某个功能无法实现而半途而废。

今天这个智能体案例就是使用dify的http节点，来请求k8s的api，从而去控制和维护k8s集群。

一、整体架构设计和思路

流程是这样的：

1. 用户通过 Dify 的聊天界面输入自然语言指令（如：“帮我重启一下生产环境的user-service”）。

2. Dify 工作流中的LLM 节点解析用户意图，提取关键信息（如：操作=重启，环境=生产，服务名=user-service）。

3. LLM 节点将提取出的参数传递给HTTP 请求节点。

4. HTTP 请求节点构造一个符合 K8s API 规范的 HTTP 请求（如：PATCH /apis/apps/v1/namespaces/production/deployments/user-service），并附上认证信息。

5. K8s API Server 接收到请求，进行认证和授权，然后在集群内执行相应的操作（如：触发 Deployment 的滚动更新）。

6. K8s API Server 将操作结果返回给 Dify 的 HTTP 节点。

7. Dify 工作流可以再次使用LLM 节点将返回的 JSON 结果格式化，用自然语言反馈给用户。

二、准备工作

1. 假设你已经有了一个k8s集群环境。

2. 安全地暴露k8s API，这是最关键的一步。

3. 创建 K8s ServiceAccount 和 Token (RBAC)

说明：以上3个操作不作为这篇文章的讨论内容，所以不涉及细节。

三、核心步骤

步骤 1: 创建工作流

在 Dify 控制台创建一个新的空白工作流应用。

步骤 2: 配置变量

在工作流的“开始”节点，添加变量，例如：

k8s_api_url : 字符串类型，默认值可以是 http://<你的proxy-ip>:8001
k8s_token: 字符串类型，粘贴上一步获取的 Token。
user_query: 字符串类型，用于接收用户输入。

步骤 3: 使用 LLM 节点解析意图

添加一个 LLM 节点（如 GPT-4），连接“开始”节点。

系统提示词

你是一个Kubernetes运维助手。你的任务是解析用户的指令，并提取出关键信息，然后以JSON格式输出。用户可能想查询Pod状态、重启Deployment或查看日志。请从用户的指令中提取以下信息（如果存在）：-"action": 操作类型，只能是"get_pod_status","restart_deployment","get_pod_logs"中的一个。-"namespace": K8s 命名空间。-"resource_name": 资源名称，如Pod或Deployment的名称。
如果信息不全，特别是"namespace"和"resource_name"，请询问用户。
示例输入:"帮我重启一下生产环境的 user-service"示例输出: {"action":"restart_deployment","namespace":"production","resource_name":"user-service"}
示例输入:"default 命名空间里 my-app-pod 这个 pod 怎么样了"示例输出: {"action":"get_pod_status","namespace":"default","resource_name":"my-app-pod"}

用户提示词：{{user_query}}

步骤 4: 配置 HTTP 请求节点

这是核心。添加一个“HTTP 请求”节点，连接 LLM 节点的输出。

URL: 这里需要根据 LLM 解析出的action动态构造。我们可以使用一个“代码”节点或“条件判断”节点来处理。为了简化示例，我们先以一个固定动作（如查询 Pod）为例。比如：{{k8s_api_url}}/api/v1/namespaces/{{#LLM.output#namespace}}/pods/{{#LLM.output#resource_name}} 注意：{{#LLM.output#namespace}}的语法是引用上一个节点输出的 JSON 字段。

Method:GET
Headers: Authorization: Bearer {{k8s_token}}

步骤 5: 处理结果

再添加一个 LLM 节点，连接 HTTP 请求节点的输出。

系统提示词

你是一个Kubernetes运维助手。你收到了一个关于Pod状态的JSON数据。请将以下JSON信息转换成易于理解的中文自然语言描述，并报告Pod的状态、IP、节点以及最近的事件（如果有）。

用户提示词：{{#HTTP请求节点.text#}}(引用 HTTP 节点的 body 文本输出)

四、应用场景示例

示例 1: 智能查询 Pod 状态

用户输入: "看看default命名空间下my-nginx这个 Pod 还活着吗？"

流程:

LLM 解析出 {"action": "get_pod_status", "namespace": "default", "resource_name": "my-nginx"}。
HTTP 节点发送 GET /api/v1/namespaces/default/pods/my-nginx。
最终 LLM 节点将返回的 JSON 解析为：“my-nginx Pod 目前处于 Running 状态，运行在节点 node-01 上，IP 地址是 10.244.1.5。一切看起来正常。”

示例 2: 重启 Deployment

用户输入: "把staging环境的payment-api重启一下"

流程:

LLM 解析出{"action": "restart_deployment", "namespace": "staging", "resource_name": "payment-api"}。
重启 Deployment 的标准 API 调用是PATCH其spec.template.metadata.annotations，添加一个带时间戳的注解来触发滚动更新。
HTTP 节点配置：

Method: PATCH

URL: {{k8s_api_url}}/apis/apps/v1/namespaces/{{#LLM.output#namespace}}/deployments/{{#LLM.output#resource_name}}
Headers: Authorization: Bearer {{k8s_token}}, Content-Type: application/strategic-merge-patch+json

Body:

{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt":"{{sys_date}}"}}}}}

{{sys_date}} 是 Dify 提供的系统变量，代表当前时间。

最终 LLM 节点根据 HTTP 返回的状态码（如 200 OK）告诉用户：“已成功向payment-apiDeployment 发送重启指令，正在执行滚动更新。”

示例 3: 高级 AIOps - 诊断与自动扩缩容

用户输入: "user-service最近响应很慢，帮我看看日志，如果 CPU 高就帮我扩容"
流程:

LLM 节点 1 (意图解析): 解析出需要查询日志、检查指标，并可能执行扩容。
HTTP 节点 1 (获取日志): 调用/api/v1/namespaces/default/pods/<pod-name>/log。
HTTP 节点 2 (获取指标): 如果集群部署了 Metrics Server，可以调用/apis/metrics.k8s.io/v1beta1/namespaces/default/pods/<pod-name>获取 CPU/内存使用率。
LLM 节点 2 (分析与决策):

输入：日志内容和指标数据。
系统提示词：“分析以下日志和指标数据。如果发现大量 OutOfMemoryError，建议增加内存限制。如果发现 CPU 使用率持续超过 80%，建议增加 Deployment 的副本数。请做出决策，并输出需要执行的操作（如：'scale', 'none'）和参数（如新的副本数）。”

条件判断节点: 根据 LLM 节点 2 的输出，判断是否需要扩容。
HTTP 节点 3 (执行扩容): 如果需要，则发送 PATCH 请求到 Deployment，修改 spec.replicas 字段。
LLM 节点 3 (总结报告): 生成最终报告：“我分析了 user-service 的日志和指标，发现 CPU 使用率持续过高，已将其副本数从 3 个扩容到 5 个。请继续观察服务状态。”

最后介绍下我的大模型课：我的运维大模型课上线了，目前还在预售期，有很大优惠。AI越来越成熟了，大模型技术需求量也越来越多了，至少我觉得这个方向要比传统的后端开发、前端开发、测试、运维等方向的机会更大，而且一点都不卷！