当前位置：首页 > news >正文

SRE AI Agent 开发复盘及小白向教程 (三) Go语言内核编写和持久存储配置

news 2026/3/27 5:59:50

先导：

接上两篇文章

SRE AI Agent 开发复盘及小白向教程 (一) 项目环境搭建https://blog.csdn.net/qq_37438848/article/details/157993572?spm=1011.2415.3001.10575&sharefrom=mp_manage_link

SRE AI Agent 开发复盘及小白向教程 (二) GitOps及附属功能搭建https://blog.csdn.net/qq_37438848/article/details/158717484?fromshare=blogdetail&sharetype=blogdetail&sharerId=158717484&sharerefer=PC&sharesource=qq_37438848&sharefrom=from_link

本期目标：

编写Go语言程序，并完成k8s集群的持久化存储配置，实现系统的主要功能并实现其长期存储

提前准备：

简单学习并了解k8s中的持久化存储，了解持久卷，申领等重要知识点。

高亮提示：

绿色：检查点，你应该保证自己的状态与截图一致。

橙色：修正配置问题，如果你确认没有该问题，可以跳过

红色：重要的配置，在后续操作中需要用到，请在配置时记录。

七、Go语言程序编写及大语言模型拉取

开发一个基于Go语言的AI智能体，使其能够：

感知Prometheus中的PodCrashLooping告警。
思考通过调用Ollama LLM服务，根据告警信息决策是否需要重启Pod。
行动调用Kubernetes API执行重启操作（通过删除Pod实现）。

1. 开发环境准备 (k8s-node1)

1.1 安装Go语言:

dnf install -y golang go version

1.2创建项目并初始化模块

mkdir -p ~/sre-agent cd ~/sre-agent go mod init sre-agent

1.3 安装Go依赖

# 在sre-agent目录下先创建一个空的 main.go，然后运行 tidy touch main.go # (此时main.go内容为空，但足以让tidy工作)  # 手动添加几个核心依赖，以确保版本 go get k8s.io/client-go@v0.30.0 go get github.com/prometheus/common@v0.53.0  # 运行tidy来处理所有间接依赖 go mod tidy

2. 编写相关程序

2.1 编写测试应用

该应用会创造持续的崩溃以测试系统功能

cat > ~/crash-app.yaml <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: crash-app spec: replicas: 1 selector: matchLabels: app: crash-app template: metadata: labels: app: crash-app spec: containers: - name: main image: alpine:latest command: ["/bin/sh", "-c", "echo 'I am designed to fail!'; exit 1"] EOF  kubectl apply -f ~/crash-app.yaml # 验证: watch kubectl get pods (会看到crash-app处于CrashLoopBackOff状态)

2.2 创建Prometheus告警规则:

cat > ~/pod-crash-rule.yaml <<EOF apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: pod-crash-alert namespace: monitoring labels: release: prometheus-stack # 确保operator能发现此规则 spec: groups: - name: kubernetes.rules rules: - alert: PodCrashLooping expr: kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1 for: 1m labels: severity: critical annotations: summary: "Pod is crash looping" description: "Pod {{ \$labels.namespace }}/{{ \$labels.pod }} is in CrashLoopBackOff state." EOF  kubectl apply -f ~/pod-crash-rule.yaml # 验证: 在Prometheus UI的Alerts页面，等待看到PodCrashLooping告警变为FIRING状态。

2.3 Go语言模型

使用Go语言编写一个简单的程序，从Prometheus的日志中获取pod状态，转述给大语言模型，并按照从大语言模型返回的简单决策关键字执行操作（代码因版权原因不能公开，请谅解）

在编写完成后重载依赖

go mod tidy

5.为Ollama拉取语言模型

确保Ollama模型已拉取: # 找到Ollama Pod名 OLLAMA_POD=$(kubectl get pods -n ai-services -l app=ollama -o jsonpath='{.items[0].metadata.name}') # 进入Pod拉取模型 kubectl exec -it $OLLAMA_POD -n ai-services -- ollama pull qwen2.5:1.5b # 验证 kubectl exec -it $OLLAMA_POD -n ai-services -- ollama list | grep 'qwen2.5:1.5b'

5.1 打开两个终端

终端一: 运行Agent

cd ~/sre-agent go run main.go

终端二: 监控Pods

watch kubectl get pods

在终端一看到Deleting pod ...的日志后，切换到终端二，观察到crash-app的Pod被Terminating并被一个新的Pod替换。

系统成功做出决策并重启

八、修改yaml文件以实现持久存储

问题

我们发现重启集群后，ArgoCD中的Ollama服务Pod状态出现异常。通过调试分析，问题根源在于Pod中的大语言模型在Pod被杀死后丢失。这是因为Pod中的文件系统是临时的，当Pod因节点重启或调度而被销毁时，其中下载的模型文件也随之被清除。为了解决这个数据持久化问题，我们需要为集群配置持久存储。

修改我们在上一篇文章5.2中上传到GitHub的文件如下:

我们优化Kubernetes配置文件，通过PersistentVolumeClaim（PVC）实现模型数据的持久化存储：

apiVersion: v1 kind: Namespace metadata: name: ai-services --- apiVersion: apps/v1 kind: Deployment metadata: name: ollama namespace: ai-services spec: replicas: 1 selector: matchLabels: { app: ollama } template: metadata: labels: { app: ollama } spec: containers: - name: ollama image: ollama/ollama:latest ports: - containerPort: 11434 volumeMounts: - name: ollama-storage mountPath: /root/.ollama # Ollama 默认的模型存储路径 volumes: - name: ollama-storage persistentVolumeClaim: claimName: ollama-pvc --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ollama-pvc namespace: ai-services spec: storageClassName: local-path accessModes: - ReadWriteOnce resources: requests: storage: 10Gi --- apiVersion: v1 kind: Service metadata: name: ollama-service namespace: ai-services spec: type: NodePort selector: { app: ollama } ports: - port: 11434 targetPort: 11434