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

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

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

一、整体架构设计和思路

二、准备工作

三、核心步骤

步骤 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-api Deployment 发送重启指令，正在执行滚动更新。”

示例 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 个。请继续观察服务状态。”