Edge · Hybrid · Flottenbetrieb
Edge- und Hybrid-Kubernetes für verteilte Standorte
Viele kleine Kubernetes-Umgebungen in Filialen, Werken und Lagern, zentral gesteuert und mit klar festgelegtem Verhalten, wenn die Leitung ausfällt.
- Flottenmodell: Talos + Omni, K3s + GitOps oder STACKIT Edge Cloud
- Offline-Verhalten je Komponente festgelegt
- Rollout in Wellen, Pilotstandorte zuerst
01Ausgangslage
Viele Standorte, niemand vor Ort: was Edge vom Rechenzentrum trennt
SKAFFON plant und baut Kubernetes für verteilte Standorte: Filialen, Lager, Werke oder Außenstellen mit eigener kleiner Hardware, dazu Hybrid-Cluster, die Rechenzentrum, Cloud und Standorte verbinden. Gefragt sind Lösungen für IT-Leitungen, die viele kleine Umgebungen zentral steuern müssen und dabei mit unzuverlässigen Leitungen, wenig Platz und fehlender IT vor Ort rechnen.
Zwei Fragen trennen Edge vom Rechenzentrum: Was läuft weiter, wenn die Leitung ausfällt, und wie bleibt eine Flotte aktuell, ohne dass jemand hinfährt? Ein Rechenzentrums-Cluster nimmt stabile Netze, einen Hausmeister und ausreichend Hardware an. Am Standort gilt meist das Gegenteil.
- Das WAN ist unzuverlässig. Der Standort muss auch allein arbeiten können.
- Kein Personal vor Ort. Ein Knoten wird per Image neu aufgesetzt, nicht per SSH repariert. Das spricht für unveränderliche Betriebssysteme und deklarative Konfiguration.
- Kleine, heterogene Hardware. Ein Ein-Knoten-Cluster ist dort oft Realität.
- Die Zahl wächst. Zehn Standorte sind ein Projekt, zweihundert eine Flotte: Updates, Zertifikate und Konfigurationen brauchen Automatisierung und ein Rollout in Wellen.
02Flottenmodell
Talos und Omni, K3s mit GitOps oder STACKIT Edge Cloud
Der Entscheidungsbaum beginnt nicht bei der Technik, sondern bei drei Fragen: Wie viele Standorte? Gibt es Hardware-Vorgaben? Wer soll die Flottenverwaltung betreiben?
| Kriterium | Talos Linux + Omni | K3s + GitOps (z. B. Argo CD) | STACKIT Edge Cloud (falls verfügbar) |
|---|---|---|---|
| Was es ist | Unveränderliches Kubernetes-Betriebssystem, zentral verwaltet | Schlanke Kubernetes-Distribution auf einem Linux Ihrer Wahl | Verwaltetes Flottenmanagement des Anbieters, auf Talos aufgebaut |
| Knoten-Betriebssystem | Talos, ohne SSH, API-gesteuert | Ihr Linux; Pflege von Betriebssystem und Patches bleibt bei Ihnen | Talos |
| Zentrale Steuerung | Omni (kommerzielle Lizenz für Produktion, siehe Talos und Omni) | Git und GitOps-Controller; Betriebssystem separat (z. B. Konfigurationsmanagement) | Dienst von STACKIT |
| Verbindung zur Zentrale | Knoten bauen die Verbindung zu Omni auf (WireGuard) | Je nach GitOps-Modell: Zentrale zieht oder Standort zieht | Ausgehende HTTPS-Verbindung der Standorte |
| Offline-Betrieb des Standorts | Cluster läuft weiter, Verwaltung pausiert | Cluster läuft weiter | Cluster läuft weiter; Verwaltung benötigt Verbindung |
| Air-Gap | Möglich, mit eigener Omni-Installation | Möglich, K3s dokumentiert Air-Gap-Installation | Nicht vorgesehen: Anbieterdienst, siehe unten |
| Grenzen | Hardware muss von Talos unterstützt sein | Mehr eigene Betriebsarbeit am Knoten-Betriebssystem | Herstellerseitige Grenzen, siehe unten |
| Passt wenn | Viele Standorte, einheitlicher Lebenszyklus, Standard-Hardware | Sehr kleine oder spezielle Hardware, vorhandenes Linux-Know-how | Sie einen verwalteten Dienst eines europäischen Anbieters wollen |
Die Angaben zu Talos und Omni stammen aus der Omni-Dokumentation, zu K3s aus der K3s-Dokumentation.
03Anbieterdienst
STACKIT Edge Cloud ist nicht automatisch Air-Gapped
STACKIT Edge Cloud ist laut Anbieter eine SaaS-Plattform für zentrales Kubernetes-Management verteilter Standorte, aufgebaut auf Talos, mit ausgehendem, Push-basiertem HTTPS-Verkehr ohne eingehende Verbindungen (STACKIT: Features, Stand der Dokumentation 24.03.2026). Das macht sie für gesperrte Firewalls geeignet, aber nicht für abgeschottete Netze: Laut FAQ muss jeder Edge-Host eine ausgehende Verbindung zu stackit.cloud über TCP 443 aufbauen können, und Talos braucht Zugriff auf Container-Registries, es sei denn, ein interner Mirror ist konfiguriert.
Genannte Grenzen: ausgelegt und getestet für bis zu 1.000 EdgeCluster-Objekte je Instanz, keine Garantie für bestimmte Single-Board-Computer, kein Klonen von VMs oder Datenträgern (STACKIT Edge Cloud FAQ). Die Verantwortungsteilung beschreibt STACKIT im Shared-Responsibility-Modell. Ob Edge Cloud für Ihr Vorhaben passt, prüfen wir gegen die aktuelle Dokumentation, bevor wir es empfehlen. Zum Anbieter allgemein: STACKIT-Beratung.
04Zielbild
Zentrale steuert, Standorte laufen allein weiter
Git, Flottenverwaltung und Registry liegen in der Zentrale; jeder Standort-Cluster arbeitet bei WAN-Ausfall lokal weiter.
05Bausteine
Was ein Standort-Template enthält
-
Standort-Cluster
Ein Knoten (ohne Hochverfügbarkeit) oder drei Knoten (mit). Bei K3s mit eingebettetem etcd verlangt die Dokumentation eine ungerade Anzahl von mindestens drei Server-Knoten für Quorum; auf langsamen Datenträgern wie SD-Karten kann etcd Leistungsprobleme haben (K3s: HA Embedded etcd). Ein-Knoten-Standorte planen wir deshalb bewusst ohne Hochverfügbarkeit, mit schnellem Wiederaufbau aus Image und Git.
-
Flotten-Steuerung
Zentrale Definition von Cluster-Templates und Konfigurationspatches; Rollout in Wellen mit Pilotstandorten zuerst. Omni sperrt Knoten gezielt, um Änderungen zunächst auf wenigen Maschinen zu prüfen (Omni: Upgrade Clusters).
-
GitOps für Workloads
Argo CD ApplicationSets können über Cluster-Generatoren Anwendungen für alle registrierten Cluster erzeugen (Argo CD: ApplicationSet). Hinter NAT oder Firewalls entscheidet, wer die Verbindung aufbaut: Ein zentrales Argo CD muss die API der Standort-Cluster erreichen; sonst setzen wir Argo CD je Standort oder Region ein. Mehr unter GitOps mit Argo CD.
06Netz und Images
Verschlüsselte Tunnel und eine Registry am Standort
Zwischen Standort und Zentrale läuft WireGuard. Talos unterstützt WireGuard-Schnittstellen in der Maschinenkonfiguration, und Omni nutzt WireGuard für die Verwaltung. Für Hybrid-Cluster, deren Knoten in verschiedenen Netzen liegen, beschreibt Omni den Einsatz von KubeSpan, das zwischen allen Knoten verschlüsselte WireGuard-Tunnel aufbaut (Omni: Hybrid Cluster). Bei K3s lässt sich der Flannel-WireGuard-Modus nutzen; die nötigen Ports listet die K3s-Anforderungsseite.
Standorte holen Images nicht einzeln über die WAN-Leitung. K3s bietet eine eingebettete Registry-Spiegelung und dokumentiert Varianten für die Air-Gap-Installation (K3s: Air-Gap Install); bei Talos lassen sich Registry-Mirror und Image-Cache konfigurieren. Zentral steht Harbor, siehe Air-Gapped Kubernetes.
07Offline-Verhalten
Was am Standort weiterläuft, wenn das WAN ausfällt
Die Tabelle beschreibt das Verhalten, das wir mit Ihnen vor dem Rollout prüfen.
| Komponente | Verhalten bei WAN-Ausfall | Was wir prüfen und festlegen |
|---|---|---|
| Laufende Pods am Standort | Laufen weiter; der lokale Cluster braucht die Zentrale nicht | Lokale Abhängigkeiten der Anwendung (DNS, Identität, Datenbank) |
| Neue Deployments aus der Zentrale | Kommen nicht an | Wie lange ein Standort ohne Updates tolerierbar ist |
| Image-Pull eines neu gestarteten Pods | Scheitert, wenn das Image nicht lokal liegt | Image-Vorhaltung oder lokaler Cache, Pull-Richtlinien |
| Knotenausfall am Standort | Kubernetes versieht ausgefallene Knoten mit Taints; Pods bleiben standardmäßig noch 5 Minuten gebunden, bevor sie verdrängt werden; DaemonSet-Pods werden nicht verdrängt (Kubernetes: Taints und Tolerations) | tolerationSeconds je Workload, Wiederanlauf bei Einknoten-Standort |
| Verwaltung (Omni, Dienst, Git) | Nicht erreichbar; Cluster bleiben laut Omni-Dokumentation lauffähig | Notzugang (Break-glass) und dessen Test |
| Zertifikate | Ablaufdaten laufen weiter; ohne Verbindung keine Erneuerung durch die Zentrale | Laufzeiten und Erneuerungsstrategie |
| Zeit | Uhr driftet ohne Zeitquelle; TLS kann scheitern | Lokale NTP-Quelle |
| Monitoring | Metriken und Logs puffern oder fehlen | Lokale Alarmierung, Pufferung, Nachlieferung |
08Projektablauf
Vom Standortinventar zum Betrieb in Wellen
- 01
Bestandsaufnahme der Standorte
Anzahl, Hardware, Netzanbindung (Bandbreite, Verfügbarkeit), Stromversorgung, vor Ort verfügbare Personen, Anwendungen und deren Anforderungen.
- 02
Flottenmodell wählen
Anhand der Entscheidungstabelle und Ihrer Vorgaben.
- 03
Referenzstandort bauen
Ein Standort-Template mit Image, Konfiguration, GitOps-Anbindung und Beobachtbarkeit.
- 04
Pilot mit absichtlicher Störung
Wenige echte Standorte, einschließlich einer absichtlichen Leitungs- und Knotenstörung.
- 05
Rollout in Wellen
Standortbetreuer bekommen eine kurze Anleitung („Gerät anschließen, Image booten“); die Registrierung läuft automatisiert.
- 06
Betrieb
Updates in Wellen, Zertifikats- und Hardware-Lebenszyklus, Alarmierung. Auf Wunsch durch SKAFFON im Rahmen von Managed Kubernetes; Betrieb und Support bieten wir rund um die Uhr (24/7) an, die Reaktionszeiten je Prioritätsstufe stehen unter Managed Services und werden je Vertrag vereinbart. Ist vor Ort Hardware zu tauschen oder der Zugang eingeschränkt, legen wir im Vertrag fest, wer vor Ort handelt und wie Fernzugriff erfolgt.
Physische Sicherheit
Wir gehen davon aus, dass ein Gerät abhandenkommen kann
Standorte sind physisch schwerer zu schützen als Rechenzentren. Datenträger-Verschlüsselung, kurzlebige Zugangsdaten und die Möglichkeit, einen Standort zentral zu sperren, sind Teil des Entwurfs. Netzsegmentierung am Standort, Zugriffsmodell und Anbindung an Ihre Identität klären wir im Projekt.
Cloud Security09Ihr Beitrag
Was wir für den Start von Ihnen brauchen
- Standortliste mit Hardware, Anbindung und Ansprechpartnern
- Anforderungen der Anwendungen an Offline-Betrieb
- Entscheidung über das Lizenzmodell der Verwaltungsplattform
- Freigabe der Rollout-Wellen und Pilotstandorte
10Passung
Wann sich eine Edge-Flotte lohnt und wann eine normale Plattform genügt
Das spricht für Edge-Kubernetes
- Viele kleine Umgebungen müssen zentral gesteuert werden.
- Leitungen sind unzuverlässig, vor Ort gibt es keine IT.
- Der Standort muss bei WAN-Ausfall weiterarbeiten.
Das spricht dagegen
- Sie haben nur ein bis zwei Standorte mit stabiler Anbindung: dann genügt eine normale Kubernetes-Plattform, siehe Kubernetes-Beratung.
- Sie suchen Hardware-Logistik (Beschaffung, Versand, Installation vor Ort): das organisieren wir nicht.
- Sie benötigen ein Gerät, das Talos oder K3s nicht unterstützt.
Standorte, Hardware und Anbindung beschreiben
Schicken Sie uns Ihre Standortliste mit Hardware und Netzanbindung; wir schlagen ein Flottenmodell vor. Zurück zum Bereich: Infrastruktur.