Fehlende Dateien
Kopieren per Tag kann eine Version verändern oder Charts, Tools und weitere Abhängigkeiten auslassen.
Eingeschränkte und getrennte Umgebungen
Kubernetes in getrennten Netzen ohne öffentliches Internet betreiben.
ClusterPilot bewahrt genaue Softwareversionen und Prüfdaten, während Pakete durch Ihren kontrollierten Freigabeweg laufen.
Operative Ausgangslage
Offline-Betrieb braucht ein vollständiges Softwarepaket.
Ein Container-Image allein reicht nicht. Teams brauchen auch passende Tools, Kubernetes-Dateien, Add-ons, Zertifikate und signierte Release-Daten.
Unterschiedliche Zertifikate
Zertifikate und Registry-Einstellungen können zwischen Plattform, Agents und Zielhosts abweichen.
Kein klarer Freigabenachweis
Dateien werden kopiert, ohne die genaue Version und Freigabe sicher festzuhalten.
Enterprise Value
Softwareverteilung wird Teil des Betriebsablaufs.
Der Nutzen entsteht aus gemeinsamem Zustand, klarer Verantwortung und überprüfbarer Ausführung.
Unveränderliches Inventar
API-, Agent-, Tool-, Kubernetes- und Add-on-Subjects werden über exakten Digest und Kompatibilitätsmetadaten gewählt.
Kontrollierte Promotion
Harbor oder eine andere freigegebene Registry wird zur Kunden-Policy- und Promotion-Grenze.
Aufbewahrte Verifikation
Prüfsummen, Signaturen, SBOM, Vulnerability-Evidenz und Provenance bleiben dem promoteten Release zugeordnet.
Kontrollierter Ablauf
Ein verifizierbarer Air-Gap-Pfad
Dieselbe Artefaktidentität bleibt vom verbundenen Staging bis zur eingeschränkten Runtime erhalten.
Release-Set auflösen
Exaktes Release, Kompatibilitätslinie, Provider-Tools, Kubernetes-Artefakte und freigegebene Add-ons wählen.
Vor Transfer verifizieren
Prüfsummen, Signaturen, Digests, SBOM und Provenance in der verbundenen Zone validieren.
Spiegeln und promoten
Vollständiges Inventar übertragen, Digests erhalten, Kunden-Policy anwenden und Freigabe dokumentieren.
Runtime attestieren
Registry-Trust, Agent-Kompatibilität, Runtime-Digests und Evidenz vor Lifecycle-Arbeit bestätigen.
Nachweis
Beweisen, was die Grenze überschritten hat.
Betreiber können das freigegebene Inventar mit Runtime-Subjects und konsumierender Operation verbinden.
Release-Identität
Version, Commit, unveränderliche Subjects, exakte Digests und signierte Kompatibilitätsmetadaten.
Promotion-Eintrag
Quell- und Ziel-Registry, Policy-Ergebnis, Akteur, Zeitstempel, Prüfsummen und Freigabe.
Runtime-Bestätigung
Agent-/Tool-Identität, gezogener Digest, Trust-Posture, Operationsergebnis und Artefakte.
Ehrliche Produktgrenze
Bereitstellungsspezifische Validierung bleibt notwendig
- Air-Gap-Reife hängt vom vollständigen Kunden-Netzwerk-, Registry-, DNS-, Zeit- und Private-CA-Design ab.
- Eine eingeschränkte Umgebung muss mit dem exakten Release und Inventar getestet werden; Dokumentation allein ist keine Abnahme.
- ClusterPilot behauptet nicht, dass jedes Drittanbieter-Add-on ohne eigene Abhängigkeitsprüfung offline-fähig ist.
Häufige Fragen
Fragen zu Kubernetes Air-Gap Betrieb
Klare Antworten auf Einsatz, Grenze und Evaluationsweg.
Benötigt ClusterPilot zur Laufzeit Internetzugriff?+
Das dokumentierte Registry- und Air-Gap-Modell unterstützt kundenseitige Distribution. Inventar und Netzwerkdesign müssen für die gewählten Capabilities validiert werden.
Können Images nur per Tag gespiegelt werden?+
Die unterstützte Release-Posture ist digest-gebunden. Ein beweglicher Tag erhält weder Artefaktidentität noch ausreichende Verifikationsevidenz.
Wird eine private CA unterstützt?+
Private Trust ist Teil der Bereitstellungsgrenze. Die CA muss auf Control Plane, Agents, Registries und Zielhosts konsistent installiert und validiert werden.
Capability-Umfang: v0.0.1 Release Candidate. Aktuelle Release-Grenze →
Mit einem messbaren Workflow starten
Die Anforderungen in eine begrenzte technische Evaluation übersetzen.
Wir prüfen Umgebung, operativen Engpass, Kontrollgrenzen und die Evidenz, die eine Entscheidung tragen muss.
hello@clusterpilot.de