Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE

Last reviewed 2024-09-11 UTC

In diesem Dokument werden Features und Optionen von Google Kubernetes Engine (GKE) sowie Best Practices zum Ausführen kostenoptimierter Anwendungen in GKE erläutert, um die von Google Cloud gebotene Elastizität zu nutzen. Dabei wird davon ausgegangen, dass Sie mit Kubernetes, Google Cloud, GKE und Autoscaling vertraut sind.

Einleitung

Mit der zunehmenden Verbreitung von Kubernetes verwenden immer mehr Unternehmen und PaaS- sowie SaaS-Anbieter (Platform as a Service bzw. Software as a Service) mehrmandantenfähige Kubernetes-Cluster für ihre Arbeitslasten. Dies bedeutet, dass ein einzelner Cluster Anwendungen ausführen kann, die zu verschiedenen Teams, Abteilungen, Kunden oder Umgebungen gehören. Die von Kubernetes gebotene Mehrmandantenfähigkeit ermöglicht es Unternehmen, einige große Cluster statt mehrerer kleinerer zu verwalten, was Vorteile wie eine adäquate Ressourcennutzung, vereinfachte Verwaltungskontrolle und geringere Fragmentierung mit sich bringt.

Im Laufe der Zeit verzeichnen einige dieser Unternehmen mit schnell wachsenden Kubernetes-Clustern einen unverhältnismäßigen Kostenanstieg. Dies liegt daran, dass traditionelle Unternehmen, die cloudbasierte Lösungen wie Kubernetes einsetzen, keine Entwickler und Operatoren mit Cloud-Fachwissen haben. Diese fehlende Cloud-Bereitschaft führt dazu, dass Anwendungen während Autoscaling-Vorgängen (z. B. Trafficschwankungen während einer normalen Tageszeit), plötzlichen Bursts oder sprunghaften Anstiegen (z. B. TV-Werbespots oder Spitzenereignissen wie Black Friday oder Cyber Monday) instabil werden. Bei dem Versuch, das Problem zu "beheben", neigen diese Unternehmen zu einer Überdimensionierung ihrer Cluster, wie sie es aus einer nicht elastischen Umgebung gewohnt sind. Eine Überdimensionierung hat zur Folge, dass deutlich mehr CPU und Arbeitsspeicher zugewiesen werden, als Anwendungen den größten Teil des Tages verwenden.

In diesem Dokument werden Best Practices zum Ausführen kostenoptimierter Kubernetes-Arbeitslasten in GKE vorgestellt. Das folgende Diagramm veranschaulicht diesen Ansatz.

Grafik: Ansatz zur Kostenoptimierung von Kubernetes-Anwendungen.

Als Grundlage für die Entwicklung kostenoptimierter Anwendungen muss die Kultur der Kosteneinsparung teamübergreifend etabliert werden. Dieser Ansatz verschiebt nicht nur die Kostendiskussionen an den Anfang des Entwicklungsprozesses, sondern zwingt Sie auch dazu, die Umgebung, in der Ihre Anwendungen ausgeführt werden, besser zu verstehen – in diesem Fall die GKE-Umgebung.

Damit Sie niedrige Kosten und Anwendungsstabilität erzielen, müssen Sie einige Features und Konfigurationen wie Autoscaling, Maschinentypen und die Auswahl der Region korrekt festlegen oder optimieren. Ein weiterer wichtiger Aspekt ist Ihr Arbeitslasttyp, da Sie je nach Arbeitslasttyp und Anforderungen Ihrer Anwendung unterschiedliche Konfigurationen anwenden müssen, um Ihre Kosten weiter zu senken. Schließlich müssen Sie Ihre Ausgaben im Blick behalten und die notwendigen Vorkehrungen treffen, damit Sie schon früh in Ihrem Entwicklungszyklus Best Practices erzwingen können.

In der folgenden Tabelle sind die Herausforderungen zusammengefasst, die Sie mit GKE leichter meistern können. Obwohl wir Ihnen empfehlen, das gesamte Dokument zu lesen, können Sie diese Tabelle als Wegweiser für die abgedeckten Themen verwenden.

Herausforderung Aktion
Ich interessiere mich für einfache Kosteneinsparungen in GKE. Wählen Sie die entsprechende Region aus, registrieren Sie sich für Rabatte für zugesicherte Nutzung und verwenden Sie E2-Maschinentypen.
Ich muss meine GKE-Kosten nachvollziehen können. Beobachten Sie Ihre GKE-Cluster sowie die entsprechende Empfehlungen und aktivieren Sie die GKE-Nutzungsmessung.
Ich möchte die Elastizität von GKE für meine vorhandenen Arbeitslasten optimal nutzen. Lesen Sie die Abschnitte Horizontales Pod-Autoscaling und Cluster Autoscaler und machen Sie sich mit den Best Practices unter Autoscaling und Überdimensionierung vertraut.
Ich möchte die effizientesten Maschinentypen verwenden. Wählen Sie den richtigen Maschinentyp für Ihre Arbeitslast aus.
In meinem Cluster sind viele Knoten inaktiv. Lesen Sie die Best Practices für Cluster Autoscaler
Ich muss höhere Kosteneinsparungen bei meinen Batchjobs erzielen. Lesen Sie die Best Practices für Batcharbeitslasten.
Ich muss höhere Kosteneinsparungen bei meinen Bereitstellungsarbeitslasten erzielen. Lesen Sie die Best Practices für Bereitstellungsarbeitslasten.
Ich weiß nicht, wie ich meine Pod-Ressourcenanfragen dimensionieren soll. Verwenden Sie vertikales Pod-Autoscaling (VPA), beachten Sie jedoch die Best Practices unter Horizontales Pod-Autoscaling (HPA) und VPA kombinieren.
Meine Anwendungen sind während Autoscaling- und Wartungsaktivitäten instabil. Bereiten Sie cloudbasierte Anwendungen für Kubernetes vor und machen Sie sich damit vertraut, wie Metrics Server funktioniert und dieser beobachtet wird.
Wie bringe ich meine Entwickler dazu, auf die Ressourcennutzung ihrer Anwendungen zu achten? Etablieren Sie die Kultur der Kosteneinsparung, ziehen Sie die Verwendung von GKE Enterprise Policy Controller in Betracht oder entwerfen Sie eine CI-/CD-Pipeline zum Erzwingen von Kosteneinsparungsverfahren und verwenden Sie Kubernetes-Ressourcenkontingente.
Was sollte ich noch in Betracht ziehen, um meine Systemkosten weiter zu senken? Prüfen Sie Ihre kleinen Entwicklungscluster, Ihre Logging- und Monitoring-Strategien und den interregionalen ausgehenden Traffic in regionalen und multizonalen Clustern.

GKE-Features und -Optionen für die Kostenoptimierung

Kostenoptimierte Kubernetes-Anwendungen sind stark auf GKE-Autoscaling angewiesen. Damit Sie ein Gleichgewicht zwischen Kosten, Zuverlässigkeit und Skalierungsleistung in GKE finden, müssen Sie wissen, wie Autoscaling funktioniert und welche Optionen Ihnen zur Verfügung stehen. In diesem Abschnitt werden GKE-Autoscaling und andere nützliche kostenoptimierte Konfigurationen für Bereitstellungs- und Batcharbeitslasten beschrieben.

Feinabstimmung des GKE-Autoscalings

Autoscaling ist die von GKE angewendete Strategie, um Google Cloud-Kunden nur für das bezahlen zu lassen, was sie benötigen. Zu diesem Zweck wird die Betriebszeit der Infrastruktur minimiert. Mit anderen Worten: Autoscaling spart Kosten, weil Arbeitslasten und ihre zugrunde liegende Infrastruktur gestartet werden, bevor der Bedarf steigt, und wieder heruntergefahren werden, wenn der Bedarf sinkt.

Das folgende Diagramm veranschaulicht dieses Konzept. In Kubernetes sind Ihre Arbeitslasten Containeranwendungen, die in Pods ausgeführt werden. Die zugrunde liegende Infrastruktur, die sich aus einer Reihe von Knoten zusammensetzt, muss genügend Rechenkapazität bereitstellen, um die Arbeitslasten auszuführen.

Grafik: Autoscaling spart Kosten, weil Arbeitslasten und ihre zugrunde liegende Infrastruktur gestartet werden, bevor der Bedarf steigt, und wieder heruntergefahren werden, wenn der Bedarf sinkt.

Wie das folgende Diagramm zeigt, hat diese Umgebung vier Dimensionen der Skalierbarkeit. Die Arbeitslast und Infrastruktur lassen sich horizontal und vertikal skalieren, im ersteren Fall durch Hinzufügen und Entfernen von Pods oder Knoten und im letzteren durch Erhöhen und Verringern der Pod- oder Knotengröße.

Grafik: Die vier Dimensionen der Skalierbarkeit einer kostenoptimierten Umgebung.

GKE handhabt diese Autoscaling-Szenarien mithilfe von Features wie den folgenden:

Das folgende Diagramm veranschaulicht diese Szenarien.

Grafik: Verwendung der Szenarien für HPA, VPA, CA und die automatische Knotenbereitstellung.

Im weiteren Verlauf dieses Abschnitts werden diese Autoscaling-Funktionen von GKE ausführlicher behandelt und weitere nützliche kostenoptimierte Konfigurationen für Bereitstellungs- und Batcharbeitslasten beschrieben.

Horizontales Pod-Autoscaling

Das horizontale Pod-Autoscaling (HPA) ist für die Skalierung von Anwendungen gedacht, die in Pods auf Basis von Messwerten ausgeführt werden, die die Last ausdrücken. Sie können entweder Messwerte zur CPU-Auslastung oder andere benutzerdefinierte Messwerte wie Anfragen pro Sekunde konfigurieren. Kurz gesagt: HPA ergänzt und löscht Pod-Replikate und eignet sich am besten für zustandslose Worker, die sich schnell hochfahren lassen, um auf Nutzungsspitzen zu reagieren, und ordnungsgemäß heruntergefahren werden, um instabile Arbeitslasten zu verhindern.

Grafik: Mit dem Schwellenwert für die HPA-Zielauslastung können Sie festlegen, wann die Skalierung automatisch ausgelöst werden soll.

Wie in der vorherigen Abbildung gezeigt, muss für HPA ein Schwellenwert für die Zielauslastung in Prozent angegeben werden, mit dem Sie festlegen können, wann die Skalierung automatisch ausgelöst werden soll. In diesem Beispiel beträgt die CPU-Zielauslastung 70 %. Das bedeutet, dass die Arbeitslast einen CPU-Puffer von 30 % für die Verarbeitung von Anfragen hat, während neue Replikate hochgefahren werden. Ein kleiner Puffer verhindert frühzeitige Hochskalierungen, kann jedoch Ihre Anwendung während Nutzungsspitzen überlasten. Allerdings verursacht ein großer Puffer Ressourcenverschwendung und damit höhere Kosten. Das genaue Ziel ist anwendungsspezifisch und die Puffergröße muss ausreichen, um Anfragen während einer Nutzungsspitze zwei oder drei Minuten lang verarbeiten zu können. Selbst wenn Sie garantieren, dass Ihre Anwendung in Sekundenschnelle gestartet werden kann, wird diese zusätzliche Zeit benötigt, wenn Cluster Autoscaler neue Knoten in den Cluster aufnimmt oder Pods aufgrund von Ressourcenmangel gedrosselt werden.

Im Folgenden finden Sie Best Practices zum Aktivieren von HPA in Ihrer Anwendung:

Weitere Informationen finden Sie unter Horizontales Pod-Autoscaling konfigurieren.

Vertikales Pod-Autoscaling

Im Gegensatz zu HPA, das Pod-Replikate zur schnellen Reaktion auf Nutzungsspitzen hinzufügt und löscht, beobachtet das vertikale Pod-Autoscaling (VPA) die Pods über einen Zeitraum und ermittelt nach und nach die optimalen CPU- und Arbeitsspeicherressourcen, die von den Pods benötigt werden. Das Festlegen der richtigen Ressourcen ist wichtig für die Stabilität und Kosteneffizienz. Wenn Ihre Pod-Ressourcen zu klein sind, kann Ihre Anwendung gedrosselt werden oder infolge von Fehlern aufgrund mangelnden Arbeitsspeichers ausfallen. Sind Ihre Ressourcen zu groß bemessen, müssen Sie Verschwendung und somit höheren Rechnungen in Kauf nehmen. VPA ist für zustandslose und zustandsorientierte Arbeitslasten vorgesehen, die nicht durch HPA geregelt werden, oder für den Fall, dass Sie die richtigen Pod-Ressourcenanfragen nicht kennen.

Grafik: VPA erkennt, dass ein Pod ständig an seine Grenzen stößt und erstellt den Pod mit größeren Ressourcen neu.

Wie die vorherige Abbildung zeigt, erkennt VPA, dass der Pod ständig an seine Grenzen stößt, woraufhin der Pod mit größeren Ressourcen neu erstellt wird. Auch das Gegenteil ist der Fall, wenn der Pod durchweg nicht ausgelastet ist: eine Herunterskalierung wird ausgelöst.

VPA kann in drei verschiedenen Modi ausgeführt werden:

  • Aus: In diesem Modus, auch Empfehlungsmodus genannt, wendet VPA keine Änderungen auf den Pod an. Die Empfehlungen werden ermittelt und können im VPA-Objekt untersucht werden.
  • Anfänglich: VPA weist Ressourcenanfragen nur bei der Pod-Erstellung zu und ändert sie später nie mehr.
  • Automatisch: VPA aktualisiert CPU- und Arbeitsspeicheranfragen während der Lebensdauer eines Pods. Das bedeutet, dass der Pod gelöscht wird, CPU und Arbeitsspeicher angepasst werden und dann ein neuer Pod gestartet wird.

Wenn Sie VPA verwenden möchten, beginnen Sie am besten mit dem Modus Aus, um VPA-Empfehlungen abzurufen. Achten Sie darauf, dass VPA vor dem Abruf von Empfehlungen 24 Stunden lang ausgeführt wird, idealerweise eine Woche oder mehr. Erst dann, wenn Sie sich Ihrer Sache sicher sind, sollten Sie einen Wechsel in den Modus Anfänglich oder Automatisch erwägen.

Halten Sie sich an die folgenden Best Practices zum Aktivieren von VPA im Modus Anfänglich oder Automatisch in Ihrer Anwendung:

Wenn Sie den Modus Automatisch verwenden möchten, sollten Sie außerdem folgende Best Practices beachten:

  • Sorgen Sie dafür, dass Ihre Anwendung neu gestartet werden kann, während sie Traffic empfängt.
  • Fügen Sie ein Budget für Pod-Störungen (Pod Disruption Budget, PDB) hinzu, um zu steuern, wie viele Pods gleichzeitig heruntergefahren werden können.

Weitere Informationen finden Sie unter Vertikales Pod-Autoscaling konfigurieren.

HPA und VPA kombinieren

Laut offizieller Empfehlung sollten Sie VPA und HPA weder für CPU- noch Arbeitsspeicherressourcen kombinieren. Die Kombination ist aber unbedenklich, wenn Sie den Empfehlungsmodus in VPA oder benutzerdefinierte Messwerte wie Anfragen pro Sekunde in HPA verwenden. Bei der Kombination von VPA mit HPA sollten Sie darauf achten, dass Ihre Deployments genug Traffic empfangen, also durchweg mit mehr Replikaten als die HPA-Mindestanzahl ausgeführt werden. Dadurch kann VPA den Ressourcenbedarf Ihres Pods verstehen.

Weitere Informationen zu VPA-Einschränkungen finden Sie unter Einschränkungen für vertikales Pod-Autoscaling.

Cluster Autoscaler

Cluster Autoscaler (CA) passt die Größe der zugrunde liegenden Computerinfrastruktur automatisch an. CA stellt Knoten für Pods bereit, für deren Ausführung im Cluster kein Platz ist, und entfernt nicht ausgelastete Knoten. CA ist für die Kosten der Infrastruktur optimiert. Anders gesagt: Wenn zwei oder mehr Knotentypen im Cluster vorhanden sind, wählt CA den Knotentyp aus, der am kostengünstigsten ist und den jeweiligen Bedarf decken kann.

Im Gegensatz zu HPA und VPA stützt sich CA nicht auf Lastmesswerte. Stattdessen basiert CA auf Planungssimulation und deklarierten Pod-Anfragen. Es empfiehlt sich, CA immer dann zu aktivieren, wenn Sie entweder HPA oder VPA verwenden. Diese Vorgehensweise gewährleistet, dass Ihre zugrunde liegende Infrastruktur entsprechend wächst, wenn Ihre Pod-Autoscaling-Funktionen feststellen, dass Sie mehr Kapazität benötigen.

Grafik: CA ergänzt und entfernt Rechenkapazität automatisch, um Trafficspitzen zu bewältigen.

Wie diese Diagramme zeigen, ergänzt und entfernt CA Rechenkapazität automatisch, um Trafficspitzen zu bewältigen und Ihnen Geld zu sparen, wenn Ihre Kunden schlafen. Es empfiehlt sich, ein Budget für Pod-Störungen für alle Anwendungen zu definieren. Dies ist besonders wichtig, wenn CA die Kapazität herunterskaliert und das PDB die Anzahl der Replikate steuert, die auf einmal heruntergefahren werden können.

Es gibt bestimmte Pods, die von keiner Autoscaling-Funktionen neu gestartet werden können, wenn sie eine vorübergehende Unterbrechung verursachen. Daher kann der Knoten, auf dem sie ausgeführt werden, nicht gelöscht werden. Beispielsweise werden System-Pods wie metrics-server und kube-dns sowie Pods, die lokalen Speicher verwenden, nicht neu gestartet. Dieses Verhalten kann jedoch geändert werden. Dazu definieren Sie PDBs für diese System-Pods und legen die Annotation "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" für Pods fest, die lokalen Speicher verwenden und vom Autoscaling gefahrlos neu gestartet werden können. Außerdem besteht die Möglichkeit, langlebige Pods, die nicht neu gestartet werden können, auf einem separaten Knotenpool auszuführen, sodass sie das Herunterskalieren von anderen Knoten nicht blockieren. Machen Sie sich schließlich noch mit der Analyse von CA-Ereignissen in den Logs vertraut, damit Sie verstehen, warum eine bestimmte Skalierungsaktivität nicht wie erwartet erfolgt ist.

Falls Ihre Arbeitslasten unbeabsichtigte Knotenneustarts und Kapazitätsverluste unbeschadet überstehen, können Sie mehr Geld sparen, wenn Sie einen Cluster oder Knotenpool mit Spot-VMs erstellen. Damit CA wie erwartet arbeitet, müssen Pod-Ressourcenanfragen groß genug sein, damit der Pod normal funktioniert. Wenn Ressourcenanfragen zu klein sind, stehen Knoten möglicherweise nicht genügend Ressourcen zur Verfügung und Ihre Pods können abstürzen oder Probleme während der Laufzeit haben.

Im Folgenden werden die Best Practices zum Aktivieren von Cluster Autoscaler in Ihrem Cluster zusammengefasst:

  • Verwenden Sie entweder HPA oder VPA, um Ihre Arbeitslasten automatisch zu skalieren.
  • Halten Sie sich unbedingt an die Best Practices, die für das ausgewählte Pod-Autoscaling beschrieben wurden.
  • Passen Sie die Größe Ihrer Anwendung richtig an. Legen Sie dazu geeignete Ressourcenanfragen und -limits fest oder verwenden Sie VPA.
  • Definieren Sie ein PDB für Ihre Anwendungen.
  • Definieren Sie ein PDB für System-Pods, die das Herunterskalieren blockieren könnten. Beispiel: kube-dns Damit vorübergehende Unterbrechungen in Ihrem Cluster vermieden werden, sollten Sie kein PDB für System-Pods wie metrics-server festlegen, die nur ein einziges Replikat haben.
  • Führen Sie kurzlebige Pods und Pods, die neu gestartet werden können, in separaten Knotenpools aus, sodass langlebige Pods deren Herunterskalierung nicht blockieren.
  • Vermeiden Sie Überdimensionierung durch das Konfigurieren von inaktiven Knoten im Cluster. Dazu müssen Sie Ihre Mindestkapazität kennen – bei vielen Unternehmen ist dies nachts – und die Mindestanzahl von Knoten in Ihren Knotenpools festlegen, um diese Kapazität zu unterstützen.
  • Wenn Sie zusätzliche Kapazität zum Verarbeiten von Anfragen während Nutzungsspitzen benötigen, verwenden Sie Pausen-Pods, die unter Autoscaling und Überdimensionierung erläutert werden.

Weitere Informationen finden Sie unter Cluster automatisch skalieren.

Automatische Knotenbereitstellung

Die automatische Knotenbereitstellung (Node Auto-Provisioning, NAP) ist ein Mechanismus von Cluster Autoscaler, der neue Knotenpools automatisch hinzufügt und außerdem deren Größe für den Nutzer verwaltet. Ohne die automatische Knotenbereitstellung startet GKE neue Knoten nur aus der Gruppe von Knotenpools, die vom Nutzer erstellt wurden. Mit der automatischen Knotenbereitstellung kann GKE neue Knotenpools automatisch erstellen und löschen.

Durch die automatische Knotenbereitstellung werden vergleichsweise weniger Ressourcen verschwendet, da Knotenpools dynamisch erstellt werden, die optimal auf die geplanten Arbeitslasten abgestimmt sind. Allerdings kann die Autoscaling-Latenz etwas höher sein, wenn neue Knotenpools erstellt werden müssen. Falls Ihre Arbeitslasten unbeabsichtigte Knotenneustarts und Kapazitätsverluste unbeschadet überstehen, können Sie die Kosten weiter senken, wenn Sie eine Toleranz für Spot-VMs in Ihrem Pod konfigurieren.

Im Folgenden finden Sie Best Practices zum Aktivieren der automatischen Knotenbereitstellung:

  • Halten Sie sich an alle Best Practices für Cluster Autoscaler.
  • Legen Sie minimale und maximale Ressourcengrößen fest, um zu verhindern, dass NAP signifikante Änderungen in Ihrem Cluster vornimmt, wenn Ihre Anwendung keinen Traffic empfängt.
  • Wenn Sie horizontales Pod-Autoscaling für Bereitstellungsarbeitslasten verwenden, sollten Sie einen etwas größeren Zielauslastungspuffer reservieren, da NAP die Autoscaling-Latenz in einigen Fällen erhöhen kann.

Weitere Informationen finden Sie unter Automatische Knotenbereitstellung verwenden und Nicht unterstützte Features.

Autoscaling und Überkapazitäten

Zur Kostenkontrolle empfehlen wir Ihnen dringend, das Autoscaling wie in den vorherigen Abschnitten beschrieben zu aktivieren. Da es keine universelle Konfiguration für alle denkbaren Szenarien gibt, müssen Sie die Einstellungen für Ihre Arbeitslast präzise abstimmen und so dafür sorgen, dass das Autoscaling korrekt auf Trafficanstiege reagiert.

Allerdings können Hochskalierungen aufgrund der Infrastrukturbereitstellung einige Zeit in Anspruch nehmen, wie im Abschnitt Horizontales Pod-Autoscaling erwähnt. Sehen Sie sich die folgende Abbildung an, damit Sie sich eine Vorstellung von den Zeitunterschieden und möglichen Szenarien für die Hochskalierung machen können.

Grafik: Visualisierung des Zeitunterschieds und der möglichen Szenarien für die Hochskalierung.

Wenn der Cluster genügend Platz zum Bereitstellen neuer Pods hat, wird eines der Szenarien für Arbeitslasthochskalierung ausgelöst. Das bedeutet, dass ein vorhandener Knoten, der Ihre Anwendung noch nie bereitgestellt hat, seine Container-Images herunterladen muss, bevor der Pod gestartet wird (Szenario 1). Wenn derselbe Knoten jedoch ein neues Pod-Replikat Ihrer Anwendung starten muss, verkürzt sich die Gesamtzeit für die Hochskalierung, da kein Image-Download erforderlich ist (Szenario 2).

Wenn der Cluster nicht genügend Platz zum Bereitstellen neuer Pods hat, wird eines der Szenarien für Infrastruktur- und Arbeitslasthochskalierung ausgelöst. Das bedeutet, dass Cluster Autoscaler neue Knoten bereitstellen und die erforderliche Software starten muss, bevor er zu Ihrer Anwendung kommt (Szenario 1). Wenn Sie die automatische Knotenbereitstellung verwenden, sind je nach geplanter Arbeitslast möglicherweise neue Knotenpools erforderlich. In diesem Fall erhöht sich die Gesamtzeit für die Hochskalierung, da Cluster Autoscaler Knoten und Knotenpools bereitstellen muss (Szenario 2).

Falls neue Infrastruktur erforderlich ist, sollten Sie nicht zu viel Kapazität in Ihren Cluster packen. Das bedeutete, dass Sie zwar mehr Kapazität als nötig bereitstellen müssen, aber nur zum Reservieren des erforderlichen Puffers, um die erwarteten Lastspitzen während der Hochskalierung zu bewältigen.

Für diese Art der Überdimensionierung gibt es zwei Hauptstrategien:

  • Stimmen Sie das HPA-Nutzungsziel genau ab. Die folgende Gleichung ist ein einfacher und sicherer Weg, ein gutes CPU-Ziel zu finden:

    (1 – Puffer) ÷ (1 + Prozent)

    • Puffer ist ein Sicherheitspuffer, den Sie festlegen können, um eine 100-prozentige Auslastung der CPU zu vermeiden. Diese Variable ist nützlich, da eine 100-prozentige Auslastung der CPU bedeutet, dass die Latenz der Anfrageverarbeitung viel höher als üblich ist.
    • Prozent ist der Prozentsatz des Trafficanstiegs, den Sie in zwei oder drei Minuten erwarten.

    Wenn Sie beispielsweise einen Anstieg von 30 % bei Ihren Anfragen erwarten und einen Sicherheitspuffer von 10 % festlegen möchten, um eine 100-prozentige Auslastung der CPU zu vermeiden, würde Ihre Formel so aussehen:

    (1 - 0,1) ÷ (1 + 0,3) = 0,69

  • Konfigurieren Sie Pausen-Pods: Es gibt keine Möglichkeit, Cluster Autoscaler so zu konfigurieren, dass Knoten im Voraus hochgefahren werden. Stattdessen können Sie ein HPA-Nutzungsziel festlegen, um einen Puffer zur besseren Bewältigung von Lastspitzen bereitzustellen. Wenn Sie jedoch große Bursts erwarten, könnte das Festlegen eines kleinen HPA-Nutzungsziels nicht ausreichen oder zu teuer werden.

    Eine alternative Lösung für dieses Problem ist die Verwendung von Pausen-Pods. Pausen-Pods sind Deployments mit niedriger Priorität, die nichts anderes tun, als Platz im Cluster zu reservieren. Wenn ein Pod mit hoher Priorität geplant ist, werden Pausen-Pods entfernt und sofort durch den Pod mit hoher Priorität ersetzt. Die entfernten Pods werden anschließend neu geplant. Falls im Cluster kein Platz dafür ist, fährt Cluster Autoscaler neue Knoten hoch. Es hat sich bewährt, nur einen einzigen Pausen-Pod pro Knoten einzurichten. Wenn Sie beispielsweise vier CPU-Knoten verwenden, konfigurieren Sie für die CPU-Anfrage der Pausen-Pods einen Wert wie etwa "3200m".

Richtigen Maschinentyp auswählen

Neben Autoscaling können Ihnen noch andere Konfigurationen helfen, kostenoptimierte Kubernetes-Anwendungen in GKE auszuführen. In diesem Abschnitt wird erläutert, wie Sie den richtigen Maschinentyp auswählen.

Spot-VMs

Spot-VMs sind Compute Engine-VM-Instanzen, die keine Verfügbarkeitsgarantien bieten. Spot-VMs sind bis zu 91% günstiger als Compute Engine-Standard-VMs, allerdings empfehlen wir, dass Sie sie mit Vorsicht auf GKE-Clustern verwenden. Spot-VMs in GKE eignen sich am besten zum Ausführen von Batch- oder fehlertoleranten Jobs, die weniger empfindlich auf die unverbindliche Natur von Spot-VMs reagieren. Zustandsorientierte und Bereitstellungsarbeitslasten dürfen keine Spot-VMs verwenden, sofern Sie Ihr System und Ihre Architektur nicht auf den Umgang mit den Einschränkungen von Spot-VMs vorbereiten.

Unabhängig vom Arbeitslasttyp müssen Sie die folgenden Einschränkungen beachten:

  • Das Budget für Pod-Störungen wird möglicherweise nicht eingehalten, da Spot-VMs unbeabsichtigt heruntergefahren werden können.
  • Es gibt keine Garantie dafür, dass Ihre Pods ordnungsgemäß heruntergefahren werden, sobald das vorzeitige Beenden von Knoten den Pod-Kulanzzeitraum ignoriert.
  • Es kann einige Minuten dauern, bis GKE erkennt, dass der Knoten vorzeitig beendet wurde und die Pods nicht mehr ausgeführt werden, was die Neuplanung der Pods auf einem neuen Knoten verzögert.

Ab GKE v1.20 ist das ordnungsgemäße Herunterfahren von Knoten standardmäßig aktiviert, um laufende Arbeitslasten zu benachrichtigen.

Spot-VMs haben keine garantierte Verfügbarkeit, was bedeutet, dass sie in manchen Regionen schnell zur Neige gehen können. Es empfiehlt sich, einen Sicherungsknotenpool ohne Spot-VMs festzulegen, um diese Einschränkung zu umgehen. Cluster Autoscaler gibt Spot-VMs den Vorzug, da er für Infrastrukturkosten optimiert ist.

Weitere Informationen finden Sie unter Mit Spot-VMs fehlertolerante Arbeitslasten zu geringeren Kosten ausführen, Fehlertolerante Arbeitslasten zu geringeren Kosten in Spot-Pods ausführen und Webanwendungen in GKE mit kosteneffizienten Spot-VMs ausführen.

E2-Maschinentypen

E2-Maschinentypen (E2-VMs) sind kostenoptimierte VMs, die im Vergleich zu N1-Maschinentypen Einsparungen von 31 % bieten. E2-VMs eignen sich für eine Vielzahl von Arbeitslasten, darunter Webserver, Mikrodienste, geschäftskritische Anwendungen, kleine bis mittlere Datenbanken und Entwicklungsumgebungen

Weitere Informationen zu E2-VMs und deren Vergleich mit anderen Google Cloud-Maschinentypen finden Sie im Blog Performance-driven dynamic resource management in E2 VMs und unter Maschinentypen.

Die geeignete Region auswählen

Wenn Kosten eine Einschränkung darstellen, ist es wichtig, wo Sie Ihre GKE-Cluster ausführen. Aufgrund vieler Faktoren variieren Kosten je nach Computing-Region. Achten Sie also darauf, dass Sie Ihre Arbeitslast in der kostengünstigsten Variante ausführen, bei der die Latenz jedoch keine Auswirkung auf Ihre Kunden hat. Wenn für Ihre Arbeitslast Daten von einer Region in eine andere kopiert werden müssen, beispielsweise zum Ausführen eines Batchjobs, müssen Sie auch die Kosten für das Verschieben dieser Daten berücksichtigen.

Weitere Informationen zur Auswahl der richtigen Region finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.

Für Rabatte für zugesicherte Nutzung registrieren

Falls Sie Google Cloud voraussichtlich einige Jahre nutzen werden, empfehlen wir Ihnen dringend, Rabatte für zugesicherte Nutzung zu erwerben und dafür hohe Rabatte für die VM-Nutzung zu erhalten. Wenn Sie einen Vertrag über zugesicherte Nutzung abschließen, erwerben Sie Rechenressourcen zu einem ermäßigten Preis (bis zu 70 % Rabatt) und verpflichten sich im Gegenzug, diese Ressourcen für ein Jahr oder drei Jahre zu bezahlen. Falls Sie sich über die Höhe der Ressourcenzusicherung nicht sicher sind, werfen Sie einen Blick auf Ihr Mindestnutzungsvolumen – z. B. während der Nacht – und verpflichten sich dann, für dieses Volumen zu zahlen.

Weitere Informationen zu Preisen für zugesicherte Nutzung verschiedener Maschinentypen finden Sie unter Preise für VM-Instanzen.

Kleine Entwicklungscluster prüfen

Verwenden Sie für kleine Entwicklungscluster, bei denen Sie die Kosten minimieren müssen, Autopilot-Cluster. Bei Clustern in diesem Betriebsmodus fallen keine Gebühren für System-Pods, Betriebssystemnutzung oder ungeplante Arbeitslasten an.

Logging- und Monitoring-Strategien prüfen

Wenn Sie Cloud Logging und Cloud Monitoring verwenden, um Ihre Anwendungen und Infrastruktur beobachten zu können, zahlen Sie nur für das, was Sie verwenden. Je mehr Logs Ihre Infrastruktur und Anwendungen jedoch produzieren und je länger Sie diese aufbewahren, desto mehr bezahlen Sie auch dafür. Ähnlich verhält es sich mit externen und benutzerdefinierten Messwerten: Je mehr Sie haben, desto höher sind Ihre Kosten.

Interregionalen ausgehenden Traffic in regionalen und multizonalen Clustern prüfen

Zu den verfügbaren GKE-Clustertypen gehören einzelzonale, multizonale und regionale Cluster. Aufgrund der zonenübergreifenden Hochverfügbarkeit von Knoten eignen sich regionale und multizonale Cluster gut für Produktionsumgebungen. Allerdings fallen für ausgehenden Traffic zwischen Zonen Kosten an. Für Produktionsumgebungen empfehlen wir, dass Sie das interzonale Trafficaufkommen beobachten und Ihre APIs verbessern, um dieses zu minimieren. Ziehen Sie auch Affinitäts- und Anti-Affinitätskonfigurationen zwischen Pods in Betracht, um abhängige Pods von verschiedenen Diensten in denselben Knoten oder in derselben Verfügbarkeitszone zu platzieren und damit die Kosten und Netzwerklatenz zwischen ihnen zu minimieren. Für das Monitoring dieses Traffics empfiehlt es sich, die GKE-Nutzungsmessung und den zugehörigen Agent für ausgehenden Netzwerktraffic zu aktivieren, die standardmäßig deaktiviert sind.

In Nicht-Produktionsumgebungen besteht die beste Methode zur Kosteneinsparung darin, Einzelzonencluster bereitzustellen.

Umgebung auf Ihren Arbeitslasttyp vorbereiten

Unternehmen haben unterschiedliche Kosten- und Verfügbarkeitsanforderungen. Die Arbeitslasten können in Bereitstellungs- und Batcharbeitslasten unterteilt werden, wobei erstere schnell auf Bursts oder Nutzungsspitzen reagieren müssen und letztere für Arbeit vorgesehen sind, die irgendwann anfällt. Für Bereitstellungsarbeitslasten muss die Skalierungslatenz gering sein, während Batcharbeitslasten latenztoleranter sind. Die unterschiedlichen Erwartungen an diese Arbeitslasttypen machen die Wahl verschiedener Kosteneinsparungsmethoden flexibler.

Batcharbeitslasten

Da Batcharbeitslasten für Arbeit vorgesehen sind, die irgendwann anfällt, ermöglichen sie Kosteneinsparungen in GKE, da sie gewöhnlich eine gewisse Latenz beim Starten von Jobs tolerieren. Diese Toleranz ermöglicht es Cluster Autoscaler, neue Knoten nur dann hochzufahren, wenn Jobs geplant sind, und wieder herunterzufahren, wenn die Jobs beendet sind.

Die erste empfohlene Vorgehensweise besteht darin, Batcharbeitslasten in verschiedenen Knotenpools mithilfe von Labels und Selektoren und Markierungen und Toleranzen zu trennen. Dies beruht auf folgender Überlegung:

  • Cluster Autoscaler kann leere Knoten schneller löschen, wenn keine Pods neu gestartet werden müssen. Nach Abschluss der Batchjobs beschleunigt der Cluster die Herunterskalierung, wenn die Arbeitslast auf dedizierten Knoten ausgeführt wird, die nun leer sind. Zur weiteren Beschleunigung von Herunterskalierungen können Sie auch das CA-Profil "optimize-utilization" konfigurieren.
  • Einige Pods können nicht neu gestartet werden, sodass sie das Herunterskalieren ihrer Knoten permanent blockieren. Diese Pods, zu denen die System-Pods gehören, müssen auf anderen Knotenpools ausgeführt werden, damit sie die Herunterskalierung nicht behindern.

Die zweite empfohlene Vorgehensweise besteht in der Verwendung der automatischen Knotenbereitstellung, um dedizierte Knotenpools für Jobs mit einer übereinstimmenden Markierung oder Toleranz automatisch zu erstellen. So können Sie viele verschiedene Arbeitslasten trennen, ohne all die verschiedenen Knotenpools einrichten zu müssen.

Wir empfehlen, Spot-VMs nur dann zu verwenden, wenn Sie fehlertolerante Jobs ausführen, die weniger empfindlich auf die unverbindliche Natur von Spot-VMs reagieren.

Arbeitslasten bereitstellen

Im Gegensatz zu Batcharbeitslasten müssen Bereitstellungsarbeitslasten so schnell wie möglich auf Bursts oder Nutzungsspitzen reagieren. Diese plötzlichen Trafficanstiege können viele Gründe haben, z. B. TV-Werbespots, Spitzenereignisse wie Black Friday oder Eilmeldungen. Ihre Anwendung muss auf diese vorbereitet sein.

Probleme bei der Bewältigung solcher Nutzungsspitzen sind häufig auf einen oder mehrere der folgenden Gründe zurückzuführen:

  • Anwendungen, die für die Ausführung auf Kubernetes nicht bereit sind, beispielsweise Anwendungen mit großen Images, langsamen Startzeiten oder nicht optimalen Kubernetes-Konfigurationen.
  • Anwendungen, die von Infrastruktur abhängig sind, deren Bereitstellung Zeit in Anspruch nimmt, beispielsweise GPUs.
  • Autoscaling und Überdimensionierung, die nicht angemessen festgelegt sind.

Cloudbasierte Kubernetes-Anwendungen vorbereiten

Einige der Best Practices in diesem Abschnitt können für sich genommen schon Geld sparen. Da die meisten dieser Praktiken jedoch darauf ausgelegt sind, Ihre Anwendung zuverlässig mit Autoscaling-Funktionen funktionieren zu lassen, empfehlen wir Ihnen dringend, diese zu implementieren.

Anwendungskapazität nachvollziehen

Bei der Planung der Anwendungskapazität müssen Sie wissen, wie viele gleichzeitige Anfragen Ihre Anwendung verarbeiten kann, wie viel CPU und Arbeitsspeicher sie benötigt und wie sie unter hoher Last reagiert. Die meisten Teams kennen diese Kapazitäten nicht. Daher sollten Sie testen, wie sich Ihre Anwendung unter Druck verhält. Versuchen Sie, ein einzelnes Anwendungs-Pod-Replikat mit deaktiviertem Autoscaling zu isolieren, und führen Sie dann die Tests aus, um eine reale Nutzungslast zu simulieren. So können Sie die Kapazität pro Pod besser nachvollziehen. Dann empfehlen wir die Konfiguration von Cluster Autoscaler, Ressourcenanfragen und -limits sowie HPA oder VPA. Belasten Sie anschließend Ihre Anwendung noch einmal, diesmal jedoch stärker, um plötzliche Bursts oder Nutzungsspitzen zu simulieren.

Zum Eliminieren von Latenzproblemen sollten Sie diese Tests idealerweise in derselben Region oder Zone ausführen, in der die Anwendung in Google Cloud ausgeführt wird. Für diese Tests können Sie ein Tool Ihrer Wahl verwenden, zum Beispiel ein selbst erstelltes Skript oder ein komplexeres Tool zur Leistungsmessung wie Apache Benchmark, JMeter oder Locust

Ein Beispiel dafür, wie Sie Ihre Tests ausführen können, finden Sie unter Verteilte Lasttests mit Google Kubernetes Engine.

Vertikales und horizontales Wachstum der Anwendung gewährleisten

Sorgen Sie dafür, dass Ihre Anwendung wachsen und schrumpfen kann. Sie müssen also Trafficanstiege dadurch bewältigen können, dass Sie entweder mehr CPU und Arbeitsspeicher oder mehr Pod-Replikate hinzufügen. Dies gibt Ihnen die Flexibilität, mit dem zu experimentieren, was besser zu Ihrer Anwendung passt, egal ob es sich dabei um eine andere Autoscaling-Konfiguration oder eine andere Knotengröße handelt. Leider sind einige Anwendungen single-threaded oder durch eine feste Anzahl von Workern oder Unterprozessen beschränkt, die dieses Experimentieren ohne eine komplette Refaktorierung ihrer Architektur unmöglich machen.

Geeignete Ressourcenanfragen und -limits festlegen

Wenn Sie Ihre Anwendungskapazität kennen, können Sie bestimmen, was in Ihren Containerressourcen zu konfigurieren ist. Ressourcen in Kubernetes werden hauptsächlich als CPU und Arbeitsspeicher (RAM) definiert. Sie konfigurieren CPU oder Arbeitsspeicher als die Menge, die zum Ausführen Ihrer Anwendung erforderlich ist. Dafür verwenden Sie die Anfrage spec.containers[].resources.requests.<cpu|memory>. Die Obergrenze konfigurieren Sie mit der Anfrage spec.containers[].resources.limits.<cpu|memory>.

Wenn Sie Ressourcenanfragen richtig festgelegt haben, kann der Kubernetes-Planer anhand dieser Anfragen entscheiden, auf welchem Knoten Ihr Pod zu platzieren ist. Dies garantiert, dass Pods in Knoten platziert werden, die eine normale Funktionsweise der Pods ermöglichen, sodass Sie mehr Stabilität und weniger Ressourcenverschwendung haben. Außerdem wird durch das Definieren von Ressourcenlimits gewährleistet, dass diese Anwendungen nie die verfügbare zugrunde liegende Infrastruktur, die von Computing-Knoten bereitgestellt wird, vollständig nutzen.

Eine gute Vorgehensweise zum Festlegen Ihrer Containerressourcen besteht darin, die gleiche Menge an Arbeitsspeicher für Anfragen und Limits sowie ein größeres oder unbegrenztes CPU-Limit zu verwenden. Ziehen Sie das folgende Deployment als Beispiel heran:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wp
  template:
    metadata:
      labels:
        app: wp
    spec:
      containers:
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"

Die Begründung für das obige Muster beruht auf der Art und Weise, wie Kubernetes mit einem Ressourcenmangel umgeht. Kurz gesagt: Wenn Computerressourcen erschöpft sind, werden Knoten instabil. Zur Vermeidung dieser Situation beobachtet kubelet diese Ressourcen und verhindert einen totalen Ressourcenmangel durch das Ranking der ressourcenhungrigen Pods. Wenn um die CPU konkurriert wird, können diese Pods auf ihre Anfragen gedrosselt werden. Da Arbeitsspeicher jedoch eine nicht komprimierbare Ressource ist, muss der Pod heruntergefahren werden, wenn der Arbeitsspeicher erschöpft ist. Damit das Herunterfahren von Pods – und folglich eine Destabilisierung Ihrer Umgebung – vermieden wird, müssen Sie den angeforderten Arbeitsspeicher auf das Arbeitsspeicherlimit festlegen.

Sie können VPA auch im Empfehlungsmodus verwenden, um die CPU- und Arbeitsspeichernutzung für eine bestimmte Anwendung leichter zu ermitteln. Da VPA diese Empfehlungen auf Basis Ihrer Anwendungsnutzung bereitstellt, sollten Sie diesen Modus in einer produktionsähnlichen Umgebung aktivieren, um echten Traffic zu erleben. Der VPA-Status generiert dann einen Bericht mit den vorgeschlagenen Ressourcenanfragen und -limits, die Sie in Ihrem Deployment-Manifest statisch angeben können. Falls in Ihrer Anwendung bereits HPA definiert ist, lesen Sie HPA und VPA kombinieren.

Einen möglichst schlanken Container ermöglichen

Wenn Sie Container in Kubernetes ausführen, kann Ihre Anwendung jederzeit gestartet und angehalten werden. Daher ist es wichtig, die folgenden Best Practices zu beachten:

  • Möglichst kleines Image verwenden: Es empfiehlt sich, kleine Images zu verwenden, da jedes Mal, wenn Cluster Autoscaler einen neuen Knoten für Ihren Cluster bereitstellt, der Knoten die Images herunterladen muss, die im Knoten ausgeführt werden. Je kleiner das Image ist, desto schneller kann der Knoten es herunterladen.

  • Anwendung so schnell wie möglich starten: Der Start einiger Anwendungen kann aufgrund des Ladens von Klassen, Cachings usw. Minuten dauern. Wenn das Starten eines Pods lang dauert, können die Anfragen Ihrer Kunden fehlschlagen, während die Anwendung bootet.

Berücksichtigen Sie diese zwei Vorgehensweisen beim Entwurf Ihres Systems, insbesondere wenn Sie Bursts oder Nutzungsspitzen erwarten. Ein kleines Image und ein schneller Start helfen Ihnen, die Latenz von Hochskalierungen zu verringern. Damit können Sie Trafficanstiege besser bewältigen, ohne sich allzu große Sorgen um Instabilität zu machen. Diese Vorgehensweisen funktionieren besser mit den unter Feinabstimmung des GKE-Autoscalings beschriebenen Best Practices für das Autoscaling.

Budget für Pod-Störungen Ihrer Anwendung hinzufügen

Das Budget für Pod-Störungen begrenzt die Anzahl der Pods, die bei einer freiwilligen Unterbrechung gleichzeitig heruntergefahren werden können. Dies bedeutet, dass das definierte Unterbrechungsbudget bei Rollouts, Knotenupgrades und allen Autoscaling-Aktivitäten eingehalten wird. Allerdings kann dieses Budget nicht garantiert werden, wenn unfreiwillige Situationen wie Hardwarefehler, Kernel-Panic oder das versehentliche Löschen einer VM eintreten.

Wenn das PDB während der Komprimierungsphase von Cluster Autoscaler eingehalten wird, empfiehlt es sich, für jede Anwendung ein Budget für Pod-Störungen festzulegen. So können Sie die Mindestanzahl von Replikaten, die zur Unterstützung Ihrer Last erforderlich ist, jederzeit steuern, auch wenn CA Ihren Cluster herunterskaliert.

Weitere Informationen finden Sie unter Unterbrechungsbudget für Ihre Anwendung festlegen.

Aussagekräftige Bereitschafts- und Aktivitätsprüfungen für Ihre Anwendung festlegen

Das Festlegen aussagekräftiger Prüfungen sorgt dafür, dass Ihre Anwendung nur dann Traffic empfängt, wenn sie vollständig gestartet und bereit ist, Traffic entgegenzunehmen. GKE verwendet Bereitschaftsprüfungen, um zu ermitteln, wann Pods in Load-Balancer aufgenommen oder daraus entfernt werden sollen. Mithilfe von Aktivitätsprüfungen ermittelt GKE, wann Ihre Pods neu zu starten sind.

Die Aktivitätsprüfung ist nützlich, um Kubernetes mitzuteilen, dass ein bestimmter Pod keine Fortschritte machen kann, beispielsweise wenn ein Deadlock-Zustand erkannt wird. Mit der Bereitschaftsprüfung können Sie Kubernetes mitteilen, dass die Anwendung für den Empfang von Traffic nicht bereit ist, beispielsweise wenn umfangreiche Cache-Daten beim Start geladen werden.

Damit der ordnungsgemäße Lebenszyklus Ihrer Anwendung beim Hochskalieren gewährleistet ist, sind folgende Schritte wichtig:

  • Definieren Sie die Bereitschaftsprüfung für alle Container.
  • Wenn Ihre Anwendung darauf angewiesen ist, dass beim Start ein Cache geladen wird, darf die Bereitschaftsprüfung erst dann Bereitschaft anzeigen, nachdem der Cache vollständig geladen wurde.
  • Falls Ihre Anwendung in der Lage ist, sofort mit der Verarbeitung zu beginnen, kann eine gute Implementierung der Standardprüfung so einfach wie möglich sein, zum Beispiel ein HTTP-Endpunkt, der den Statuscode 200 zurückgibt.
  • Wenn Sie eine komplexere Prüfung implementieren, beispielsweise den Verbindungspool auf verfügbare Ressourcen prüfen, müssen Sie darauf achten, dass Ihre Fehlerrate im Vergleich zu einer einfacheren Implementierung nicht zunimmt.
  • Lassen Sie niemals eine Prüfungslogik auf andere Dienste zugreifen. Der Lebenszyklus Ihres Pods kann beeinträchtigt werden, wenn diese Dienste nicht sofort reagieren.

Weitere Informationen finden Sie unter Aktivitäts-, Bereitschafts- und Startprüfungen konfigurieren.

Anwendungen gemäß Kubernetes-Erwartungen herunterfahren

Autoscaling-Funktionen helfen Ihnen dabei, auf Nutzungsspitzen zu reagieren. Dazu werden neue Pods und Knoten hochgefahren und nach den Spitzen wieder gelöscht. Ihre Pods müssen also auf einen schnellen Start oder ein ordnungsgemäßes Herunterfahren vorbereitet sein, um Fehler während der Verarbeitung zu vermeiden.

Da Kubernetes Endpunkte und Load-Balancer asynchron aktualisiert, ist es wichtig, dass Sie sich an folgende Best Practices halten, um ein unterbrechungsfreies Herunterfahren zu gewährleisten:

  • Hören Sie nicht direkt nach SIGTERM auf, neue Anfragen anzunehmen. Die Anwendung darf nicht sofort beendet werden, sondern muss alle In-Flight-Anfragen abschließen und weiterhin eingehende Verbindungen überwachen, die nach Beginn der Pod-Beendigung eingehen. Es kann eine Weile dauern, bis Kubernetes alle kube-proxies und Load-Balancer aktualisiert hat. Wenn Ihre Anwendung beendet wird, bevor diese aktualisiert sind, können einige Anfragen clientseitige Fehler verursachen.
  • Falls Ihre Anwendung die vorhergehende Praxis nicht umsetzt, verwenden Sie den Hook preStop. Die meisten Programme hören nicht sofort damit auf, Anfragen anzunehmen. Wenn Sie jedoch Drittanbietercode verwenden oder ein System wie Nginx verwalten, über das Sie keine Kontrolle haben, ist der Hook preStop eine gute Möglichkeit, um ein ordnungsgemäßes Herunterfahren auszulösen, ohne die Anwendung zu ändern. Eine gängige Strategie besteht darin, im Hook preStop einen Ruhemodus von einigen Sekunden auszuführen, um SIGTERM hinauszuzögern. Dies gibt Kubernetes zusätzliche Zeit, um den Pod-Löschvorgang abzuschließen, und reduziert clientseitige Verbindungsfehler.
  • Fangen Sie SIGTERM für Bereinigungen ab. Wenn Ihre Anwendung eine Bereinigung ausführen muss oder einen In-Memory-Status hat, der vor Beendigung des Prozesses beibehalten werden muss, ist jetzt der richtige Zeitpunkt, um dies zu implementieren. Unterschiedliche Programmiersprachen haben unterschiedliche Möglichkeiten, dieses Signal abzufangen. Suchen Sie also nach der richtigen Methode in Ihrer Sprache.
  • Konfigurieren Sie terminationGracePeriodSeconds entsprechend den Anforderungen Ihrer Anwendung. Einige Anwendungen benötigen mehr als die standardmäßigen 30 Sekunden, um beendet zu werden. In diesem Fall müssen Sie terminationGracePeriodSeconds angeben. Hohe Werte können beispielsweise die Zeit für Knotenupgrades oder Rollouts erhöhen. Niedrige Werte lassen Kubernetes möglicherweise nicht genügend Zeit, den Prozess der Pod-Beendigung abzuschließen. So oder so empfehlen wir Ihnen, den Beendigungszeitraum der Anwendung auf weniger als zehn Minuten festzulegen, da Cluster Autoscaler nur einen zehnminütigen Zeitraum unterstützt.
  • Wenn Ihre Anwendung containernatives Load-Balancing verwendet, sollten Sie die Bereitschaftsprüfung fehlschlagen lassen, wenn Sie ein SIGTERM-Signal empfangen. Dadurch wird Load-Balancern direkt angezeigt, keine neuen Anfragen mehr an den Backend-Pod weiterzuleiten. Je nachdem, ob die Systemdiagnosenkonfiguration oder die Endpunktprogrammierung schneller ist, kann der Backend-Pod möglicherweise schon früher keinen Traffic mehr empfangen.

Weitere Informationen finden Sie im Blog Kubernetes best practices: terminating with grace.

NodeLocal DNSCache einrichten

Das von GKE verwaltete DNS wird von kube-dns implementiert, einem Add-on, das in allen GKE-Clustern bereitgestellt wird. Wenn Sie DNS-lastige Anwendungen ausführen, reicht die kube-dns-autoscaler-Standardkonfiguration, die die Anzahl der kube-dns-Replikate anhand der Anzahl der Knoten und Kerne im Cluster anpasst, unter Umständen nicht aus. In diesem Szenario können DNS-Abfragen entweder verlangsamt werden oder zu einer Zeitüberschreitung führen. Zur Lösung dieses Problems passen Unternehmen gewöhnlich die kube-dns-autoscaler-ConfigMap an, um die Anzahl der kube-dns-Replikate in ihren Clustern zu erhöhen. Obwohl diese Strategie wie erwartet funktionieren kann, erhöht sie die Ressourcennutzung und die GKE-Gesamtkosten.

Eine weitere kostenoptimierte und skalierbarere Alternative besteht darin, NodeLocal DNSCache im Cluster zu konfigurieren. NodeLocal DNSCache ist ein optionales GKE-Add-on, das die DNS-Lookup-Latenz verbessert, DNS-Lookup-Zeiten konsistenter macht und die Anzahl der DNS-Abfragen an kube-dns verringert. Dazu wird auf jedem Clusterknoten ein DNS-Cache ausgeführt.

Weitere Informationen finden Sie unter NodeLocal DNSCache einrichten.

Containernatives Load-Balancing über Ingress verwenden

Containernatives Load-Balancing ermöglicht es Load-Balancern, Kubernetes-Pods direkt anzusteuern und Traffic gleichmäßig auf Pods zu verteilen. Dazu kommt ein Datenmodell namens Netzwerk-Endpunktgruppen (NEGs) zum Einsatz. Dieser Ansatz verbessert die Netzwerkleistung, erhöht die Sichtbarkeit, aktiviert erweiterte Load-Balancing-Features und ermöglicht die Verwendung von Cloud Service Mesh, der vollständig verwalteten Trafficsteuerungsebene für Service Mesh von Google Cloud.

Aufgrund dieser Vorteile ist das containernative Load-Balancing die empfohlene Lösung für das Load-Balancing über Ingress. Wenn NEGs mit GKE Ingress verwendet werden, erleichtert der Ingress-Controller das Erstellen aller Aspekte des L7-Load-Balancers. Dazu gehören das Erstellen von virtuellen IP-Adressen, Weiterleitungsregeln, Systemdiagnosen, Firewallregeln usw.

Containernatives Load-Balancing wird noch wichtiger, wenn Sie Cluster Autoscaler verwenden. Bei Nicht-NEG-Load-Balancern kann es während Herunterskalierungen vorkommen, dass die Load-Balancing-Programmierung und der Verbindungsausgleich nicht vollständig abgeschlossen sind, bevor Cluster Autoscaler die Knoteninstanzen beendet. Dadurch könnten bestehende Verbindungen, die den Knoten durchlaufen, unterbrochen werden, selbst wenn sich die Backend-Pods nicht auf dem Knoten befinden.

Containernatives Load-Balancing ist für Dienste standardmäßig aktiviert, wenn alle der folgenden Bedingungen erfüllt sind:

  • Die Dienste wurden in GKE-Clustern ab Version 1.17.6-gke.7 erstellt.
  • Sie verwenden VPC-native Cluster.
  • Sie verwenden keine freigegebene VPC.
  • Sie verwenden keine GKE-Netzwerkrichtlinie.

Weitere Informationen finden Sie in der GKE-Dokumentation zu Ingress und unter Containernatives Load-Balancing verwenden.

Wiederholungsversuche mit exponentiellem Backoff verwenden

In Mikrodienstarchitekturen, die auf Kubernetes ausgeführt werden, können vorübergehende Fehler aus verschiedenen Gründen auftreten. Dazu gehören:

Diese Probleme sind kurzlebig und können behoben werden, wenn Sie den Dienst nach einer Verzögerung noch einmal aufrufen. Damit der Zieldienst jedoch nicht mit Anfragen überlastet wird, ist es wichtig, dass Sie diese Aufrufe mit einem exponentiellen Backoff ausführen.

Zur Umsetzung eines solchen Wiederholungsmusters implementieren viele vorhandene Bibliotheken die exponentielle Wiederholungslogik. Sie können dafür die Bibliothek Ihrer Wahl verwenden oder Ihren eigenen Code schreiben. Wenn Sie Istio oder Cloud Service Mesh (ASM) verwenden, können Sie sich für den Wiederholungsmechanismus auf Proxyebene entscheiden, der Wiederholungsversuche transparent für Sie ausführt.

Es ist wichtig, die Anwendung so zu planen, dass Wiederholungsversuche von Dienstaufrufen unterstützt werden. So vermeiden Sie beispielsweise, dass bereits eingefügte Informationen noch einmal eingefügt werden. Bedenken Sie, dass sich eine Kette von Wiederholungsversuchen auf die Latenz des Endnutzers auswirken und bei falscher Planung zu einer Zeitüberschreitung führen kann.

Umgebung im Blick behalten und kostenoptimierte Konfigurationen und Verfahren erzwingen

In vielen mittleren und großen Unternehmen ist häufig ein zentrales Plattform- und Infrastrukturteam für das Erstellen, Warten und Beobachten von Kubernetes-Clustern für das gesamte Unternehmen verantwortlich. Dies macht es dringend notwendig, die Ressourcennutzung nachzuvollziehen zu können und zu gewährleisten, dass alle Teams die Richtlinien des Unternehmens einhalten. In diesem Abschnitt werden Optionen für das Monitoring und die Erzwingung kostenbezogener Verfahren beschrieben.

GKE-Cluster beobachten und Empfehlungen erhalten

Zum Ermitteln der Ressourcennutzung in einem Kubernetes-Cluster können Sie die Container, Pods und Dienste sowie die Eigenschaften des gesamten Clusters untersuchen. Es gibt viele Möglichkeiten, wie Sie diese Aufgabe ausführen können. Wir empfehlen jedoch als ersten Ansatz, Ihre GKE-Cluster über das Monitoring-Dashboard zu beobachten. Dadurch erhalten Sie Zeitreihendaten über die Nutzung Ihres Clusters, sodass Sie Infrastruktur, Arbeitslasten und Dienste aggregieren und überblicken können.

Obwohl dies ein guter Ausgangspunkt ist, bietet Google Cloud noch weitere Optionen. Zum Beispiel:

  • Sehen Sie sich in der Google Cloud Console auf der Seite GKE-Cluster die Spalte Benachrichtigungen an. Wenn in einem Cluster viel Ressourcen verschwendet werden, gibt Ihnen die UI einen Hinweis mit Informationen zu den insgesamt zugewiesenen gegenüber den angeforderten Ressourcen.

    Zur GKE-Clusterliste

  • Suchen Sie in der Google Cloud Console auf der Seite Empfehlungen nach Empfehlungskarten für Kosteneinsparungen.

    Zum Empfehlungs-Hub

Weitere Informationen finden Sie unter GKE-Cluster beobachten und Erste Schritte mit dem Empfehlungs-Hub.

GKE-Nutzungsmessung aktivieren

Wenn Sie einen flexibleren Ansatz wünschen und ungefähre Kostenaufschlüsselungen sehen möchten, können Sie es mit der GKE-Nutzungsmessung versuchen. Die GKE-Nutzungsmessung zeigt Ihnen die Nutzungsprofile Ihrer GKE-Cluster nach Namespaces und Labels aufgeschlüsselt an. Das Tool erfasst Informationen zu den Ressourcenanfragen und der Ressourcennutzung der Arbeitslasten Ihres Clusters, z. B. CPU, GPU, TPU, Arbeitsspeicher, Datenspeicher und wahlweise ausgehenden Netzwerktraffic.

Die GKE-Nutzungsmessung hilft Ihnen, die Gesamtkostenstruktur Ihrer GKE-Cluster zu verstehen: welches Team oder welche Anwendung am meisten ausgibt, welche Umgebung oder Komponente einen plötzlichen Nutzungs- oder Kostenanstieg verursacht hat und welches Team verschwenderisch handelt. Durch den Vergleich von Ressourcenanfragen mit der tatsächlichen Nutzung können Sie ermitteln, welche Arbeitslasten über- oder unterdimensioniert sind.

Sie können die Standardvorlagen von Looker Studio nutzen oder einen Schritt weiter gehen und die Dashboards an Ihre organisatorischen Anforderungen anpassen. Weitere Informationen zur GKE-Nutzungsmessung und ihren Voraussetzungen finden Sie unter Grundlagen der Nutzung von Clusterressourcen.

Funktionsweise von Metrics Server verstehen und diesen beobachten

Metrics Server ist die Quelle von Container-Ressourcenmesswerten für integrierte GKE-Autoscaling-Pipelines. Metrics Server ruft Messwerte aus kubelets ab und stellt sie über die Metrics API von Kubernetes bereit. HPA und VPA bestimmen dann anhand dieser Messwerte, wann das Autoscaling ausgelöst werden soll.

Für ein fehlerfreies GKE-Autoscaling muss auch Metrics Server fehlerfrei sein. Beim Deployment des GKE-metrics-server wird ein Nanny-Programm zur Größenänderung installiert, das den Metrics Server-Container vertikal wachsen lässt. Dazu werden CPU und Arbeitsspeicher entsprechend der Knotenanzahl des Clusters hinzugefügt oder entfernt. Direkte Pod-Updates werden in Kubernetes noch immer nicht unterstützt. Aus diesem Grund muss das Nanny-Programm den Pod metrics-server neu starten, um die benötigten neuen Ressourcen anzuwenden.

Obwohl der Neustart schnell erfolgt, kann sich die Gesamtlatenz, bis die Autoscaling-Funktionen erkennen, dass sie handeln müssen, nach einer metrics-server-Größenänderung leicht erhöhen. Damit häufige Metrics Server-Neustarts in Clustern vermieden werden, die sich schnell ändern, unterstützt das Nanny-Programm Verzögerungen bei der Größenänderung ab GKE 1.15.11-gke.9.

Halten Sie sich bei Verwendung von Metrics Server an folgende Best Practices:

  • Wählen Sie die GKE-Version aus, die Verzögerungen bei der metrics-server-Größenänderung unterstützt. Zur Bestätigung können Sie prüfen, ob die YAML-Datei für das metrics-server-Deployment die Konfiguration scale-down-delay im Container metrics-server-nanny enthält.
  • Behalten Sie das metrics-server-Deployment im Blick. Wenn Metrics Server ausgefallen ist, bedeutet dies, dass das Autoscaling überhaupt nicht funktioniert. Daher sollten dafür sorgen, dass Ihre wichtigsten Monitoring-Dienste dieses Deployment überwachen.
  • Halten Sie sich an die Best Practices, die unter Feinabstimmung des GKE-Autoscalings erläutert werden.

Kubernetes-Ressourcenkontingente verwenden

Bei mehrmandantenfähigen Clustern sind verschiedene Teams häufig für Anwendungen verantwortlich, die in verschiedenen Namespaces bereitgestellt werden. Für eine zentrale Plattform- und Infrastrukturgruppe stellt die Tatsache, dass ein Team mehr Ressourcen als nötig nutzen könnte, ein Problem dar. Wenn Sie alle Rechenressourcen des Clusters auslasten oder sogar zu viele Hochskalierungen auslösen, können Ihre Kosten steigen.

Zur Lösung dieses Problems müssen Sie Ressourcenkontingente verwenden. Ressourcenkontingente verwalten die Menge an Ressourcen, die von Objekten in einem Namespace verwendet werden. Sie können Kontingente für Rechen- (CPU und Arbeitsspeicher) und Datenspeicherressourcen oder für die Anzahl von Objekten festlegen. Mit Ressourcenkontingenten können Sie dafür sorgen, dass kein Mandant mehr als den ihm zugewiesenen Anteil an Clusterressourcen nutzt.

Weitere Informationen finden Sie unter Arbeitsspeicher- und CPU-Kontingente für einen Namespace konfigurieren.

GKE Enterprise Policy Controller verwenden

GKE Enterprise Policy Controller ist ein dynamischer Admission-Controller von Kubernetes, der die Compliance Ihrer Cluster mit Richtlinien in Bezug auf Sicherheit, Vorschriften oder beliebige Geschäftsregeln kontrolliert, auditiert und erzwingt. Policy Controller nutzt Einschränkungen, um die Compliance Ihrer Cluster zu erzwingen. Beispielsweise können Sie in Ihren Clustern Einschränkungen für viele der Best Practices installieren, die im Abschnitt Cloudbasierte Kubernetes-Anwendung vorbereiten beschrieben werden. Auf diese Weise werden Deployments abgelehnt, wenn sie sich nicht strikt an Ihre Kubernetes-Praktiken halten. Das Erzwingen solcher Regeln trägt dazu bei, unerwartete Kostenspitzen zu vermeiden, und verringert die Wahrscheinlichkeit, dass Arbeitslasten während des Autoscalings instabil werden.

Weitere Informationen zum Erzwingen und Schreiben eigener Regeln finden Sie unter Einschränkungen erstellen und Einschränkungsvorlage schreiben. Wenn Sie kein GKE Enterprise-Kunde sind, können Sie auch Gatekeeper verwenden, die Open-Source-Software, auf der Policy Controller basiert.

CI-/CD-Pipeline zur Durchsetzung der Kostensenkung konzipieren

GKE Enterprise Policy Controller hilft Ihnen, das Deployment nicht konformer Software in Ihrem GKE-Cluster zu vermeiden. Wir empfehlen Ihnen jedoch, solche Richtlinieneinschränkungen früh in Ihrem Entwicklungszyklus zu erzwingen, beispielsweise bei Prüfungen vor Commits, Pull-Anfrageprüfungen, Bereitstellungsworkflows oder jedem anderen Schritt, der in Ihrer Umgebung sinnvoll ist. Mit dieser Vorgehensweise können Sie Fehlkonfigurationen schnell finden und beheben und durch das Erstellen von Leitlinien besser verstehen, auf was Sie achten müssen.

Ziehen Sie auch die Verwendung von kpt-Funktionen in Ihrer CI-/CD-Pipeline in Betracht. Damit können Sie prüfen, ob Ihre Kubernetes-Konfigurationsdateien die von GKE Enterprise Policy Controller erzwungenen Einschränkungen einhalten, und außerdem die Ressourcennutzungs- oder Deployment-Kosten schätzen. Auf diese Weise kann die Pipeline angehalten werden, wenn ein kostenbezogenes Problem festgestellt wird. Alternativ können Sie einen anderen Deployment-Genehmigungsprozess für Konfigurationen erstellen, die beispielsweise die Anzahl der Replikate erhöhen.

Weitere Informationen finden Sie unter Policy Controller in einer CI-Pipeline verwenden. Ein vollständiges Beispiel für eine Bereitstellungsplattform ist unter Moderne CI/CD mit GKE Enterprise enthalten.

Kostengünstige Kultur schaffen

Viele Organisationen erstellen Abstraktionen und Plattformen, um die Komplexität der Infrastruktur vor Ihnen zu verbergen. Dies ist eine gängige Praxis in Unternehmen, die ihre Dienste von virtuellen Maschinen zu Kubernetes migrieren. In einigen Fällen ermöglichen diese Unternehmen Entwicklern, ihre eigenen Anwendungen in der Produktion zu konfigurieren. Allerdings sind Entwickler, die noch nie mit einem Kubernetes-Cluster in Berührung gekommen sind, nichts Ungewöhnliches.

Die in diesem Abschnitt empfohlenen Praktiken bedeuten nicht, dass Sie überhaupt keine Abstraktionen mehr verwenden sollten. Sie helfen ihnen vielmehr, Ihre Ausgaben für Google Cloud zu beobachten und Ihre Entwickler und Operatoren in Ihrer Infrastruktur zu schulen. Sie können dafür Lernanreize und Programme schaffen, in denen Sie traditionelle oder Online-Kurse, Foren, Begutachtungen durch Kollegen, gemeinsame Programmierung, CI-/CD- und Kosteneinsparungs-Gamifizierungen und vieles mehr verwenden können. In der Kubernetes-Welt ist es beispielsweise wichtig, die Auswirkungen einer Anwendung mit einem 3-GB-Image, einer fehlenden Bereitschaftsprüfung oder einer HPA-Fehlkonfiguration zu verstehen.

Wie aus der DORA-Studie von Google hervorgeht, sind kulturelle Fähigkeiten einige der Hauptfaktoren, die zu einer besseren organisatorischen Leistung, weniger Nacharbeit, weniger Burnout usw. führen. Mit der Kosteneinsparung verhält es sich nicht anders. Wenn Sie Ihren Mitarbeitern Zugang zu ihren Ausgaben geben, richten Sie sie enger an Geschäftszielen und Einschränkungen aus.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die Best Practices zusammengefasst, die in diesem Dokument empfohlen werden.

Thema Aufgabe
GKE-Features und -Optionen für die Kostenoptimierung
Cloudbasierte Kubernetes-Anwendungen vorbereiten
Umgebung überwachen und kostenoptimierte Konfigurationen und Verfahren erzwingen
Kultur

Nächste Schritte