Edge-Computing-Patterns mit k3s: Multi-Cluster-Management, Offline-First-Deployments und Observability im großen Maßstab

k3s Disaster Recovery Testing and Edge Patterns

Comprehensive DR testing and edge-specific patterns for k3s — failover validation, scheduled snapshots, multi-cluster recovery, and RPO/RTO planning.

k3s ist für Edge-Computing-Szenarien optimiert, in denen hunderte oder tausende kleine Kubernetes-Cluster an verteilten Standorten bereitgestellt und verwaltet werden müssen. Dieser Artikel untersucht bewährte Muster für das Multi-Cluster-Management, Offline-First-Deployments und Observability in großem Maßstab mit k3s.

Multi-Cluster-Management in großem Maßstab

Die Verwaltung verteilter Edge-Cluster erfordert hierarchische Muster, GitOps-Workflows und zentralisierte Control Planes, die auf tausende Cluster skalieren können.

Rancher Fleet für 10.000+ Cluster

Rancher Fleet ist ein GitOps-Tool für das Multi-Cluster-Management, das für Kubernetes in großem Maßstab entwickelt wurde. Es folgt einem hierarchischen Control-Plane-Modell:

Central Cluster (Rancher + Fleet)
    ↓ GitOps repositories
    ↓
Regional Clusters (Hub clusters)
    ↓ Fleet agents
    ↓
Edge Clusters (Leaf nodes)

Hauptfunktionen:

• Deklaratives GitOps: Deployment auf tausende Cluster über Git-Repositories
• Hierarchische Architektur: Topologie von Central → Regional → Edge
• Gezielte Deployments: Deployment auf Teilmengen mittels Cluster-Selektoren, Labels und Gruppen
• Rollout-Strategien: Canary, Blue-Green und phasenweise Rollouts
• Ressourcenoptimierung: Ein einziger Agent pro Cluster (~50 MB Speicherbedarf)
• Offline-Unterstützung: Bündelung von Manifesten und Artefakten für Airgap-Deployments

Fleet CLI Grundlagen:

# Register a downstream cluster
fleetctl login https://fleet.example.com
fleetctl cluster register --name store-001 --labels region=us-west,zone=store

# Create a GitRepo resource
fleetctl gitrepo create \
  --name my-app \
  --repo https://github.com/org/manifests \
  --paths ./clusters/production \
  --targets "clusterSelectors.matchLabels.region=us-west"

# Trigger rollout
fleetctl gitrepo update my-app --force

GitOps-Muster für die Edge

GitOps ist für Edge-Deployments essenziell, da es Folgendes bietet:

1. Audit Trail: Jede Änderung wird in Git aufgezeichnet
2. Offline-Resilienz: Cluster können auch ohne zentrale Konnektivität weiterarbeiten
3. Rollback: Rückgängigmachen durch einen Commit in Git
4. Multi-Tenancy: Verschiedene Teams verwalten unterschiedliche Manifeste

Beispiel für eine GitRepo-Ressource:

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: retail-app
  namespace: fleet-default
spec:
  repo: https://github.com/retail/edge-manifests
  branch: main
  paths:
    - ./clusters/production
  targets:
    - clusterSelector:
        matchLabels:
          region: us-west
          site-type: retail-store
  revisionHistoryLimit: 10

Hierarchische Cluster-Architektur

Verwenden Sie für verteilte Edge-Standorte eine 3-stufige Hierarchie:

Vorteile regionaler Cluster:

• Caching-Proxy: Eine Harbor-Registry cached Images für Edge-Standorte
• Failover-Hub: Ein regionaler Cluster kann als Fleet-Hub dienen, falls die zentrale Instanz nicht verfügbar ist
• Bandbreitenoptimierung: Regionale Cluster filtern und aggregieren Telemetriedaten
• Lokale Observability: Regionale Grafana-Dashboards für eine schnelle Reaktion auf Vorfälle

Fallstudie: 500+ Einzelhandelsgeschäfte

Eine nationale Einzelhandelskette hat k3s in über 500 Filialen mithilfe von Rancher Fleet implementiert:

Herausforderungen:

• Deployment dauerte 3–5 Tage pro Geschäft (manuelle Vor-Ort-Besuche)
• Configuration Drift zwischen den Standorten
• Keine zentralisierte Sichtbarkeit
• Firmware-Updates erforderten physische Besuche

Lösung:

Central Rancher (k3s)
  ↓ GitOps manifests
  ↓ Fleet agents
  ↓
500+ Store k3s clusters (Raspberry Pi 4 + industrial chassis)

Ergebnisse:

• Deployment-Zeit: Reduzierung von Tagen auf weniger als eine Stunde (Remote-Provisioning)
• Fehlerrate: 90 % Reduzierung der Deployment-Fehler
• Sichtbarkeit: Echtzeit-Dashboards, die alle 500+ Cluster anzeigen
• Updates: Firmware- und App-Updates werden innerhalb von Minuten flächendeckend ausgerollt
• Hardware: Raspberry Pi 4 (8GB) mit maßgeschneidertem Industriegehäuse
• Kosten: ~$300 pro Store im Vergleich zu$2.000+ bei der vorherigen Lösung

Fleet-Manifest für Einzelhandelsgeschäfte:

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: retail-store
spec:
  repo: https://github.com/retail/store-manifests
  paths:
    - ./clusters/production
  targets:
    - clusterSelector:
        matchLabels:
          environment: production
          store-type: retail
  helm:
    releaseName: pos-system
    chart: ./charts/pos-system
    valuesFiles:
      - ./clusters/production/values/store-default.yaml

Offline-First Deployments

Edge-Standorte verfügen oft über eine unzuverlässige oder gar keine Verbindung. Offline-First-Patterns stellen sicher, dass Cluster booten, aktualisieren und betreiben können, ohne auf einen zentralen Zugriff angewiesen zu sein.

Airgap-Installation

k3s unterstützt die Airgap-Installation über ein gebündeltes Images-Archiv:

Schritt 1: Airgap-Bundle auf einer verbundenen Maschine herunterladen

# Download k3s binary and airgap images
wget https://github.com/k3s-io/k3s/releases/download/v1.30.2/k3s-airgap-images-amd64.tar.gz
wget https://github.com/k3s-io/k3s/releases/download/v1.30.2/k3s

# Copy to airgap media
cp k3s k3s-airgap-images-amd64.tar.gz /media/usb/

Schritt 2: Auf die Airgap-Maschine übertragen und installieren

# Import images
sudo mkdir -p /var/lib/rancher/k3s/agent/images/
sudo cp /media/usb/k3s-airgap-images-amd64.tar.gz /var/lib/rancher/k3s/agent/images/
sudo chmod 644 /var/lib/rancher/k3s/agent/images/*.tar.gz

# Install k3s
sudo install /media/usb/k3s /usr/local/bin/

# Start k3s
sudo INSTALL_K3S_SKIP_DOWNLOAD=true \
  INSTALL_K3S_SKIP_ENABLE=true \
  INSTALL_K3S_EXEC="server --no-deploy traefik" \
  /usr/local/bin/k3s

Schritt 3: Airgap-Installation überprüfen

# Check images are imported
sudo crictl images | grep -E "rancher|pause"

# Verify cluster
kubectl get nodes

Private Registry für Airgap

Implementieren Sie an jedem Edge-Standort eine private Container-Registry, um Images zu cachen:

Harbor-Deployment via Helm:

# harbor-values.yaml
expose:
  type: nodePort
  tls:
    enabled: false
persistence:
  enabled: true
  resourcePolicy: "keep"
  persistentVolumeClaim:
    registry:
      storageClass: "local-path"
portal:
  replicas: 1
registry:
  replicas: 1
  storage:
    type: filesystem

# Install Harbor
helm repo add harbor https://helm.goharbor.io
helm install harbor harbor/harbor -f harbor-values.yaml -n harbor --create-namespace

# Push images to local registry
docker tag rancher/local-path-provisioner:v0.0.26 harbor.local/rancher/local-path-provisioner:v0.0.26
docker push harbor.local/rancher/local-path-provisioner:v0.0.26

k3s so konfigurieren, dass die lokale Registry verwendet wird:

# Create registry mirror config
sudo mkdir -p /etc/rancher/k3s
cat <<EOF | sudo tee /etc/rancher/k3s/registries.yaml
mirrors:
  docker.io:
    endpoint:
- http://harbor.local/v2/registry/mirrors/docker.io
  registry.k8s.io:
    endpoint:
    - http://harbor.local/v2/registry/mirrors/registry.k8s.io
EOF

# k3s neu starten
sudo systemctl restart k3s

Embedded Registry Mirror with Spegel

Spegel is a P2P registry mirror that runs on each k3s node:

# spegel-helm-values.yaml
image:
  repository: ghcr.io/xenitab/spegel
  tag: v0.0.18
registry:
  mirror:
    enabled: true
    interval: 10m
  registries:
    - https://registry.k8s.io
    - https://docker.io
podMonitor:
  enabled: true

# Spegel installieren
helm repo add spegel https://charts.spegel.io
helm install spegel spegel/spegel -f spegel-helm-values.yaml -n kube-system

How Spegel works:

1. P2P distribution: Images are distributed peer-to-peer across nodes
2. Local cache: Each node caches images locally
3. Registry proxy: Spegel acts as a registry proxy, pulling from peers first
4. Offline resilience: Once images are cached, no external connectivity needed

Benefits:

• No external registry required after initial boot
• Faster image pulls (local LAN vs internet)
• Bandwidth savings (each image downloaded once per cluster)
• Offline operation (clusters continue operating without internet)

Observability at Scale

Observability across thousands of edge clusters requires bandwidth-efficient patterns, hierarchical aggregation, and resilient telemetry collection.

Prometheus + node-exporter + Grafana

Standard monitoring stack adapted for edge:

# prometheus-operator-values.yaml
prometheus:
  prometheusSpec:
    retention: 15d
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: local-path
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 10Gi
    resources:
      requests:
        cpu: 200m
        memory: 512Mi
      limits:
        cpu: 500m
        memory: 1Gi

nodeExporter:
  enabled: true

grafana:
  enabled: true
  persistence:
    enabled: true
    size: 5Gi
    storageClassName: local-path

Edge Prometheus configurations:

• Reduced retention: 15-30 days (vs 90+ days in central)
• Resource limits: ~500MB RAM, ~500m CPU per cluster
• Local-path storage: No distributed storage required
• Consul federation: Optional federation to regional Prometheus

Loki + Fluent Bit for Log Aggregation

Loki provides cost-effective log aggregation for edge:

# loki-stack-values.yaml
loki:
  persistence:
    enabled: true
    storageClassName: local-path
    size: 10Gi
  config:
    limits_config:
      retention_period: 168h # 7 Tage
    ingester:
      lifecycler:
        ring:
          kvstore:
            store: inmemory

fluent-bit:
  enabled: true
  config:
service: |
      [SERVICE]
          Flush        1
          Daemon       Off
          Log_Level    info
          Parsers_File parsers.conf
    inputs: |
      [INPUT]
          Name         tail
          Path         /var/log/containers/*.log
          Parser       docker
          Tag          kube.*
          Mem_Buf_Limit 5MB
          Skip_Long_Lines On
    filters: |
      [FILTER]
          Name                kubernetes
          Match               kube.*
          Kube_URL            https://kubernetes.default.svc:443
          Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
          Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
          Kube_Tag_Prefix     kube.var.log.containers.
          Merge_Log           On
          Merge_Log_Key       log_processed
          K8S-Logging.Parser  On
          K8S-Logging.Exclude On
    outputs: |
      [OUTPUT]
          Name            loki
          Match           *
          Host            loki.monitoring.svc
          Port            3100
          Labels          job=fluent-bit,cluster=store-001,region=us-west
          Line_Format     json

Loki optimization for edge:

• Short retention: 7 days (vs 30+ days in central)
• Local storage: No external database required
• Tail-based sampling: Filter logs before shipping
• Structured logging: JSON format for efficient querying

Thanos/Cortex for Long-Term Storage

For long-term metrics retention and cross-cluster analytics:

# thanos-values.yaml
query:
  replicas: 1
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 256Mi

queryFrontend:
  replicas: 1
  resources:
    requests:
      cpu: 50m
      memory: 64Mi
    limits:
      cpu: 100m
      memory: 128Mi

store:
  replicas: 1
  persistence:
    storageClass: local-path
    size: 50Gi
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 200m
      memory: 512Mi

objstore:
  type: s3
  config:
    endpoint: minio.storage.svc.cluster.local
    bucket: thanos
    access_key: ${THANOS_S3_ACCESS_KEY}
    secret_key: ${THANOS_S3_SECRET_KEY}

Thanos remote_write from edge Prometheus:

# remote_write Konfiguration
remote_write:
  - url: http://thanos-receive.thanos.svc.cluster.local:19291/api/v1/receive
    queue_config:
      capacity: 10000
      max_shards: 10
      min_shards: 1
      max_samples_per_send: 1000
      batch_send_deadline: 5s
      min_backoff: 30ms
      max_backoff: 100ms
      retry_on_http_429: true
    write_relabel_configs:
      - source_labels: [__name__]
        regex: "go_.*|process_.*"
        action: drop # Metriken mit geringem Wert verwerfen

Bandwidth-Efficient Telemetry

Tail-based sampling (Loki):

# Fluent Bit Filter für Sampling
[FILTER]
    Name                sample
Match               kube.*
    Rate                10    # Behalte 10% der Logs
    Sample_Key          level
    Sample_Values       info,warn,error,critical

Metrics aggregation (Prometheus):

# Recording Rules für Edge-Aggregation
groups:
  - name: edge_aggregation
    interval: 30s
    rules:
      - record: cluster:node_cpu_usage:avg5m
        expr: avg(rate(node_cpu_seconds_total[5m])) by (cluster)
      - record: cluster:node_memory_usage:avg5m
        expr: avg(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) by (cluster)
      - record: cluster:container_memory_usage_bytes:sum
        expr: sum(container_memory_working_set_bytes) by (cluster, namespace)

Downsampling for long-term storage:

# Thanos Downsampling-Konfiguration
downsample:
  enable: true
  retention:
    raw: 30d
    five_minutes: 90d
    one_hour: 1y

File-Backed Queues for Outages

Use bbolt for reliable telemetry during outages:

[OUTPUT]
    Name            loki
    Match           *
    Host            loki.monitoring.svc
    Port            3100
    Labels          job=fluent-bit,cluster=store-001
    storage_path    /var/lib/fluent-bit
    storage_sync    normal
    storage_checksum off
    storage_max_backups 3
    storage_max_chunks_up 128
    storage_chunk_size 1M

How bbolt works:

1. Local queue: Logs buffered to local bbolt database
2. Retry on failure: Fluent Bit retries failed sends
3. No data loss: Survives network outages and pod restarts
4. Backpressure: Rate limits when remote endpoint is slow

Production Considerations

Network Topology

Design network topology for edge resilience:

Internet
  |
  ↓
[Zentrales Rechenzentrum]
  |                                   |
  ↓ (Glasfaser/VPN)                  ↓ (LTE/5G Backup)
[Regionaler Hub A]                 [Regionaler Hub B]
  |                                   |
  ↓ (lokale Glasfaser)               ↓ (lokale Glasfaser)
[Edge Stores]                      [Edge Stores]
  (Mesh P2P via Spegel)              (Mesh P2P via Spegel)

Best practices:

• Dual uplinks: Primary fiber + LTE/5G backup
• VPN tunnels: WireGuard or IPsec for secure communication
• Local DNS: CoreDNS with conditional forwarding for local services
• Time sync: Chrony for accurate time across edge sites

Resource Planning

Recommended hardware for k3s edge nodes:

k3s resource tuning:

# k3s Konfiguration für Edge
controller-args:
  - --disable=traefik
  - --disable=servicelb
  - --disable=metrics-server
  - --kubelet-arg=pod-max-pods=50
  - --kubelet-arg=cgroups-per-qos=true
  - --kubelet-arg=system-reserved=cpu=200m,memory=512Mi
  - --kubelet-arg=kube-reserved=cpu=200m,memory=512Mi

Security at the Edge

Security Hardening für Edge-Deployments:

1. Immutable Infrastructure: Kein SSH-Zugriff, nur Fleet Agent
2. Netzwerksegmentierung: VLANs oder Network Policies zur Isolation
3. Zertifikatsmanagement: Automatisierte Zertifikatsrotation via cert-manager
4. Image Scanning: Trivy Admission Controller
5. RBAC: Strikte rollenbasierte Zugriffskontrolle
6. Audit-Logging: Kubernetes Audit Log + zentralisiertes SIEM

Admission Controller für Image-Scanning:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: trivy-admission-controller
webhooks:
  - name: trivy.kb.io
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    clientConfig:
      service:
        name: trivy
        namespace: trivy-system
    admissionReviewVersions: ["v1"]
    sideEffects: None

Entscheidungsrahmen (Decision Framework)

Fazit

k3s bietet ein solides Fundament für Edge-Computing-Szenarien, aber erfolgreiche Deployments erfordern Patterns für:

1. Multi-Cluster-Management: Fleet für die GitOps-Steuerung über tausende von Clustern
2. Offline-first-Betrieb: Airgap-Installationen, private Registries und P2P-Mirrors
3. Observability in großem Maßstab: Bandbreiteneffiziente Telemetrie, hierarchische Aggregation und resiliente Datenerfassung

Die Kombination aus der GitOps-Control-Plane von Fleet, dem Registry-Caching von Harbor und der P2P-Distribution von Spegel schafft eine resiliente Edge-Computing-Plattform, die von einigen dutzend bis hin zu tausenden von Clustern skaliert und dabei die operative Einfachheit sowie die Offline-Resilienz beibehält.