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

玩转AGI
107 阅读6分钟

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

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

今天这个智能体案例就是使用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-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 个。请继续观察服务状态。”

avatar
文章
阅读
粉丝