Version: 1.67.x (Q1 26)
Codesphere Installationsoptionen
Codesphere bietet mehrere Installationsoptionen, um unterschiedliche Anforderungen an Sicherheit, Konnektivität und Verwaltungspräferenzen zu erfüllen. Die folgenden Szenarien beschreiben die verschiedenen verfügbaren Deployment-Modelle.
Szenario 1: Air-Gapped-Installation
Wesentliche Merkmale: Vollständig getrennt vom Netz. Alle Codesphere-Komponenten, einschließlich K8s-Control-Plane, Codesphere Services, Codesphere-Datenbank und Codesphere Management Console, laufen auf kundeneigener Infrastruktur innerhalb eines einzelnen Kubernetes-Clusters. Ceph-Storage ist lokal.
loading...Szenario 2A: Federated Installation (gemeinsame Datenbank)
Wesentliche Merkmale: Läuft auf kundeneigener Infrastruktur über ein oder potenziell mehrere Rechenzentren. Jedes Rechenzentrum verfügt über eine eigene lokale K8s-Control-Plane. Codesphere Services laufen lokal innerhalb des K8s-Clusters jedes Rechenzentrums. Eine zentrale Management Console und eine gemeinsame Codesphere-Datenbank (gehostet vom Kunden oder in einer vertrauenswürdigen Zone) ermöglichen eine einheitliche Benutzerverwaltung und Sichtbarkeit über diese föderierten Installationen hinweg. Ceph-Storage ist immer lokal zum jeweiligen Rechenzentrum.
loading...Szenario 2B: Federated Installation (individuelle Datenbanken)
Wesentliche Merkmale: Läuft auf kundeneigener Infrastruktur über mehrere Rechenzentren. Jedes Rechenzentrum verfügt über eine eigene lokale K8s-Control-Plane, lokale Codesphere Services (im Namespace „codesphere") und eine eigene individuelle Codesphere-Datenbank. Eine zentrale Management Console bietet eine einheitliche Ansicht, indem sie mit der K8s-API und/oder den Codesphere Services in jedem Rechenzentrum kommuniziert. Ceph-Storage ist immer lokal zum jeweiligen Rechenzentrum. Dies bietet eine stärkere Datenisolation zwischen Rechenzentren im Vergleich zu einer gemeinsamen globalen Datenbank.
loading...Szenario 3A: Central Control Plane (gemeinsame Datenbank)
Wesentliche Merkmale:
- Der Kunde stellt K8s-Worker-Nodes und lokalen Ceph-Storage in seinem/seinen Rechenzentrum(en) bereit.
- Für jedes Kunden-Rechenzentrum verwaltet Codesphere die K8s-Control-Plane (z. B. mittels k0smotron/Gardener).
- Codesphere Services laufen im Namespace „codesphere" auf den Worker-Nodes des Kunden, bereitgestellt und verwaltet durch die von Codesphere verwaltete K8s-Control-Plane.
- Eine zentrale Management Console und eine gemeinsame Codesphere-Datenbank befinden sich an einem zentralen Ort und bieten eine einheitliche Verwaltung für den Tenant.
Szenario 3B: Central Control Plane (individuelle Datenbanken)
Wesentliche Merkmale:
- Der Kunde stellt K8s-Worker-Nodes und lokalen Ceph-Storage in seinem/seinen Rechenzentrum(en) bereit.
- Für jedes Kunden-Rechenzentrum verwaltet Codesphere die K8s-Control-Plane in der Codesphere Cloud.
- Codesphere Services laufen im Namespace „codesphere" auf den Worker-Nodes des Kunden, verwaltet durch die von Codesphere verwaltete K8s-Control-Plane.
- Jedes Rechenzentrum verfügt über eine eigene logische Codesphere-Datenbankinstanz (die Infrastruktur kann von Codesphere verwaltet werden, die Daten sind jedoch pro Rechenzentrum isoliert).
- Eine zentrale Management Console in der Codesphere Cloud aggregiert die Ansichten, indem sie mit jeder verwalteten K8s-Control-Plane und den jeweiligen Codesphere Services/Datenbanken kommuniziert.
Codesphere Installationsszenarien: Vor- und Nachteile
| Szenario | Vorteile | Nachteile |
|---|---|---|
| 1. Air-Gapped-Installation | - Maximale Sicherheit & Datensouveränität: Vollständige Isolation von externen Netzwerken. - Volle Kontrolle: Der Kunde verwaltet alle Komponenten und die Infrastruktur. - Keine externen Abhängigkeiten (nach dem Deployment): Funktioniert vollständig offline. | - Hoher Betriebsaufwand (relativ): Der Kunde ist für alle Updates, Patches und die Verwaltung von K8s/Datenbank/Codesphere verantwortlich (auch wenn der Codesphere-Installer die Ersteinrichtung im Vergleich zur Eigenentwicklung vereinfacht). - Manuelle Updates: Neue Funktionen/Patches erfordern manuellen Import und Deployment. |
| 2A. Federated Installation (gemeinsame globale Datenbank) | - Einheitliche Verwaltung: Eine Console und eine gemeinsame Datenbank für Benutzer, Teams und Workspace-Metadaten über mehrere Rechenzentren hinweg (Console/Datenbank kundengehostet). - Kundenkontrolle über K8s: Lokale K8s-Control-Planes und Worker in jedem Rechenzentrum. - Datenlokalität (Ceph): Das verteilte Dateisystem (Ceph) ist immer lokal zum jeweiligen Rechenzentrum. - Zentralisierte Übersicht: Einfacherer Überblick über alle föderierten Deployments. | - Komplexität der gemeinsamen Datenbank: Kann ein Single Point of Failure oder Engpass sein, wenn sie vom Kunden nicht für Hochverfügbarkeit/Disaster Recovery ausgelegt ist (der Codesphere-Installer bietet eine optimierte Einrichtung). - Datenaggregation: Globale Benutzer-/Team-/Workspace-Metadaten an einem vom Kunden verwalteten Ort erfüllen möglicherweise nicht alle Souveränitätsanforderungen, wenn sie nicht ordnungsgemäß abgesichert sind. - WAN-Abhängigkeit: Erfordert eine zuverlässige Verbindung zwischen den Rechenzentren und der kundengehosteten zentralen Management Console/Datenbank für einheitliche Funktionen. |
| 2B. Federated Installation (individuelle Rechenzentrums-Datenbanken) | - Verbesserte Datenisolation: Jedes Rechenzentrum verfügt über eine eigene, vom Kunden verwaltete Codesphere-Datenbank, die Benutzer-/Team-/Workspace-Metadaten pro Rechenzentrum isoliert. - Kundenkontrolle über K8s & Datenbanken: Lokale K8s-Control-Planes, Worker und Datenbanken. - Datenlokalität (Ceph): Lokaler Ceph-Storage pro Rechenzentrum. - Aggregierte Ansicht (optionale Console): Eine kundengehostete zentrale Management Console kann einen Überblick durch Abfragen der einzelnen Rechenzentren bieten. - Reduzierte WAN-Abhängigkeit für zentrale Rechenzentrumsabläufe: Rechenzentren können unabhängig arbeiten; WAN wird primär für die optionale zentrale Console-Ansicht benötigt. | - Höhere Verwaltungskomplexität (relativ): Mehr Datenbanken, die vom Kunden verwaltet werden müssen (auch wenn der Codesphere-Installer die Einrichtung vereinfacht). - Isolierte Benutzerverwaltung (potenziell): Rechenzentrumsübergreifende Benutzer-/Team-Vorgänge können komplexer sein, sofern die zentrale Console die Synchronisierung nicht effektiv handhabt. - WAN-Abhängigkeit (für Console): Die kundengehostete zentrale Console muss sich, falls genutzt, mit jedem Rechenzentrum verbinden. |
| 3A. Managed Control Plane (gemeinsame globale Datenbank) | - Vereinfachter K8s-Betrieb: Codesphere verwaltet die K8s-Control-Planes für jedes Kunden-Rechenzentrum. - Einheitliche Verwaltung (Tenant): Zentrale Management Console und gemeinsame Datenbank für den Tenant (gehostet von Codesphere). - Kundenkontrolle über Worker: Der Kunde verwaltet K8s-Worker-Nodes und lokalen Ceph-Storage. - Schnelleres Onboarding: Potenziell schnellere Einrichtung neuer K8s-Control-Planes. | - Abhängigkeit von Codesphere: Die Verfügbarkeit von K8s-Control-Plane und zentraler Console/Datenbank ist von Codesphere abhängig. - Bedenken zur gemeinsamen Datenbank (auf Tenant-Ebene): Ähnlich wie bei 2A, jedoch für die globalen Metadaten des Tenants (Single Point of Failure, potenzieller Engpass, verwaltet von Codesphere). - Internetkonnektivität: Erfordert eine stabile Verbindung zwischen den Kunden-Rechenzentren und den von Codesphere gehosteten Diensten. - Datenübertragung (Metadaten): Die Workspace-Metadaten sowie Benutzer-/Teaminformationen des Tenants befinden sich in der von Codesphere gehosteten Datenbank. |
| 3B. Managed Control Plane (individuelle Rechenzentrums-Datenbanken – lokal beim Kunden) | - Vereinfachter K8s-Betrieb: Codesphere verwaltet die K8s-Control-Planes. - Maximale Datenisolation (Metadaten): Die individuellen Codesphere-Datenbanken sind lokal und werden vom Kunden innerhalb jedes Rechenzentrums verwaltet. - Kundenkontrolle über Worker & Datenbanken: Der Kunde verwaltet K8s-Worker-Nodes, lokalen Ceph-Storage und lokale Codesphere-Datenbanken. - Aggregierte Ansicht: Die zentrale Management Console (gehostet von Codesphere) bietet eine Übersicht. | - Abhängigkeit von Codesphere für die K8s-Control-Plane: Die Verfügbarkeit der K8s-Control-Plane ist von Codesphere abhängig. - Kundenverantwortung für Datenbank (relativ): Der Kunde ist für Verwaltung sowie Hochverfügbarkeit/Disaster Recovery der lokalen Codesphere-Datenbanken in jedem Rechenzentrum verantwortlich (der Codesphere-Installer vereinfacht die Einrichtung). - Internetkonnektivität: Erfordert eine stabile Verbindung für verwaltete Control-Planes und die zentrale Console. - Datenübertragung (für Console-Ansicht): Die aggregierte Ansicht in der von Codesphere gehosteten Console erfordert Daten-/API-Zugriff auf lokale Dienste. |
Wesentliche Überlegungen für den Kunden:
- Sicherheits- und Souveränitätsanforderungen: Wie streng sind die Anforderungen an Datenisolation und Kontrolle, insbesondere im Hinblick auf Metadaten im Vergleich zu Workload-Daten?
- Betriebskapazität: Welches Maß an Infrastruktur- und Plattformverwaltung (K8s, Datenbanken, Console) kann das Team des Kunden bewältigen, unter Berücksichtigung der Tatsache, dass der optimierte Installer von Codesphere die Ersteinrichtung vereinfacht?
- Skalierbarkeit & Multi-Rechenzentrums-Anforderungen: Besteht die Notwendigkeit, Workloads über mehrere Rechenzentren hinweg mit einheitlichen oder isolierten Benutzerbasen/Metadaten zu verwalten?
- Konnektivität: Welche Einschränkungen und welche Zuverlässigkeit weisen die WAN-/Internetverbindungen auf, insbesondere im Hinblick auf optionale versus erforderliche Komponenten?
- Budget: Unterschiedliche Modelle haben unterschiedliche Auswirkungen auf Infrastruktur-, Lizenz- und Betriebskosten.
- Benutzerfreundlichkeit vs. Kontrolle: Wo möchte der Kunde die Balance für die verschiedenen Komponenten (K8s-Control-Plane, Datenbank, Management Console) finden?