Sådan udruller du kant-AI med Kubernetes og GPU'er

---

Hvorfor kant-AI med Kubernetes og GPU’er?

Kant-AI flytter inferens helt ud til der, hvor dataen opstår - i kameraet over produktionslinjen, på POS-terminalen i butikken eller i IoT-gatewayen på lygtepælen. Ved at bearbejde data lokalt får man millisekunders latenstid, hvilket er afgørende for real-time beslutninger og sikkerheds-kritiske scenarier. Samtidig bliver rådata i højere grad på stedet, hvilket styrker dataprivatliv og reducerer båndbredde-omkostninger. Endelig sikrer lokale modeller robusthed offline; hvis forbindelsen til cloud brydes, kører applikationen videre som vanligt.

Typiske anvendelser spænder bredt:

• Computer vision til kvalitetskontrol, trafikovervågning og adgangskontrol.
• Predictive maintenance baseret på vibrations- eller lydsensorer, der kræver høj samplingfrekvens.
• Retail med hyldescan, køtidsanalyse og personaliseret digital skiltning.
• Smart city-initiativer som intelligent affaldshåndtering og energistyring.

Fælles for disse brugsscenarier er krav om forudsigelig performance, lavt energiforbrug (ofte passivkølede enheder) og høj pålidelighed i ugæstfrie miljøer. Derudover forventes en fleksibel platform, som gør det let at opdatere modeller og sikkerhedspatche uden fysisk tilstedeværelse.

Her kommer kombinationen af Kubernetes og GPU-akceleration ind i billedet. Kubernetes giver en standardiseret orkestreringsplatform, så de samme CI/CD- og GitOps-workflows, der kører i datacentret, kan genbruges på kanten. Samtidig kan GPU’er - fra små NVIDIA Jetson-moduler til fuldfede datacenterkort - levere den nødvendige regnekraft pr. watt til både FP16 og INT8-inferens. Med device-plugins eksponeres GPU-ressourcer som first-class citizens i klyngen, og autoscaling eller node-pool-strategier kan sikre optimal udnyttelse og fallback ved hardwarefejl. Resultatet er en konsistent, automatiserbar og ressourceeffektiv platform, der gør det realistisk at rulle tusindvis af kant-noder ud uden at miste styring eller sikkerhed.

---

Referencearkitektur: fra hardware til klynge

Edge-hardware og software stack
De konkrete krav til kant-AI spænder fra få watt i en drone til fuld server-racks i en fabrik. Vælg derfor hardware efter workloads og miljø:

• NVIDIA Jetson Orin/NX - kompakt ARM-SOC med integreret GPU til lavt strømforbrug (<30 W) som f.eks. droner eller mobile robotter.
• x86-noder med datacenter-GPU’er - A2/L4 til let AI-inferens, T4/L40S til mellemklassen, eller L4/Tesla-klassen i micro-datacentre.

Driver- og runtime-laget skal matche HW’en:

• CUDA + cuDNN for kerne­ak­cel­er­a­tion.
• TensorRT for optimeret inferens (FP16/INT8).
• Kun én container runtime (containerd) reducerer overhead og sikrer kompatibilitet med GPU-plugins.
• Vælg en Kubernetes-distribution, der rammer det rette kompromis mellem footprint og features:

  Distribution	Footprint	Når du bør vælge den
  K3s	<100 MB	Indlejrede enheder og single-board-computere
  MicroK8s	Medium	Rapid prototyping og udvikler­venligt snap-flow
  Vanilla K8s	Stor	Edge-datacentre med krav om fuld upstream-kompatibilitet

Fra GPU-integration til driftssikkerhed
Efter basis-klyngen er på plads, kobles GPU’er, netværk og sikkerhedslag på for at opnå en robust, reproducerbar platform:

• NVIDIA Device Plugin - eksponerer GPU’er til Pods; GPU Operator automatiserer driver- + toolkit-installation, og MIG deler A100/Hopper-kort op i logiske slices.
• Netværk: Calico til policy-styret CNI, Flannel til ultra-let overlay og WireGuard til krypteret node-til-node-trafik.
• Storage: lokal SSD/NVMe via CSI host-path for lav latency, evt. distribueret OpenEBS når flere noder deles om modeller.
• Sikkerhed: RBAC + Pod Security Admission for least-privilege, AppArmor/SELinux til host-isolation, og node-hardening med sysctl-profiler.
• GitOps: Argo CD eller Flux synkroniserer YAML/Helm fra Git til klyngen, hvilket giver sporbar “single source of truth”, automatiske roll-backs og ensartede versioner på tværs af hundrede edge-sites.

Ved at kombinere disse byggesten opnås en referencearkitektur, hvor nye enheder kan bootes, joines til klyngen og modtage både GPU-drivere, inferens-containere og sikkerheds­politikker fuldautomatisk - klar til at køre AI-workloads med få minutters opsætning.

---

Fra model til inferens: udrulning og orkestrering

Rejsen fra trænet model til produktion starter med optimering: Når din datavidenskabsafdeling har færdiggjort træningen i PyTorch eller TensorFlow, konverteres modellen typisk til ONNX for maksimal portabilitet. Herfra kan du med TensorRT eller OpenVINO lave FP16- eller INT8-kvantisering, som reducerer både latenstid og strømforbrug på GPU’er som Jetson, L4 eller T4. Resultatet placeres i et versionsstyret artefakt-repository (fx Azure ML eller MLflow) og pakkes derefter i en slank container (distroless/ubi-minimal). Selve inferenslaget kører typisk i NVIDIA Triton - når du har brug for multi-model/batchering - eller i en letvægts OpenVINO-REST/gRPC-wrapper, hvis CPU-fallback er vigtigt. Alle konfigurationsfiler - fra config.pbtxt til Kubernetes Deployment - templatiseres med Helm eller Kustomize, så du kan genbruge samme chart på både test-, staging- og edge-klynger.

Skalerbar og begivenhedsdrevet inferens realiseres ved at sætte modellen bag Knative Revisioner eller et almindeligt Deployment koblet til KEDA. KEDA aflæser kø-længder i Kafka, MQTT eller en Prometheus-metric og justerer automatisk pod-antallet - helt ned til nul for at spare strøm, hvis der ikke er trafik. Trafikken selv kan komme via REST/gRPC, rå video-frames i RTSP, IoT-events i MQTT eller sensor-telegrammer i Kafka, som forwardes til Triton med minimal overhead. I brancher med flakket netforbindelse (industrianlæg, skibe, tog) indbygges et store-and-forward-lag: producer-side gemmer payload lokalt i en LightDB/SQLite-wal, og en sidecar uploader i batches, når linket er tilbage - uden at Kubernetes behøver at kende til det.

Til sidst skal livscyklussen på kanten håndteres. Hver ny modelversion får et semver-tag (fx v2.1.0-int8) i et privat OCI-registry, så du kan rulle ud med canary 10 %, måle KPI’er og rulle tilbage med et kubectl rollout undo, hvis præcisionen falder. For at minimere cold-start-tiden på små noder kan du aktivere Triton Model Cache eller pre-warmes med init-containers, der loader vægte til GPU-RAM før første request. Begræns samtidig resources.limits (memory, GPU-SM shares via MIG) for at undgå, at én glubsk model fortrænger de andre. Når modellen til sidst deprecateres, fjernes tags i registry via retention-politikker, og GitOps-værktøjet (Argo CD/Flux) synkroniserer automatisk manifests, så hele flåden af edge-noder forbliver ren og konsekvent.

---

Drift i stor skala: observability, sikkerhed og livscyklus

Observability og fejlfinding begynder med et metrics-first mindset. Installer Prometheus Operator og scrap både kube-state-metrics og node-exporter. Til GPU-telemetri aktiveres dcgm-exporter, som giver temperatur, power draw og SM-udnyttelse pr. kort eller MIG-slice. Visualisér alt i Grafana med færdige dashboards fra Grafana Labs GPU-mixin.

• Logs: Send container- og system-logs til Loki via Promtail; rul op på tværs af noder selv når edge-forbindelsen er flappende.
• Tracing: Brug OpenTelemetry Collector til at samle spans fra inferens­servicen; eksportér til Jaeger/Tempo for root-cause analyse af latenstid.
• Alerting: Opsæt Alertmanager regler for f.eks. “GPU power > 90 W i > 5 min” og “Pod restart loop”; send notifikationer via webhooks til Slack, Opsgenie eller SMS-gateway på stedet.

Skyd metrics tilbage til et centralt datacenter med remote write, men buffer lokalt i min.IO når uplink er nede - så mister du ingen datapunkter under fiberbrud.

Rulleplaner og flådestyring sikrer nul-nedetid og kontrolleret test af nye modeller. Kubernetes Deployment-strategier suppleres med Argo Rollouts eller Flagger for canary, blue/green og A/B eksperimenter. Typisk flow:

1. Push container med ny model-hash til registry.
2. ArgoCD synkroniserer manifest; Rollouts dirigerer 5 % af trafikken til “canary”.
3. Prometheus SLO’er (f.eks. p95 latency < 50 ms) evalueres automatisk. Består testen, øges trafikken trinvis til 100 %, ellers rulles tilbage.

Til OTA-opdateringer af selve edge-noderne anvendes KubeEdge eller OpenYurt med “cloud/edge dual” control-plane. Disse projekter håndterer:

• Batch-opdatering af hundreder af bokse via diff-pakker og torrents for at spare båndbredde.
• Node autonomy: Pods fortsætter lokalt under control-plane udfald.
• DeviceTwin-API til at skubbe firmware patches og hente sensordata i én kanal.

Forsvar i dybden kræver supply-chain sikkerhed fra build til runtime.

• Image signering: Byg med ko/BuildKit, signer med cosign sign --key=kms://. Kør kyverno verifyImages som admission-kontrol - unsigned images nægtes.
• SBOM & attestation: Generér SBOM med syft, attach som OCI artefakt; valider med in-toto policies.
• Hardware-root: Udnyt TPM 2.0 til Secure Boot & measured boot, så kun verificerede kernel- images startes.
• Netværkspolitikker: Med Calico defineres NetworkPolicy der kun tillader egress til API-gateway og NTP; inferens-pods kan ikke “phone home”.
• Runtime beskyttelse: Aktivér AppArmor/SELinux profiler samt GPU-isolering via nvidia-container-toolkit --no-new-privileges.

Sådan minimeres både angrebsflade og supply-chain risici i et distribueret setup, hvor fysisk sikkerhed ofte er lav.

Omkostninger, energi og livscyklus knyttes tæt til business-case og ESG-krav:

Disciplin	Værktøj	Best practice
Energimåling	DCGM, IPMI	Auto-skaler ned når GPU-util < 30 %; sæt application clocks lavere om natten.
Backup/rollback	Velero, Restic	Tag etcd-snapshots + persistente volumener; re-seed clusters via GitOps repo.
Compliance	OPA Gatekeeper	Policies for data residency - “No PVC in US region for EU PII”.
Kapacitetsplan	Goldilocks, KEDA	Rightsize pod-requests; scale to zero ved inaktivitet.

Afslut livscyklussen med e-waste håndtering: frakobl GPU’er, wipe diske via nvme sanitize, og genanvend køleprofiler i nye deployments. Resultatet er en robust, sikker og økonomisk bæredygtig kant-AI platform, der kan vokse fra første POC til global flåde uden at knække budget eller compliance-ramme.