--- title: "Edge- und Hybrid-Kubernetes für verteilte Standorte | SKAFFON" description: "Kubernetes an Filialen, Werken und Lagern: Flottenmanagement mit Talos, Omni oder K3s, GitOps und Offline-Betrieb. Mit WAN-Ausfall-Tabelle." url: https://skaffon.de/infrastruktur/edge-hybrid-kubernetes/ --- 1. [Startseite](/) 2. [Infrastruktur](/infrastruktur/) 3. Edge- und Hybrid-Kubernetes für verteilte Standorte 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. [Standorte beschreiben](/projekt-anfragen/) [Zur Ausfall-Tabelle](/infrastruktur/edge-hybrid-kubernetes/#wan-ausfall) - Flottenmodell: Talos + Omni, K3s + GitOps oder STACKIT Edge Cloud - Offline-Verhalten je Komponente festgelegt - Rollout in Wellen, Pilotstandorte zuerst Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 ![Weite Produktionshalle mit orangefarbenen Stahlstützen und Maschinen, Beispiel für einen Werksstandort](/_astro/produktionshalle-orange-stuetzen.CkuS8-eB_jWV2J.jpg) Ausgangslage ## 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. ![Blick in eine Lagerhalle mit Hochregalen und palettierter Ware, Beispiel für einen Standort mit eigener Technik](/_astro/lagerhalle-hochregale.DBvbKu4p_MsE73.jpg) Flottenmodell ## 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? __Drei Wege, eine Standort-Flotte zu betreiben, im Vergleich__ | 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](/infrastruktur/talos-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](https://docs.siderolabs.com/omni/overview/what-is-omni.md), zu K3s aus der [K3s-Dokumentation](https://docs.k3s.io/architecture). Anbieterdienst ## 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](https://docs.stackit.cloud/products/runtime/edge-cloud/basics/features-and-benefits/), 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](https://docs.stackit.cloud/products/runtime/edge-cloud/faq/)). Die Verantwortungsteilung beschreibt STACKIT im [Shared-Responsibility-Modell](https://docs.stackit.cloud/products/runtime/edge-cloud/basics/shared-responsibility/). Ob Edge Cloud für Ihr Vorhaben passt, prüfen wir gegen die aktuelle Dokumentation, bevor wir es empfehlen. Zum Anbieter allgemein: [STACKIT-Beratung](/stackit/). Zielbild ## Zentrale steuert, Standorte laufen allein weiter Git, Flottenverwaltung und Registry liegen in der Zentrale; jeder Standort-Cluster arbeitet bei WAN-Ausfall lokal weiter. Bausteine ## 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](https://docs.k3s.io/datastore/ha-embedded)). 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](https://docs.siderolabs.com/omni/cluster-management/upgrading-clusters.md)). - ### GitOps für Workloads Argo CD ApplicationSets können über Cluster-Generatoren Anwendungen für alle registrierten Cluster erzeugen ([Argo CD: ApplicationSet](https://argo-cd.readthedocs.io/en/stable/operator-manual/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](/leistungen/gitops-argocd/). Netz 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](https://docs.siderolabs.com/omni/cluster-management/create-a-hybrid-cluster.md)). Bei K3s lässt sich der Flannel-WireGuard-Modus nutzen; die nötigen Ports listet die [K3s-Anforderungsseite](https://docs.k3s.io/installation/requirements). 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](https://docs.k3s.io/installation/airgap)); bei Talos lassen sich Registry-Mirror und Image-Cache konfigurieren. Zentral steht Harbor, siehe [Air-Gapped Kubernetes](/infrastruktur/air-gapped-kubernetes/). ![Nahaufnahme von Glasfaser-Patchkabeln, die in Ports von Netzwerk- und Serverhardware in einem Rack gesteckt sind](/_astro/glasfaser-patchkabel-serverrack.Gl43myJ8_GOUL0.jpg) Offline-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. __Verhalten je Komponente bei WAN-Ausfall und was wir festlegen__ | 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](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)) | 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 | Projektablauf ## Vom Standortinventar zum Betrieb in Wellen 1. 01 ### Bestandsaufnahme der Standorte Anzahl, Hardware, Netzanbindung (Bandbreite, Verfügbarkeit), Stromversorgung, vor Ort verfügbare Personen, Anwendungen und deren Anforderungen. 2. 02 ### Flottenmodell wählen Anhand der Entscheidungstabelle und Ihrer Vorgaben. 3. 03 ### Referenzstandort bauen Ein Standort-Template mit Image, Konfiguration, GitOps-Anbindung und Beobachtbarkeit. 4. 04 ### Pilot mit absichtlicher Störung Wenige echte Standorte, einschließlich einer absichtlichen Leitungs- und Knotenstörung. 5. 05 ### Rollout in Wellen Standortbetreuer bekommen eine kurze Anleitung („Gerät anschließen, Image booten“); die Registrierung läuft automatisiert. 6. 06 ### Betrieb Updates in Wellen, Zertifikats- und Hardware-Lebenszyklus, Alarmierung. Auf Wunsch durch SKAFFON im Rahmen von [Managed Kubernetes](/managed-services/managed-kubernetes/); Betrieb und Support bieten wir rund um die Uhr (24/7) an, die Reaktionszeiten je Prioritätsstufe stehen unter [Managed Services](/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 Security](/cybersecurity/cloud-security/) Ihr 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 Passung ## 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](/leistungen/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](/infrastruktur/). [Projekt anfragen](/projekt-anfragen/)