Kubernetes Edge Computing: Hybrid Cloud und IoT-Orchestrierung

TL;DR

K3s ist die bevorzugte Edge-Distribution -- unter 50 MB, ARM-Support, laeuft ab 512 MB RAM und eignet sich fuer tausende Edge-Standorte
KubeEdge erweitert Kubernetes um Cloud-Edge-Koordination mit Offline-Faehigkeit und Metadata-Sync ueber instabile Verbindungen
Akri entdeckt IoT-Geraete (USB, OPC-UA, IP-Kameras) automatisch und stellt sie als Kubernetes-Ressourcen bereit
Hub-Spoke-Architektur ist das Standard-Pattern: zentrales Management in der Cloud, lokale Ausfuehrung am Edge
Offline-Faehigkeit ist kein Nice-to-Have sondern Pflicht -- Edge-Nodes muessen ohne Cloud-Verbindung weiterarbeiten

Edge Computing mit Kubernetes: Warum jetzt?

Die Verarbeitung von Daten verlagert sich zunehmend an den Rand des Netzwerks. Gruende dafuer sind Latenz-Anforderungen unter 10 Millisekunden, Bandbreiten-Limitierungen bei Millionen von IoT-Sensoren und regulatorische Vorgaben zur lokalen Datenverarbeitung.

Kubernetes hat sich als Standard fuer Container-Orchestrierung etabliert. Die Frage ist nicht mehr ob, sondern wie Kubernetes am Edge funktioniert. Lightweight-Distributionen wie K3s machen es moeglich, denselben Orchestrierungs-Ansatz vom Rechenzentrum bis zum Shopfloor zu nutzen.

K3s: Kubernetes fuer den Edge

K3s von Rancher (SUSE) ist die meistverbreitete Kubernetes-Distribution fuer Edge-Umgebungen. Der Grund: Eine einzige Binary unter 50 MB, die auf ARM- und x86-Hardware laeuft.

K3s-Installation auf einem Edge-Node

# K3s Server (Control Plane) auf dem ersten Node
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - \
  --write-kubeconfig-mode 644 \
  --disable traefik \
  --disable servicelb \
  --node-label edge-location=warehouse-berlin \
  --node-label edge-tier=gateway

# Token fuer Worker-Nodes auslesen
cat /var/lib/rancher/k3s/server/node-token

# K3s Agent (Worker) auf weiteren Edge-Nodes
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="agent" sh -s - \
  --server https://edge-server-01:6443 \
  --token YOUR_NODE_TOKEN \
  --node-label edge-location=warehouse-berlin \
  --node-label edge-tier=compute

K3s fuer ressourcenbeschraenkte Hardware

# k3s-config.yaml fuer Minimal-Setup (Raspberry Pi, ARM-Geraete)
write-kubeconfig-mode: "0644"
disable:
  - traefik
  - servicelb
  - metrics-server
kubelet-arg:
  - "max-pods=30"
  - "eviction-hard=memory.available\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\<100Mi"
  - "system-reserved=cpu=200m,memory=256Mi"
  - "kube-reserved=cpu=100m,memory=128Mi"
kube-controller-manager-arg:
  - "node-monitor-period=10s"
  - "node-monitor-grace-period=40s"

# K3s mit Konfigurationsdatei starten
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - \
  --config /etc/rancher/k3s/config.yaml

Persistent Storage am Edge mit Local Path

# Local-Path-StorageClass (in K3s standardmaessig enthalten)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: edge-data
  namespace: edge-apps
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 10Gi

KubeEdge: Cloud-Edge-Koordination

KubeEdge ist ein CNCF-Projekt, das Kubernetes um Edge-spezifische Funktionen erweitert. Anders als K3s ist KubeEdge kein eigenstaendiger Cluster, sondern eine Erweiterung eines bestehenden Cloud-Clusters.

Architektur

KubeEdge besteht aus zwei Komponenten:

CloudCore laeuft im zentralen Kubernetes-Cluster und verwaltet Edge-Nodes
EdgeCore laeuft auf jedem Edge-Node und fuehrt Workloads lokal aus

CloudCore installieren

# KubeEdge CloudCore per Helm auf dem zentralen Cluster
helm repo add kubeedge https://kubeedge.io/charts
helm repo update

helm install cloudcore kubeedge/cloudcore \
  --namespace kubeedge \
  --create-namespace \
  --set cloudCore.modules.cloudHub.advertiseAddress="{CLOUD_IP}" \
  --set cloudCore.modules.cloudHub.nodeLimit=1000

EdgeCore auf Edge-Nodes deployen

# keadm auf dem Edge-Node installieren
curl -LO https://github.com/kubeedge/kubeedge/releases/download/v1.18.0/keadm-v1.18.0-linux-amd64.tar.gz
tar xzf keadm-v1.18.0-linux-amd64.tar.gz

# Edge-Node mit dem Cloud-Cluster verbinden
keadm join \
  --cloudcore-ipport=CLOUD_IP:10000 \
  --token=YOUR_TOKEN \
  --kubeedge-version=1.18.0 \
  --edgenode-name=edge-berlin-01 \
  --remote-runtime-endpoint=unix:///run/containerd/containerd.sock

Offline-Faehigkeit mit KubeEdge

KubeEdge speichert den gewuenschten Zustand lokal in einer SQLite-Datenbank. Wenn die Cloud-Verbindung abbricht, laufen Edge-Workloads weiter und Aenderungen werden nach Reconnect synchronisiert:

# DeviceModel fuer OPC-UA-Sensor (KubeEdge CRD)
apiVersion: devices.kubeedge.io/v1beta1
kind: DeviceModel
metadata:
  name: temperature-sensor
  namespace: edge-devices
spec:
  properties:
    - name: temperature
      description: Aktuelle Temperatur in Celsius
      type:
        float:
          accessMode: ReadOnly
          maximum: 150
          minimum: -40
          unit: Celsius
    - name: humidity
      description: Relative Luftfeuchtigkeit
      type:
        float:
          accessMode: ReadOnly
          maximum: 100
          minimum: 0
          unit: Percent

# DeviceInstance -- konkreter Sensor am Edge
apiVersion: devices.kubeedge.io/v1beta1
kind: Device
metadata:
  name: temp-sensor-hall-a1
  namespace: edge-devices
spec:
  deviceModelRef:
    name: temperature-sensor
  nodeName: edge-berlin-01
  protocol:
    opcua:
      url: opc.tcp://192.168.1.50:4840
      securityPolicy: None
      securityMode: None
  propertyVisitors:
    - propertyName: temperature
      opcua:
        nodeID: "ns=2;s=Temperature"
        browseName: Temperature
    - propertyName: humidity
      opcua:
        nodeID: "ns=2;s=Humidity"
        browseName: Humidity

Akri: IoT-Geraete automatisch entdecken

Akri (A Kubernetes Resource Interface) ist ein CNCF-Sandbox-Projekt, das IoT-Geraete automatisch erkennt und als Kubernetes-Ressourcen bereitstellt.

Akri installieren

helm repo add akri-helm-charts https://project-akri.github.io/akri/
helm repo update

helm install akri akri-helm-charts/akri \
  --namespace akri \
  --create-namespace \
  --set agent.enabled=true \
  --set kubeconfig.enabled=true

USB-Geraete entdecken

# Akri Configuration fuer USB-Kameras
apiVersion: akri.sh/v0
kind: Configuration
metadata:
  name: usb-camera-discovery
  namespace: akri
spec:
  discoveryHandler:
    name: udev
    discoveryDetails: |
      udevRules:
        - 'SUBSYSTEM=="video4linux"'
  brokerProperties:
    CAMERA_RESOLUTION: "1920x1080"
    CAMERA_FPS: "30"
  brokerSpec:
    brokerPodSpec:
      containers:
        - name: camera-broker
          image: ghcr.io/project-akri/akri/udev-video-broker:latest
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
  instanceServiceSpec:
    type: ClusterIP
    ports:
      - name: grpc
        port: 8083
        targetPort: 8083
  configurationServiceSpec:
    type: ClusterIP
    ports:
      - name: grpc
        port: 8083
        targetPort: 8083
  capacity: 1

Akri erstellt automatisch eine Kubernetes-Instance pro entdecktem Geraet und startet einen Broker-Pod, der Zugriff auf das Geraet bereitstellt.

Architektur-Patterns fuer Edge Computing

Hub-Spoke-Architektur

Das gaengigste Pattern: Ein zentraler Hub-Cluster verwaltet viele Edge-Spokes.

Hub-Spoke Architecture
+------------------+
|   Cloud / Hub    |
|   (Management)   |
|                  |
|  Fleet Manager   |
|  GitOps Server   |
|  Central Monitor |
+--------+---------+
         |
    +----+----+----+----+
    |         |         |
+---v---+ +---v---+ +---v---+
| Edge  | | Edge  | | Edge  |
| Site  | | Site  | | Site  |
| Berlin| |Hamburg| |Munich |
+-------+ +-------+ +-------+

Fleet-Management mit GitOps

# Fleet-Bundle fuer Edge-Standorte (Rancher Fleet)
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: edge-applications
  namespace: fleet-default
spec:
  repo: https://github.com/company/edge-apps
  branch: main
  paths:
    - base/
    - overlays/production/
  targets:
    - name: all-warehouses
      clusterSelector:
        matchLabels:
          location-type: warehouse
    - name: berlin-only
      clusterSelector:
        matchLabels:
          location: berlin
      paths:
        - overlays/berlin/

# Kustomize Overlay fuer Standort-spezifische Konfiguration
# overlays/berlin/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patchesStrategicMerge:
  - replicas-patch.yaml
  - config-patch.yaml

Netzwerk-Herausforderungen am Edge

Intermittierende Konnektivitaet

Edge-Standorte haben oft instabile Netzwerkverbindungen. Die Architektur muss damit umgehen:

# K3s Agent mit erhoehter Toleranz fuer Netzwerk-Ausfaelle
apiVersion: v1
kind: ConfigMap
metadata:
  name: k3s-agent-config
data:
  config.yaml: |
    kubelet-arg:
      - "node-status-update-frequency=20s"
    kube-proxy-arg:
      - "conntrack-max-per-core=0"

# Pod mit Offline-Caching-Strategie
apiVersion: apps/v1
kind: Deployment
metadata:
  name: edge-data-collector
  namespace: edge-apps
spec:
  replicas: 1
  selector:
    matchLabels:
      app: data-collector
  template:
    metadata:
      labels:
        app: data-collector
    spec:
      containers:
        - name: collector
          image: edge-collector:v2.0.0
          env:
            - name: OFFLINE_BUFFER_SIZE_MB
              value: "500"
            - name: SYNC_RETRY_INTERVAL
              value: "30s"
            - name: CLOUD_ENDPOINT
              value: "https://ingest.cloud.example.com"
          volumeMounts:
            - name: offline-buffer
              mountPath: /data/buffer
      volumes:
        - name: offline-buffer
          persistentVolumeClaim:
            claimName: edge-data

Praxis: Use Cases fuer Kubernetes Edge Computing

Einzelhandel und Point of Sale

# POS-System am Edge -- laeuft autark pro Filiale
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pos-backend
  namespace: retail
  labels:
    app: pos-backend
    edge-critical: "true"
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pos-backend
  template:
    metadata:
      labels:
        app: pos-backend
    spec:
      tolerations:
        - key: node.kubernetes.io/unreachable
          operator: Exists
          effect: NoExecute
          tolerationSeconds: 86400
      containers:
        - name: pos
          image: pos-backend:v4.2.0
          ports:
            - containerPort: 8080
          env:
            - name: OFFLINE_MODE
              value: "true"
            - name: LOCAL_DB
              value: "sqlite:///data/pos.db"
            - name: SYNC_ENDPOINT
              value: "https://central.example.com/api/sync"
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi
          volumeMounts:
            - name: pos-data
              mountPath: /data
      volumes:
        - name: pos-data
          persistentVolumeClaim:
            claimName: pos-storage

Fertigung und OPC-UA-Integration

# Manufacturing Edge -- OPC-UA Gateway
apiVersion: apps/v1
kind: Deployment
metadata:
  name: opcua-gateway
  namespace: manufacturing
spec:
  replicas: 1
  selector:
    matchLabels:
      app: opcua-gateway
  template:
    metadata:
      labels:
        app: opcua-gateway
    spec:
      hostNetwork: true
      containers:
        - name: gateway
          image: opcua-gateway:v1.5.0
          ports:
            - containerPort: 4840
              protocol: TCP
          env:
            - name: OPCUA_DISCOVERY_URL
              value: "opc.tcp://plc-controller:4840"
            - name: MQTT_BROKER
              value: "tcp://mosquitto.manufacturing:1883"
            - name: SAMPLING_INTERVAL_MS
              value: "100"
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

Logistik und Warehouse-Management

# Warehouse-Scanner-Integration
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: scanner-agent
  namespace: logistics
spec:
  selector:
    matchLabels:
      app: scanner-agent
  template:
    metadata:
      labels:
        app: scanner-agent
    spec:
      nodeSelector:
        edge-function: scanner-gateway
      containers:
        - name: agent
          image: scanner-agent:v3.1.0
          securityContext:
            privileged: true
          volumeMounts:
            - name: usb-devices
              mountPath: /dev/bus/usb
      volumes:
        - name: usb-devices
          hostPath:
            path: /dev/bus/usb

Security am Edge

Edge-Nodes stehen oft in physisch weniger gesicherten Umgebungen. Zusaetzliche Absicherung ist notwendig.

# NetworkPolicy -- Edge-Workloads duerfen nur mit definierten Endpoints kommunizieren
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: edge-egress-restriction
  namespace: edge-apps
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8
      ports:
        - protocol: TCP
          port: 443
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - protocol: UDP
          port: 53

# Pod Security Standard fuer Edge-Workloads
apiVersion: v1
kind: Namespace
metadata:
  name: edge-apps
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Fazit

Kubernetes edge computing bringt die Vorteile von Container-Orchestrierung an den Rand des Netzwerks. K3s senkt die Einstiegshuerde fuer Edge-Deployments radikal, KubeEdge loest die Cloud-Edge-Synchronisation, und Akri macht IoT-Geraete zu First-Class-Citizens im Kubernetes-Oekosystem.

Der pragmatische Einstieg: Mit K3s auf wenigen Edge-Nodes beginnen, GitOps-basiertes Fleet Management aufbauen und schrittweise KubeEdge oder Akri ergaenzen, wenn die Anforderungen wachsen.

Wenn Sie Unterstuetzung beim Aufbau Ihrer Edge-Kubernetes-Infrastruktur brauchen -- von der Architekturberatung ueber die Implementierung bis zum Betrieb -- kontaktieren Sie uns unter /kontakt fuer ein unverbindliches Gespraech.

Kubernetes Edge Computing: K3s, KubeEdge und Akri