Flottenfeatures planen

Ein wichtiger Teil der Planung für Flotten besteht darin, zu entscheiden, welche flottenfähigen Funktionen Sie verwenden möchten. Insbesondere wenn Sie mit vorhandenen Clustern und Produktionsarbeitslasten arbeiten, sollten Sie Flottenfunktionen ermitteln, die sofort mit minimalem Aufwand oder Risiko für Ihre vorhandenen Anwendungen eingeführt werden können. Planen Sie gleichzeitig andere Funktionen, die eine allmähliche oder vorsichtige Einführung erfordern. In diesem Leitfaden werden die verschiedenen Arten von Funktionen beschrieben, die durch die Verwendung von Flotten aktiviert werden, sowie ihre Anforderungen. Außerdem erhalten Sie praktische Hinweise zur Einführung von Funktionen.

Viele der in diesem Leitfaden beschriebenen Funktionen sind nur in GKE Enterprise verfügbar. Weitere Informationen finden Sie unter GKE Enterprise-Bereitstellungsoptionen.

Dieser Leitfaden richtet sich an Cloud-Architekten, die mit Flotten in ihren Organisationen beginnen möchten. Bevor Sie diesen Leitfaden lesen, sollten Sie sich mit der Übersicht zur Flottenverwaltung und dem Artikel Flottenressourcen planen vertraut machen. Dort erfahren Sie, wie Sie neue oder vorhandene Cluster in Flotten organisieren.

Best Practices für die Einführung von Funktionen

Alle Flottenfunktionen (mit Ausnahme der grundlegenden Beobachtbarkeit von Flotten) sind optional. Sie müssen also angeben, dass Sie sie verwenden möchten. Wenn Sie einer Flotte einen vorhandenen Cluster hinzufügen, ändert sich dadurch nicht die Konfiguration. Wenn Sie sich für die Nutzung von Flottenfunktionen entscheiden, können einige Funktionen sofort und mit minimalem Risiko aktiviert werden. Bei anderen sollten Sie jedoch vorsichtiger vorgehen. In diesem Abschnitt finden Sie einige Hinweise zur Einführung von Funktionen.

Besonders bei vorhandenen Clustern und Arbeitslasten müssen Sie besonders vorsichtig sein, wenn Funktionen Gleichheiten verwenden. Bei diesem Flottenkonzept wird davon ausgegangen, dass Namespaces, Dienste oder Identitäten mit demselben Namen in verschiedenen Clustern identisch sind. Weitere Informationen zum Prinzip der Gleichheit und zu den Funktionen, die sie verwenden, finden Sie unter Funktionsweise von Flotten.

Funktionen mit geringem Risiko einrichten

Die folgenden „ambient“-Funktionen gehen nicht von Gleichheit aus und wirken sich in keiner Weise auf Cluster aus. Sie können alle auch mit vorhandenen Arbeitslasten und Clustern sicher verwendet werden. So profitieren Sie sofort von verbesserter Beobachtbarkeit und Sicherheitsinformationen in Ihrer gesamten Flotte sowie von der Möglichkeit, die Reihenfolge der Clusterupgrades basierend auf der Flottenmitgliedschaft zu verwalten.

Die folgenden Funktionen werden in einzelnen Clustern installiert. Die Funktionen können Gleichheit annehmen, aber nur, wenn Ressourcen über mehrere Cluster hinweg konfiguriert oder angegeben werden. Sie können diese Funktionen also sicher in Ihren Clustern mit vorhandenen Arbeitslasten aktivieren und müssen die Gleichheit nur berücksichtigen, wenn Sie Konfigurationen für sie erstellen oder verwenden, in denen diese optionalen Auswahlmöglichkeiten verwendet werden.

Erweiterte Multi-Cluster-Features einrichten

Die folgenden leistungsstarken Funktionen reduzieren den operativen Aufwand bei der Verwaltung mehrerer Cluster. Bei diesen Funktionen ist jedoch Vorsicht geboten, da sie alle eine oder mehrere Arten von Gleichheit voraussetzen, um zu funktionieren. Wenn Sie sie aktivieren oder deaktivieren, kann sich das auf mehrere Cluster und ihre Arbeitslasten auswirken.

Wenn Sie beispielsweise Kubernetes-Namespaces mit demselben Namen in verschiedenen Clustern und Anwendungen (einschließlich des Standard-Namespaces) haben, sollten Sie prüfen, ob sie als derselbe Namespace behandelt werden sollen, bevor Sie Funktionen aktivieren, die diese Annahme treffen. Wenn Sie Cloud Service Mesh verwenden möchten, sollten Sie ebenfalls wissen, welche Dienstendpunkte in Ihren Clustern zusammengeführt werden, und dafür sorgen, dass dies das gewünschte Verhalten ist.

Namespace-Gleichheit prüfen

Wenn Sie Ihre Anwendungen gut kennen, können Sie Ihre Namespaces prüfen, indem Sie nur prüfen, ob keine zwei „verschiedenen“ Anwendungen denselben Namespace verwenden. Achten Sie insbesondere auf die Ad-hoc-Nutzung des Standard-Namespaces. Wenn Sie beispielsweise in einem Cluster einen Namespace namens default und in einem anderen Cluster einen Namespace namens default haben, die aber für unterschiedliche Zwecke verwendet werden, sollten Sie einen davon umbenennen.

Für einen strengeren Ansatz können Sie Folgendes versuchen: Prüfen Sie für jeden Satz von Namespaces mit demselben Namen in verschiedenen Clustern einer Flotte Folgendes:

  • In jedem Cluster gelten dieselben RBAC-Regeln und dem Namespace der Principals ist der Zugriff auf den Namespace erlaubt.
  • die von Pods verwendeten Bilder (ohne Hash/Tag) identisch sind.
  • die von den Pods verwendeten Secrets identisch sind.

Wenn alle diese Bedingungen erfüllt sind, sind die Namespaces ausreichend ähnlich, um sie als „identisch“ zu behandeln.

Wenn Ihre Namespaces nicht ausreichend ähnlich sind, können Sie Apps in neue Namespaces migrieren. Sobald Sie sicher sind, dass die Namespaces übereinstimmen, können Sie Funktionen aktivieren, die sie verwenden.

Dienstgleichheit prüfen

Wenn Sie Cloud Service Mesh zum Verwalten Ihrer mikroservicebasierten Anwendungen verwenden möchten, sollten Sie auch die Dienstgleichheit berücksichtigen. Das bedeutet, dass Cloud Service Mesh jede Kombination aus Namespace und Dienstname in Bezug auf Folgendes als denselben logischen Dienst behandelt:

  • Identität (speziell für die Sicherheit von Cloud Service Mesh): Wenn namespace1/service1 für eine Aktion autorisiert ist, sind auch Arbeitslasten mit dieser Identität aus jedem Cluster autorisiert.
  • Traffic-Management: Standardmäßig wird der Traffic in jedem Cluster über namespace1/service1 Dienste verteilt.
  • Beobachtbarkeit: Messwerte für namespace1/service1 in allen Clustern werden zusammengefasst.

Wenn Sie Cloud Service Mesh mit neuen Clustern und Anwendungen aktivieren, empfehlen wir, eindeutige Kombinationen aus Namespace und Dienstnamen für Ihr gesamtes Mesh zu reservieren. Prüfen Sie bei vorhandenen Anwendungen Ihre Dienste, um sicherzustellen, dass Dienste mit demselben Namespace und Namen in Ihren Clustern als derselbe Dienst in Bezug auf Identität, Traffic-Management und Beobachtbarkeit behandelt werden sollen.

Achten Sie insbesondere darauf, dass logisch unterschiedliche Dienste (z. B. eine Zahlungsabrechnungs-API und eine Zahlungstransaktions-API) nicht dieselbe Kombination aus Namespace und Name haben (z. B. payments/api), da sie in einem Service Mesh als derselbe Dienst behandelt werden. Diese konzeptionelle Verbindung erfolgt auch über regionale Grenzen hinweg. Außerdem kann die Funktion der Dienste beeinträchtigt werden.

Die Gleichheit des Service-Namespace/-Namens wird auch von Multi-Cluster-Ingress und Multi-Cluster-Gateway angenommen, wenn Traffic an Dienste in mehreren Clustern weitergeleitet wird, jedoch nur für Dienste, die außerhalb der Cluster verfügbar gemacht werden.

Workload Identity berücksichtigen

Eine leistungsstarke Flottenfunktion ist die standortübergreifende Workload Identity-Föderation. Dadurch werden die Funktionen der Workload Identity-Föderation für GKE erweitert, mit der sich die Arbeitslasten in Ihrem Cluster bei Google authentifizieren können, ohne dass Sie Dienstkontoschlüssel herunterladen, manuell rotieren und im Allgemeinen verwalten müssen. Google Cloud Stattdessen werden die Arbeitslasten mithilfe der vom Cluster generierten kurzlebigen Tokens authentifiziert. Jeder Cluster wird einem speziellen Workload Identity-Pool als Identitätsanbieter hinzugefügt. Arbeitslasten, die in einem bestimmten Namespace ausgeführt werden, können dieselbe Identitäts- und Zugriffsverwaltungsidentität in allen Clustern teilen.

Während bei der regulären Workload Identity-Föderation für GKE ein projektweiter Identitätspool verwendet wird, wird bei der flottenweiten Workload Identity-Föderation ein Workload Identity-Pool für die gesamte Flotte verwendet, auch wenn sich die Cluster in verschiedenen Projekten befinden. Dabei werden Identitäten innerhalb der Flotte sowie Namespaces und Dienste implizit als identisch betrachtet. Dies vereinfacht die Einrichtung der Authentifizierung für Ihre Anwendungen in mehreren Projekten. Es kann jedoch zusätzliche Zugriffssteuerungsaspekte geben, die über die für die reguläre Identitätsföderation von Arbeitslasten für GKE hinausgehen, wenn Sie sie in Flotten mit mehreren Projekten verwenden. Dies gilt insbesondere, wenn das Flotten-Hostprojekt eine Mischung aus Flotten- und Nicht-Flottenclustern enthält.

Weitere Informationen zur Identitätsföderation von Arbeitslasten für Flotten und zur Verwendung für den Zugriff auf Google Cloud Dienste finden Sie unter Workload Identity für Flotten verwenden. Eine Anleitung zum Minimieren von Risiken mit der Workload Identity-Föderation für Flotten mit einigen Beispielen finden Sie unter Best Practices für die Verwendung von Workload Identity für Flotten.

Standardeinstellungen auf Flottenebene

Mit GKE Enterprise können Sie Standardeinstellungen für bestimmte Enterprise-Features auf Flottenebene festlegen, darunter Cloud Service Mesh, Config Sync und Policy Controller. So können Sie Cluster so einrichten, dass diese Funktionen verwendet werden, ohne jeden Cluster einzeln konfigurieren zu müssen. Ein Administrator kann beispielsweise Policy Controller für seine Flotte aktivieren und Standardrichtlinien auf Flottenebene festlegen. Dadurch wird der erforderliche Agent in Clustern neuer Flottenmitglieder installiert und Standardrichtlinien werden auf sie angewendet.

Diese Standardeinstellungen werden jedoch nur automatisch auf neue Cluster angewendet, die Sie der Flotte bei der Clustererstellung hinzufügen. Vorhandene Cluster und ihre Arbeitslasten sind davon nicht betroffen, auch wenn Sie sie der Flotte bereits hinzugefügt haben oder sie die Cluster nach der Einrichtung der Standardfunktionen hinzufügen. Sie können also Standardeinstellungen auf Flottenebene sicher einrichten, ohne dass Sie befürchten müssen, dass Features in Clustern aktiviert oder konfiguriert werden, in denen Sie dies noch nicht tun möchten. Sie können die Standardeinstellungen jederzeit auf vorhandene Cluster anwenden.

Funktionsanforderungen

Bei der Implementierung von Flotten auf der Grundlage der Flottenfunktionen, die Ihre Organisation verwenden möchte, sind einige Einschränkungen zu beachten. Beispielsweise unterstützen einige Funktionen die Arbeit mit Clustern, die sich nicht im Flotten-Hostprojekt befinden, während andere nicht in Clustern außerhalb von Google Cloudunterstützt werden.

In der folgenden Tabelle sind die aktuellen Anforderungen und Einschränkungen für jede Komponente aufgeführt. In den folgenden Abschnitten finden Sie einige spezifische Richtlinien.

Funktion
 Clustertypen
 Projektanforderungen
 VPC-Anforderungen
Config Sync Alle von GKE Enterprise unterstützten Cluster Keine Keine
Policy Controller Alle von GKE Enterprise unterstützten Cluster Keine Keine
Cloud Service Mesh Weitere Informationen zu Einschränkungen Alle Cluster, die mit Cloud Service Mesh verwendet werden und sich im selben Projekt befinden, müssen bei derselben Flotte registriert sein. Weitere Informationen finden Sie unter Anforderungen an Cloud Service Mesh-Flotten. GKE-Cluster müssen sich im selben VPC-Netzwerk befinden.
Multi-Cluster-Dienste (MCS) GKE auf Google Cloud Keine Weitere Informationen finden Sie unter MCS in einer freigegebenen VPC.
Multi-Cluster-Ingress und Multi-Cluster-Gateway GKE auf Google Cloud Ingress-/Gateway-Ressourcen, GKE-Cluster und Flotten müssen sich im selben Projekt befinden. Ingress-/Gateway-Ressourcen und GKE-Cluster müssen sich im selben VPC-Netzwerk befinden.
Identitätspools für Arbeitslasten Optimiert für GKE on Google Cloud und Google Distributed Cloud on VMware. Andere Kubernetes-Cluster werden unterstützt, erfordern aber zusätzliche Einrichtungsarbeiten. Keine Keine
Binärautorisierung GKE on Google Cloud, Google Distributed Cloud on VMware, Google Distributed Cloud on Bare Metal Keine Keine
Advanced Vulnerability Insights GKE auf Google Cloud Keine Keine
Sicherheitsstatus GKE auf Google Cloud Keine Keine
Compliancestatus GKE auf Google Cloud Keine Keine
Messwerte zur Auslastung von Flottenressourcen GKE auf Google Cloud Keine Keine
Flottenprotokollierung Alle Keine Keine
Connect-Gateway Alle Keine Keine
Flottenteamverwaltung Alle Keine Keine
Pod-FQDN-Netzwerkrichtlinien GKE auf Google Cloud Keine Keine
Transparente Verschlüsselung zwischen Knoten GKE auf Google Cloud Keine Keine
Config Controller Nicht zutreffend Keine Keine
Roll‑out-Sequenzierung GKE auf Google Cloud Keine Keine

Anforderungen an die Virtual Private Cloud berücksichtigen

Wenn Sie eine Funktion wie Cloud Service Mesh verwenden möchten, für die sich Cluster in einem einzigen VPC-Netzwerk (Virtual Private Cloud) befinden müssen, wie in der vorherigen Tabelle dargestellt, sollten Sie für jedes VPC eine Flotte erstellen. Wenn Sie diese Funktionen nicht verwenden möchten, können mehrere VPCs in einer Flotte zusammengefasst werden.

Ein häufiges Muster ist beispielsweise, dass eine Organisation mehrere Projekte mit jeweils einem eigenen Standard-VPC hat. Zwischen diesen Standorten bestehen möglicherweise bereits Peering-Verbindungen. Wenn Sie keine Funktion mit VPC-Anforderungen verwenden, können alle in einer einzigen Flotte zusammengefasst werden. Ein weiteres gängiges Muster folgt einer Hub-and-Spoke-Topologie, bei der mehrere VPCs verwendet werden. Wenn Sie keine Funktion verwenden, die eine einzelne VPC erfordert, können Sie Cluster aus all diesen VPCs in einer Flotte platzieren. Beachten Sie, dass Sie in einigen Fällen durch die Einhaltung dieser Richtlinien Flotten mit nur einem Cluster haben. In diesem Fall müssen Sie möglicherweise auf die Verwendung von Funktionen mit VPC-Einschränkungen verzichten und Flotten mit mehreren Projekten erstellen oder Ihre Architektur überdenken und Arbeitslasten gegebenenfalls verschieben.

Anforderungen an Multi-Cluster-Netzwerke

Wenn Sie Multi-Cluster-Ingress oder Multi-Cluster-Gateways für die Traffic-Verwaltung verwenden möchten, beachten Sie, dass der Gateway-Controller in beiden Fällen nicht über mehrere Projekte hinweg verwendet werden kann. Das bedeutet, dass sich alle Cluster, die Sie mit diesen Funktionen verwenden möchten, im selben Projekt und in derselben Flotte befinden müssen. Wenn Sie Flotten mit Clustern aus mehreren Projekten erstellen möchten, können Sie stattdessen einzelne Cluster-Gateways verwenden und den Traffic auf andere Weise (z. B. über DNS) an das richtige Gateway weiterleiten. Cluster, die diese Funktionen verwenden, müssen sich außerdem im selben VPC-Netzwerk befinden.

Nächste Schritte