Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connect.

Flottenpakete in Distributed Cloud Connected verwenden

Auf dieser Seite wird erläutert, wie Sie Config Sync-Flottenpakete in Ihrer Google Distributed Cloud Connected-Umgebung verwenden. Flottenpakete sind ein Tool, das ein Git-Repository als zentrale Informationsquelle für Ihre Clusterkonfiguration verwendet.

Flottenpakete in Distributed Cloud Connected verwenden dieselbe zugrunde liegende Technologie und dieselben Befehle wie Standardcluster in der Google Kubernetes Engine. In der GKE-Dokumentation wird auf der Seite Flottenpakete bereitstellenerläutert, wie Sie Flotten pakete erstellen und verwalten. Auf dieser Seite wird erläutert, wie Sie diese Anleitung für Ihre Distributed Cloud Connected-Umgebung anpassen.

In den folgenden Abschnitten wird erläutert, was Sie für Distributed Cloud Connected anders machen müssen und welche Schritte in der GKE-Dokumentation Sie ohne Änderungen ausführen können.

Voraussetzungen

Für die Verwendung von Config Sync-Flottenpaketen in Distributed Cloud Connected gelten die folgenden Voraussetzungen:

Da sich der Roll-out-Controller in der Cloud befindet, muss Ihr Git-Repository über das öffentliche Internet erreichbar sein. Interne oder lokale Git-Server, die nicht öffentlich zugänglich sind, werden nicht unterstützt.
Distributed Cloud Connected unterstützt nur die Verwendung der Flotten- Workload Identity-Föderation zur Authentifizierung bei Google Cloud Diensten. Andere Config Sync-Authentifizierungsmethoden wie SSH-Schlüssel oder Cookies werden für die Verbindung zwischen Ihren Clustern und dem Repository mit Versionen von Paketen nicht unterstützt. Weitere Informationen finden Sie unter Clusterauthentifizierung mit Workload Identity.
Alle Cluster in einer Flotte müssen sich im selben Projekt befinden. Distributed Cloud Connected unterstützt nicht die Registrierung von Clustern aus mehreren Projekten in einem einzelnen zentralen Projekt für die Flottenverwaltung.
Ihre Kubernetes-Manifeste müssen den Einschränkungen für Arbeitslasten in Distributed Cloud Connected entsprechen. Manifeste, die gegen diese Einschränkungen verstoßen, werden vom Cluster-Zulassungscontroller blockiert.
Für Flottenpakete ist Config Sync Version 1.16.0 oder höher erforderlich.

Systemverhalten

Flottenpakete in Distributed Cloud Connected haben die folgenden Verhaltensweisen:

Flottenpakete wandeln Ihre Kubernetes-Manifeste in OCI-Images mit Versionsverwaltung um. Diese Images werden in einem verwalteten Artifact Registry-Repository mit dem Namen fleet-packages gespeichert, das automatisch in Ihrem Projekt erstellt wird. Ihre Cluster rufen diese Images direkt aus dem Repository ab, um eine konsistente und zuverlässige Bereitstellung zu gewährleisten.
Flottenpakete übernehmen das Verhalten von Config Sync zur Korrektur von Abweichungen. Manuelle Änderungen an Ressourcen in einem Cluster werden automatisch überschrieben, damit sie mit den OCI-Paketen mit Versionsverwaltung übereinstimmen.
Wenn ein Distributed Cloud Connected-Cluster in den Überlebensmoduswechselt, erzwingt der Config Sync-Agent weiterhin die letzte erfolgreich synchronisierte Konfiguration lokal. Neue Roll-outs oder Updates für das Flottenpaket werden jedoch pausiert, bis die Cloud-Verbindung wiederhergestellt ist.
Flottenpakete übernehmen das automatische Verhalten von Config Sync zur Ressourcenbereinigung. Wenn Sie ein neues Tag in Ihrem Git-Repository erstellen und die Konfiguration des Flottenpakets mit dem neuen Tag aktualisieren, um eine Synchronisierung zu starten, löscht der Config Sync-Agent die entsprechende Ressource aus Ihrem Cluster, wenn Sie ein Manifest aus Ihrem Git-Repository entfernen.
Wenn mehrere Flottenpakete dieselbe Ressource verwalten, tritt ein eigentumsrechtlicher Konflikt auf. Wenn Sie versuchen, ein Flottenpaket zu löschen, während ein Eigentumskonflikt besteht, kann die Löschung ins Stocken geraten. Um dieses Problem zu beheben, ändern Sie eines der konkurrierenden Flottenpakete, um die in Konflikt stehende Ressource zu entfernen, bevor Sie versuchen, das Paket zu löschen.

Voraussetzungen für Distributed Cloud Connected

Bevor Sie die Schritte unter Flottenpakete bereitstellen, ausführen, prüfen Sie, ob Ihre Distributed Cloud Connected-Umgebung und die Nutzer berechtigungen richtig konfiguriert sind.

Netzwerk und Sicherheit

Ihre Netzwerkumgebung muss die folgenden Anforderungen erfüllen:

VPC Service Controls. Wenn Ihr Projekt durch einen VPC-Dienstperimeter geschützt ist, prüfen Sie, ob Ihre Cloud Build- und Config Delivery-Dienst-Agents, z. B. service-PROJECT_NUMBER@gcp-sa-configdelivery.iam.gserviceaccount.com, berechtigt sind, den Perimeter zu überqueren und Images aus Artifact Registry abzurufen. Weitere Informationen finden Sie unter VPC Service Controls-Integration konfigurieren.
Ausgehender Zugriff. Ihre Distributed Cloud Connected-Cluster müssen Ausgangszugriff auf us-central1-docker.pkg.dev haben. Flottenpakete speichern Ihre Manifestpakete als OCI-Images in Artifact Registry. Die Cluster müssen diese Images direkt aus Artifact Registry abrufen können.

Repository-Einrichtung

Das Artifact Registry-Repository mit Ihren Manifestpaketen muss sich im selben Projekt wie das Flottenpaket befinden und in us-central1 gehostet werden.

Erforderliche Berechtigungen

Um die Schritte in der Distributed Cloud Connected-Umgebung auszuführen, benötigen Sie die folgenden IAM-Rollen für das Projekt:

Config Delivery-Administrator (roles/configdelivery.admin): erforderlich, um Flottenpakete und Roll-outs zu erstellen und zu verwalten
Developer Connect-Administrator (roles/developerconnect.admin): erforderlich, um Repository-Verbindungen zu erstellen und zu verwalten
Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin): erforderlich, um dem Dienstkonto die erforderlichen Rollen zu gewähren

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

Erforderliche APIs

Sie müssen APIs für Repository-Verbindungen und die sichere Kommunikation mit Distributed Cloud Connected-Clustern aktivieren. Führen Sie den folgenden gcloud services enable Befehl aus, um die erforderlichen APIs zu aktivieren:

gcloud services enable anthosconfigmanagement.googleapis.com \
    configdelivery.googleapis.com \
    cloudbuild.googleapis.com \
    connectgateway.googleapis.com \
    developerconnect.googleapis.com \
    artifactregistry.googleapis.com

Diese APIs sind für die folgenden Komponenten erforderlich:

anthosconfigmanagement.googleapis.com: verwaltet den Config Sync-Agent in Ihren Clustern
configdelivery.googleapis.com: koordiniert den Roll-out von Kubernetes-Ressourcen in Ihrer Flotte von Clustern
cloudbuild.googleapis.com: ruft Ihre Kubernetes-Manifeste aus Git ab und packt sie in Pakete mit Versionsverwaltung
connectgateway.googleapis.com: bietet eine sichere Verbindung zwischen dem Config Delivery-Dienst und Ihren Distributed Cloud Connected-Clustern
developerconnect.googleapis.com: ermöglicht sichere Verbindungen zu Ihrem externen Git-Repository-Host
artifactregistry.googleapis.com: speichert die Paketpakete mit Versionsverwaltung als OCI-Images in Ihrem Projekt

Standardeinstellungen für die Umgebung

Die Config Delivery API für Flottenpakete wird nur in us-central1 unterstützt. Damit Ihre Befehle richtig weitergeleitet werden, legen Sie mit dem gcloud config set Befehl Ihr Standardprojekt und Ihren Standardstandort fest:

Legen Sie ein Standardprojekt fest:
```
gcloud config set project PROJECT_ID
```
Ersetzen Sie PROJECT_ID dabei durch die ID Ihres Projekts in. Google Cloud
Legen Sie den standardmäßigen Standort für Flottenpakete fest. Alle Cloud Build-Repository-Verbindungen, die mit Flottenpaketen verwendet werden, müssen sich in der Region us-central1 befinden.
```
gcloud config set config_delivery/location us-central1
```

Verfahrensunterschiede

In der folgenden Tabelle erfahren Sie, wie Sie die Schritte unter Flottenpakete bereitstellen auf Ihre Distributed Cloud Connected-Umgebung anwenden.

Standardschritt	Anpassung für Distributed Cloud Connected
Cluster bei einer Flotte registrieren	Überspringen Sie diesen Schritt. Distributed Cloud Connected-Cluster werden beim Erstellen automatisch bei einer Flotte in Ihrem Projekt registriert.
Config Sync installieren	Führen Sie die Standardschritte aus. Wir empfehlen jedoch die Methode In der gesamten Flotte installieren (Standard für Flotte). Konfigurieren Sie diese Methode in den Einstellungen Hub oder Flotte in der Google Cloud Console. Diese Implementierung sorgt dafür, dass alle vorhandenen oder zukünftigen Distributed Cloud Connected-Knoten in Ihrer Zone automatisch den Config Sync-Agent erhalten. Wählen Sie für den Authentifizierungsmitgliedstyp Workload Identity aus. Das Dienst konto, das Sie für Workload Identity verwenden, muss die Rolle `roles/artifactregistry.reader` für das Projekt haben, damit der Config Sync-Agent Manifestpakete aus dem verwalteten Repository `fleet-packages` abrufen kann.
Dienstkonto erstellen	Folgen Sie der Anleitung, um ein Dienstkonto für Cloud Build zu erstellen und die erforderlichen Berechtigungen zu gewähren. Das Dienst konto muss sich im selben Projekt wie Ihr Flottenpaket befinden. Wir empfehlen, die folgenden Befehle zu verwenden: Erstellen Sie das Dienstkonto mit dem `gcloud iam service-accounts create` Befehl: gcloud iam service-accounts create "`SERVICE_ACCOUNT_NAME`" Ersetzen Sie `SERVICE_ACCOUNT_NAME` durch einen Namen für das Dienstkonto. Fügen Sie die obligatorischen Identity and Access Management-Rollen hinzu, indem Sie den `gcloud projects add-iam-policy-binding` Befehl für jede der folgenden Rollen ausführen. Weitere Informationen zu IAM finden Sie in der IAM-Übersicht. `roles/configdelivery.resourceBundlePublisher`: ermöglicht dem Dienstkonto, Ressourcenpakete und Releases zu erstellen und zu verwalten `roles/cloudbuild.connectionUser`: ermöglicht dem Dienst konto, die Cloud Build-Repository-Verbindung zu verwenden `roles/logging.logWriter`: ermöglicht dem Dienstkonto Build-Logs zu schreiben `roles/artifactregistry.writer`: ermöglicht dem Dienst konto, Paketpakete mit Versionsverwaltung in Artifact Registry zu übertragen `roles/developerconnect.connectionUser`: ermöglicht dem Dienstkonto, die Developer Connect-Verbindung zu verwenden Das Dienstkonto benötigt außerdem die Berechtigung, aus Ihrem verbundenen Git-Repository bei Ihrem Git-Anbieter zu lesen. Informationen zum Autorisieren der Verbindung finden Sie unter Verbindung zu einem Repository herstellen.
Mitgliedschaftsnamen identifizieren	Wenn ein Befehl einen `MEMBERSHIP_NAME` erfordert, verwenden Sie den Namen Ihres Distributed Cloud Connected-Clusters. Sie können den Clusternamen mit dem `gcloud container fleet memberships list` Befehl ermitteln.
Cluster identifizieren	Bevor Sie einen Cluster mit einem Flottenpaket als Ziel auswählen, wenden Sie die `NodeSystemConfigUpdate` Ressourcen auf jeden Knoten im Cluster an und prüfen Sie sie, wenn für Ihre Arbeitslasten eine Netzwerkkonfiguration auf Hostebene erforderlich ist, z. B. HugePages oder SR-IOV.
Git-Tags identifizieren	Für den Roll-out-Controller müssen Git-Tags im vollständigen semantischen Versionsformat (`major.minor.patch`) vorliegen. `v1.0.0` ist beispielsweise gültig, `v1` jedoch nicht.
Bestimmte Cluster als Ziel auswählen	Obwohl Cluster automatisch registriert werden, müssen Sie den Clustermitgliedschaften manuell Labels hinzufügen , wenn Sie mit Label-Selektoren auf Teilmengen von Clustern abzielen möchten.
Bereitstellungsstrategien	Verwenden Sie Labels und Varianten, um bestimmte Cluster als Ziel auszuwählen. Für Distributed Cloud Connected beziehen sich die Metadatavariablen für die Mitgliedschaft, z. B. Projekt und Standort, die in Ihren Variantenvorlagen verwendet werden, auf die Cloud-Ressourcen, die mit Ihrem Distributed Cloud Connected-Cluster verknüpft sind. Die folgenden Distributed Cloud-spezifischen Mitgliedschaftsmetadaten können in Variantenvorlagen verwendet werden: `cluster_name`: der Name Ihres Distributed Cloud Connected-Clusters `location`: die Google Cloud Region, die mit dem Cluster verknüpft ist `project`: die Projekt-ID, in der der Cluster registriert ist `labels`: alle Labels, die Sie auf die Clustermitgliedschaft angewendet haben

Gemeinsame Verfahren

Für die folgenden Betriebsaufgaben sind die Befehlssyntax und das Dienstverhalten für Distributed Cloud Connected und Standard-GKE identisch. Verwenden Sie bei der Ausführung dieser Schritte die Einstellungen und Werte, die in der Tabelle im Abschnitt Verfahrensunterschiede dieses Dokuments definiert sind.

Flottenpaket erstellen: Definieren Sie die FleetPackage Ressource, um Ihre Konfiguration abzurufen und bereitzustellen.
Flottenpaket aktualisieren: Ändern Sie Ihr Paket, um Änderungen einzuführen oder Einstellungen zu aktualisieren.
Roll-outs von Flottenpaketen verwalten: Aktive Roll-outs anhalten, fortsetzen oder abbrechen.
Ressourcenpakete und Releases prüfen: Debuggen Sie die Variantenerstellung und Versionsverwaltung. Ressourcenpakete sind Container für Ihre Konfigurationen und Releases sind Versionen dieser Pakete. Um zu prüfen, ob die Bereitstellung auf Ihrer Distributed Cloud Connected-Hardware erfolgreich war, rufen Sie mit dem gcloud container fleet memberships get-credentials Befehl Zugriff auf Ihren Cluster ab, und prüfen Sie dann mit kubectl den RootSync Status im Cluster.
Flottenpaket löschen: Entfernen Sie ein Flottenpaket und die zugehörigen verwalteten Ressourcen. Um eine saubere Entfernung zu gewährleisten, prüfen Sie, ob die verwalteten RootSync-Objekte, die mit dem Flottenpaket verknüpft sind, aus Ihren Clustern entfernt wurden.

Monitoring und Fehlerbehebung

Verwenden Sie das Flag --format mit dem Befehl gcloud, um detaillierte Statusmeldungen während eines Roll-outs zu erhalten und Bereitstellungen effektiver zu überwachen.

Führen Sie beispielsweise den folgenden gcloud container fleet packages rollouts describe Befehl aus, um eine detaillierte Statusmeldung für jeden Cluster in Ihrer Flotte aufzurufen:

gcloud container fleet packages rollouts describe ROLLOUT_NAME \
    --fleet-package=FLEET_PACKAGE_NAME \
    --format=json

Ersetzen Sie die folgenden Werte:

ROLLOUT_NAME: Der Name des Roll-outs.
FLEET_PACKAGE_NAME: Der Name des Flottenpakets.

Wenn ein Build fehlschlägt oder hängen bleibt, finden Sie in der Ausgabe des gcloud container fleet packages list Befehls einen Link zu den Streaming-Logs für den Cloud Build-Job. Wenn ein Roll-out im Status PENDING oder STALLED verbleibt, prüfen Sie die Konnektivität Ihrer Distributed Cloud Connected-Hardware, wie unter Fehlerbehebung für Distributed Cloud Connected beschrieben.

Weitere Informationen zur Diagnose von Fehlern im Zusammenhang mit Cloud Build finden Sie unter Fehlerbehebung bei Build-Fehlern.

Synchronisierungsstatus im Cluster prüfen

Prüfen Sie die RootSync-Ressource im Cluster, um zu prüfen, ob Ihr Cluster erfolgreich mit dem Flottenpaket synchronisiert wird. Der Name des RootSync-Objekts im Cluster ist identisch mit dem FLEET_PACKAGE_NAME, den Sie für Ihr Paket ausgewählt haben.

Führen Sie zum Prüfen des Status den folgenden Befehl aus:

kubectl get rootsync FLEET_PACKAGE_NAME -n config-management-system

Eine erfolgreiche Synchronisierung zeigt den Status SYNCED an. Wenn der Status Error angezeigt wird, führen Sie den folgenden Befehl aus, um weitere Details zu erhalten:

kubectl describe rootsync FLEET_PACKAGE_NAME -n config-management-system

Weitere Informationen finden Sie in der GKE-Dokumentation unter RootSync- und RepoSync-Objekte überwachen.

Informationen zum Decodieren bestimmter Fehlercodes in der Ausgabe finden Sie in der Referenz zu Config Sync-Fehlern.

Flottenpakete in Distributed Cloud Connected verwenden Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.