K8sGPT met een Lokale 70B Model op Apple Silicon

“Autonomous cluster management” — de belofte dat een AI je Kubernetes cluster kan monitoren, problemen kan diagnosticeren, en misschien zelfs kan fixen zonder menselijke interventie. Het klinkt als de heilige graal voor platform engineers.

De realiteit is genuanceerder.

In deze post test ik K8sGPT met een lokaal draaiende Llama 3.3 70B model op Apple Silicon. Geen cloud APIs, geen data die je netwerk verlaat, volledig sovereign. Is dit bruikbaar voor echte cluster diagnose? Laten we het uitzoeken.

Disclaimer: Dit is een homelab experiment. Ik beschrijf wat ik heb getest en wat ik heb gevonden. Dit is geen aanbeveling om dit in productie te draaien — integendeel, zoals de security analyse zal laten zien.

Hardware en Software Stack

De Hardware

• Mac Studio M3 Ultra met 512GB unified memory
• De M3 Ultra heeft 80 GPU cores die je kunt gebruiken voor inference
• Unified memory betekent geen kopiëren tussen CPU en GPU RAM

Dit is geen goedkope setup (~€10.000), maar het is de enige consumer hardware die een 70B model in Q8 quantization kan draaien met acceptabele snelheid.

De Software Stack

Installatie: vLLM met Metal Backend

vLLM heeft experimentele Metal support voor Apple Silicon. Installatie:

# Maak een dedicated conda environment
conda create -n vllm python=3.11
conda activate vllm

# Installeer vLLM met Metal support
pip install vllm

# Verifieer Metal backend
python -c "import vllm; print(vllm.__version__)"

Let op: Op moment van schrijven is Metal support in vLLM nog experimenteel. Voor productie-achtige workloads is llama.cpp met de Metal backend stabieler, maar K8sGPT verwacht een OpenAI-compatible API.

Model Download

# Download het model (Q8 quantization, ~75GB)
huggingface-cli download meta-llama/Llama-3.3-70B-Instruct \
  --local-dir ./models/llama-3.3-70b-instruct

Je hebt een Hugging Face account nodig en moet de Llama license accepteren.

vLLM Server Starten

# Start de inference server
vllm serve ./models/llama-3.3-70b-instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --dtype float16 \
  --max-model-len 8192 \
  --device mps

De --device mps flag forceert Metal Performance Shaders. Zonder deze flag valt vLLM terug op CPU.

Verifieer dat de server draait:

curl http://localhost:8000/v1/models

K8sGPT Operator Deployment

Installeer de K8sGPT operator in je cluster:

# Voeg de Helm repo toe
helm repo add k8sgpt https://charts.k8sgpt.ai/
helm repo update

# Installeer de operator
helm install k8sgpt-operator k8sgpt/k8sgpt-operator \
  -n k8sgpt-operator-system \
  --create-namespace

Configureer een custom backend die naar je lokale vLLM server wijst:

# k8sgpt-config.yaml
apiVersion: core.k8sgpt.ai/v1alpha1
kind: K8sGPT
metadata:
  name: k8sgpt-local
  namespace: k8sgpt-operator-system
spec:
  ai:
    enabled: true
    model: llama-3.3-70b-instruct
    backend: localai
    baseUrl: http://192.168.1.100:8000/v1  # IP van je Mac Studio
  noCache: false
  version: v0.3.40
  analyzers:
    - Pod
    - Deployment
    - Service
    - ReplicaSet
    - PersistentVolumeClaim
    - Ingress
    - StatefulSet
    - CronJob

kubectl apply -f k8sgpt-config.yaml

Test Scenarios

Nu de setup draait, tijd om te testen of het daadwerkelijk nuttig is.

Scenario A: CrashLoopBackOff Diagnose

Ik introduceer een deployment met een ontbrekende ConfigMap:

# broken-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: broken-app
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: broken-app
  template:
    metadata:
      labels:
        app: broken-app
    spec:
      containers:
      - name: app
        image: nginx:1.25
        envFrom:
        - configMapRef:
            name: app-config  # Deze ConfigMap bestaat niet

kubectl apply -f broken-deployment.yaml

Na een minuut is de pod in CrashLoopBackOff. K8sGPT analyse:

kubectl get results -n k8sgpt-operator-system -o yaml

Output (geparafraseerd):

Analysis: Pod broken-app-xxxx is in CreateContainerConfigError state.
The pod is referencing a ConfigMap 'app-config' that does not exist
in the namespace.

Suggested remediation:
1. Create the missing ConfigMap:
   kubectl create configmap app-config --from-literal=KEY=value
2. Or remove the configMapRef from the deployment spec
3. Verify the ConfigMap name spelling matches exactly

Score: Bruikbaar

De diagnose is correct en de suggesties zijn praktisch. Een junior engineer zou hiermee uit de voeten kunnen. Wat mist: het suggereert niet om eerst te checken of de ConfigMap wellicht in een andere namespace staat, wat een veelvoorkomende fout is.

Scenario B: Resource Recommendations

Een deployment zonder resource limits:

# no-limits.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: no-limits-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: no-limits
  template:
    metadata:
      labels:
        app: no-limits
    spec:
      containers:
      - name: app
        image: nginx:1.25
        # Geen resources gedefinieerd

K8sGPT analyse:

Analysis: Deployment no-limits-app has containers without resource
requests or limits defined.

Issues identified:
- Container 'app' has no CPU requests/limits
- Container 'app' has no memory requests/limits

Suggested remediation:
Add resource specifications to ensure predictable scheduling and
prevent resource starvation:

resources:
  requests:
    memory: "64Mi"
    cpu: "100m"
  limits:
    memory: "128Mi"
    cpu: "200m"

Score: Deels bruikbaar

Het identificeert het probleem correct, maar de gesuggereerde waarden zijn generiek en niet gebaseerd op daadwerkelijk verbruik. Een ervaren engineer zou eerst metrics verzamelen met kubectl top pods of Prometheus data, en dan rightsizen.

Wat mist:

• Geen suggestie om VPA (Vertical Pod Autoscaler) te gebruiken
• Geen waarschuwing dat limits zonder requests problematisch kunnen zijn
• De ratio requests:limits (1:2) is willekeurig

Scenario C: Security Audit

Een pod met slechte security practices:

# insecure-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
  namespace: default
spec:
  hostNetwork: true
  containers:
  - name: app
    image: nginx:1.25
    securityContext:
      privileged: true
      runAsRoot: true
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /

K8sGPT analyse met Trivy integratie:

Analysis: Pod insecure-pod has multiple security issues:

Critical:
- Container running in privileged mode (privileged: true)
- Container has access to host network (hostNetwork: true)
- Container mounts host root filesystem

High:
- No securityContext.readOnlyRootFilesystem
- No securityContext.allowPrivilegeEscalation: false

Suggested remediation:
1. Remove privileged: true unless absolutely necessary
2. Use a dedicated network namespace (remove hostNetwork: true)
3. Avoid mounting host paths, especially root filesystem
4. Add security hardening:

   securityContext:
     privileged: false
     readOnlyRootFilesystem: true
     allowPrivilegeEscalation: false
     runAsNonRoot: true
     capabilities:
       drop:
         - ALL

Score: Bruikbaar

Dit is verrassend goed. De issues zijn correct geïdentificeerd en de remediation is wat een security engineer zou adviseren. De Trivy integratie voegt waarde toe door ook image vulnerabilities te checken.

Wat mist:

• Geen suggestie voor Pod Security Standards (restricted profile)
• Geen warning over Kyverno/OPA policies die dit zouden moeten blokkeren

Performance Metrics

Inference Snelheid

End-to-End Latency

Van issue detectie tot rapport in K8sGPT:

Resource Gebruik

Tijdens inference:

Vergelijking met OpenAI API

De OpenAI API is sneller en de output is marginaal beter, maar je data verlaat je netwerk.

Air-Gapped Deployment

Kan deze setup werken zonder internetverbinding? Ja, met voorbereiding.

Wat je vooraf moet downloaden

# 1. Model weights (~75GB)
huggingface-cli download meta-llama/Llama-3.3-70B-Instruct \
  --local-dir ./airgap-bundle/models/

# 2. vLLM Python packages
pip download vllm -d ./airgap-bundle/packages/

# 3. K8sGPT container images
docker pull ghcr.io/k8sgpt-ai/k8sgpt-operator:latest
docker save ghcr.io/k8sgpt-ai/k8sgpt-operator:latest > ./airgap-bundle/images/k8sgpt-operator.tar

# 4. Helm charts
helm pull k8sgpt/k8sgpt-operator --destination ./airgap-bundle/charts/

Transport en Installatie

# Op de air-gapped machine:

# 1. Installeer Python packages offline
pip install --no-index --find-links=./airgap-bundle/packages/ vllm

# 2. Laad container images
docker load < ./airgap-bundle/images/k8sgpt-operator.tar
# Of push naar je lokale registry

# 3. Installeer Helm chart
helm install k8sgpt-operator ./airgap-bundle/charts/k8sgpt-operator-*.tgz \
  --set image.repository=your-local-registry/k8sgpt-operator

Air-Gap Friendly Components

Let op: De Trivy vulnerability database moet je apart updaten en transporteren. Zonder recente DB mist K8sGPT nieuwe CVEs.

Security Analyse en Threat Model

Dit is waar het interessant wordt. Laten we eerlijk zijn over de risico’s.

Platform Security Issues

Een Mac Studio als inference server heeft fundamentele beperkingen:

Conclusie: Een Mac Studio is ongeschikt voor omgevingen met strikte compliance eisen (ISO27001 Annex A, NIS2, SOC2). Voor homelab en development is het acceptabel.

LLM-Specifieke Risico’s

Threat Model

Conclusies en Aanbevelingen

Is een lokale LLM bruikbaar voor Kubernetes diagnose?

Ja, onder voorwaarden.

Het kan:

• Standaard issues correct identificeren
• Bruikbare remediatie suggesties geven
• Security problemen detecteren
• Dit alles zonder data je netwerk te verlaten

Het kan niet:

• Complexe, multi-component issues debuggen
• Betrouwbaar auto-remediation doen
• De context van je specifieke setup begrijpen
• Garanties geven over correctheid

Aanbevelingen per Use Case

Homelab / Learning

Aanbeveling: Ga ervoor.

Dit is een uitstekende manier om te leren over:

• LLM inference infrastructure
• Kubernetes troubleshooting patterns
• De grenzen van AI-assisted operations

Risico’s zijn acceptabel omdat de impact beperkt is.

Development / Staging

Aanbeveling: Bruikbaar met guardrails.

Implementeer:

• Output review voordat suggesties worden toegepast
• Logging van alle LLM interacties
• Geen auto-remediation, alleen diagnose

Productie (niet air-gapped)

Aanbeveling: Gebruik cloud APIs.

Waarom:

• Betere modellen (GPT-4, Claude)
• Lagere latency
• Geen hardware investering
• Professionele SLAs

De privacy trade-off is voor de meeste organisaties acceptabel als je geen PII in cluster metadata hebt.

Productie (air-gapped / sovereign)

Aanbeveling: Alleen als laatste optie.

Als je écht geen data naar buiten mag sturen:

• Overweeg kleinere, dedicated models
• Implementeer defense-in-depth voor de inference server
• Treat alle LLM output als untrusted
• Zorg voor extensive logging en audit trails
• Gebruik dit als assistentie, nooit als autoriteit

De Staat van Autonomous Cluster Management

Laat me direct zijn: “autonomous cluster management” met LLMs is op dit moment marketing, geen realiteit.

Wat we hebben is “assisted cluster management” — een AI die kan helpen bij diagnose en suggesties kan doen. Maar de human-in-the-loop is niet optioneel. Het is een vereiste.

De technologie is indrukwekkend. Een 70B model kan verrassend goede analyses produceren. Maar verrassend goed is niet goed genoeg voor autonome actie op productie infrastructure.

Mijn advies: gebruik deze tools als een slimme collega die je kunt raadplegen. Niet als een vervanger voor je eigen oordeelsvermogen.

Gerelateerde posts:

• Sovereign Infrastructure — Waarom ik alles self-host
• Why Privacy Matters — De context voor lokale LLMs