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. Node-Kapazität für einen bestimmten Zweck, die kommt und geht, legen Pool Claims an.
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 DeploymentsEin IAM-Schlüssel des Zielprojekts mit vollem Zugriff auf Kubernetes, VPC, Private Networks, Public Gateways, IPAM, Managed Databases und Container Registry. Private Networks sind bei Scaleway ein eigener Berechtigungssatz, VPC allein reicht nicht. Optional kommen Block Storage für Volume-Snapshots, Observability für Datenbank-Metriken und IAM Manager für den Push-Schlüssel der Registry dazu. „Testen“ zeigt pro Produkt, was der Schlüssel darf. Beim Speichern prüft das Cockpit jeden Satz einzeln und nennt einen fehlenden, bevor etwas gespeichert wird.
Ihre 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.
