Wenn Sie die Konfiguration Ihres Google Kubernetes Engine-Clusters (GKE) vor der Installation von Config Sync planen, können Sie eine zuverlässige Richtlinien- und Konfigurationssynchronisierung in Ihren Umgebungen gewährleisten. Ihre Cluster müssen bestimmte Anforderungen an den Clustermodus, die Flottenregistrierung, die IAM-Berechtigungen (Identity and Access Management), die Plattformversionen, die Authentifizierung, das Netzwerk und die Knotenarchitektur erfüllen.
Allgemeine Best Practices für die Planung Ihrer GKE-Cluster finden Sie unter Clusterkonfigurationsoptionen.
GKE-Betriebsmodus auswählen
Config Sync unterstützt sowohl Autopilot- als auch Standard-GKE-Cluster.
Informationen zur Auswahl des richtigen Betriebsmodus finden Sie unter GKE-Betriebsmodi.
Cluster bei einer Flotte registrieren
Für Config Sync müssen Ihre Cluster bei einer Flotte registriert sein.
Wenn Sie Config Sync mit der Cloud de Confiance Console installieren und konfigurieren möchten, können Sie Ihren Cluster gleichzeitig mit der Installation von Config Sync registrieren.
Andernfalls müssen Sie Ihren Cluster bei einer Flotte registrieren, bevor Sie Config Sync aktivieren.
Erforderliche Berechtigungen gewähren
Da Config Sync erfordert, dass Cluster bei einer Flotte registriert sind, benötigen Sie möglicherweise zusätzliche Berechtigungen, wenn Sie Config Sync installieren.
Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Flottenadministrator (früher GKE Hub-Administrator) (roles/gkehub.admin) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Registrieren von Clustern in einer Flotte benötigen.
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.
Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.
Ressourcenanforderungen im Autopilot-Modus
Im GKE Autopilot-Modus werden Ressourcenanfragen automatisch geändert, um die Stabilität der Arbeitslasten zu gewährleisten. Informationen zum Planen dieser Anfragen finden Sie in der GKE-Dokumentation zu Autopilot-Ressourcenanfragen.
Aufgrund der Art und Weise, wie Autopilot Ressourcenanfragen ändert, nimmt Config Sync die folgenden Anpassungen vor:
- Passt die benutzerdefinierten Überschreibungslimits für Ressourcen an Anfragen an.
- Wendet Überschreibungen nur an, wenn eine oder mehrere Ressourcenanfragen vorhanden sind, die höher sind als die entsprechende in der Annotation deklarierte Ausgabe, oder eine oder mehrere Ressourcenanfragen, die niedriger sind als die entsprechende Eingabe in der Annotation.
Unterstützte GKE-Plattformen und -Versionen
Damit Sie Config Sync verwenden können, muss Ihr Cluster eine unterstützte GKE-Version haben.
Workload Identity Federation for GKE
Workload Identity Federation for GKE ist die empfohlene Methode, um eine sichere Verbindung zu Cloud de Confiance by S3NS-Diensten herzustellen. Die Workload Identity-Föderation für GKE ist in Autopilot-Clustern standardmäßig aktiviert.
Wenn Sie Flottenpakete mit Config Sync verwenden möchten, ist die Workload Identity Federation for GKE erforderlich.
Wenn Sie Config Sync auf angehängten GKE-Clustern installiert haben, können Sie Active Directory nicht mit der Workload Identity-Föderation verwenden. Diese Einschränkung besteht, weil Config Sync das Connect-Gateway verwendet, um eine Verbindung zu angehängten GKE-Clustern herzustellen, und das Connect-Gateway diese Funktion nicht unterstützt.
Netzwerk
Im folgenden Abschnitt sind einige der Änderungen aufgeführt, die Sie je nach Netzwerkeinstellungen möglicherweise an Ihrem GKE-Cluster vornehmen müssen.
Weitere Informationen zu den GKE-Netzwerkoptionen finden Sie unter Netzwerkübersicht.
Private Cluster
Wenn Sie GKE-Cluster mit privaten Knoten verwenden, sollten Sie Ihre Cluster auf eine der folgenden Arten konfigurieren, damit Config Sync Zugriff auf Ihre Source of Truth hat und sich dort authentifizieren kann:
Konfigurieren Sie Cloud NAT so, dass ausgehender Traffic von privaten GKE-Knoten zugelassen wird. Weitere Informationen finden Sie unter Beispielkonfiguration für GKE.
Aktivieren Sie den privaten Google-Zugriff, um eine Verbindung zu der Gruppe von externen IP-Adressen herzustellen, die von Google APIs und Google-Diensten verwendet werden.
Öffentliche Cluster
Wenn Sie öffentliche Cluster verwenden, aber strenge VPC-Firewall-Anforderungen haben, die unnötigen Traffic blockieren, müssen Sie Firewallregeln erstellen, um den folgenden Traffic zuzulassen:
- TCP: Eingehenden und ausgehenden Traffic an Port 53 und 443 zulassen
- UDP: Erlauben Sie ausgehenden Traffic an Port 53.
Wenn Sie diese Regeln nicht angeben, wird Config Sync nicht korrekt synchronisiert. nomos status meldet den folgenden Fehler:
Error: KNV2004: unable to sync repo Error in the git-sync container
Cloud Source Repositories mit Authentifizierung über das Compute Engine-Standarddienstkonto
Wenn Sie Config Sync verwenden, um eine Verbindung zu Cloud Source Repositories herzustellen, und die Workload Identity-Föderation für GKE nicht aktiviert ist, können Sie das Compute Engine-Standarddienstkonto zur Authentifizierung verwenden. Sie müssen Zugriffsbereiche mit schreibgeschützten Bereichen für die Knoten im Cluster verwenden.
Sie können den schreibgeschützten Bereich für Cloud Source Repositories hinzufügen, indem Sie cloud-source-repos-ro in die Liste --scopes aufnehmen, die beim Erstellen des Clusters angegeben wird, oder indem Sie den Bereich cloud-platform beim Erstellen des Clusters verwenden. Beispiel:
gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform
Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.
Hinweis: Sie können Zugriffsbereiche nicht ändern, nachdem Sie einen Knotenpool erstellt haben.
Allerdings haben Sie die Möglichkeit, unter Verwendung desselben Clusters einen neuen Knotenpool mit dem richtigen Zugriffsbereich zu erstellen. Der Standardbereich gke-default enthält nicht cloud-source-repos-ro.
Arm-Knoten
Config Sync kann nur auf x86-basierten Knoten ausgeführt werden, nicht auf Arm-Knoten. Wenn Sie Config Sync jedoch in einem Cluster mit mehreren Architekturen ausführen müssen, gehen Sie je nach Clustertyp so vor:
- GKE on AWS oder GKE on Azure: Fügen Sie Ihren Arm-Knoten eine Markierung hinzu, damit auf den Arm-Knoten keine Pods ohne entsprechende Toleranz geplant werden.
- GKE: GKE fügt eine Standardmarkierung hinzu, damit Arbeitslasten ohne die entsprechende Toleranz dort nicht geplant werden. Es sind keine weiteren Maßnahmen erforderlich.