Best Practices für den Entwurf und die Erstellung hochverfügbarer GKE-Cluster

Wie viele Unternehmen verfolgen sicherlich auch Sie eine vielfältige Reihe von Strategien für das Risikomanagement und die Risikominimierung, um die Verfügbarkeit Ihrer Systeme zu gewährleisten. Dazu gehört auch Ihre Google Kubernetes Engine (GKE) Umgebung. So sorgen Sie für Geschäftskontinuität bei geplanten und ungeplanten Ausfällen und halten die Auswirkungen der aktuellen Situation auf Ihr Unternehmen so gering wie möglich.

Dieser erste von zwei Blogposts enthält Empfehlungen und Best Practices für die Einrichtung von GKE-Clustern mit höherer Verfügbarkeit am sogenannten Tag 0. Im zweiten Post geht es um Best Practices für Hochverfügbarkeit ab Tag 2, wenn Ihre Cluster laufen. 

Beim Thema Hochverfügbarkeit von GKE-Clustern wird der Tag 0 häufig übersehen. Viele denken, dass Störungen und Wartungsarbeiten Teil des laufenden Betriebs ab Tag 2 sind. Sie sollten aber die Topologie und Konfiguration Ihres GKE-Clusters sorgfältig planen, bevor Sie Workloads darauf bereitstellen.

Die richtige Topologie, Größe und Systemdiagnose für Ihre Workloads auswählen

Bevor Sie eine GKE-Umgebung erstellen und Workloads bereitstellen, sollten Sie sich Gedanken über das Systemdesign machen. 

Die geeignete Topologie für Ihren Cluster auswählen

GKE bietet zwei Arten von Clustern: regionale und zonale. Bei einer zonalen Clustertopologie werden die Steuerungsebene und die Knoten in einer einzigen Computing-Zone ausgeführt, die Sie beim Erstellen des Clusters festlegen. Bei einer regionalen Clustertopologie werden die Steuerungsebene und die Knoten über mehrere Zonen einer Region hinweg repliziert.

Regionale Cluster haben mindestens drei Kubernetes-Steuerungsebenen und bieten damit für die Steuerungsebenen-API des Clusters eine höhere Verfügbarkeit als zonale Cluster. Bestehende Workloads, die auf den Knoten ausgeführt werden, sind zwar nicht beeinträchtigt, falls eine Steuerungsebene nicht verfügbar ist, es gibt aber Anwendungen, die stark von der Verfügbarkeit der Cluster API abhängen. Für diese Workloads sollten Sie besser eine regionale Clustertopologie verwenden. 

Die Auswahl eines regionalen Clusters allein reicht jedoch nicht aus, um GKE-Cluster zu schützen. Die Skalierung, Planung und der Austausch von Pods sind Aufgaben der Steuerungsebene. Falls diese ausfällt, kann sich das auf die Zuverlässigkeit Ihres Clusters auswirken, welches seine Arbeit erst wieder aufnehmen kann, wenn die Steuerungsebene wieder verfügbar ist.

Darüber hinaus sollten Sie bedenken, dass regionale Cluster redundante Steuerungsebenen und Knoten haben. In einer regionalen Topologie sind die Knoten über verschiedene Zonen hinweg redundant, was teuren zonenübergreifenden Netzwerktraffic verursachen kann.

Außerdem wird durch das regionale Cluster-Autoscaling zwar versucht, die Ressourcen gleichmäßig auf die drei Zonen zu verteilen, aber es erfolgt kein automatischer Ausgleich. Hierfür ist eine Skalierung nötig.

Wir empfehlen Ihnen daher, für eine höhere Verfügbarkeit der Kubernetes API und zur Minimierung von Störungen des Clusters während Wartungsarbeiten an der Steuerungsebene einen regionalen Cluster mit Knoten in drei verschiedenen Verfügbarkeitszonen einzurichten und auf das Autoscaling zu achten.

Horizontal und vertikal skalieren

Kapazitätsplanung ist wichtig, aber Sie können nicht alles vorhersehen. Damit Ihre Workloads auch bei Höchstbelastungen des Systems fehlerfrei ausgeführt werden und Sie die Kosten bei normaler oder geringer Last unter Kontrolle halten können, sollten Sie geeignete Autoscaling-Funktionen von GKE einsetzen.

• Aktivieren Sie Cluster Autoscaler, um die Größe des Knotenpools nach Bedarf automatisch anzupassen.

• Nutzen Sie horizontales Pod-Autoscaling, um die Anzahl der Pods abhängig von bestimmten Auslastungsmesswerten automatisch zu erhöhen bzw. zu senken.

Wenn Sie vertikales Pod-Autoscaling (VPA) in Kombination mit der automatischen Knotenbereitstellung (Node Auto Provisioning, NAP) bzw. Knotenpoolbereitstellung einsetzen, kann Ihr Cluster in GKE effizient sowohl horizontal (Pods) als auch vertikal (Knoten) skaliert werden. Durch VPA werden automatisch Werte für CPU und Speicheranfragen sowie Limits für Container festgelegt. NAP ermöglicht die automatische Verwaltung von Knotenpools. Außerdem ist die standardmäßige Einschränkung aufgehoben, dass neue Knoten nur aus von Nutzer*innen erstellten Knotenpools gestartet werden dürfen.

Anhand dieser Empfehlungen können Sie Ihre Kosten senken. NAP trägt beispielsweise hierzu bei, indem Knoten bei geringer Auslastung deaktiviert werden. Aber vielleicht liegt Ihr Augenmerk gar nicht so sehr auf den Kosten, sondern mehr auf Latenz und Verfügbarkeit. In diesem Fall sollten Sie von vornherein einen großen Cluster erstellen und GCP-Reservierungen nutzen, um die gewünschte Kapazität zu garantieren. Dieser Ansatz ist jedoch in der Regel teurer.

Standardmäßige Monitoring-Einstellungen prüfen

Kubernetes ist hervorragend dafür geeignet, das Verhalten von Workloads zu beobachten und sicherzustellen, dass die Last von Anfang an gleichmäßig verteilt ist. Die Verfügbarkeit der Workloads können Sie noch weiter optimieren, indem Sie bestimmte Signale zu Workloads an Kubernetes senden. Diese Signale zur Bereitschaft und Aktivität liefern Kubernetes weitere Informationen über Ihren Workload, anhand derer das System ermitteln kann, ob sie korrekt funktioniert und für den Empfang von Traffic bereit ist. Sehen wir uns die Unterschiede zwischen Bereitschafts- und Aktivitätsprüfungen einmal an.

Jede Anwendung verhält sich anders: Bei manchen dauert der Start eine Weile, andere sind Batchprozesse, die über längere Zeit laufen und daher den Eindruck erwecken können, sie seien nicht verfügbar. Bereitschafts- und Aktivitätsprüfungen wurden entwickelt, um Kubernetes Informationen zum akzeptablen Verhalten eines Workloads zu liefern. Wenn der Start einer Anwendung beispielsweise lange dauert, soll Kubernetes ihr keinen Kundentraffic senden, da sie dafür noch nicht bereit ist. Mit einer Bereitschaftsprüfung können Sie Kubernetes ein genaues Signal geben, wenn eine Anwendung die Initialisierung beendet hat und für die Endnutzer*innen zur Verfügung steht.

Sie sollten Bereitschaftsprüfungen einrichten, damit Kubernetes weiß, wann Ihr Workload wirklich für den Empfang von Traffic bereit ist. Durch eine Aktivitätsprüfung können Sie Kubernetes signalisieren, ob ein Workload wirklich nicht reagiert oder nur gerade CPU-intensive Aufgaben ausführt.

Bereitschafts- und Aktivitätsprüfungen müssen jedoch sorgfältig definiert und geschrieben werden. Testen und validieren Sie also alle Prüfungen vorab.

Deployment korrekt einrichten

Jede Anwendung hat ganz eigene Merkmale. Einige sind Batchworkloads, andere basieren auf zustandslosen Mikrodiensten, wieder andere auf zustandsorientierten Datenbanken. Damit Kubernetes die Einschränkungen Ihrer Anwendung kennt, können Sie Ihre Workloads mit Kubernetes-Deployments verwalten. Ein Deployment beschreibt den gewünschten Status. Anhand des Kubernetes-Plans wird dafür gesorgt, dass ein Workload den gewünschten Status annimmt.

Ist Ihre Anwendung zustandsorientiert oder nicht?

Wenn Ihre Anwendung ihren Status von einer Sitzung zur nächsten beibehalten soll (dies gilt z. B. für Datenbanken), sollten Sie StatefulSet verwenden. Mit diesem Kubernetes-Controller können Sie einen oder mehrere Pods entsprechend den besonderen Merkmalen zustandsorientierter Anwendungen verwalten. Er ähnelt anderen Kubernetes-Controllern für die Pod-Verwaltung wie ReplicaSets und Deployments. Im Gegensatz zu Deployments wird bei StatefulSet jedoch nicht davon ausgegangen, dass Pods austauschbar sind.

Zur Beibehaltung des Status benötigt StatefulSet außerdem nichtflüchtige Volumes, damit die gehostete Anwendung Daten speichern und bei einem Neustart wiederherstellen kann. Kubernetes stellt Speicherklassen, nichtflüchtige Volumes und Ansprüche auf nichtflüchtige Volumes als Abstraktionsebene über Cloud Storage bereit.

Pod-Affinität

Sollen alle Replikate auf demselben Knoten geplant werden? Was würde passieren, wenn der Knoten ausfällt? Wäre es ein Problem, wenn alle Replikate gleichzeitig verloren gehen? Mit Affinitäts- und Anti-Affinitätsregeln für Kubernetes-Pods können Sie die Platzierung des Pods und der Replikate steuern.

Nutzen Sie die Pod-Anti-Affinität, um Kubernetes anzuweisen, Pods NICHT auf demselben Knoten zu speichern. So vermeiden Sie einen Single Point Of Failure. Für eine zustandsorientierte Anwendung kann diese Konfiguration entscheidend sein, insbesondere wenn eine Mindestzahl von Replikaten (d. h. ein Quorum) für die korrekte Ausführung nötig ist.

Apache ZooKeeper braucht beispielsweise ein Quorum von Servern, um den Commit von Datenmutationen durchzuführen. Bei einem System mit drei Servern müssen zwei fehlerfrei sein, damit Schreibvorgänge erfolgreich sind. In einem stabilen Deployment werden die Server daher auf mehreren Ausfalldomains bereitgestellt. 

Zur Vermeidung von Ausfällen aufgrund des Verlusts eines Knotens sollten Sie also von vornherein verhindern, dass sich mehrere Instanzen einer Anwendung auf derselben Maschine befinden. Dazu können Sie die Pod-Anti-Affinität verwenden.

Es könnte aber auch hilfreich sein, eine Gruppe von Pods auf demselben Knoten zu haben, da dies eine geringere Latenz und bessere Leistung bei der Kommunikation untereinander mit sich bringt. Das erreichen Sie über die Pod-Affinität.

Mit Redis, einer weiteren zustandsorientierten Anwendung, können Sie einen speicherinternen Cache für Ihre Webanwendung bereitstellen. Bei diesem Deployment soll sich der Webserver so nah wie möglich bei dem Cache befinden, um Latenz zu vermeiden und die Leistung zu steigern.

Unterbrechungen vorhersehen

Nachdem Sie Ihren GKE-Cluster und die darauf laufenden Anwendungen konfiguriert haben, sollten Sie überlegen, was Sie im Fall einer erhöhten Last oder Unterbrechung tun möchten.

Ein rein digitales System erfordert eine bessere Kapazitätsplanung

Wenn Sie Kubernetes-Cluster auf GKE ausführen, müssen Sie sich keine Gedanken mehr über die physische Infrastruktur und ihre Skalierung machen. Eine Kapazitätsplanung wird jedoch dringend empfohlen, insbesondere wenn Sie mit höheren Lasten rechnen.

Eine Möglichkeit sind reservierte Instanzen, um einen erwarteten Anstieg des Ressourcenbedarfs sicher zu bewältigen. GKE unterstützt spezifische Reservierungen (Maschinentyp und Spezifikation) sowie unspezifische Reservierungen. Wenn Sie eine Reservierung vornehmen, verbrauchen die Knoten diese automatisch im Hintergrund aus einem Ressourcenpool, der nur Ihnen zur Verfügung steht.

Einen Supportplan abschließen

Die Entwickler*innen des Google Cloud-Supportteams stehen Ihnen rund um die Uhr auf der ganzen Welt zur Verfügung. Bevor Ihr System läuft und in der Produktion genutzt wird, sollten Sie einen passenden Supportplan abschließen, damit Sie bei Problemen Unterstützung erhalten. 

• Prüfen Sie Ihren Supportplan, um sicherzustellen, dass Sie das richtige Angebot für Ihr Unternehmen gewählt haben.

• Prüfen Sie die Support-Nutzerkonfigurationen, um sicherzustellen, dass Ihre Teammitglieder Supportanfragen stellen können.

• Vergewissern Sie sich, dass GKE-Monitoring und -Logging auf Ihrem Cluster aktiviert sind. Supporttechniker*innen benötigen die Logs und Messwerte, um Fehler im System zu beheben.

• Falls Sie GKE-Monitoring und -Logging nicht aktiviert haben, können Sie stattdessen das neue Feature für Systemlogs (Beta) verwenden, um nur Logs zu erfassen, die für die Problembehebung relevant sind.

Zusammenfassung

Containeranwendungen sind portierbar und lassen sich einfach bereitstellen und skalieren. GKE macht es Ihnen mit seiner Vielzahl von Funktionen für die Clusterverwaltung noch leichter, Ihre Workloads reibungslos auszuführen. Sie kennen Ihre Anwendung am besten, aber wenn Sie sich an diese Empfehlungen halten, können Sie die Verfügbarkeit und Stabilität der Cluster deutlich erhöhen. Sie haben weitere Ideen oder Tipps? Geben Sie uns Feedback. Demnächst kommt Teil zwei dieser Reihe, in dem es darum geht, wie Sie am besten auf Probleme in Produktionsclustern reagieren.