Anforderungen und Dimensionierung
Die erforderlichen Angaben sammeln
Entscheide Folgendes, bevor du irgendetwas bereitstellst:
- Eine Basisdomain, deren DNS-Zone du ändern kannst.
- Eine Data-Center-ID, einen Namen, eine Stadt und einen Ländercode.
- Stabile private IP-Adressen für jede Maschine.
- Eine öffentliche IP-Adresse für die Jumpbox. Diese ist von den Service-Adressen getrennt und sollte SSH nur von vertrauenswürdigen Administrationsnetzwerken akzeptieren.
- Drei stabile, extern erreichbare Service-IP-Adressen: Platform-Gateway, Workspace-Gateway und Workspace-SSH-Proxy.
- Von Codesphere bereitgestellte GitHub-Container-Registry-Zugangsdaten.
Codesphere-Knoten beziehen Images derzeit direkt von
ghcr.io, und Kunden müssen den benötigten Benutzernamen und Token bei Codesphere anfordern. - Zugang zum Codesphere-Paketportal.
- Eine initiale E-Mail-Adresse für den Cluster-Administrator, falls gewünscht.
- OAuth-Zugangsdaten für jeden Git-Provider oder OIDC-Provider, den Nutzer verwenden werden.
- Einen SSH-Schlüssel mit administrativem Zugriff auf alle Hosts.
Zugangsdaten für Git-Provider müssen als vollständige Sätze bereitgestellt werden. Eine GitHub App benötigt beispielsweise ihren App-Namen, ihre Client-ID und ihr Client-Secret; ein OIDC-Provider benötigt seine Issuer-URL, Client-ID und ihr Client-Secret.
Minimal unterstützte Versionen
Codesphere benötigt:
- Ubuntu 22.04 LTS oder eine neuere unterstützte Version
- Kubernetes 1.31 oder neuer
- Ceph 18.2 oder neuer
- x86-64-Hosts (linux/amd64)
Die Kubernetes- und Ceph-Mindestanforderungen gelten auch, wenn diese Komponenten außerhalb von OMS installiert oder verwaltet werden.
POC-Topologie
Verwende diese kompakte Topologie für Proofs of Concept, Evaluierungen und andere Nicht-Produktionsumgebungen:
| Rolle | Anzahl | Pro Maschine | Storage | Öffentliche IP |
|---|---|---|---|---|
| Jumpbox | 1 | 2 vCPU, 4 GiB RAM | 50 GiB SSD-Root-Disk | Ja |
| PostgreSQL | 1 | 2 vCPU, 8 GiB RAM | 200 GiB SSD-Root-Disk | Nicht erforderlich |
| Ceph | 3 | 8 vCPU, 32 GiB RAM | 50 GiB SSD-Root, eine 10-GiB-DB/WAL-Disk und eine 250-GiB-Daten-Disk | Nein |
| Kombinierte k0s-Control-Plane und Worker | 3 | 8 vCPU, 32 GiB RAM | 200 GiB SSD-Root-Disk | Nein |
Alle drei k0s-Knoten nehmen an der Control Plane teil und stellen zusätzlich Workload-Kapazität bereit. Diese Topologie hält die Maschinenanzahl gering, bietet aber nicht denselben Wartungs- und Ausfallspielraum wie die Produktionstopologie. Verwende sie nicht für Produktions-Workloads.
Produktions-Baseline
Verwende in der Produktion getrennte Control-Plane- und Worker-Pools. Beginne mit:
| Rolle | Startanzahl | Pro Maschine | Storage | Öffentliche IP |
|---|---|---|---|---|
| Jumpbox | 1 | 2 vCPU, 4 GiB RAM | 50 GiB SSD-Root-Disk | Ja |
| PostgreSQL Primary | 1 | 2 vCPU, 8 GiB RAM | 200 GiB SSD-Root-Disk | Nein |
| PostgreSQL Replica | 1 empfohlen | 2 vCPU, 8 GiB RAM | 200 GiB SSD-Root-Disk | Nein |
| Ceph | 4 oder mehr | 16 vCPU, 64 GiB RAM | 50 GiB SSD-Root, eine 10-GiB-DB/WAL-Disk und eine oder mehrere 500-GiB-Daten-Disks | Nein |
| Dedizierte k0s-Control-Plane | 3 | 4 vCPU, 8 GiB RAM | 50 GiB SSD-Root-Disk | Nein |
| Dedizierter k0s-Worker | 3 oder mehr | 16 vCPU, 64 GiB RAM | 200 GiB SSD-Root-Disk | Nein |
Drei Control-Plane-Knoten stellen Control-Plane-Quorum und Hochverfügbarkeit sicher. Starte den separaten Worker-Pool mit mindestens drei Maschinen mit 16 vCPU und 64 GiB, und skaliere ihn dann für Workload-CPU, -Memory, Scheduling-Spielraum und die Anzahl gleichzeitiger Knotenausfälle, die die Plattform tolerieren muss. Skaliere Ceph über vier Knoten hinaus und füge Daten-Disks basierend auf Zielen für nutzbare Kapazität, Replikations-Overhead, Recovery-Spielraum und Wachstum hinzu.
Verwende 250-GiB-Ceph-Daten-Disks als POC-Minimum und 500-GiB-Daten-Disks als Produktionsminimum. Stelle Ceph-DB/WAL- und Daten-Disks als eigenständige, unbenutzte Block-Devices bereit; formatiere oder mounte sie nicht. Validiere für die Produktion die Disk-Performance und dimensioniere das DB/WAL-Device für die gewählten Daten-Devices und den Workload.
Verwende dedizierten PostgreSQL-Storage und eine Replica, wenn Datenbankverfügbarkeit erforderlich ist. Die POC-Topologie belässt PostgreSQL auf der Root-Disk und hat keine Replica.
Notiere den Hostnamen und die private IP jedes Hosts. Hostnamen müssen
eindeutig und konsistent auflösbar sein, entweder über internes DNS oder
/etc/hosts.
Weiter geht's
Weiter geht es mit Netzwerk, Firewalls und DNS, dann Hosts bereitstellen.