Clusterward läuft als SaaS. Sie brauchen keine Installation, nur ein Scaleway-Projekt, einen IAM-Schlüssel und ein Repository mit Dockerfile. Diese Anleitung führt vom Demo-Termin bis zur ersten Anwendung mit Datenbank, Domain und Alarmkanal.
Alles, was Clusterward anlegt, entsteht in Ihrem eigenen Scaleway-Projekt. Legen Sie deshalb vorab ein Projekt an, das nur Clusterward gehört, und erzeugen Sie darin einen IAM-Schlüssel. Eine Domain brauchen Sie erst in Schritt fünf, ein Repository mit Dockerfile in Schritt vier. Der ganze Weg dauert mit einem provisionierten Cluster etwa dreißig Minuten, die meiste Zeit davon wartet Scaleway.
Ein eigenes Projekt für Clusterward, damit Kosten und Rechte sauber getrennt sind.
Mit den Berechtigungen aus der Tabelle unten; „Testen“ prüft sie vor dem Speichern.
Oder ein fertiges Image in einer Registry, oder ein Helm-Chart.
Bei Cloudflare oder Scaleway DNS, wenn Records automatisch entstehen sollen; sonst legen Sie den Record selbst an.
In der Demo sehen wir uns Ihren Anwendungsfall an: welche Anwendungen, wie viele Kunden, welche Datenbanken. Danach richten wir Ihren Workspace ein: eine eigene Control-Plane-Datenbank, ein eigener Datenschlüssel, ein eigener Backup-Bucket und Ihre Adresse unter clusterward.app. Ihr erster Administrator bekommt eine Einladung per E-Mail, setzt sein Passwort selbst und richtet beim ersten Anmelden die Pflicht-2FA per Authenticator-App ein. Auf dem Dashboard wartet dann eine Checkliste mit den nächsten Schritten.
Dreißig Minuten, live an Ihrem Anwendungsfall, mit Ihren Fragen zu Betrieb und Preis.
Adresse, Einladung für den ersten Administrator, Testphase von dreißig Tagen mit zwei Clustern.
Beim ersten Anmelden mit einer beliebigen TOTP-App; ohne zweiten Faktor gibt es keinen Zugang.
Unter Infrastruktur → Provisioning legen Sie ein Provisioning-Profil an: Name, Projekt-ID und der IAM-Schlüssel des Projekts. Clusterward prüft den Schlüssel sofort gegen Scaleway, jede Berechtigung einzeln, lehnt ihn ab, wenn eine Pflicht-Berechtigung fehlt, speichert ihn verschlüsselt und zeigt ihn nie wieder an. „Testen“ meldet pro Produkt, was der Schlüssel darf, und holt den Projektnamen aus der Konsole. Beim Anlegen führt das Cockpit durch IAM-Anwendung und Berechtigungssätze und prüft jeden Satz einzeln. Fehlt eine Berechtigung, sehen Sie es hier und nicht erst mitten im Provisioning.
In der Scaleway-Konsole unter IAM, mit den Policies aus der Tabelle unten, nur für dieses Projekt.
Access Key und Secret Key kopieren; das Secret zeigt Scaleway nur einmal.
Das Cockpit zeigt die Berechtigungen pro Produkt; Private Networks ist ein eigener Satz.
Der Assistent unter Cluster → Provisionieren fragt Profil, Region, Node-Typ, Anzahl der Nodes und den Adressbereich, der die Kubernetes-API erreichen darf; „Meine IP hinzufügen“ trägt Ihre aktuelle Adresse ein. Clusterward legt Private Network, Public Gateway, Cluster und Node-Pool an, installiert ingress-nginx mit Proxy-Protokoll, cert-manager, metrics-server und Reflector, erzeugt eine private Registry und tauscht das Admin-Token gegen eine eingeschränkte Identität. Der Tracker zeigt jeden Schritt mit Dauer. Haben Sie schon einen Kapsule-Cluster, importieren Sie stattdessen seine Kubeconfig.
Region Paris oder Amsterdam, Node-Typ, Anzahl, API-Adressbereich. Proxy-Protokoll ist voreingestellt.
Kubeconfig einfügen; das Token wird mit einer Leseanfrage geprüft und verschlüsselt gespeichert.
Die Cluster-Seite zeigt Nodes, Pods, Auslastung, Add-ons mit Version und den Load Balancer.
Unter Anwendungen legen Sie ein Projekt an, dazu einen Build: Repository, Branch, Pfad zum Dockerfile, Image-Name und Tag, Build-Quelle Cluster oder GitHub Actions. Für ein privates Repository hinterlegen Sie ein Zugriffstoken, verschlüsselt und schreibgeschützt. Dann eine Umgebung auf dem Cluster, etwa „produktion“, und darin einen Service vom Typ Anwendung, der auf den Build zeigt. Umgebungsvariablen kommen in den verschlüsselten Editor oder aus einer Vorlage.
Branch, Dockerfile, Image-Name; der Name wird einmal aus dem Anwendungsnamen abgeleitet und bleibt.
Eine Umgebung ist eine Namespace auf genau einem Cluster; der Service bekommt Port, Ressourcen und Skalierung.
Im Editor oder per Vorlage; mehrzeilige Werte wie Schlüssel bleiben intakt.
Braucht die Anwendung eine Datenbank, provisionieren Sie zuerst auf der Cluster-Seite eine Managed-Instanz, PostgreSQL oder MySQL, nur mit privatem Endpunkt. Auf der Service-Seite erzeugt „Datenbank anlegen“ dann in einem Schritt Datenbank, Rolle und Passwort, schon zugewiesen; die Verbindungsdaten kopieren Sie in die Variablen. Für die Domain tragen Sie den Host auf der Domains-Karte ein: Liegt er in einer registrierten Cloudflare-Zone, entsteht der Record automatisch, sonst legen Sie ihn selbst an. Die TLS-Strategie bleibt auf „auto“.
Engine wählen, Name, Netz des Clusters; die Instanz hat nie einen öffentlichen Endpunkt.
Name aus der Domain abgeleitet, Passwort generiert, Verbindungsdaten zum Kopieren.
Zone bei Cloudflare oder Scaleway DNS vorher unter DNS registrieren, dann entsteht der Record von allein.
„Deploy“ startet den Build und den Rollout im Hintergrund; die Deployment-Zeile zeigt Build, Registry-Prüfung, Rollout und Health-Check. Sobald die Pods bereit sind und das Zertifikat ausgestellt ist, antwortet der Host. Die Instanzen-Karte zeigt Pods mit Auslastung und Logs. Zum Schluss legen Sie unter Settings → Notifications einen Slack-, Teams- oder E-Mail-Kanal an und abonnieren fehlgeschlagene Deployments, auffällige Pods und ablaufende Zertifikate.
Antwort sofort, Fortschritt in der Deployment-Zeile; Abbruch während des Builds möglich.
Zertifikat per Let’s Encrypt in Minuten; hinter Cloudflare-Proxy sofort.
„Test senden“ prüft die Zustellung; Alarme kommen einmal pro Ereignis, mit Entwarnung.
Die IAM-Anwendung des Profils braucht diese Policies. Die ersten sieben sind Pflicht und gelten für das eine Projekt, die übrigen sind optional; ProjectReadOnly und IAMManager vergeben Sie auf Ebene der Organisation. „Testen“ im Cockpit zeigt pro Produkt, ob der Schlüssel reicht. Zwei Fallstricke aus dem Betrieb: VPC deckt Private Networks nicht ab, und ohne Observability liefert das Dashboard keine Datenbank-Metriken. Für Object Storage und den Secret Manager tragen Sie besser eigene Schlüssel ein.
| Produkt | Policy | Wofür |
|---|---|---|
| Kubernetes | KubernetesFullAccess | Cluster, Node-Pools, API-Zugriffsliste |
| VPC | VPCFullAccess | Das VPC, in dem das private Netz liegt |
| Private Networks | PrivateNetworksFullAccess | Eigener Satz, nicht in VPC enthalten |
| Public Gateway | VPCGatewayFullAccess | Ausgehender Zugang der Nodes ohne öffentliche IP |
| IPAM | IPAMFullAccess | Adressen im privaten Netz für Nodes und Datenbanken |
| Managed Databases | RelationalDatabasesFullAccess | Instanzen, Datenbanken, Nutzer, Backups |
| Container Registry | ContainerRegistryFullAccess | Registry für Ihre Images, Pull der Nodes |
| Block Storage | BlockStorageFullAccess | Optional: Snapshots und Wiederherstellung von Volumes |
| Observability | ObservabilityFullAccess | Optional: Datenbank-Metriken im Dashboard |
| Secret Manager | SecretManagerFullAccess | Optional: nur wenn der Schlüssel auch einen Secret-Store bedient |
| Projekt | ProjectReadOnly | Optional, Organisation: Projektname im Cockpit |
| IAM | IAMManager | Optional, Organisation: Push-Schlüssel nur für die Registry, pro Cluster |
Der Assistent erzeugt Netz, Gateway, Cluster und Pool sicher ab Werk: Nodes ohne öffentliche IP, API nur aus Ihrem Adressbereich, Basis-Komponenten in geprüften Versionen. Jede Ressource ist mit der Cluster-ID getaggt, ein abgebrochener Lauf lässt sich wiederholen, der Teardown entfernt genau das Angelegte.
Zum Cluster-ProvisioningEin vorhandener Kapsule-Cluster wird über seine Kubeconfig registriert. Clusterward prüft das Token, speichert es verschlüsselt und liest zunächst nur. Add-ons, die schon laufen, erkennt die Setup-Karte mit Version; die eingeschränkte Operator-Identität prägen Sie mit einem Klick. Der Teardown bleibt für angebundene Cluster gesperrt.
Zur Migration bestehender SetupsMit dem ersten Service steht der Rahmen. Weitere Umgebungen wie Staging entstehen in Minuten, Kollegen bekommen Rollen mit Anwendungsbereich, und wer denselben Stack für viele Kunden ausrollt, beschreibt ihn einmal als Tenant-Pipeline.
Persistente Dateien gehören auf Volumes mit Snapshots, und die Kubernetes-Version sowie die Add-ons pflegen Sie später über Cluster-Updates. Begriffe, die in dieser Anleitung neu waren, erklärt das Glossar.
Wenn die erste Anwendung läuft: Logs, Auslastung und Uptime-Checks zeigt Logs & Monitoring.
Eine fertige Anwendung zum Ausprobieren: WordPress aus dem App-Katalog.
Für den Start nicht. Die Anleitung kommt ohne kubectl aus: Cluster, Anwendung, Datenbank und Domain entstehen im Cockpit. Kubernetes-Wissen hilft später beim Lesen von Logs und beim Verstehen, warum ein Pod nicht startet; die Instanzen-Karte zeigt beides im Cockpit.
Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenIn der Demo gehen wir diese sechs Schritte an Ihrem Scaleway-Projekt durch und richten Ihren Workspace direkt ein.
