Version: 1.89.x (Q2 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 Bereitstellungsmodelle.
Szenario 1: Air-Gapped-Installation
Wesentliche Merkmale: Vollständig getrennt vom Netz. Alle Codesphere-Komponenten, einschließlich K8s Control Plane, Codesphere Services, Codesphere Database und Codesphere Management Console, laufen auf kundeneigener Infrastruktur innerhalb eines einzelnen Kubernetes-Clusters. Der Ceph-Speicher ist lokal.
loading...Szenario 2A: Federierte Installation (gemeinsame Datenbank)
Wesentliche Merkmale: Läuft auf kundeneigener Infrastruktur über ein oder potenziell mehrere Rechenzentren hinweg. Jedes Rechenzentrum hat seine lokale K8s Control Plane. Codesphere Services laufen lokal innerhalb des K8s-Clusters jedes Rechenzentrums. Eine zentrale Management Console und eine gemeinsame Codesphere Database (gehostet vom Kunden oder in einer vertrauenswürdigen Zone) ermöglichen eine einheitliche Benutzerverwaltung und Übersicht über diese föderierten Installationen hinweg. Der Ceph-Speicher ist immer lokal im jeweiligen Rechenzentrum.
loading...Szenario 2B: Federierte Installation (einzelne Datenbanken)
Wesentliche Merkmale: Läuft auf kundeneigener Infrastruktur über mehrere Rechenzentren hinweg. Jedes Rechenzentrum hat seine lokale K8s Control Plane, lokale Codesphere Services (im Namespace "codesphere") und seine eigene individuelle Codesphere Database. Eine zentrale Management Console bietet eine einheitliche Übersicht, indem sie mit der K8s-API und/oder den Codesphere Services in jedem Rechenzentrum kommuniziert. Der Ceph-Speicher ist immer lokal im jeweiligen Rechenzentrum. Dies bietet eine höhere Datenisolation zwischen den Rechenzentren im Vergleich zu einer gemeinsamen globalen Datenbank.
loading...Szenario 3A: Zentrale Control Plane (gemeinsame Datenbank)
Wesentliche Merkmale:
- Der Kunde stellt K8s-Worker-Nodes und lokalen Ceph-Speicher in seinem/seinen Rechenzentrum(en) bereit.
- Für jedes Kunden-Rechenzentrum verwaltet Codesphere dessen K8s Control Plane (z. B. mittels k0smotron/Gardener).
- Codesphere Services laufen im Namespace "codesphere" auf den Worker-Nodes des Kunden, bereitgestellt und verwaltet von der Codesphere-verwalteten K8s Control Plane.
- Eine zentrale Management Console und eine gemeinsame Codesphere Database befinden sich an einem zentralen Standort und bieten eine einheitliche Verwaltung für den Tenant.
Szenario 3B: Zentrale Control Plane (einzelne Datenbanken)
Wesentliche Merkmale:
- Der Kunde stellt K8s-Worker-Nodes und lokalen Ceph-Speicher in seinem/seinen Rechenzentrum(en) bereit.
- Für jedes Kunden-Rechenzentrum verwaltet Codesphere dessen K8s Control Plane in der Codesphere Cloud.
- Codesphere Services laufen im Namespace "codesphere" auf den Worker-Nodes des Kunden, verwaltet von der Codesphere-verwalteten K8s Control Plane.
- Jedes Rechenzentrum hat seine eigene logische Codesphere-Database-Instanz (die Infrastruktur kann von Codesphere verwaltet werden, die Daten sind jedoch pro Rechenzentrum isoliert).
- Eine zentrale Management Console in der Codesphere Cloud aggregiert 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 & Datenhoheit: Vollständige Isolation von externen Netzwerken. - Volle Kontrolle: Der Kunde verwaltet alle Komponenten und die Infrastruktur. - Keine externen Abhängigkeiten (nach der Bereitstellung): Funktioniert vollständig offline. | - Hoher operativer Aufwand (relativ): Der Kunde ist für alle Updates, Patches und die K8s-/DB-/Codesphere-Verwaltung verantwortlich (obwohl der Codesphere-Installer die Ersteinrichtung im Vergleich zur Eigenentwicklung vereinfacht). - Manuelle Updates: Neue Funktionen/Patches erfordern manuellen Import und manuelle Bereitstellung. |
| 2A. Federierte Installation (gemeinsame globale Datenbank) | - Einheitliche Verwaltung: Eine einzige Console und gemeinsame Datenbank für Benutzer, Teams und Workspace-Metadaten über mehrere Rechenzentren hinweg (Console/Datenbank vom Kunden gehostet). - Kundenkontrolle über K8s: Lokale K8s Control Planes und Worker in jedem Rechenzentrum. - Datenlokalität (Ceph): Das verteilte Dateisystem (Ceph) ist immer lokal im jeweiligen Rechenzentrum. - Zentralisierte Übersicht: Einfacherer Überblick über alle föderierten Bereitstellungen. | - Komplexität der gemeinsamen Datenbank: Kann ein Single Point of Failure oder Engpass sein, wenn sie vom Kunden nicht für HA/DR ausgelegt wird (der Codesphere-Installer bietet eine optimierte Einrichtung). - Datenaggregation: Globale Benutzer-/Team-/Workspace-Metadaten an einem einzigen kundenverwalteten Ort erfüllen möglicherweise nicht alle Anforderungen an die Datenhoheit, wenn sie nicht ordnungsgemäß gesichert werden. - WAN-Abhängigkeit: Erfordert eine zuverlässige Verbindung zwischen den Rechenzentren und der kundengehosteten zentralen Management Console/Datenbank für einheitliche Funktionen. |
| 2B. Federierte Installation (einzelne Datenbanken pro Rechenzentrum) | - Verbesserte Datenisolation: Jedes Rechenzentrum verfügt über seine eigene kundenverwaltete Codesphere-Datenbank, wodurch Benutzer-/Team-/Workspace-Metadaten pro Rechenzentrum isoliert werden. - Kundenkontrolle über K8s & Datenbanken: Lokale K8s Control Planes, Worker und Datenbanken. - Datenlokalität (Ceph): Lokaler Ceph-Speicher pro Rechenzentrum. - Aggregierte Ansicht (optionale Console): Eine kundengehostete zentrale Management Console kann durch Abfrage der einzelnen Rechenzentren eine Übersicht bieten. - Reduzierte WAN-Abhängigkeit für den Kernbetrieb der Rechenzentren: Rechenzentren können unabhängig arbeiten; WAN wird hauptsächlich für die optionale zentrale Console-Ansicht benötigt. | - Höhere Verwaltungskomplexität (relativ): Mehr Datenbanken, die der Kunde verwalten muss (obwohl der Codesphere-Installer die Einrichtung vereinfacht). - Isolierte Benutzerverwaltung (potenziell): Rechenzentrumsübergreifende Benutzer-/Team-Vorgänge könnten komplexer sein, sofern die zentrale Console die Synchronisierung nicht effektiv handhabt. - WAN-Abhängigkeit (für die Console): Die kundengehostete zentrale Console muss sich mit jedem Rechenzentrum verbinden, sofern verwendet. |
| 3A. Verwaltete 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-Speicher. - Schnelleres Onboarding: Potenziell schnellere Einrichtung neuer K8s Control Planes. | - Abhängigkeit von Codesphere: Die Verfügbarkeit der K8s Control Plane und der zentralen Console/Datenbank hängt von Codesphere ab. - 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). - Internetverbindung: Robuste Verbindung zwischen den Kunden-Rechenzentren und den von Codesphere gehosteten Diensten erforderlich. - Datenübertragung (Metadaten): Die Workspace-Metadaten sowie Benutzer-/Team-Informationen des Tenants befinden sich in einer von Codesphere gehosteten Datenbank. |
| 3B. Verwaltete Control Plane (einzelne Datenbanken pro Rechenzentrum – kundenlokal) | - Vereinfachter K8s-Betrieb: Codesphere verwaltet die K8s Control Planes. - Maximale Datenisolation (Metadaten): Die einzelnen Codesphere-Datenbanken sind lokal und werden vom Kunden innerhalb jedes Rechenzentrums verwaltet. - Kundenkontrolle über Worker & Datenbanken: Der Kunde verwaltet K8s-Worker-Nodes, lokalen Ceph-Speicher 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 hängt von Codesphere ab. - Verantwortung für die Datenbank beim Kunden (relativ): Der Kunde ist für Verwaltung, HA/DR der lokalen Codesphere-Datenbanken in jedem Rechenzentrum verantwortlich (der Codesphere-Installer vereinfacht die Einrichtung). - Internetverbindung: Robuste Verbindung für verwaltete Control Planes und die zentrale Console erforderlich. - Datenübertragung (für die Console-Ansicht): Die aggregierte Ansicht in der von Codesphere gehosteten Console erfordert Daten-/API-Zugriff auf die lokalen Dienste. |
Wesentliche Überlegungen für den Kunden:
- Sicherheits- und Souveränitätsanforderungen: Wie streng sind die Anforderungen an Datenisolation und Kontrolle, insbesondere bei Metadaten im Vergleich zu Workload-Daten?
- Operative Kapazität: Welches Maß an Infrastruktur- und Plattformverwaltung (K8s, Datenbanken, Console) kann das Team des Kunden bewältigen, unter Berücksichtigung, dass der optimierte Codesphere-Installer die Ersteinrichtung vereinfacht?
- Skalierbarkeit & Multi-Rechenzentrum-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 haben die WAN-/Internetverbindungen, insbesondere im Hinblick auf optionale versus erforderliche Komponenten?
- Budget: Unterschiedliche Modelle haben unterschiedliche Auswirkungen auf Infrastruktur-, Lizenz- und Betriebskosten.
- Benutzerfreundlichkeit versus Kontrolle: Wo möchte der Kunde die Balance für die verschiedenen Komponenten (K8s Control Plane, Datenbank, Management Console) finden?