Abrechnung und Kontingente

CPU und Arbeitsspeicher werden nach Requests abgerechnet, nicht nach Verbrauch

Abgerechnet wird, was deine Pods unter resources.requests anfordern, nicht was sie tatsächlich auslasten. Ein Pod, der 1 vCPU anfordert und davon 5 % benutzt, kostet trotzdem die volle vCPU.

Warum das so ist

Ein Request ist eine Reservierung. Der Scheduler stellt deinen Pod auf einen Node und hält dort genau diese Kapazität frei, unabhängig davon, ob du sie benutzt. Kein anderer Tenant kann sie bekommen. Reservierte Kapazität ist belegte Kapazität, und deshalb ist der Request die Größe, nach der abgerechnet wird.

Gezählt wird der Request eines Pods, der tatsächlich läuft, und zwar über die Zeit gemessen statt stichprobenartig. Ein Pod wird ab dem Moment abgerechnet, in dem er läuft, bis er stoppt, in Schritten von einer Minute. Ein Job, der fünf Minuten läuft, kostet also fünf Minuten seiner Requests und nicht eine Stunde, und ein bereits beendeter Pod, dessen Objekt noch existiert (etwa aus der aufbewahrten CronJob-Historie), kostet gar nichts.

Praktisch heißt das: Zu großzügig gesetzte Requests sind der teuerste Fehler, den du in einem Manifest machen kannst. Er fällt nicht auf, weil nichts kaputtgeht. Die Anwendung läuft, die Auslastung sieht entspannt aus, nur die Rechnung passt nicht zu dem, was tatsächlich gearbeitet wird.

Dieselbe Zahl steuert auch dein Kontingent: Ein Pending-Pod bedeutet fast immer, dass die Summe der Requests im Namespace ausgeschöpft ist, nicht dass die Anwendungen zu viel verbrauchen.

Storage

Storage wird nach bereitgestellter PVC-Kapazität abgerechnet, nicht nach geschriebenen Bytes. Ein leeres 100-GiB-Volume kostet so viel wie ein volles.

Dazu kommt ein Minimum von 10 GiB pro Volume. Ein kleineres PVC wird ganz normal provisioniert, aber trotzdem mit 10 GiB abgerechnet. Details und die Storage-Klassen stehen unter Storage.

Ausgehender Traffic

Traffic wird nach tatsächlich übertragenen Daten abgerechnet. Hier zahlst du also wirklich nur, was fließt.

Requests richtig setzen

Requests wegzulassen macht einen Pod nicht kostenlos

Ein Container ohne Requests wird nicht abgelehnt. Dein Namespace setzt stattdessen einen Standard ein, aktuell 50m CPU und 64Mi Speicher, mit Limits von 200m und 256Mi. Dieser Standard wird abgerechnet wie jeder andere Request, und die Limits gelten, ob sie zu deiner Anwendung passen oder nicht. "Keine Requests" heißt also "jemand anderes hat deine Requests gewählt", nicht "keine Kosten".

• Setz den Request auf das, was die Anwendung im Normalbetrieb braucht. Nicht auf das Maximum, das sie im schlimmsten Fall erreichen könnte.
• Setz das Limit darüber. Zwischen Request und Limit liegt der Spielraum für Lastspitzen. Den bezahlst du nicht dauerhaft mit, weil abgerechnet wird, was reserviert ist.
• Rate nicht, miss. Das Portal hat schon gemessen: Die Workloads-Ansicht vergleicht den Request jedes Workloads mit dem tatsächlichen Verbrauch der letzten sieben Tage und schlägt einen passenden Wert vor, mit der Ersparnis daneben. Siehe Was du im Portal siehst. Wenn du es lieber im Cluster hast, sammelt der VPA im Empfehlungsmodus (updateMode: "Off", siehe Autoscaling) dieselbe Art von Vorschlag, ohne etwas zu ändern.

Zu klein ist allerdings auch nicht gratis: Ein zu niedriger CPU-Request bedeutet unter Last weniger Rechenzeit, weil die CPU zwischen den Pods nach ihren Requests gewichtet wird. Ein zu niedriger Speicher-Request macht deinen Pod zum ersten Kandidaten, wenn ein Node Speicher zurückholen muss. Das Ziel ist nicht der kleinste Wert, sondern der ehrliche.

Nichts zahlen, während nichts läuft

Weil sich die Abrechnung nach den Requests laufender Pods richtet, kostet ein Workload ohne laufende Pods nichts an CPU und Arbeitsspeicher. Einen HTTP-Service kannst du so einrichten, dass er auf null Replicas heruntergeht, wenn ihn niemand aufruft, und beim nächsten Request wieder aufwacht. Für alles, was den größten Teil des Tages ungenutzt ist, lohnt sich das. Siehe Scale-to-Zero.

Das senkt den Compute-Anteil deiner Rechnung, nicht die ganze Rechnung. Volumes bleiben belegt, während die Pods schlafen, Storage und Grundgebühr laufen also normal weiter.

Was du im Portal siehst

Das Portal zeigt ohne kubectl, was läuft und was es kostet: das Kontingent gegen deine Grenzen, Kosten pro Workload, Verbrauch seit Monatsbeginn samt Hochrechnung und die Untergrenze, also was der Namespace kostet, wenn alles schläft.

Zwei Dinge dort solltest du einrichten, bevor du sie brauchst: die Größenvorschläge, der schnellste Weg zu einem überdimensionierten Workload, und ein Ausgabenlimit für den Namespace. Siehe Was du im Portal siehst.

Kontingente und Preise

Die Kontingente des kostenlosen Namespace stehen unter Free Tier.

Für die kostenpflichtigen Tarife gelten die Preise und Kontingente, die auf der Kubernetes-Produktseite und im Preisrechner stehen. Deine tatsächliche Nutzung siehst du im Portal unter Kubernetes.

Wie es weitergeht

• Scale-to-Zero, um idle Services nicht mehr zu zahlen
• Überraschungen bei Storage und Kosten, wenn die Rechnung nicht passt