Posted inAI

Tự động hóa khắc phục sự cố Kubernetes với K8sGPT và Ollama cục bộ

AI tutorial - IT technology blog
AI tutorial - IT technology blog

Bắt đầu nhanh (5 phút)

Debug các workload Kubernetes thường đồng nghĩa với việc phải lùng sục qua hàng tá dòng log bất tận, các Event khó hiểu và mã exit code mơ hồ. Phải làm việc đó lúc 2 giờ sáng quả là một cơn ác mộng. Việc kết hợp K8sGPT với Ollama cho phép bạn tự động phân loại và xử lý sự cố nhanh chóng ngay trên máy của mình. Bạn sẽ nhận được các bản tóm tắt chẩn đoán rõ ràng mà không phải gửi secret, manifest hay địa chỉ IP nội bộ của cụm đến các cloud API bên ngoài.

Dưới đây là cách thiết lập pipeline chẩn đoán offline trên máy trạm quản trị của bạn chỉ trong năm phút.

1. Cài đặt Ollama và tải model gọn nhẹ

Hãy bắt đầu bằng việc cài đặt Ollama và tải một model nhỏ gọn. Đối với tác vụ chẩn đoán cụm, mistral (7B) hoặc llama3.2 (3B) có khả năng xử lý tốt cấu trúc YAML và dấu vết lỗi (error trace) mà không chiếm dụng quá nhiều bộ nhớ:

# Cài đặt Ollama trên Linux
curl -fsSL https://ollama.com/install.sh | sh

# Khởi chạy daemon Ollama dưới nền
ollama serve &

# Tải trọng số Mistral 7B (~4.1 GB)
ollama pull mistral

Kiểm tra xem Ollama đã phản hồi trên cổng 11434 hay chưa:

curl http://localhost:11434/api/version
# Kết quả mong đợi: {"version":"0.5.4"}

2. Cài đặt K8sGPT CLI

Tải bản binary của K8sGPT tương ứng với kiến trúc hệ thống của bạn:

# Tải về và cài đặt package Debian cho AMD64
curl -LO https://github.com/k8sgpt-ai/k8sgpt/releases/download/v0.3.40/k8sgpt_amd64.deb
sudo dpkg -i k8sgpt_amd64.deb

# Kiểm tra phiên bản đã cài đặt
k8sgpt version

3. Kết nối K8sGPT với Ollama engine cục bộ

Ollama cung cấp một endpoint /v1 tương thích với OpenAI. Vì truy vấn trực tiếp vào daemon cục bộ, K8sGPT không cần API key thực tế. Bạn chỉ cần truyền một chuỗi giữ chỗ để đáp ứng yêu cầu của trình phân tích cú pháp CLI:

k8sgpt auth add --backend localai --model mistral --baseurl http://localhost:11434/v1 --password dummy

# Đặt LocalAI làm backend mặc định
k8sgpt auth default -b localai

4. Chạy lượt quét chẩn đoán đầu tiên

Trỏ context của kubectl tới cụm thử nghiệm và tiến hành phân tích:

k8sgpt analyze --explain --backend localai

K8sGPT sẽ kiểm tra các namespace đang hoạt động, tìm các đối tượng bị lỗi và gửi các đoạn trích lỗi đã được làm sạch tới Ollama. Trong vòng 2 đến 4 giây, bạn sẽ nhận được giải thích nguyên nhân gốc rễ rõ ràng kèm theo các lệnh kubectl cụ thể để khắc phục.

Kiến trúc: Cách K8sGPT phân tích cụm cục bộ

Hiểu rõ những gì diễn ra trong quá trình phân tích sẽ giúp hệ thống của bạn vận hành ổn định và tránh rò rỉ dữ liệu.

Pipeline phân tích có lọc (Filtered Analyzer Pipeline)

K8sGPT không bao giờ đưa toàn bộ manifest thô của cụm vào prompt của LLM. Việc nạp toàn bộ cây đối tượng sẽ nhanh chóng làm vượt quá giới hạn token và tăng độ trễ — bài toán quen thuộc khi thực hiện Context Engineering cho các hệ thống AI. Thay vào đó, các analyzer chuyên biệt viết bằng Go sẽ truy vấn trực tiếp Kubernetes API để tìm các điểm bất thường:

  • PodAnalyzer: Phát hiện các trạng thái CrashLoopBackOff, ImagePullBackOff, liveness probe thất bại và sự kiện exit code 137 (OOMKilled).
  • ServiceAnalyzer: Phát hiện các endpoint cấu hình sai khi label không khớp với pod đang chạy.
  • IngressAnalyzer: Bắt lỗi thiếu TLS secret, xung đột định tuyến và tham chiếu service backend bị hỏng.
  • PV/PVC Analyzers: Đánh dấu các PVC chưa được liên kết (unbound), thiếu storage class và lỗi quá thời gian chờ (timeout) của provisioner.

Các analyzer này thực hiện kiểm tra sức khỏe có mục tiêu đối với các đối tượng trong cụm. Khi một tài nguyên gặp sự cố, analyzer sẽ loại bỏ các thông tin thừa, chỉ giữ lại thông báo lỗi liên quan, exit code của container và các Event gần nhất. Sau đó, nó đưa dữ liệu cô đọng đó vào Ollama thông qua một mẫu prompt tinh gọn.

Tại sao việc chạy suy luận LLM offline lại quan trọng đối với bảo mật cụm

Các môi trường tài chính, quốc phòng và y tế phải tuân thủ nghiêm ngặt ranh giới dữ liệu. Việc gửi trực tiếp manifest hoặc log container đến các mô hình SaaS bên ngoài tiềm ẩn rủi ro bảo mật thực sự. Prompt có thể vô tình làm lộ các endpoint riêng tư, dải mạng CIDR nội bộ hoặc thông tin đăng nhập cơ sở dữ liệu chưa được che giấu trong biến môi trường — một rủi ro nghiêm trọng về bảo mật AI và bảo vệ dữ liệu nhạy cảm.

Chạy Ollama cục bộ loại bỏ hoàn toàn việc truyền dữ liệu ra ngoài. Mọi token của prompt đều nằm trọn trong ranh giới VPC hoặc máy trạm của bạn. Việc phân loại sự cố chỉ mất dưới 3 giây cho mỗi lỗi, và đội ngũ bảo mật của bạn sẽ không bao giờ phải lo lắng về các vi phạm tuân thủ.

Tự động hóa trong môi trường Production: Thiết lập Operator trong cụm

Các lệnh CLI thủ công rất hữu ích khi xử lý sự cố tức thời, tương tự như việc ứng dụng AI trên Terminal để tăng tốc công việc. Tuy nhiên, các đội ngũ kỹ sư nền tảng (platform engineering) quản lý nhiều cụm sẽ thu được nhiều giá trị hơn từ việc phân tích liên tục dưới nền.

Triển khai Ollama với lưu trữ liên tục (Persistent Storage)

Để tránh phải tải lại các model dung lượng hàng gigabyte mỗi khi pod khởi động lại, hãy gắn một persistent volume vào Ollama tại đường dẫn /root/.ollama:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
  namespace: k8sgpt-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      containers:
      - name: ollama
        image: ollama/ollama:latest
        ports:
        - containerPort: 11434
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
          limits:
            memory: "8Gi"
            cpu: "4"
        volumeMounts:
        - name: model-cache
          mountPath: /root/.ollama
      volumes:
      - name: model-cache
        persistentVolumeClaim:
          claimName: ollama-models-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: ollama-service
  namespace: k8sgpt-system
spec:
  type: ClusterIP
  ports:
  - port: 11434
    targetPort: 11434
  selector:
    app: ollama

Tải model bạn đã chọn trực tiếp vào volume sau khi pod khởi động:

kubectl exec -it -n k8sgpt-system deploy/ollama -- ollama pull mistral

Triển khai K8sGPT Operator

Cài đặt operator chính thức bằng Helm vào namespace giám sát của bạn:

helm repo add k8sgpt https://charts.k8sgpt.ai/
helm repo update

helm install k8sgpt-operator k8sgpt/k8sgpt-operator \
  --namespace k8sgpt-system \
  --create-namespace

Cấu hình Custom Resource trong cụm

Tạo một secret chứa mật khẩu giữ chỗ, sau đó khai báo tài nguyên K8sGPT trỏ tới service Ollama nội bộ trong cụm:

kubectl create secret generic k8sgpt-ollama-secret \
  --namespace k8sgpt-system \
  --from-literal=password=dummy

apiVersion: core.k8sgpt.ai/v1alpha1
kind: K8sGPT
metadata:
  name: k8sgpt-ollama
  namespace: k8sgpt-system
spec:
  ai:
    enabled: true
    model: mistral
    backend: localai
    baseUrl: http://ollama-service.k8sgpt-system.svc.cluster.local:11434/v1
    secret:
      name: k8sgpt-ollama-secret
      key: password
  noCache: false
  repository: ghcr.io/k8sgpt-ai/k8sgpt
  version: v0.3.40

Xem kết quả qua Custom Resource

Operator sẽ quét các tài nguyên theo chu kỳ điều hòa (reconciliation loop) đều đặn và xuất kết quả dưới dạng các custom resource Result:

kubectl get results -n k8sgpt-system -o wide

Để kiểm tra nguyên nhân pod bị lỗi, hãy dùng lệnh describe tài nguyên result tương ứng:

kubectl describe result default-payment-service-crashloop -n k8sgpt-system

Kết quả hiển thị chính xác thông báo lỗi, chẳng hạn như Back-off restarting failed container payment-api, kèm theo lời khuyên rõ ràng giải thích rằng việc thiếu một secret key là nguyên nhân gây ra sự cố sập ứng dụng.

Quy chuẩn cấu hình và hướng dẫn vận hành cho Production

1. Chọn tham số model phù hợp với tài nguyên tính toán

Tuyệt đối không chạy model 70B tham số trên các node dùng chung CPU. Trong lúc xảy ra sự cố, câu trả lời nhanh chóng luôn giá trị hơn những mô tả dài dòng mang tính văn phong:

  • Llama-3.2 (3B) hoặc Phi-3 Mini (3.8B): Cần khoảng 2.2 GB RAM. Thời gian phản hồi từ 1 đến 3 giây trên các worker node CPU 4-core tiêu chuẩn mà không cần GPU passthrough.
  • Mistral (7B) hoặc Llama-3.1 (8B): Yêu cầu khoảng 5.5 GB VRAM. Một GPU Nvidia T4 (16 GB) hoặc A10G cho thời gian suy luận dưới 800 ms cùng khả năng phân tích vượt trội các network policy và cấu hình multi-container.

2. Thu hẹp phạm vi quét để bảo vệ tài nguyên cụm

Việc quét toàn bộ trên 50 namespace sẽ gây áp lực lớn lên cả API server lẫn inference engine. Hãy giới hạn phạm vi quét ở các namespace quan trọng và tài nguyên có vấn đề:

# Chỉ quét namespace payment môi trường production
k8sgpt analyze --namespace payments --explain

# Lọc riêng cho các pod và service bị lỗi
k8sgpt analyze --filter Pod,Service --explain

3. Bật tính năng ẩn danh dữ liệu phía client (Client-Side Anonymization)

Che giấu các định danh là một biện pháp hữu ích ngay cả khi sử dụng inference engine nội bộ. K8sGPT có thể làm sạch tên pod, label của namespace và các ID dạng số trước khi tạo prompt:

k8sgpt analyze --explain --anonymize

4. Định tuyến cảnh báo qua Prometheus

K8sGPT operator xuất một metric Prometheus có tên là k8sgpt_number_of_failures. Hãy thêm một alert rule kích hoạt khi giá trị này vượt quá 0 trong hơn năm phút trên các workload cấp độ 1 (tier-1). Kết hợp với giải pháp AIOps để phân tích cảnh báo Prometheus và RCA, kỹ sư trực on-call có thể kiểm tra ngay các CRD Result đã được tạo sẵn thay vì phải sàng lọc thủ công qua các bản log container thô.

Share:
Tags: