Google Distributed Cloud Air-Gapped: Setup, Betrieb, DR und Governance

Definition

Google Distributed Cloud (GDC) air-gapped ist eine Variante der Distributed Cloud, bei der Kubernetes-Cluster in einer Umgebung ohne direkte Internetverbindung betrieben und zentral verwaltet werden. Es ist kein Public-Cloud-Ersatz für beliebige Standard-Workloads, sondern ein Betriebsmodell für strikte Isolation mit klarer Governance.

Einleitung

google distributed cloud air-gapped wird relevant, wenn „kein Internet“ nicht nur eine Policy ist, sondern ein Muss: kritische Daten, regulatorische Anforderungen oder Hochsicherheitszonen. Der Knackpunkt ist nicht Kubernetes an sich, sondern der zuverlässige Betrieb: Updates, Images, Identitäten, Auditing, Backup/Restore und Disaster Recovery müssen auch ohne externe Abhängigkeiten funktionieren.

Zentrale Konzepte: Organization, Projects, Resources, Cluster

In GDC strukturierst du die Plattform innerhalb einer Organization, darunter Projects als organisatorische Einheiten für teamspezifische resources und Zugriff. Technisch läuft alles über Kubernetes cluster bzw. mehrere clusters, in denen Workloads (Containerarbeitslasten) betrieben werden. Diese Struktur ist nicht „Formalität“, sondern dein Hebel für Messbarkeit: Kosten- und Verantwortungszuordnung, Audit-Spuren, klare Grenzen zwischen Umgebungen und Teams.

Cluster-Architektur in Air-Gapped-Umgebungen

Die wichtigste Architekturfrage ist nicht „ein Cluster oder viele“, sondern: Welche Blast-Radius-Grenzen brauchst du für Betrieb und Recovery? Typisch ist eine Trennung nach Umgebungen (z.B. Prod/Non-Prod) und nach Kritikalität der Workloads. Je nach Anforderung planst du zonal oder eine multi-zone universe Architektur, um Ausfälle über Zonen hinweg abzufangen.

• Plane Steuerungsebene und Knotengruppen (knoten) so, dass kritische Plattformdienste nicht mit Anwendungs-Last konkurrieren.

• Definiere klar, welche Workloads GPU benötigen (z.B. NVIDIA GPUs) und welche nicht, damit Kapazität und Beschaffung steuerbar bleiben.

• Lege früh fest, ob du GKE on GDC als Betriebsstandard nutzt und wie du Cluster-Lifecycle (Create/Upgrade/Decommission) operationalisierst.

Setup Schritt für Schritt: Checkliste für Start und Betrieb

Für das Setup nutzt du typischerweise GDC console und gdcloud CLI, um Projekte, Ressourcen und Cluster kontrolliert aufzusetzen. Entscheidend ist, dass du Setup und Betrieb nicht trennst: Alles, was du heute „schnell“ anlegst, musst du morgen auditieren, patchen und wiederherstellen können.

Setup-Checkliste

• Organization- und Project-Struktur festlegen, inkl. Namenskonventionen, Umgebungen und Ownership.

• Identity provider (IdP) anbinden, Multi-factor authentication aktivieren, Rollen nach Least Privilege definieren, Auditing-Events zentral erfassbar machen.

• Supply Chain vorbereiten: Registry (z.B. Harbor registry), Signaturen/Schlüssel, Zertifikate (z.B. Certificate Authority Service (CAS)), Freigabeprozess für Images.

Netzwerk, Interconnect und Load Balancing

Air gapped bedeutet „isoliert“, nicht „ohne Netzwerkanforderungen“. Häufig gibt es kontrollierte Verbindungen zu anderen Sicherheitszonen oder Rechenzentren, z.B. über Interconnect und BGP. Für Anwendungen brauchst du außerdem erreichbare Endpunkte: Internal and External Load Balancer (ILB / ELB), load balancer Backends, health checks und ggf. forwarding rules.

Der Nutzen im Alltag: Teams bekommen stabile Zugriffspfade für ihre Anwendungen, während Security den traffic kontrolliert und segmentiert. Ohne saubere Netzwerklogik entstehen Schattenpfade, manuelle Workarounds und unklare Zuständigkeiten.

Backup/Restore und Disaster Recovery (DR)

Backup restore ist in isolierten Umgebungen besonders kritisch, weil „mal eben aus der Cloud ziehen“ nicht funktioniert. Plane deshalb Backups als Produkt, nicht als Nebenaufgabe: Was wird gesichert (Kubernetes-Objekte, Persistenz, Konfiguration), wo liegen backups, und wie läuft restore unter Zeitdruck?

DR-Plan: minimal belastbar

• RTO/RPO pro Workload-Klasse festlegen (Messbarkeit), daraus Recovery-Reihenfolge und Abhängigkeiten ableiten.

• Wiederherstellungsszenarien definieren: Cluster-Ausfall, Zonen-Ausfall, Datenkorruption, versehentliche Löschung, kompromittierte Credentials.

• Restore-Runbooks testen: nicht nur „kann zurückgespielt werden“, sondern „kann in der richtigen Reihenfolge produktiv gehen“.

Wenn du Backup- und DR-Workflows sauber definierst, sinkt das Betriebsrisiko messbar: weniger ungeplante Downtime, weniger Ad-hoc-Entscheidungen, klarere Verantwortlichkeiten.

Sicherheit und Berechtigungsdesign: IdP, MFA, Least Privilege, Auditing

In GDC air-gapped ist Security kein Add-on, sondern Teil der Steuerungsebene: Identitäten, Rollen und Protokollierung entscheiden, ob Betrieb skalierbar bleibt. Best Practice ist ein zentraler IdP, MFA als Default, Rollen nach Least Privilege und regelmäßige Reviews. Für Auditing gilt: Logs müssen so strukturiert sein, dass du im Incident die Kette aus identity, access, Änderungen an resources und Workloads nachvollziehen kannst.

Governance: Tags, Ressourcenorganisation, Zugriffskontrollen

Governance wird oft als Bürokratie empfunden, ist aber der Hebel gegen Budget- und Zeitrisiken. Project tags (Tags) und eine klare Ressourcenorganisation machen sichtbar, welche Teams welche Workloads betreiben, wo Kapazität gebunden ist und was wirklich kritisch ist. Das hilft für interne Verrechnung, Priorisierung und Audit-Anforderungen, ohne dass Betrieb „manuell“ wird.

Updates, Release Notes und Betrieb ohne Überraschungen

In einer air gapped Umgebung sind Updates planbar, aber selten „einfach“. Release Notes und Abhängigkeiten (z.B. Kubernetes-Version, Ingress/Load-Balancing-Verhalten, Storage-Änderungen) müssen vorab bewertet werden. Sinnvoll ist ein festes Update-Ritual: Bewertung, Lab-Test, Change-Fenster, Rollback-Plan. So reduzierst du Risiko und vermeidest, dass ein Upgrade unbemerkt an Governance oder Networking scheitert.

Mini-Praxisbeispiel: Recovery-Trockenübung statt Incident

Ein Team betreibt mehrere Kubernetes cluster für getrennte Workloads innerhalb einer Organization und nutzt Tags, um Kritikalität zu markieren. In einer DR-Übung wird ein Cluster absichtlich als „verloren“ simuliert, Backups werden restored und der Zugriff über ILB/ELB neu validiert. Ergebnis: Die Technik funktioniert, aber ein fehlendes Least-Privilege-Rollenrecht blockiert den finalen Cutover. Genau dafür sind Tests da: kleine Lücke gefunden, bevor es ein echter Ausfall wird.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn du mehrere Cluster, Interconnect-Anbindungen, strikte Compliance und DR in einem Plan zusammenbringen musst. Typische Trigger sind: hoher Zeitdruck, unklare Verantwortlichkeiten zwischen Netzwerk/Security/Plattformteam oder wenn Budget und Risiko gegenüber Management sauber begründet werden müssen. Dann ist ein Architektur- und Governance-Design mit überprüfbaren Runbooks oft schneller und sicherer als „Learning on the job“ im Produktivbetrieb.