Version: Weekly Build
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 der K8s-Control-Plane, der Codesphere Services, der Codesphere-Datenbank und der Codesphere Management Console, laufen auf kundeneigener Infrastruktur innerhalb eines einzelnen Kubernetes-Clusters. Der Ceph-Speicher ist lokal.
loading...Szenario 2A: Federated-Installation (geteilte Datenbank)
Wesentliche Merkmale: Läuft auf kundeneigener Infrastruktur über ein oder potenziell mehrere Rechenzentren. Jedes Rechenzentrum verfügt über eine lokale K8s-Control-Plane. Die Codesphere Services laufen lokal innerhalb des K8s-Clusters jedes Rechenzentrums. Eine zentrale Management Console und eine geteilte Codesphere-Datenbank (gehostet vom Kunden oder in einer vertrauenswürdigen Zone) ermöglichen eine einheitliche Benutzerverwaltung und Übersicht über diese Federated-Installationen. Der Ceph-Speicher ist stets lokal in jedem Rechenzentrum.
loading...Szenario 2B: Federated-Installation (individuelle Datenbanken)
Wesentliche Merkmale: Läuft auf kundeneigener Infrastruktur über mehrere Rechenzentren. Jedes Rechenzentrum verfügt über eine lokale K8s-Control-Plane, lokale Codesphere Services (im Namespace "codesphere") und eine eigene, individuelle Codesphere-Datenbank. 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 stets lokal in jedem Rechenzentrum. Dies bietet eine stärkere Datenisolation zwischen den Rechenzentren im Vergleich zu einer geteilten globalen Datenbank.
loading...Szenario 3A: Zentrale Control Plane (geteilte 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 die zugehörige K8s-Control-Plane (z. B. mittels k0smotron/Gardener).
- Die Codesphere Services laufen im Namespace "codesphere" auf den Worker-Nodes des Kunden und werden von der Codesphere-verwalteten K8s-Control-Plane deployt und verwaltet.
- Eine zentrale Management Console und eine geteilte Codesphere-Datenbank befinden sich an einem zentralen Ort und bieten eine einheitliche Verwaltung für den Tenant.
Szenario 3B: Zentrale Control Plane (individuelle 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 die zugehörige K8s-Control-Plane in der Codesphere Cloud.
- Die Codesphere Services laufen im Namespace "codesphere" auf den Worker-Nodes des Kunden und werden von der Codesphere-verwalteten K8s-Control-Plane verwaltet.
- 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 (wobei der Codesphere-Installer die Ersteinrichtung im Vergleich zur Eigenentwicklung vereinfacht). - Manuelle Updates: Neue Funktionen/Patches erfordern manuellen Import und manuelles Deployment. |
| 2A. Federated-Installation (geteilte globale Datenbank) | - Einheitliche Verwaltung: Eine einzige Console und eine geteilte Datenbank für Benutzer, Teams und Workspace-Metadaten über mehrere Rechenzentren hinweg (Console/Datenbank kundenseitig gehostet). - Kontrolle des Kunden über K8s: Lokale K8s-Control-Planes und Worker in jedem Rechenzentrum. - Datenlokalität (Ceph): Das verteilte Dateisystem (Ceph) ist stets lokal in jedem Rechenzentrum. - Zentrale Übersicht: Einfacherer Überblick über alle Federated-Deployments. | - Komplexität der geteilten Datenbank: Kann bei nicht kundenseitig für HA/DR ausgelegter Architektur ein Single Point of Failure oder Engpass sein (der Codesphere-Installer bietet eine optimierte Einrichtung). - Datenaggregation: Globale Benutzer-/Team-/Workspace-Metadaten an einem kundenverwalteten Ort können nicht allen Souveränitätsanforderungen entsprechen, wenn sie nicht ausreichend abgesichert sind. - WAN-Abhängigkeit: Erfordert eine zuverlässige Verbindung zwischen den Rechenzentren und der kundenseitig gehosteten zentralen Management Console/Datenbank für einheitliche Funktionen. |
| 2B. Federated-Installation (individuelle Datenbanken je Rechenzentrum) | - Erhöhte Datenisolation: Jedes Rechenzentrum verfügt über eine eigene, kundenseitig verwaltete Codesphere-Datenbank, die Benutzer-/Team-/Workspace-Metadaten pro Rechenzentrum isoliert. - Kontrolle des Kunden über K8s & Datenbanken: Lokale K8s-Control-Planes, Worker und Datenbanken. - Datenlokalität (Ceph): Lokaler Ceph-Speicher pro Rechenzentrum. - Aggregierte Ansicht (optionale Console): Eine kundenseitig gehostete zentrale Management Console kann durch Abfrage der einzelnen Rechenzentren eine Übersicht liefern. - Geringere WAN-Abhängigkeit für den Kernbetrieb der Rechenzentren: 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 der Kunde verwalten muss (wobei 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 übernimmt. - WAN-Abhängigkeit (für die Console): Die kundenseitig gehostete zentrale Console muss sich, falls verwendet, mit jedem Rechenzentrum verbinden. |
| 3A. Managed Control Plane (geteilte globale Datenbank) | - Vereinfachter K8s-Betrieb: Codesphere verwaltet die K8s-Control-Planes für jedes Kunden-Rechenzentrum. - Einheitliche Verwaltung (Tenant): Zentrale Management Console und geteilte Datenbank für den Tenant (gehostet von Codesphere). - Kontrolle des Kunden über Worker: Der Kunde verwaltet die K8s-Worker-Nodes und den 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 geteilten Datenbank (auf Tenant-Ebene): Ähnlich wie bei 2A, jedoch für die globalen Metadaten des Tenants (Single Point of Failure, potenzieller Engpass, von Codesphere verwaltet). - Internetverbindung: Robuste Verbindung zwischen den Kunden-Rechenzentren und den von Codesphere gehosteten Diensten erforderlich. - Datenübertragung (Metadaten): Die Workspace-Metadaten sowie Benutzer-/Teaminformationen des Tenants liegen in einer von Codesphere gehosteten Datenbank. |
| 3B. Managed Control Plane (individuelle Datenbanken je Rechenzentrum - kundenlokal) | - Vereinfachter K8s-Betrieb: Codesphere verwaltet die K8s-Control-Planes. - Maximale Datenisolation (Metadaten): Die individuellen Codesphere-Datenbanken sind lokal und werden kundenseitig innerhalb jedes Rechenzentrums verwaltet. - Kontrolle des Kunden über Worker & Datenbanken: Der Kunde verwaltet die K8s-Worker-Nodes, den lokalen Ceph-Speicher und die lokalen 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 des Kunden für die Datenbank (relativ): Der Kunde ist für Verwaltung sowie 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. |
Wichtige Überlegungen für den Kunden:
- Sicherheits- und Souveränitätsanforderungen: Wie streng sind die Anforderungen an Datenisolation und Kontrolle, insbesondere im Vergleich von Metadaten zu Workload-Daten?
- Betriebliche Kapazität: Welches Maß an Infrastruktur- und Plattformverwaltung (K8s, Datenbanken, Console) kann das Team des Kunden bewältigen, wobei zu berücksichtigen ist, dass der optimierte Installer von Codesphere die Ersteinrichtung vereinfacht?
- Skalierbarkeit & Multi-Rechenzentrum-Anforderungen: Besteht die Notwendigkeit, Workloads über mehrere Rechenzentren mit einheitlichen oder isolierten Benutzerbasen/Metadaten zu verwalten?
- Konnektivität: Welche Einschränkungen und welche Zuverlässigkeit weisen die WAN-/Internetverbindungen auf, insbesondere hinsichtlich optionaler versus erforderlicher 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?