Kubernetes am Edge mit GitOps: Wie ayedo eine verteilte IoT-Flotte von SSH-Deployments zu kontrollierten Rollouts geführt hat

Edge Computing ist für IoT, Industrie 4.0 und Smart-Grid-Szenarien kein Hype, sondern Betriebsrealität. Daten entstehen nicht im Rechenzentrum, sondern draußen: an Messpunkten, in Trafostationen, an Gateways in kommunalen Netzen oder in Industrieanlagen. Wer diese Daten zuverlässig in ein zentrales Datahub bringen will, muss die Software an hunderten Standorten betreiben – oft mit instabiler Konnektivität, begrenzten Wartungsfenstern und hohen Anforderungen an Verfügbarkeit und Integrität.

Genau hier zeigt Kubernetes seine Stärke: Nicht nur wegen Skalierbarkeit, sondern weil es ein deklaratives Betriebsmodell erzwingt, das sich auch auf verteilte Edge-Worker übertragen lässt. In Kombination mit ArgoCD als GitOps-Interface entsteht daraus ein Flottenbetrieb, der sich wie Cloud anfühlt – aber am Edge funktioniert.

In diesem Beitrag zeigen wir anhand eines anonymisierten Kundenprojekts, wie ayedo einen europäischen Anbieter von IoT- und IIoT-Lösungen dabei unterstützt hat, über 400 Edge Points of Presence (PoPs) von manuellen SSH/SFTP-Deployments auf eine Kubernetes-basierte Edge-Plattform umzustellen – reproduzierbar, versionssicher, auditierbar. Der Kunde bleibt anonym. Der Ansatz ist übertragbar.

Ausgangslage: 400 PoPs, wachsende Software – und Deployments wie vor zehn Jahren

Der Kunde entwickelt IoT- und IIoT-Lösungen für Smart City-, Smart Grid- und Smart Metering-Szenarien. Die Edge-Standorte erfassen Messwerte, führen Vorverarbeitung durch und übertragen Daten an zentrale Systeme. Die PoPs sind weit verteilt und häufig nur über 5G oder Richtfunk angebunden – also genau dort, wo „mal schnell draufgehen" im Zweifel nicht funktioniert.

Betrieblich war das Setup über Jahre gewachsen. Software wurde manuell verteilt, Updates wurden über SSH eingespielt, Artefakte per SFTP ausgerollt, Konfigurationen an einzelnen Standorten angepasst. Das ist für eine Handvoll Systeme machbar. Bei mehreren hundert PoPs wird es zum Engpass.

Denn manuelle Deployments sind nicht nur langsam. Sie erzeugen unweigerlich Inkonsistenzen. Ein Standort erhält ein Update später als der nächste. Eine Konfigurationsdatei wird „kurz" angepasst, aber nie zurück in einen Standard überführt. Ein Fix wird direkt am System gemacht, weil es schnell gehen muss. Über Zeit entsteht Configuration Drift – und Drift ist am Edge besonders teuer, weil jede Abweichung Debugging und Rollouts unvorhersehbar macht.

Das Team merkte die Folgen zuerst an der Planbarkeit. Wartungsfenster wurden schwieriger, weil nicht klar war, welche PoPs wirklich auf welchem Stand sind und welche Abhängigkeiten sich über die Jahre angesammelt haben. Neue Features erreichten die Flotte verzögert, weil jeder Rollout operativen Aufwand bedeutete. Sicherheitsupdates wurden zu einer logistischen Aufgabe – und genau das ist in kritischen Umfeldern ein Risiko, nicht nur eine Unbequemlichkeit.

Parallel wuchs das Engineering-Team. Damit kamen neue Anforderungen, die in „SSH-Realitäten" kaum sauber lösbar sind: Segmentierung von Zugriffsrechten, Conditional Access, klare Verantwortlichkeiten, Wissenstransfer ohne Heldentum. Erste Versuche, die Komplexität mit Nomad oder Docker Swarm zu reduzieren, brachten nicht den erhofften Durchbruch – weil das Kernproblem nicht „Orchestrator fehlt" war, sondern „Betriebsmodell ist nicht standardisiert".

Der Kern des Problems: Edge braucht deklarativen Zustand – nicht imperatives Basteln

Manuelle Deployments folgen einem imperativen Muster: „tu dies, tu das". Dieses Muster bricht am Edge aus zwei Gründen.

Der erste Grund ist Konnektivität. PoPs sind nicht dauerhaft stabil erreichbar. Ein Deployment, das mitten im Transfer abbricht, hinterlässt einen undefinierten Zustand. Das erhöht Drift und erzeugt einen operativen Rattenschwanz.

Der zweite Grund ist Skalierung. Selbst wenn jedes Deployment perfekt wäre: Wenn ein Team bei jedem Rollout hunderte Standorte anfassen muss, skaliert nicht die Plattform, sondern nur die Arbeitslast. Das führt zwangsläufig dazu, dass Updates verschleppt werden – und damit sowohl Innovation als auch Security leiden.

Die Lösung ist nicht „mehr Skripte", sondern ein System, das den gewünschten Zustand beschreibt und ihn kontinuierlich durchsetzt. Genau hier ist Kubernetes – richtig implementiert – ein sehr gutes Fundament. Und genau hier entfaltet GitOps mit ArgoCD seinen Wert: nicht als Tool, sondern als Steuerungsprinzip.

ayedos Ansatz: Edge-Flotte als GitOps-System – mit Kubernetes Distribution und zentralem Plattform-Backbone

Wir haben die Edge-Infrastruktur vollständig auf die ayedo Kubernetes Distribution migriert und die Flotte so organisiert, dass jeder PoP als eigenständiger Kubernetes-Node betrieben wird – zentral orchestriert und gemanagt über ArgoCD.

Das ist der entscheidende Perspektivwechsel: Der PoP ist kein „Server", auf den man Dinge kopiert. Der PoP ist ein Teil einer Flotte, die ihren Zustand aus Git bezieht. Deployments passieren deklarativ, reproduzierbar und versionssicher. Wenn ein Standort zeitweise offline ist, entsteht kein Chaos – der PoP reconciled automatisch, sobald er wieder erreichbar ist.

Damit dieser Ansatz nicht zu einem „GitOps-Silo" wird, haben wir das Betriebsmodell zusätzlich mit zentralen Plattformkomponenten ausgerüstet, die im Edge-Kontext nicht optional sind: Identity, Observability, Artifact Security und Secrets.

ArgoCD als Management-Interface: Rollouts werden kontrollierbar und auditierbar

ArgoCD wurde zur Schnittstelle zwischen Entwicklung und Betrieb. Jede Änderung an Workloads ist ein Commit. Jede Ausbringung ist nachvollziehbar. Jede Abweichung zwischen gewünschtem Zustand und Realität wird sichtbar.

Gerade am Edge ist diese Drift-Erkennung ein Schlüssel. Während in einem manuellen Setup Drift oft erst auffällt, wenn etwas bricht, wird sie im GitOps-Modell zu einem Signal: Der PoP weicht ab – und der Controller bringt ihn zurück in den definierten Zustand.

Das bringt nicht nur technische Konsistenz. Es schafft Planbarkeit. Rollouts können in Wellen laufen, schrittweise, mit klaren Kriterien. Und wenn eine Version Probleme macht, ist ein Rollback kein Notfall-SSH, sondern ein kontrollierter Rücksprung auf den letzten bekannten Zustand.

Identity und Zugriff: Keycloak als Grundlage für Team-Skalierung

Mit der Flotte wächst auch die Anzahl der Menschen, die Zugriff brauchen – und damit die Notwendigkeit, Zugriff zu kontrollieren, zu segmentieren und zu dokumentieren.

Wir haben deshalb Keycloak als Identity Provider eingeführt, inklusive Single Sign-On und rollenbasierter Zugriffskontrolle. Das ist im Edge-Kontext mehr als Komfort. Es ist ein Sicherheits- und Governance-Baustein: Wer darf deployen? Wer darf nur beobachten? Wer darf an Secrets? Wer darf an Produktionsumgebungen?

Durch zentrale Identitäten wird das Betriebsmodell auch organisatorisch belastbar. Wissen und Verantwortung lassen sich verteilen, ohne dass „wer hat den SSH-Key" zum versteckten Machtzentrum wird.

Observability: VictoriaMetrics, VictoriaLogs und Grafana für Flottenbetrieb

Bei verteilten PoPs reicht Monitoring auf „läuft oder läuft nicht" nie aus. Man braucht zentrale Sicht auf Zustände, Trends und Anomalien. Das betrifft nicht nur technische Metriken, sondern auch das Verhalten der Workloads unter wechselnden Netzbedingungen und realer Feldlast.

Wir haben dafür einen Observability-Stack aus VictoriaMetrics, VictoriaLogs und Grafana integriert. Damit wird Flottenbetrieb steuerbar: man erkennt PoPs, die aus der Reihe laufen, man sieht Latenz- und Error-Trends, man kann Rollouts mit Telemetrie absichern und Probleme frühzeitig identifizieren.

Ein zusätzlicher Hebel entstand dadurch, dass der Stack nicht nur „Ops-Signale" aggregiert, sondern auch Business-Daten. Energiewerte und Messdaten aus dem Feld werden direkt in diese Pipeline eingespeist und visualisiert. Das ist ein pragmatischer erster Schritt in Richtung „Edge-to-Cloud Data Intelligence": technische Transparenz und fachliche Auswertung wachsen zusammen, und Daten werden schneller anschlussfähig für BI und weitere Verarbeitung.

Artifact Security: Harbor mit SBOM-Scans als Standardprozess

Edge-Umgebungen haben eine besondere Sicherheitsrealität: viele Standorte, viele Updates, oft physische Nähe zu potenziellen Angriffsflächen. Wenn man hier nicht sicherstellt, dass nur geprüfte Artefakte ausgerollt werden, ist man dauerhaft verwundbar.

Wir haben Harbor als Container Registry eingeführt, inklusive integrierter Security-Scans und SBOM-Generierung. Der Effekt ist zweifach. Erstens wird die Sicherheit der deployten Artefakte messbar und kontrollierbar. Zweitens entsteht Nachweisfähigkeit: Welche Komponenten laufen wo, welche Schwachstellen waren bekannt, welche Versionen wurden wann ausgerollt?

Gerade wenn Edge-Projekte in regulierte Branchen hineinwachsen, ist diese Art von Supply-Chain-Transparenz ein echter Türöffner – weil Compliance nicht mehr „Projektarbeit" ist, sondern Teil des Delivery-Prozesses.

Secrets Management: Vault für Schlüssel, Tokens und Rotationsfähigkeit

In der Praxis scheitern viele Edge-Setups nicht an Kubernetes, sondern an Secrets. API-Keys, Zertifikate, Tokens und Zugangsdaten werden oft lokal verteilt, manuell erneuert oder in Konfigurationen versteckt. Bei 400 PoPs wird daraus ein permanentes Risiko.

Mit HashiCorp Vault wurde Secrets Management zentralisiert und in den GitOps-/Delivery-Prozess integriert. Das reduziert die Angriffsfläche und macht Schlüsselverwaltung operational: Secrets sind nicht mehr „irgendwo", sondern kontrolliert, auditierbar und rotierbar. Damit wird ein Betrieb möglich, der sowohl schneller als auch sicherer ist – statt sich zwischen beiden entscheiden zu müssen.

Der größte Hebel: cloud-native Delivery-Prozesse statt Edge-Sonderwege

Die zentrale Veränderung war nicht ein einzelnes Tool, sondern der Umstieg auf cloud-native Entwicklungs- und Betriebsprozesse. Das hat auf beiden Seiten Wirkung.

Auf Engineering-Seite bedeutet es: Änderungen gehen durch standardisierte Pipelines, sind versioniert, reviewed, reproduzierbar. Auf Betriebsseite bedeutet es: Rollouts sind planbar, Drift wird sichtbar, Incidents werden schneller eingegrenzt, und Updates sind nicht mehr „ein Ereignis", sondern Routine.

Diese Kombination aus Geschwindigkeit und Planbarkeit ist der Punkt, an dem Edge-Betrieb wirtschaftlich wird. Nicht weil man weniger betreibt – sondern weil man Betrieb als Plattformstandard definiert.

Ergebnis: Mehrmals tägliche Deployments, höhere Sicherheit, auditierbare Prozesse

Nach der Umstellung erfolgen Deployments für die gesamte Edge-Flotte heute mehrmals täglich – in einem kontrollierten, durchgehend überwachten GitOps-Prozess. Deploymentzeiten sind drastisch gesunken, Updates werden konsistent ausgerollt und erreichen Standorte unabhängig davon, ob sie gerade perfekt erreichbar sind oder nicht.

Durch SBOM- und Security-Scans in Harbor ist die Sicherheit der Artefakte deutlich gestiegen. Fehler und Anomalien werden über den Observability-Stack früh erkannt und unmittelbar in Incident-Prozesse übersetzt. Damit wird Betrieb nicht nur reaktiv, sondern proaktiv: Probleme werden forecast-bar und actionable, bevor sie eskalieren.

Die eingebauten Audit-Funktionen der Plattform ermöglichen es dem Kunden zudem, Projekte mit höheren Compliance-Anforderungen zu bedienen, ohne dass das Engineering-Team dafür eigene Sonderprozesse bauen muss. Und durch die Einbindung der Business-Daten in die Observability-Pipeline entsteht ein zusätzlicher Mehrwert: Messwerte aus dem Feld werden nicht nur transportiert, sondern sofort sichtbar und auswertbar – ein Baustein für neue datengetriebene Services.

Warum dieser Ansatz funktioniert: Edge ist eine Flotte – und Flotten brauchen Steuerung

Edge-Standorte wie einzelne Server zu behandeln, skaliert nicht. Je mehr PoPs, desto mehr Drift, desto mehr manuelle Arbeit, desto langsamer werden Updates – und desto größer wird das Sicherheitsrisiko.

Kubernetes als Betriebsmodell, kombiniert mit GitOps über ArgoCD, macht aus Edge-Standorten eine Flotte, die zentral steuerbar ist und lokal selbst heilt. Ergänzt um Identity, Observability, Artifact Security und Secrets entsteht ein End-to-End-Prozess, der Geschwindigkeit und Zuverlässigkeit gleichzeitig erhöht.

Das ist der Unterschied zwischen „Edge betreiben" und „Edge beherrschen".

Call to Action

Wenn ihr hunderte Edge-Standorte betreibt und Deployments heute noch per SSH/SFTP organisiert, ist das nicht nur ineffizient – es ist ein strukturelles Risiko für Verfügbarkeit, Sicherheit und Compliance. Und wenn Sicherheitsupdates nicht in Tagen, sondern in Wochen ausgerollt werden, wächst eure Angriffsfläche schneller als eure Plattform.

ayedo unterstützt beim Aufbau Kubernetes-basierter Edge-Flotten mit GitOps, zentraler Observability, Supply-Chain-Security und auditierbaren Betriebsprozessen – damit ihr am Edge so kontrolliert liefern könnt wie in der Cloud.

Wenn ihr eure Edge-Infrastruktur in ein echtes Fleet-Operating-Modell überführen wollt, sprechen wir gern darüber.