Mit einem Pool Claim sagen Sie, welche Nodes ein Zweck braucht – für einen Scanner, einen Batch-Lauf oder einen einzelnen Mandanten. Clusterward legt dafür einen eigenen Kapsule-Node-Pool an, hält ihn passend und gibt ihn wieder frei. Ephemere Claims laufen ab null Nodes und lösen sich im Leerlauf selbst auf, Sie zahlen also nur, solange sie genutzt werden.
Ein Pool Claim ist eine Anfrage nach eigener Node-Kapazität auf einem Cluster, den Clusterward angelegt hat. Sie geben an, wer sie braucht und wofür, welchen Node-Typ und wie viele Nodes höchstens. Clusterward macht daraus einen echten Kapsule-Node-Pool, markiert ihn mit seinem Zweck und hält ihn mit dem Claim im Einklang: anlegen, Grenzen anpassen, freigeben. Mit einem Label und einem Taint gehört der Pool allein diesem Zweck.
Cluster-Seite → „Pool claims“ → „New claim“: Verbraucher, Zweck, Node-Typ, Größe, Lebenszyklus und – für die Isolation – Label und Taint.
Clusterward legt den Kapsule-Pool mit Autoscaling-Grenzen an und markiert ihn mit seinem Zweck. Der Status wechselt von „pending“ auf „active“.
Pods mit passendem nodeSelector und Toleration laufen auf dem Pool; neue Nodes bekommen Label und Taint innerhalb einer Minute.
Ohne Heartbeat endet ein ephemerer Claim nach der Leerlaufzeit; „Release…“ beendet jeden Claim. Clusterward leert und löscht den Pool.
Verbraucher und Zweck sind freie Angaben – derselbe Mechanismus dient jeder Arbeitslast.
Sicherheitsscans laufen auf eigenen Nodes statt neben Ihren Anwendungen – und der Pool verschwindet, wenn der Scan vorbei ist.
Nächtliche Läufe oder größere Berechnungen bekommen Nodes nur, wenn Pods darauf warten. Danach skaliert der Pool auf null.
Ein dauerhafter Claim mit Label und Taint gibt einem Kunden eigene Nodes – die Isolation, die manche Verträge verlangen.
Ein ephemerer Claim startet bei null Nodes. Der Cluster-Autoscaler fügt Nodes nur für wartende Pods hinzu, und Clusterward gibt den Pool im Leerlauf frei.
Clusterward setzt Label und Taint auf jeden Node des Pools und wiederholt das bei jedem Durchlauf, auch für Nodes, die der Autoscaler später hinzufügt. Fremde Taints bleiben erhalten.
Ein Programm legt Claims über die REST-API an, hält sie mit einem Heartbeat am Leben und gibt sie frei – mit einem API-Token, dessen Rolle das erlaubt.
Die Karte „Pool claims“ zeigt jeden Claim mit Größe, Lebenszyklus, Status und Pool. Anlegen und Freigeben stehen im Audit-Log.
„Release…“ verlangt den Namen des Claims als Bestätigung und berührt nie einen anderen Pool oder die Grundkapazität des Clusters.
Sie wählen den Scaleway-Instanztyp, der zum Zweck passt – vom kleinen Node für einen Scanner bis zur großen Maschine für Rechenjobs.
Der Lebenszyklus entscheidet, ob der Pool im Leerlauf verschwindet oder immer bereitsteht. Ein ephemerer Claim lebt, solange sein Verbraucher einen Heartbeat sendet – im Cockpit „Touch (keep alive)“, für ein Programm der Touch-Aufruf der API. Über die API weckt ein Touch auch einen freigegebenen Claim wieder auf.
| Lebenszyklus | Größe | Wann sinnvoll |
|---|---|---|
| Ephemer | 0 bis Maximum, Autoscaler nach Bedarf | Scans, Batch-Läufe, Tests – alles mit Anfang und Ende |
| Dauerhaft | Minimum bis Maximum, nie unter dem Minimum | Kapazität, die immer bereitstehen muss, etwa ein Pool für einen Mandanten |
| Leerlaufzeit | in Minuten, nur bei ephemer | So lange darf der Heartbeat ausbleiben, bevor der Pool freigegeben wird |
Pool Claims arbeiten mit Kapsule-Clustern, die Clusterward angelegt hat. Pods kommen auf den Pool, wenn sie ihn mit einem nodeSelector ansprechen und den Taint tolerieren; alle anderen Pods bleiben fern.
| Thema | So ist es |
|---|---|
| Cluster | nur von Clusterward angelegte Kapsule-Cluster |
| Größe | bis 50 Nodes pro Pool |
| Isolation | bis 20 Labels und 10 Taints; NoSchedule, PreferNoSchedule oder NoExecute |
| Freigabe | Pods ziehen auf andere Pools um, wenn sie passen; sonst warten sie |
| Kosten | kein Aufpreis bei Clusterward; Scaleway berechnet die laufenden Nodes |
| Rechte | Anlegen und „Touch“ mit „Operate“, „Release…“ mit „Manage“ im Bereich Provisionierung |
Pool Claims ergänzen die Node-Pools, die Sie unter Cluster-Updates von Hand pflegen: Dort steuern Sie Größe und Kubernetes-Version, ein Claim kümmert sich um Kapazität, die kommt und geht. Wie ein Cluster entsteht, auf dem Claims laufen, zeigt Cluster-Provisioning.
Für eine eigene Infrastruktur pro Kunde passen Pool Claims zu den Tenant-Pipelines und zur Seite für SaaS-Anbieter.
Kubernetes-Upgrade, Node-Pools und Add-ons aus dem Cockpit.
Zu Cluster-UpdatesKapsule-Cluster in Minuten, sicher ab Werk.
Zu Cluster-ProvisioningKunden-Onboarding mit eigener Datenbank, Speicher und Domain pro Mandant.
Zu SaaS-AnbieterIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir legen einen ephemeren Claim für einen Scanner an, zeigen Label und Taint auf den Nodes und lassen den Pool im Leerlauf wieder verschwinden.
