Flottenfeatures planen

Ein wichtiger Teil der Planung für Flotten ist die Entscheidung, welche flottenfähigen Funktionen Sie verwenden möchten. Insbesondere wenn Sie mit vorhandenen Clustern und Produktionsarbeitslasten arbeiten, sollten Sie Flottenfunktionen identifizieren, die sofort mit minimalem Aufwand oder Risiko für Ihre vorhandenen Anwendungen eingeführt werden können. Gleichzeitig sollten Sie andere Funktionen planen, die möglicherweise eine schrittweise oder sorgfältige Einführung erfordern. In diesem Leitfaden werden die verschiedenen Arten von Funktionen beschrieben, die durch die Verwendung von Flotten aktiviert werden, sowie die Anforderungen an diese Funktionen. Außerdem finden Sie hier einige praktische Hinweise zur Einführung von Funktionen.

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 unserer Übersicht zur Flottenverwaltung und Flottenressourcen planen vertraut machen, in denen die Organisation neuer oder vorhandener Cluster in Flotten beschrieben wird.

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 einen vorhandenen Cluster einer Flotte hinzufügen, ändert sich seine Konfiguration nicht. Wenn Sie sich für die Verwendung von Flottenfunktionen entscheiden, können einige Funktionen sofort mit minimalem Risiko aktiviert werden. Bei anderen Funktionen ist jedoch mehr Vorsicht geboten. In diesem Abschnitt finden Sie einige Hinweise zur Einführung von Funktionen.

Insbesondere bei vorhandenen Clustern und Arbeitslasten müssen Sie besonders darauf achten, wo Funktionen Gleichheit verwenden. Dies ist ein Flottenkonzept, bei dem Namespaces, Dienste oder Identitäten mit demselben Namen in verschiedenen Clustern von der Funktion als identisch angenommen werden. Weitere Informationen zum Prinzip der Gleichheit und zu den Funktionen, die es verwenden, finden Sie unter Funktionsweise von Flotten.

Einführung von Funktionen mit geringem Risiko

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

Die folgenden Funktionen werden in einzelnen Clustern installiert. Die Funktionen können von Gleichheit ausgehen, aber nur, wenn Ressourcen in mehreren Clustern konfiguriert oder angegeben werden. Sie können diese Funktionen also bedenkenlos für Ihre Cluster mit vorhandenen Arbeitslasten aktivieren. Die Gleichheit muss nur berücksichtigt werden, wenn Sie Konfigurationen für diese Cluster erstellen oder verwenden, in denen diese optionalen Selektoren 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 für ihre Verwendung eine Annahme von einer oder mehreren Arten von Gleichheit erforderlich ist. Das Aktivieren oder Deaktivieren kann sich auf mehrere Cluster und ihre Arbeitslasten auswirken.

Wenn Sie beispielsweise vorhandene Kubernetes-Namespaces mit demselben Namen in verschiedenen Clustern und Anwendungen (einschließlich des Standard-Namespace) 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 nachvollziehen, welche Dienstendpunkte clusterübergreifend zusammengeführt werden, und bestätigen, 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 einfach bestätigen, dass nicht zwei „verschiedene“ Anwendungen denselben Namespace verwenden. Achten Sie insbesondere auf die Ad-hoc-Verwendung des Standard-Namespace. Wenn Sie beispielsweise in einem Cluster einen Namespace mit dem Namen default und in einem anderen Cluster einen Namespace mit dem Namen default haben, diese aber für unterschiedliche Zwecke verwendet werden, sollten Sie einen der beiden umbenennen.

Für einen strengeren Ansatz können Sie Folgendes ausprobieren. Prüfen Sie für jede Gruppe von Namespaces mit demselben Namen in verschiedenen Clustern einer Flotte Folgendes:

  • In jedem Cluster sind dieselben RBAC-Regeln im Cluster vorhanden und der Zugriff auf den Namespace ist für den Namespace der Principals zulässig.
  • 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 ähnlich genug, um als „gleich“ betrachtet zu werden.

Wenn Ihre Namespaces nicht ähnlich genug sind, können Sie Apps zu neuen Namespaces migrieren. Wenn Sie davon ausgehen, dass die Namespaces identisch sind, können Sie Funktionen aktivieren, die diese Annahme nutzen.

Gleichheit des Audit-Dienstes 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 für jede Kombination aus Namespace und Dienstname diese als denselben logischen Dienst behandelt in Bezug auf:

  • Identität (speziell für Cloud Service Mesh-Sicherheit): Wenn namespace1/service1 autorisiert ist, etwas zu tun, sind Arbeitslasten mit dieser Identität aus einem beliebigen Cluster autorisiert.
  • Traffic-Verwaltung: Standardmäßig wird der Traffic auf namespace1/service1-Dienste in einem beliebigen Cluster 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 Namespace-/Dienstnamenkombinationen für das gesamte Mesh zu reservieren. Prüfen Sie bei vorhandenen Anwendungen Ihre Dienste, um sicherzustellen, dass Dienste mit demselben Namespace und Namen in Ihren Clustern diejenigen sind, die in Bezug auf Identität, Traffic-Management und Observability als derselbe Dienst behandelt werden sollen.

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

Die Gleichheit von Service-Namespace und -Name wird auch von Multi-Cluster-Ingress und Multi-Cluster-Gateway angenommen, wenn Traffic an Dienste in mehreren Clustern weitergeleitet wird. Dies gilt 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 von den Clustern 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 sich dieselbe Identity and Access Management-Identitä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. Dadurch wird die Einrichtung der Authentifizierung für Ihre Anwendungen projektübergreifend vereinfacht. Wenn Sie sie in Flotten mit mehreren Projekten verwenden, insbesondere wenn das Flotten-Hostprojekt eine Mischung aus Flotten- und Nicht-Flottenclustern enthält, kann es jedoch zusätzliche Zugriffssteuerungsaspekte geben, die über die für die reguläre Identitätsföderation von Arbeitslasten für GKE hinausgehen.

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. Hinweise zur Minimierung von Risiken mit der Identitätsföderation von Arbeitslasten für Flotten finden Sie unter Best Practices für die Verwendung von Workload Identity für Flotten.

Standardeinstellungen auf Flottenebene

GKE bietet die Möglichkeit, Standardeinstellungen auf Flottenebene für bestimmte Funktionen festzulegen, darunter Cloud Service Mesh, Config Sync und Policy Controller. So können Sie Cluster für die Verwendung dieser Funktionen einrichten, 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 nicht betroffen, auch wenn Sie sie bereits der Flotte hinzugefügt haben oder die Cluster nach dem Einrichten der Standardeinstellungen für Funktionen hinzufügen. Das bedeutet, dass Sie Standardeinstellungen auf Flottenebene sicher einrichten können, ohne das Risiko einzugehen, Funktionen in Clustern zu aktivieren oder zu konfigurieren, in denen Sie dazu noch nicht bereit sind. Sie können die Standardeinstellungen jederzeit später auf vorhandene Cluster anwenden.

Funktionsanforderungen

Bei der Implementierung von Flotten auf der Grundlage von 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 in Clustern außerhalb von Google Cloudnicht unterstützt werden.

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

Funktion
 Clustertypen
 Projektanforderungen
 VPC-Anforderungen
Config Sync Alle von GKE unterstützten Cluster Keine Keine
Policy Controller Alle von GKE unterstützten Cluster Keine Keine
Cloud Service Mesh Einschränkungen Alle Cluster, die mit Cloud Service Mesh verwendet werden und sich im selben Projekt befinden, müssen in 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
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 auf Google Cloud und Google Distributed Cloud on VMware. Andere Kubernetes-Cluster werden unterstützt, erfordern aber zusätzlichen Einrichtungsaufwand. Keine Keine
Binärautorisierung GKE auf 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
FQDN-Netzwerkrichtlinien für Pods 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

Virtual Private Cloud-Anforderungen berücksichtigen

Wenn Sie eine Funktion wie Cloud Service Mesh verwenden möchten, für die Cluster in einem einzelnen VPC-Netzwerk (Virtual Private Cloud) erforderlich sind, wie in der vorherigen Tabelle dargestellt, sollten Sie für jede VPC eine Flotte erstellen. Wenn Sie diese Funktionen nicht verwenden möchten, können Sie mehrere VPCs in einer Flotte zusammenfassen.

Ein häufiges Muster ist beispielsweise, dass eine Organisation mehrere Projekte mit jeweils einer eigenen Standard-VPC hat. Möglicherweise bestehen bereits Peering-Verbindungen zwischen ihnen. Wenn Sie keine Funktion mit Anforderungen an eine einzelne VPC verwenden, können alle in einer einzelnen Flotte zusammengefasst werden. Ein weiteres gängiges Muster folgt einer Hub-and-Spoke-Topologie, bei der mehrere VPCs verwendet werden. Wenn Sie keine Funktion mit Anforderungen an eine einzelne VPC verwenden, können Sie Cluster aus allen diesen VPCs in einer Flotte platzieren. Beachten Sie, dass es in einigen Fällen vorkommen kann, dass Sie Flotten mit nur einem Cluster haben, wenn Sie diese Richtlinien befolgen. In diesem Fall müssen Sie möglicherweise auf die Verwendung von Funktionen mit VPC-Einschränkungen verzichten und Flotten für mehrere Projekte erstellen oder Ihre Architektur überdenken und Arbeitslasten entsprechend verschieben.

Anforderungen für 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 projektübergreifend sein 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 erstellen müssen, die Cluster aus mehreren Projekten enthalten, können Sie stattdessen Single-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 auch im selben VPC-Netzwerk befinden.

Nächste Schritte