做Aiops智能体，一开始我们可以先从最简单、最容易落地的入手，然后一点一点增加新的功能，从而让智能体更强大。一上来就搞得太复杂，很有可能你因为某个功能无法实现而半途而废。
今天这个智能体案例就是使用dify的http节点，来请求k8s的api，从而去控制和维护k8s集群。
一、整体架构设计和思路
user-service”）。PATCH /apis/apps/v1/namespaces/production/deployments/user-service），并附上认证信息。二、准备工作
三、核心步骤
步骤 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 个。请继续观察服务状态。”
