GKE Autopilot – Übersicht

Autopilot ist ein verwalteter Betriebsmodus in Google Kubernetes Engine (GKE). Auf dieser Seite werden die Vorteile des Autopilot-Modus beschrieben. Außerdem finden Sie Informationen zum Planen von Clustern, Bereitstellen von Arbeitslasten und Konfigurieren von Netzwerk und Sicherheit. Administratoren, Architekten und Operatoren können diese Informationen nutzen, um fundierte Entscheidungen zu treffen, wenn sie bewerten, wie der GKE Autopilot-Modus mit den betrieblichen Anforderungen ihrer containerisierten Arbeitslasten übereinstimmt.

Weitere Informationen zu den Unterschieden zwischen den Betriebsmodi in GKE finden Sie unter GKE Autopilot und Standard vergleichen.

Was ist Autopilot?

GKE Autopilot ist ein Betriebsmodus in GKE, in dem Google Ihre Infrastrukturkonfiguration verwaltet, einschließlich Knoten, Skalierung, Sicherheit und anderer vorkonfigurierter Einstellungen. Der Autopilot-Modus ist für die Ausführung der meisten Produktionsarbeitslasten optimiert und stellt Rechenressourcen basierend auf Ihren Kubernetes-Manifesten bereit.

Sie können einen gesamten Cluster im Autopilot-Modus ausführen, sodass der Cluster und alle seine Arbeitslasten den Best Practices und Empfehlungen von GKE für Skalierung, Sicherheit, Upgrades und Knotenkonfiguration entsprechen. Sie können auch bestimmte Arbeitslasten im Autopilot-Modus in GKE Standard-Clustern ausführen. Mit dieser Option können Sie Autopilot in Umgebungen verwenden, in denen Sie weiterhin die manuelle Kontrolle über Ihre Infrastruktur benötigen. Weitere Informationen finden Sie unter Arbeitslasten im Autopilot-Modus in GKE Standard.

Vorteile

  • Fokus auf die Anwendungen: Google verwaltet die Infrastruktur, sodass Sie sich auf das Erstellen und Bereitstellen Ihrer Anwendungen konzentrieren können.
  • Sicherheit: Autopilot-Cluster haben eine standardmäßig gehärtete Konfiguration, wobei viele Sicherheitseinstellungen standardmäßig aktiviert sind. GKE wendet Sicherheitspatches automatisch auf Ihre Knoten an, wenn verfügbar. Dabei werden alle konfigurierten Wartungspläne eingehalten.
  • Preise: Das Preismodell von Autopilot vereinfacht Abrechnungsprognosen und Attributionen.
  • Knotenverwaltung: Google verwaltet Worker-Knoten. Sie müssen also keine neuen Knoten erstellen, um Ihre Arbeitslasten zu berücksichtigen oder automatische Upgrades und Reparaturen zu konfigurieren.
  • Skalierung: Wenn Ihre Arbeitslasten eine hohe Last aufweisen und Sie weitere Pods hinzufügen, um den Traffic zu verarbeiten, z. B. mit dem horizontalen Pod-Autoscaling von Kubernetes, stellt GKE automatisch neue Knoten für diese Pods bereit und erweitert die Ressourcen in Ihren vorhandenen Knoten nach Bedarf automatisch.
  • Planung: Autopilot verwaltet das Pod-Bin-Pack für Sie, sodass Sie sich nicht Gedanken darüber machen müssen, wie viele Pods auf jedem Knoten ausgeführt werden. Sie können die Pod-Platzierung mithilfe von Kubernetes-Mechanismen wie Affinität und Pod-Verteilungstopologie zusätzlich steuern.
  • Ressourcenverwaltung: Wenn Sie Arbeitslasten bereitstellen, ohne Ressourcenwerte wie CPU und Arbeitsspeicher festzulegen, legt Autopilot automatisch vorkonfigurierte Standardwerte fest und ändert Ihre Ressourcenanfragen auf Arbeitslastebene.
  • Netzwerk: Autopilot aktiviert standardmäßig einige Netzwerksicherheitsfunktionen, z. B. dass der gesamte Pod-Netzwerktraffic durch Ihre Firewallregeln für Virtual Private Cloud geleitet wird, auch wenn der Traffic an andere Pods im Cluster geht.
  • Release-Verwaltung: Alle Autopilot-Cluster sind in einer GKE-Release-Version registriert, sodass Ihre Steuerungsebene und Ihre Knoten auf den neuesten qualifizierten Versionen in dieser Release-Version ausgeführt werden.
  • Verwaltete Flexibilität: Wenn Ihre Arbeitslasten spezielle Hardware- oder Ressourcenanforderungen haben, z. B. GPUs, können Sie diese Anforderungen in ComputeClasses definieren. Wenn Sie eine ComputeClass in Ihrer Arbeitslast anfordern, verwendet GKE Ihre Anforderungen, um Knoten für Ihre Pods zu konfigurieren. Sie müssen die Hardware für Knoten oder einzelne Arbeitslasten nicht manuell konfigurieren.
  • Geringere betriebliche Komplexität: Autopilot reduziert den Aufwand für die Plattformverwaltung, da Sie die Knoten, die Skalierung und die Planung von Vorgängen nicht ständig überwachen müssen.

Autopilot bietet ein SLA, das sowohl die Steuerungsebene als auch die Rechenkapazität abdeckt, die Ihre Pods verwenden.

Informationen zur containeroptimierten Computing-Plattform von Autopilot

In GKE-Version 1.32.3-gke.1927002 und höher enthält Autopilot eine spezielle containeroptimierte Computing-Plattform für Ihre Arbeitslasten. Diese Plattform eignet sich gut für die meisten Arbeitslasten für allgemeine Zwecke, die keine bestimmte Hardware erfordern, z. B. Webserver und Batchjobs mit mittlerer Intensität.

Die containeroptimierte Computing-Plattform verwendet GKE Autopilot-Knoten, deren Größe während der Ausführung dynamisch angepasst werden kann. Sie sind so konzipiert, dass sie mit minimalen Unterbrechungen von Bruchteilen einer CPU hochskaliert werden können. Durch diese dynamische Größenanpassung wird die Zeit, die für die Bereitstellung neuer Kapazität bei der Skalierung Ihrer Arbeitslasten erforderlich ist, erheblich reduziert. Um die Geschwindigkeit der Skalierung und Größenanpassung zu verbessern, verwaltet die GKE auch einen Pool mit vorab bereitgestellter Rechenkapazität, die bei erhöhtem Ressourcenbedarf automatisch für Arbeitslasten zugewiesen werden kann. Da die zugrunde liegende Maschinenreihe nicht festgelegt ist, variiert die Leistung pro CPU je nachdem, auf welcher Maschinenreihe GKE Ihren Pod plant.

Die containeroptimierte Computing-Plattform bietet folgende Vorteile:

  • Rechenkapazität entspricht Arbeitslasten: Autopilot passt die Rechenkapazität für die containeroptimierte Rechenplattform dynamisch an Faktoren wie die Anzahl der Pods und den Ressourcenverbrauch an. Dadurch entspricht die Rechenkapazität im Cluster den Anforderungen Ihrer Arbeitslasten.
  • Schnelle Skalierungszeiten: Bei Hochskalierungsereignissen kann GKE die Größe vorhandener Knoten dynamisch anpassen, um mehr Pods oder einen höheren Ressourcenverbrauch zu ermöglichen. Diese dynamische Kapazitätsbereitstellung bedeutet oft, dass neue Pods nicht auf das Hochfahren neuer Knoten warten müssen. Die Größenanpassung von Knoten wird für Arm-Arbeitslasten nicht unterstützt.
  • Unterstützung mehrerer Architekturen: Die containeroptimierte Rechenplattform unterstützt sowohl x86- als auch Arm-Architekturen für Ihre Arbeitslasten für allgemeine Zwecke. Standardmäßig verwenden Arbeitslasten die x86-Architektur. Sie können Arbeitslasten auf der Arm-Plattform für allgemeine Zwecke ausführen, indem Sie die Knotenauswahl kubernetes.io/arch: arm64 angeben oder die ComputeClasses autopilot-arm oder autopilot-arm-spot auswählen.

Sie können die containeroptimierte Autopilot-Computing-Plattform auf folgende Weise verwenden:

Preise

Die Autopilot-Preise hängen vom Typ der Hardware ab, die Ihre Pods verwenden:

  • Autopilot-Pods für allgemeine Zwecke: Die folgenden Pod-Typen verwenden ein Pod-basiertes Abrechnungsmodell und werden als Pods für allgemeine Zwecke kategorisiert:

    • Pods, die auf der containeroptimierten Computing-Plattform in Autopilot-Clustern oder Standardclustern ausgeführt werden.
    • Pods, die die integrierten ComputeClasses Balanced oder Scale-Out in Autopilot-Clustern auswählen.

    Weitere Informationen finden Sie im Abschnitt „Autopilot-Arbeitslasten für allgemeine Zwecke“ unter Google Kubernetes Engine-Preise.

  • Autopilot-Arbeitslasten, die bestimmte Hardware auswählen: Pods, die bestimmte Hardware auswählen, z. B. Compute Engine-Maschinenserien, Hardwarebeschleuniger oder ComputeClasses, verwenden ein knotenbasiertes Abrechnungsmodell. In diesem Modell bezahlen Sie für die zugrunde liegende Hardware und eine Prämie für die Knotenverwaltung.

    Weitere Informationen finden Sie im Abschnitt „Autopilot-Arbeitslasten, die bestimmte Hardware auswählen“ unter Google Kubernetes Engine-Preise.

Autopilot-Cluster und -Arbeitslasten

Mit der GKE können Sie den Autopilot-Modus für ganze Cluster oder für bestimmte Arbeitslasten in Ihren Standardclustern verwenden. Autopilot-Cluster sind die empfohlene Methode zur Verwendung von GKE, da der gesamte Cluster standardmäßig die Best Practices von Google verwendet.

Einige Organisationen haben jedoch Anforderungen an die manuelle Steuerung oder Flexibilität, die die Verwendung eines GKE Standard-Clusters erfordern. In diesen Fällen können Sie Autopilot weiterhin für bestimmte Arbeitslasten in Ihren Standardclustern verwenden und so von vielen Autopilot-Funktionen auf Arbeitslastebene profitieren.

In den folgenden Abschnitten wird beschrieben, wie Sie Autopilot-Cluster planen und erstellen. Wenn Sie einen Standardcluster haben und einige Ihrer Arbeitslasten im Autopilot-Modus ausführen möchten, lesen Sie den Abschnitt Arbeitslasten im Autopilot-Modus in GKE Standard.

Autopilot-Cluster planen

Planen und entwerfen Sie Ihre Google Cloud -Architektur, bevor Sie einen Cluster erstellen. In Autopilot fordern Sie Hardware in Ihren Arbeitslastspezifikationen an. GKE stellt die entsprechende Infrastruktur für die Ausführung dieser Arbeitslasten bereit und verwaltet sie. Wenn Sie beispielsweise Machine-Learning-Arbeitslasten ausführen, können Sie Hardwarebeschleuniger anfordern.

Planen und beantragen Sie ein Kontingent für Ihr Google Cloud -Projekt oder Ihre Organisation entsprechend der Größe Ihrer Arbeitslasten. GKE kann nur dann Infrastruktur für Ihre Arbeitslasten bereitstellen, wenn Ihr Projekt ein ausreichendes Kontingent für diese Hardware hat.

Berücksichtigen Sie bei der Planung die folgenden Faktoren:

  • Geschätzte Clustergröße und geschätzter Clusterumfang
  • Arbeitslasttyp
  • Clusterlayout und ‑nutzung
  • Netzwerklayout und ‑konfiguration
  • Sicherheitskonfiguration
  • Clusterverwaltung und ‑wartung
  • Bereitstellung und Verwaltung von Arbeitslasten
  • Logging und Monitoring

In den folgenden Abschnitten finden Sie Informationen und nützliche Ressourcen zu diesen Aspekten.

Netzwerk

Wenn Sie einen Autopilot-Cluster mit öffentlichen Netzwerken erstellen, können Arbeitslasten im Cluster miteinander und mit dem Internet kommunizieren. Dies ist der Standard-Netzwerkmodus. Google Cloud und Kubernetes bieten verschiedene zusätzliche Netzwerkfunktionen und -funktionen, die Sie je nach Ihren Anforderungen nutzen können, z. B. Cluster mit privatem Netzwerk.

Die Netzwerke in Kubernetes und in der Cloud sind komplex. Machen Sie sich mit den grundlegenden Konzepten von Netzwerken vertraut, bevor Sie mit der Änderung der Standardeinstellungen vonGoogle Cloud beginnen. Die folgende Tabelle bietet Ressourcen, mit denen Sie je nach Anwendungsfall weitere Informationen zum Netzwerk in GKE erhalten können:

Anwendungsfall Ressourcen
Funktionsweise von Netzwerken in Kubernetes und GKE

Nachdem Sie sich mit dem Netzwerkmodell vertraut gemacht haben, berücksichtigen Sie die Anforderungen an die Netzwerk- und Netzwerksicherheit Ihrer Organisation. Wählen Sie GKE- und Google Cloud -Netzwerkfeatures aus, die diese Kriterien erfüllen.

GKE-Netzwerkkonfiguration planen

Wir empfehlen, die Netzwerkkontingente für GKE zu verstehen, z. B. Endpunkte pro Dienst und API-Anfragelimits. Die folgenden Ressourcen helfen Ihnen, bestimmte Aspekte Ihrer Netzwerkeinrichtung zu planen:
Arbeitslasten freigeben
  • Verwenden Sie die Dienste, um Ihre Anwendungen im Internet freizugeben. Damit können Sie eine Anwendung, die in einer Gruppe von Pods ausgeführt wird, als einen einzelnen Netzwerkdienst verfügbar machen.
  • Verwenden Sie Workload Identity Federation for GKE, um Arbeitslasten für die sichere Kommunikation mit Google Cloud -APIs zu konfigurieren.
Hochverfügbare verbundene Dienste in mehreren Clustern ausführen Verwenden Sie Multi-Cluster-Dienste (MCS).
Load-Balancing für eingehenden Traffic ausführen
  • Verwenden Sie Ingress für Application Load Balancer, um externen HTTP(S)-Traffic anhand von URIs und Pfaden, z. B. einer komplexen Webanwendung, auf mehrere Dienste zu verteilen.
  • Verwenden Sie zum Erstellen eines regionalen externen Passthrough-Network-Load-Balancers einen LoadBalancer-Dienst, um externen Traffic auf einen einzelnen Dienst zu verteilen, z. B. ein Deployment, das einen öffentlichen E-Mail-Server ausführt.
  • Verwenden Sie Ingress für interne Application Load Balancer, um Load-Balancing von internem HTTP(S)-Traffic auf mehrere Dienste basierend auf URIs und Pfaden, z. B. mit einer Webanwendung im Intranet Ihres Unternehmens, zu verteilen.
  • Verwenden Sie einen internen Passthrough-Network-Load-Balancer, um Load-Balancing für internen Traffic auf einen einzelnen Dienst zu verwenden, z. B. mit einem Unternehmens-E-Mail-Server.
Netzwerksicherheit für Cluster konfigurieren
  • Wenn Sie den Zugriff auf Ihren Cluster über das öffentliche Internet steuern oder verhindern möchten, passen Sie die Netzwerkisolation an.
  • Wenn Sie den Zugriff auf die Steuerungsebene auf bestimmte IP-Adressbereiche beschränken möchten, verwenden Sie autorisierte Netzwerke auf Steuerungsebene.
  • Verwenden Sie Netzwerkrichtlinien, um den Pod-Traffic zu steuern. Die Durchsetzung von Netzwerkrichtlinien ist mit GKE Dataplane V2 verfügbar (standardmäßig in Autopilot-Clustern aktiviert). Eine Anleitung finden Sie unter Netzwerkrichtlinien.
Kubernetes-Netzwerktraffic beobachten

Standardmäßig verwendet Autopilot GKE Dataplane V2 für Messwerte und Beobachtbarkeit.

Skalierung

Der effektive Betrieb einer Plattform erfordert umfangreiche Planungen und sorgfältige Überlegungen. Sie müssen die Skalierbarkeit Ihres Designs berücksichtigen. Das ist die Fähigkeit Ihrer Cluster, zu wachsen, ohne die Service Level Objectives (SLOs) zu überschreiten. Eine ausführliche Anleitung für Plattformadministratoren und Entwickler finden Sie unter Richtlinien für das Erstellen skalierbarer Cluster.

Sie sollten auch die Kontingente und Limits von GKE berücksichtigen, insbesondere wenn Sie große Cluster mit potenziell Tausenden von Pods ausführen möchten.

In Autopilot skaliert GKE Ihre Knoten automatisch anhand der Anzahl der Pods in Ihrem Cluster. Wenn in einem Cluster keine Arbeitslasten ausgeführt werden, kann Autopilot den Cluster automatisch auf null Knoten herunterskalieren. Nach dem Herunterskalieren des Clusters verbleiben keine Knoten im Cluster und System-Pods befinden sich daher in einem nicht planbaren Zustand. Das ist ganz normal. Bei den meisten neu erstellten Autopilot-Clustern kann es sein, dass für die ersten bereitgestellten Arbeitslasten mehr Zeit für die Planung nötig ist. Das liegt daran, dass der neue Autopilot-Cluster beim Erstellen mit null nutzbaren Knoten beginnt und wartet, bis Sie eine Arbeitslast bereitstellen, um zusätzliche Knoten bereitzustellen.

Best Practice:

Um die Anzahl der Pods in Ihrem Cluster automatisch zu skalieren, verwenden Sie einen Mechanismus wie das horizontale Pod-Autoscaling von Kubernetes. Damit werden Pods basierend auf den integrierten CPU- und Arbeitsspeichermesswerten oder benutzerdefinierten Messwerten aus Cloud Monitoring skaliert. Außerdem wird in Autopilot standardmäßig das vertikale Pod-Autoscaling aktiviert. Wenn Sie die CPU-Anfragen von Containern optimieren und gleichzeitig Replikate automatisch skalieren möchten, können Sie die HPA-Größenanpassung mit VPA (Vorabversion) verwenden. Informationen zum Konfigurieren der horizontalen Skalierung anhand verschiedener Messwerte finden Sie unter Horizontales Pod-Autoscaling konfigurieren.

Sicherheit

Autopilot-Cluster aktivieren Best Practices und Einstellungen für die Sicherheit automatisch und wenden sie standardmäßig an. Dazu gehören viele Empfehlungen in Clustersicherheit härten und GKE-Sicherheitsübersicht..

Wenn Sie Autopilot-Arbeitslasten in Ihren Standard-Clustern ausführen, wendet GKE verschiedene Autopilot-Sicherheitsmaßnahmen auf diese Arbeitslasten an, soweit dies möglich ist. Sie können bestimmte Autopilot-Sicherheitsrichtlinien im gesamten Standardcluster strikt erzwingen. Wenn Sie alle verfügbaren Autopilot-Richtlinien erzwingen, hat Ihr Standardcluster eine ähnliche Betriebsumgebung wie ein Autopilot-Cluster.

Weitere Informationen zu Autopilot-Härtungsmaßnahmen und zur Implementierung Ihrer spezifischen Sicherheitsanforderungen finden Sie unter Sicherheitsmaßnahmen in Autopilot.

Cluster erstellen

Nachdem Sie Ihre Umgebung geplant und Ihre Anforderungen kennen, erstellen Sie einen Autopilot-Cluster. Neue Autopilot-Cluster sind regionale Cluster mit einer öffentlich zugänglichen IP-Adresse. Auf jeden Cluster werden Baseline-Härtungsmaßnahmen sowie automatische Skalierung und andere Features angewendet. Eine vollständige Liste der vorkonfigurierten Features finden Sie unter GKE Autopilot und Standard vergleichen.

Wenn Sie den Cluster ohne Zugriff auf externe IP-Adressen erstellen möchten, konfigurieren Sie die Netzwerkisolation.

Arbeitslasten im Autopilot-Modus bereitstellen

Sie können kompatible Kubernetes-Arbeitslasten im Autopilot-Modus ausführen, sodass die GKE die Skalierung, die effiziente Planung und die zugrunde liegende Infrastruktur verwaltet. Sie können die containeroptimierte Computing-Plattform für Ihre Arbeitslasten für allgemeine Zwecke verwenden oder mithilfe einer ComputeClass bestimmte Hardware für Ihre Arbeitslasten auswählen.

Sie können diese Autopilot-Arbeitslasten auf eine der folgenden Arten ausführen:

Klicken Sie auf Anleitung, um einen interaktiven Leitfaden in der Google Cloud Console zum Bereitstellen und Freigeben einer Anwendung in einem Autopilot-Cluster zu erhalten:

Anleitung

Die folgende Tabelle enthält einige gängige Anforderungen und gibt Empfehlungen, was Sie tun sollten:

Anwendungsfall Ressourcen
Einzelne Knoteneigenschaften beim Skalieren eines Clusters steuern Erstellen Sie eine benutzerdefinierte ComputeClass und fordern Sie sie in Ihrem Arbeitslastmanifest an. Weitere Informationen finden Sie unter Benutzerdefinierte ComputeClasses.
Autopilot-Arbeitslasten in einem Standardcluster ausführen Verwenden Sie eine Autopilot-ComputeClass im Standardcluster. Weitere Informationen finden Sie unter Arbeitslasten im Autopilot-Modus in GKE Standard.
Arm-Arbeitslasten ausführen Fordern Sie für Arbeitslasten für allgemeine Zwecke die Arm-Architektur und die integrierte ComputeClass autopilot-arm oder autopilot-arm-spot an. Wenn Sie bestimmte Hardwareanforderungen haben, fordern Sie eine Maschinenreihe mit Arm-CPUs in einer benutzerdefinierten ComputeClass an. Weitere Informationen finden Sie unter Benutzerdefinierte ComputeClasses.
Beschleunigte KI/ML-Arbeitslasten ausführen Fordern Sie GPUs in einer ComputeClass oder in Ihrem Arbeitslastmanifest an. Weitere Informationen zum Anfordern von GPUs in Ihrem Arbeitslastmanifest finden Sie unter GPU-Arbeitslasten in Autopilot bereitstellen.
Fehlertolerante Arbeitslasten wie Batchjobs zu geringeren Kosten ausführen

Sie können eine beliebige ComputeClass oder Hardwarekonfiguration mit Spot-Pods verwenden.
Arbeitslasten ausführen, die nur minimale Unterbrechungen erfordern, z. B. Spieleserver oder Arbeitswarteschlangen Geben Sie nur in Autopilot-Clustern die Annotation cluster-autoscaler.kubernetes.io/safe-to-evict=false in der Pod-Spezifikation an. Pods sind bis zu sieben Tage vor der Bereinigung geschützt, die durch automatische Knotenupgrades oder Herunterskalierungsereignisse verursacht werden. Weitere Informationen finden Sie unter Laufzeit von Autopilot-Pods verlängern.
Lassen Sie Arbeitslasten Bursts über ihre Anfragen hinaus verursachen, wenn nicht verwendete Ressourcen in der Summe der Pod-Ressourcenanfragen auf dem Knoten verfügbar sind. Legen Sie die limits-Ressource höher als requests fest oder legen Sie keine Ressourcenlimits fest. Weitere Informationen finden Sie unter Pod-Bursting in GKE konfigurieren.

Mit Autopilot können Sie CPU-, Arbeitsspeicher- und sitzungsspezifische Speicherressourcen für Ihre Arbeitslasten anfordern. Die zulässigen Bereiche hängen davon ab, ob Sie Ihre Pods auf der containeroptimierten Autopilot-Computing-Plattform oder auf bestimmter Hardware ausführen möchten. Informationen zu den standardmäßigen Anfragen für Containerressourcen und den zulässigen Ressourcenbereichen finden Sie unter Ressourcenanfragen in Autopilot.

Arbeitslasttrennung

Autopilot-Cluster unterstützen die Verwendung von Knotenauswahlen und Knotenaffinität zum Konfigurieren der Arbeitslasttrennung. Die Arbeitslasttrennung ist nützlich, wenn Sie GKE anweisen müssen, Arbeitslasten auf Knoten zu platzieren, die bestimmte Kriterien erfüllen, z. B. benutzerdefinierte Knotenlabels. Sie können GKE beispielsweise anweisen, Gameserver-Pods auf Knoten mit dem Label game-server zu planen und keine anderen Pods auf diesen Knoten zu planen.

Weitere Informationen finden Sie unter Arbeitslasttrennung in GKE konfigurieren.

Pods in bestimmten Zonen mithilfe der zonalen Topologie planen

Wenn Sie Pods in einer bestimmten Google Cloud -Zone platzieren müssen, um beispielsweise auf Informationen zu einem zonalen nichtflüchtigen Compute Engine-Speicher zuzugreifen, lesen Sie die Informationen unter GKE-Pods in bestimmten Zonen platzieren.

Pod-Affinität und Anti-Affinität

Verwenden Sie Pod-Affinität und -Antiaffinität, um Pods auf einem einzelnen Knoten zu platzieren oder andere Pods zu vermeiden. Die Pod-Affinität und -Antiaffinität weist Kubernetes an, eine Planungsentscheidung anhand der Labels von Pods zu treffen, die auf Knoten in einer bestimmten Topologiedomain, z. B. einer bestimmten Region oder Zone, ausgeführt werden. Beispielsweise können Sie GKE anweisen, Frontend-Pods nicht zusammen mit anderen Frontend-Pods auf denselben Knoten zu planen, um die Verfügbarkeit bei einem Ausfall zu verbessern.

Eine Anleitung und weitere Informationen finden Sie unter Pod-Affinität und Anti-Affinität.

In GKE können Sie die Pod-Affinität und Anti-Affinität mit den folgenden Labels in topologyKey verwenden:

  • topology.kubernetes.io/zone
  • kubernetes.io/hostname

Streuungseinschränkungen für Pod-Topologien

Wenn Sie die Verfügbarkeit Ihrer Arbeitslasten verbessern möchten, weil Kubernetes die Anzahl der Pods nach oben und unten skaliert, können Sie Einschränkungen für die Pod-Topologieverteilung festlegen. Damit wird gesteuert, wie Kubernetes Ihre Pods auf Knoten innerhalb einer Topologiedomain verteilt, z. B. eine Region. Sie können Kubernetes beispielsweise anweisen, eine bestimmte Anzahl von Gameserver-Sitzungs-Pods in jeder der drei Google Cloud -Zonen in der Region us-central1 zu platzieren.

Beispiele, weitere Informationen und Anleitungen finden Sie unter Pod-Topologie-Streuungseinschränkungen.

Best Practice:

Wenn Sie topologySpreadConstraints mit Cluster-Autoscaling verwenden, empfehlen wir, nodeTaintsPolicy: Honor festzulegen. Mit dieser Einstellung wird sichergestellt, dass Cluster Autoscaler die Pod-Migration beim Herunterskalieren korrekt simuliert, um potenzielle Skalierungsschleifen zu vermeiden. Ohne diese Einstellung kann es passieren, dass der Autoscaler Knoten so herunterskaliert, dass die Einschränkungen für die Topologieverteilung verletzt werden. Das führt zu sofortigen Hochskalierungsereignissen und Unterbrechungen der Arbeitslast.

Die Einstellung whenUnsatisfiable: ScheduleAnyway trägt auch dazu bei, dass Pods bei vorübergehenden Topologieungleichgewichten, z. B. während eines Zonenausfalls, nicht mehr planbar sind.

Autopilot-Cluster verwalten und überwachen

In Autopilot verwaltet GKE automatisch Cluster-Upgrades und ‑Wartungen sowohl für die Steuerungsebene als auch für die Worker-Knoten. Autopilot-Cluster haben auch integrierte Funktionen, mit denen Sie Ihre Cluster und Arbeitslasten überwachen können.

Upgrades der GKE-Versionen

Alle Autopilot-Cluster sind in einer GKE-Release-Version registriert. In Release-Versionen verwaltet GKE die Kubernetes-Version des Clusters, wobei je nach Version ein Gleichgewicht zwischen Feature-Verfügbarkeit und Versionsstabilität angestrebt wird. Autopilot-Cluster werden standardmäßig in der Release-Version „Regular“ registriert. Sie können jedoch einen anderen Kanal auswählen, der Ihren Anforderungen an Stabilität und Funktionalität entspricht. Weitere Informationen zu Release-Versionen finden Sie unter Release-Versionen.

GKE startet automatisch Upgrades, überwacht den Fortschritt und pausiert Vorgänge, wenn Probleme auftreten. Sie haben folgende Möglichkeiten, um den Upgrade-Vorgang manuell zu steuern:

  • Wenn Sie festlegen möchten, wann GKE automatische Upgrades ausführen kann, erstellen Sie Wartungsfenster. Beispiel: Sie können das Wartungsfenster auf den Abend vor dem wöchentlichen Zurücksetzen Ihres Multiplayer-Games festlegen, damit sich Nutzer beim Zurücksetzen ohne Unterbrechung anmelden können.
  • Mit Wartungsausschlüssen können Sie festlegen, wann GKE in einem bestimmten Zeitraum keine automatischen Upgrades starten darf. Beispiel: Sie können einen Wartungsausschluss für die Dauer Ihrer Black Friday- und Cyber Monday-Verkaufsereignisse festlegen, damit Ihre Kunden problemlos einkaufen können.
  • Wenn Sie eine neue Version abrufen möchten, bevor automatische Upgrades beginnen, führen Sie ein manuelles Upgrade der Steuerungsebene durch. GKE gleicht die Knotenversion im Laufe der Zeit mit der Version der Steuerungsebene ab.
  • Informationen zum Abrufen einer Patchversion, die nur in einer neueren Release-Version verfügbar ist, finden Sie unter Patchversionen aus einer neueren Version ausführen. Beispielsweise kann es sein, dass Sie eine bestimmte Patchversion benötigen, um kürzlich erkannte Sicherheitslücken anzusprechen.

Autopilot-Cluster überwachen

Für Autopilot-Cluster sind Cloud Logging, Cloud Monitoring und Google Cloud Managed Service for Prometheus bereits aktiviert.

Autopilot-Cluster erfassen automatisch folgende Arten an Logs und Messwerten, wobei die Best Practices von Google für die Telemetrieerfassung berücksichtigt werden:

Logs für Cloud Logging

  • Systemprotokolle
  • Arbeitslast-Logs
  • Audit-Logs zur Administratoraktivität
  • Audit-Logs zum Datenzugriff

Messwerte für Cloud Monitoring

  • Systemmesswerte
  • Arbeitslastmesswerte (von Google Cloud Managed Service for Prometheus)

Zum Aktivieren von Logging und Monitoring ist keine zusätzliche Konfiguration erforderlich. In der folgenden Tabelle wird beschrieben, wie Sie die erfassten Telemetriedaten entsprechend Ihren Anforderungen verwenden können:

Anwendungsfall Ressourcen
GKE-Logs verstehen und auf sie zugreifen
  • Informationen zu automatisch erfassten Logs finden Sie unter Welche Logs erfasst werden.
  • Informationen zum Zugriff auf die Logs und zur Verwendung der Cloud Logging-Benutzeroberfläche in der Google Cloud Console finden Sie unter GKE-Logs anzeigen.
  • Beispielabfragen, mit denen Sie System- und Arbeitslastprotokolle in Kubernetes filtern können, finden Sie unter Kubernetes-bezogene Abfragen.
  • Beispielabfragen zum Filtern von Audit-Logs für Administratoraktivitäten und Datenzugriff finden Sie unter Informationen zum GKE-Audit-Logging.
  • Informationen zum Konfigurieren von Logs für mehrmandantenfähige Umgebungen, z. B. wenn Teams bestimmte Namespaces in einem einzelnen GKE-Cluster haben, aber jedes Team ein eigenes Google Cloud -Projekt hat, finden Sie unter Mehrmandantenfähiges Logging in GKE.
Leistung Ihrer GKE-Cluster beobachten

Eine effektive Überwachung der Clusterleistung kann Ihnen helfen, die Betriebskosten Ihrer Cluster und Arbeitslasten zu optimieren.

  • Verwenden Sie das GKE-Dashboard in Monitoring, um den Status Ihrer Cluster zu visualisieren. Weitere Informationen finden Sie unter GKE-Cluster beobachten.
  • GKE bietet auch ein Beobachtbarkeits-Dashboard in der Google Cloud Console. Weitere Informationen finden Sie unter Beobachtbarkeitsmesswerte anzeigen.
Sicherheitsstatus Ihrer Cluster überwachen Mit dem Sicherheitsstatus-Dashboard können Sie Ihre laufenden Arbeitslasten anhand von GKE-Best Practices prüfen, nach Sicherheitslücken in Ihren Containerbetriebssystemen und Sprachpaketen suchen und umsetzbare Empfehlungen für Abhilfemaßnahmen erhalten. Weitere Informationen finden Sie unter Das Sicherheitsstatus-Dashboard.

Fehlerbehebung

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Autopilot-Clustern.

Nächste Schritte