Text size
Ausprobiert & getestet6 Min. Lesezeit

Wie viel kosten die Kubernetes jedes Teams?

OpenCost und Kubecost beantworten die Frage, die sich die Finanzmärkte immer wieder stellen.

What does each team's Kubernetes cost?
KI-generierte Illustration

Auf einer Cloud-Rechnung sieht Kubernetes einfach aus: Sie bezahlen für Knoten. Zwanzig VMs, ein Lastbalancer, ein paar Festplatten. Aber wer benutzt diese Knoten eigentlich? Zehn Teams, fünfzig Dienststellen, ein paar hundert Kapseln, alle teilen die gleichen Maschinen. Wenn die Finanzen fragen: "Wie viel kostet die Infrastruktur des Suchteams?", kann die Cloud-Rechnung nicht antworten.

Das ist das Kubernetes-Kosten-Sichtbarkeitsproblem. Hier ist, wie man es löst, und wie man die Rechnung reduziert, sobald man sie sehen kann.

Ich teile die Rechnung auf.

Um Clusterkosten an Teams zuzuweisen, müssen Sie wissen, wie viel von jedem Knoten jeder Pod verwendet oder reserviert und was dieser Knoten kostet.

OpenCost ist ein CNCF-Projekt, das genau das tut. Sie vereint:

  • Ressource der Pod Anträge und tatsächliche Verwendung (CPU, Speicher, GPU, Speicherung).
  • Preise Sie können die Daten über die Abrechnungs-API Ihres Cloud-Anbieters (einschließlich Rabatte und Spot-Preise) oder kundenspezifische Preise für On-Premises erhalten.
  • Die Metadaten von Kubernetes: Namenräume, Etiketten, Bereitstellungen.

Das Ergebnis: Kosten pro Namespace, pro Etikett (wie team oder app), pro Arbeitslast, pro Stunde.

Kubecost (jetzt Teil von IBM) basiert auf OpenCost mit weiteren Funktionen: Einsparungsempfehlungen, Budgets, Warnungen, Multi-Cluster-Ansichten und einer polierten Benutzeroberfläche. Cloud-Anbieter haben auch ihre eigenen Kostenfunktionen für Kubernetes, wie die Aufteilung der Kosten für EKS in AWS und die Kostenallokation in GKE und AKS.

helm install opencost opencost/opencost --namespace opencost --create-namespace
kubectl port-forward -n opencost svc/opencost 9090

Ein paar Minuten später sehen Sie die Kosten pro Namespace.

Das Problem der "Leerlaufzeit"

Eine Sache, die Teams beim ersten Mal überrascht: Ein großer Teil der Kosten gehört niemandem. Das ist... Leerlaufkapazität: Teile von Knoten, die kein Pod angefordert hat.

Wenn Ihre Knoten nur 50% der Anfragen durchschnittlich haben, ist die Hälfte des Clusters untätig. Sie entscheiden, wie Sie damit umgehen: Sie verteilen sie proportional, weisen sie dem Plattformteam zu oder (am besten) reduzieren sie sie.

Man kann nicht reparieren, was man nicht sieht. Sobald die Teams ihre Kubernetes-Kosten sehen, geschieht die Hälfte der Optimierung von selbst.

Etiketten machen oder brechen es

Die Kostenverteilung ist nur so gut wie die Etiketten. Einig auf ein paar Standard-Etiketten für jede Arbeitsbelastung:

  • team oder owner
  • app oder service
  • environment
  • cost-center (falls die Finanzen dies benötigen)

Durchsetzen Sie sie mit einer Richtlinie (Kyverno oder Gatekeeper), so dass neue Workloads nicht ohne sie bereitgestellt werden können.

Verpackungsknoten fest

Wenn man einmal die Abfälle sieht, kommt es in der Regel darauf an, sie zu reduzieren. Nutzung: mehr nützliche Arbeit aus jedem Knoten zu bekommen.

  • Richtige Anfragen. Überforderte Kapseln haben keine Reservekapazität. Die Empfehlungen der VPA und Goldlöckchen helfen, realistische Werte zu finden.
  • - Die Konsolidierung. Schreiner Sie sucht ständig nach unterbenutzten Knoten und verlegt die Kapseln, um sie zu entfernen oder durch kleinere, billigere zu ersetzen. Der Cluster Autoscaler verkleinert auch unterbenutzte Knoten, konservativ.
  • Bessere Entscheidungen. Mischte Instanztypen, neuere Generationen und ARM-basierte Knoten können die Kosten pro CPU senken.
  • - Einfach einpacken. Der Standardplaner verteilt die Kapseln. Eine Planerkonfiguration, die vollere Knoten bevorzugt, oder die Konsolidierung von Karpenter, packt sie enger.
  • UnterbrechungBudgets So kann die Konsolidierung Kapseln sicher bewegen, ohne Ausfälle zu verursachen.

Spot auf Kubernetes

Spot-Instanzen können die Knotenkosten drastisch senken. Kubernetes passt perfekt, weil es automatisch die Pods neu planen kann, wenn ein Knotenpunkt verschwindet.

Gute Praxis:

  • A getrennter Spot-Node-Pool (oder Karpenter NodePool) für fehlertolerante Arbeitslasten.
  • Diversifizierung der Instanztypen, also sind Sie nicht von einem Spot Pool abhängig.
  • Bearbeitung von Unterbrechungsmeldungen (Karpenter und der AWS Node Termination Handler tun dies) um Knoten anmutig abzuleiten.
  • Mehrfache Nachbildungen und PDB für alles, was auf Spot läuft.
  • Bleib dran. stateful und kritische Singleton-Workloads auf Anforderung genutzte Knoten.

Showback oder Chargeback

Was machen Sie mit den Zahlen?

  • Showback: zeigen Sie jedem Team seine Kosten. Geld bewegt sich nicht, aber Sichtbarkeit verändert das Verhalten. Die meisten Unternehmen beginnen hier.
  • Rückbuchung: tatsächlich die Teams' Budgets für ihre Nutzung berechnen. Mehr Rechenschaftspflicht, mehr Argumente über Fairness, besonders für geteilte und untätige Kosten.

Ich beginne immer mit Showback: ein wöchentlicher Bericht oder Dashboard pro Team, mit Trends und den größten Chancen. Es ist überraschend, wie schnell Teams ihren eigenen Müll reparieren, wenn die Nummer ihren Namen trägt.

Also, wo fange ich an?

Installieren Sie OpenCost, stellen Sie sicher, dass jede Arbeitslast eine team Die Ergebnisse werden in einem Bericht veröffentlicht. Dann schauen Sie sich die ungenutzte Kapazität an, bestimmen Sie die größten Überforderer und ermöglichen Sie die Konsolidierung. Spott kommt als nächstes, für die Arbeitslasten, die damit umgehen können.

Meine Meinung: Kubernetes macht das Teilen von Infrastruktur einfach und die Kosten unsichtbar. Machen Sie sie sichtbar, und die Teams helfen Ihnen, sie zu schnappen.

Desly