Clusterward legt Ihren Scaleway-Kapsule-Cluster mit privatem Netzwerk, Gateway und gesperrtem API-Zugang an, installiert Ingress-Controller und cert-manager und zeigt jeden Schritt mit Dauer im Cockpit.
Cluster-Provisioning ist der Assistent, mit dem Clusterward einen Kapsule-Cluster samt Netzwerk in Ihrem Scaleway-Projekt erzeugt. Sie wählen ein Provisioning-Profil (den IAM-Schlüssel des Projekts), eine Region, den Node-Typ und den CIDR-Bereich, der die Kubernetes-API erreichen darf. Clusterward erzeugt daraus ein Private Network, ein Public Gateway mit Masquerade, den Cluster mit Cilium und den Node-Pool ohne öffentliche IPs, holt die Kubeconfig, ersetzt das Admin-Token durch eine eigene, eingeschränkte Identität und installiert die Basis-Komponenten. Jede erzeugte Ressource ist mit der Cluster-ID markiert, damit ein Wiederholungslauf sie übernimmt und ein Teardown genau sie entfernt.
Ein Provisioning-Profil ist der geprüfte IAM-Schlüssel eines Scaleway-Projekts.
Private Network und Public Gateway mit Masquerade entstehen zuerst.
Kapsule mit Cilium, an das private Netz gebunden, API-ACL gesetzt.
Node-Pool mit deaktivierter öffentlicher IP im gewählten Typ.
Kubeconfig geholt, eingeschränkte Identität geprägt, Admin-Token verworfen.
Ingress-Controller, cert-manager, Reflector und eine private Registry-Namespace.
Die Entscheidungen, die sonst in einem Terraform-Modul oder einem Runbook stecken, sind hier Voreinstellungen.
Ein Profil pro Scaleway-Projekt: Der IAM-Schlüssel wird vor dem Speichern geprüft, verschlüsselt abgelegt und nie wieder ausgegeben. „Testen“ zeigt die Berechtigungen pro Produkt.
Nodes ohne öffentliche IP, Kubernetes-API nur aus Ihrem CIDR, Verkehr nach außen über das Gateway. Nichts davon muss nachträglich gehärtet werden.
Jede Ressource trägt die Cluster-ID als Tag. Ein Neustart übernimmt vorhandene Teile, der Teardown löscht genau das Erzeugte und nichts anderes.
Nodes, Pods, Kapazität und Auslastung aus dem metrics-server, auffällige Pods nach einer Schonfrist, Load Balancer mit Scaleway-Zuordnung.
Ein ServiceAccount mit einer ClusterRole, die Workloads verwalten darf, aber keine Cluster-RBAC oder CRDs schreibt. Rotierbar und widerrufbar aus dem Cockpit.
Beim Anlegen entsteht eine private Container-Registry-Namespace im Projekt des Clusters, weil Pull-Rechte dem Projekt folgen. Dazu entsteht ein Push-Schlüssel, der nur diese Registry nutzen darf: Builds im Cluster pushen damit und halten nie den Schlüssel des Profils.
Beim Anlegen eines Profils führt das Cockpit durch IAM-Anwendung und Berechtigungssätze, mit Kopier-Knopf. Beim Speichern wird jeder Satz geprüft; ein fehlender wird benannt, bevor etwas gespeichert ist.
Ein Hilfe-Artikel erklärt, was Clusterward mit dem Schlüssel anlegt und liest, wie er verschlüsselt liegt und wie Sie ihn rotieren oder widerrufen.
Die Karte API-Zugriff zeigt, welche Adressen die Kubernetes-API erreichen, und erlaubt die eigene mit einem Klick – ohne Scaleway-Konsole.
ingress-nginx oder Envoy Gateway, mit Proxy-Protokoll für echte Client-Adressen.
Let’s-Encrypt-Issuer für HTTP-01 und DNS-01, bereit für Wildcards.
Spiegelt Wildcard-Secrets automatisch in jede Namespace.
Das CNI von Kapsule, Grundlage für die optionalen NetworkPolicies.
Jede Ressource entsteht in Ihrem Scaleway-Projekt und bleibt Ihr Eigentum. Clusterward hält nur die IDs.
| Ressource | Einstellung | Warum |
|---|---|---|
| Private Network | Eigenes Netz pro Cluster | Datenbanken und Nodes sprechen privat |
| Public Gateway | Masquerade aktiv | Ausgehender Verkehr ohne öffentliche Node-IPs |
| Kapsule-Cluster | Cilium, API-ACL auf Ihren CIDR | NetworkPolicies und gesperrte API |
| Node-Pool | public_ip_disabled | Keine Angriffsfläche von außen |
| Registry-Namespace | Privat, Name des Clusters | Pull-Rechte folgen dem Projekt |
| Operator-Identität | ServiceAccount + ClusterRole | Kein Admin-Token im Umlauf |
Steht der Cluster, rollen Sie Anwendungen über Deployments aus. Eine private Managed-Datenbank hängt mit einem Klick am selben Netz, beschrieben unter Managed Datenbanken.
Kubernetes-Version, Node-Pools und Add-ons pflegen Sie später ohne Konsole über Cluster-Updates. Wie der erste Cluster in der Praxis aussieht, zeigt der Leitfaden Erste Schritte.
Kubernetes-Version, Node-Pools und Add-ons aus dem Cockpit.
Zu Cluster-UpdatesRollen, Pflicht-2FA, Audit-Log und IP-Allowlist.
Zu Sicherheit & ZugriffGit, Container-Image oder Helm-Chart – mit Health-Check ausgerollt.
Zu DeploymentsIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir legen gemeinsam einen Kapsule-Cluster in Ihrem Scaleway-Projekt an und rollen die erste Anwendung darauf aus.
