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

qq_37438848

478人浏览 · 2026-03-19 20:49:11

qq_37438848 · 2026-03-19 20:49:11 发布

先导：

接上两篇文章

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