Kubernetes errors are cryptic. CrashLoopBackOff, OOMKilled, ImagePullBackOff — each requires different debugging steps. AI can analyze the error context and suggest fixes, but sending your cluster state to ChatGPT means exposing internal service names, configs, and potentially secrets.

With Ollama, you can debug Kubernetes locally.

Quick setup

# Install Ollama if you haven't
brew install ollama
ollama pull qwen3:8b

# Create a k8s debugging alias
alias k8s-debug='function _kd() { kubectl describe pod $1 2>&1 | ollama run qwen3:8b "Analyze this Kubernetes pod description. Identify the problem and suggest a fix:"; }; _kd'

# Usage
k8s-debug my-failing-pod

Common errors with AI-assisted fixes

CrashLoopBackOff

# Get the context
kubectl describe pod $POD_NAME > /tmp/pod.txt
kubectl logs $POD_NAME --previous >> /tmp/pod.txt

# Ask AI
cat /tmp/pod.txt | ollama run qwen3:8b "This Kubernetes pod is in CrashLoopBackOff. Analyze the pod description and previous logs. What's causing the crash and how do I fix it?"

OOMKilled

kubectl describe pod $POD_NAME | ollama run qwen3:8b "This pod was OOMKilled. Based on the resource limits and usage, what should I set the memory limit to? Current config included below:"

ImagePullBackOff

kubectl describe pod $POD_NAME | ollama run qwen3:8b "This pod has ImagePullBackOff. Check the image name, registry, and pull secrets. What's wrong?"

Python script for automated debugging

import subprocess
import ollama

def debug_pod(pod_name, namespace="default"):
    # Gather context
    describe = subprocess.run(
        ["kubectl", "describe", "pod", pod_name, "-n", namespace],
        capture_output=True, text=True
    ).stdout
    
    logs = subprocess.run(
        ["kubectl", "logs", pod_name, "-n", namespace, "--tail=50"],
        capture_output=True, text=True
    ).stdout
    
    events = subprocess.run(
        ["kubectl", "get", "events", "-n", namespace,
         "--field-selector", f"involvedObject.name={pod_name}",
         "--sort-by=.lastTimestamp"],
        capture_output=True, text=True
    ).stdout
    
    prompt = f"""Debug this Kubernetes pod issue.

Pod description:
{describe[:3000]}

Recent logs:
{logs[:2000]}

Events:
{events[:1000]}

Provide:
1. Root cause
2. Severity (critical/warning/info)
3. Fix command(s) to run
4. Prevention (what to change in the deployment yaml)"""

    response = ollama.chat(model="qwen3:8b", messages=[
        {"role": "user", "content": prompt}
    ])
    return response["message"]["content"]

# Debug a specific pod
print(debug_pod("api-server-7f8b9c6d4-x2k9p"))

Cluster health check

# One-liner: check all pods and get AI summary
kubectl get pods --all-namespaces | grep -v Running | grep -v Completed | \
  ollama run qwen3:8b "These Kubernetes pods are not in Running state. For each one, explain the likely cause and priority of fixing it:"

Integrate with monitoring

Combine with n8n for automated alerts:

Schedule (every 5 min) → kubectl get pods → Filter non-running → Ollama (analyze) → Slack alert

Or use a Claude Code Routine if cloud AI is acceptable.

Which model for K8s debugging

Model	RAM	Best for
qwen3:8b	5 GB	Quick diagnostics, common errors
deepseek-r1:14b	9 GB	Complex networking issues, reasoning
qwen3.5:27b	16 GB	Architecture analysis, capacity planning

For most K8s debugging, qwen3:8b is sufficient. The errors are usually well-documented patterns that an 8B model handles well.

Security note

Even with local models, be careful about what you pipe in:

# Safe: pod descriptions and logs
kubectl describe pod $POD | ollama run qwen3:8b "debug this"

# Dangerous: secrets and configmaps
# DON'T do this:
kubectl get secret $SECRET -o yaml | ollama run qwen3:8b "explain this"

Secrets should never be sent to any AI model, even local ones — they end up in conversation history and potentially in logs.

Related: Ollama Complete Guide · AI Log Analysis with Local Models · Self-Host n8n with Local AI · Kubernetes Cheat Sheet · Docker Cheat Sheet · Self-Hosted AI for Enterprise