Versionsinformationen finden Sie in den Versionshinweisen zu Distributed Cloud Connected.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 Standard-Google Kubernetes Engine-Cluster. In der GKE-Dokumentation wird auf der Seite Flottenpakete bereitstellen beschrieben, wie Sie Flottenpakete erstellen und verwalten. Auf dieser Seite wird erläutert, wie Sie diese Anleitung für Ihre mit Distributed Cloud verbundene 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 unverändert ausführen können.

Voraussetzungen

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

Da sich der Rollout-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 Workload Identity-Föderation auf Flottenebene 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 des Bundles 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 verbundene Arbeitslasten in Distributed Cloud 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

Für Flottenpakete in Distributed Cloud Connected gelten die folgenden Verhaltensweisen:

Mit Flottenpaketen werden Ihre Kubernetes-Manifeste in versionierte OCI-Images umgewandelt. Diese Bilder 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 bei der Driftkorrektur. Manuelle Änderungen an Ressourcen in einem Cluster werden automatisch überschrieben, damit sie mit den versionierten OCI-Bundles übereinstimmen.
Wenn ein mit Distributed Cloud verbundener Cluster in den Überlebensmodus wechselt, erzwingt der Config Sync-Agent weiterhin die letzte erfolgreich synchronisierte Konfiguration lokal. Neue Bereitstellungen oder Updates für das Flottenpaket werden jedoch angehalten, bis die Cloud-Verbindung wiederhergestellt ist.
Flottenpakete übernehmen das automatische Verhalten von Config Sync beim Bereinigen von Ressourcen. Wenn Sie ein neues Tag in Ihrem Git-Repository erstellen und die Flottenpaketkonfiguration 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, kommt es zu einem eigentumsrechtlichen Konflikt. Wenn Sie versuchen, ein Flottenpaket zu löschen, während es einen Inhaberkonflikt gibt, kann das Löschen fehlschlagen. 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, müssen Sie dafür sorgen, dass Ihre mit Distributed Cloud verbundene Umgebung und die Nutzerberechtigungen 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, müssen Sie dafür sorgen, dass Ihre Cloud Build- und Config Delivery-Dienst-Agents, z. B. service-PROJECT_NUMBER@gcp-sa-configdelivery.iam.gserviceaccount.com, autorisiert sind, den Perimeter zu überschreiten und Images aus Artifact Registry abzurufen. Weitere Informationen finden Sie unter VPC Service Controls-Integration konfigurieren.
Ausgehender Traffic: Ihre mit Distributed Cloud verbundenen Cluster müssen ausgehenden Zugriff auf us-central1-docker.pkg.dev haben. In Flottenpaketen werden Ihre Manifest-Bundles als OCI-Images in Artifact Registry gespeichert. Die Cluster müssen diese Images direkt aus Artifact Registry abrufen können.

Repository einrichten

Das Artifact Registry-Repository mit Ihren Manifest-Bundles muss sich im selben Projekt wie das Flottenpaket befinden und in us-central1 gespeichert sein.

Erforderliche Berechtigungen

Für die Schritte in der verbundenen Umgebung von Distributed Cloud benötigen Sie die folgenden IAM-Rollen für das Projekt:

Config Delivery-Administrator (roles/configdelivery.admin): erforderlich zum Erstellen und Verwalten von Flottenpaketen und ‑Roll-outs
Developer Connect Admin (roles/developerconnect.admin): erforderlich zum Erstellen und Verwalten von Repository-Verbindungen
Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin): erforderlich, um dem Dienstkonto die erforderlichen Rollen zuzuweisen

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 mit Distributed Cloud verbundenen Clustern aktivieren. Führen Sie den folgenden Befehl gcloud services enable 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 die Bereitstellung von Kubernetes-Ressourcen in Ihrer Clusterflotte.
cloudbuild.googleapis.com: Ruft Ihre Kubernetes-Manifeste aus Git ab und packt sie in versionierte Bundles.
connectgateway.googleapis.com: stellt eine sichere Verbindung zwischen dem Config Delivery-Dienst und Ihren mit Distributed Cloud verbundenen Clustern her
developerconnect.googleapis.com: Ermöglicht sichere Verbindungen zu Ihrem externen Git-Repository-Host
artifactregistry.googleapis.com: Speichert die versionierten Paket-Bundles als OCI-Images in Ihrem Projekt.

Erforderliche RBAC-Berechtigungen für Cluster

Sie müssen dem Dienst-Agent für die Konfigurationsbereitstellung (P4SA) in Ihrem Cluster die in diesem Abschnitt beschriebenen RBAC-Berechtigungen erteilen, damit er Config Sync-Objekte verwalten kann.

Um diese Berechtigungen zu erteilen, wenden Sie das folgende Manifest auf Ihren Cluster an:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: fleet-packages-impersonator
rules:
- apiGroups:
  - ""
  resourceNames:
  - P4SA_EMAIL
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: fleet-packages-impersonator-binding
roleRef:
  kind: ClusterRole
  name: fleet-packages-impersonator
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: fleetpackages-configsync-admin
rules:
- apiGroups:
  - "configsync.gke.io"
  resources:
  - rootsyncs
  - reposyncs
  verbs:
  - "*"
- apiGroups:
  - "kpt.dev"
  resources:
  - resourcegroups
  verbs:
  - "*"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: fleet-packages-configsync-admin-binding
subjects:
- kind: User
  name: P4SA_EMAIL
roleRef:
  kind: ClusterRole
  name: fleetpackages-configsync-admin
  apiGroup: rbac.authorization.k8s.io

Ersetzen Sie P4SA_EMAIL durch die E-Mail-Adresse Ihres Config Delivery Service-Agents, die in der Regel folgendes Format hat: service-PROJECT_NUMBER@gcp-sa-configdelivery.iam.gserviceaccount.com.

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 Befehl gcloud config set Ihr Standardprojekt und Ihren Standardstandort fest:

Legen Sie ein Standardprojekt fest:
```
gcloud config set project PROJECT_ID
```
Ersetzen Sie dabei PROJECT_ID durch die ID Ihres Projekts in Google Cloud .
Standardmäßiger Standort für Flottenpakete festlegen 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 mit Distributed Cloud verbundene Umgebung anwenden.

Standardschritt	Anpassung für Distributed Cloud Connected
Cluster bei einer Flotte registrieren	Diesen Schritt überspringen Distributed Cloud Connected-Cluster werden beim Erstellen automatisch in einer Flotte in Ihrem Projekt registriert.
Config Sync installieren	Folgen Sie den Standardschritten. Wir empfehlen jedoch die Methode In der gesamten Flotte installieren (Standardeinstellung für die Flotte). Konfigurieren Sie diese Methode in den Hub- oder Flotten-Einstellungen in der Google Cloud -Konsole. Durch diese Implementierung wird sichergestellt, dass alle vorhandenen oder zukünftigen mit Distributed Cloud verbundenen Knoten in Ihrer Zone automatisch den Config Sync-Agenten erhalten. Für den Authentifizierungsmitgliedstyp müssen Sie Workload Identity auswählen. Das Dienstkonto, das Sie für Workload Identity verwenden, muss die Rolle `roles/artifactregistry.reader` für das Projekt haben, damit der Config Sync-Agent Manifest-Bundles aus dem verwalteten `fleet-packages`-Repository abrufen kann.
Cluster-RBAC konfigurieren	Für Distributed Cloud Connected müssen Sie dem Config Delivery-Dienst-Agent (P4SA) explizit RBAC-Berechtigungen für Ihre Cluster erteilen. Weitere Informationen finden Sie unter Erforderliche RBAC für Cluster.
Dienstkonto erstellen	Folgen Sie der Anleitung, um ein Dienstkonto für Cloud Build zu erstellen und die erforderlichen Berechtigungen zu erteilen. Das Dienstkonto muss sich im selben Projekt wie Ihr Flottenpaket befinden. Wir empfehlen, die folgenden Befehle zu verwenden: Erstellen Sie das Dienstkonto mit dem Befehl `gcloud iam service-accounts create`: gcloud iam service-accounts create "`SERVICE_ACCOUNT_NAME`" Ersetzen Sie `SERVICE_ACCOUNT_NAME` durch einen Namen für das Dienstkonto. Fügen Sie die erforderlichen Identity and Access Management-Rollen hinzu, indem Sie den Befehl `gcloud projects add-iam-policy-binding` 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, Ressourcenbündel und Releases zu erstellen und zu verwalten. `roles/cloudbuild.connectionUser`: Ermöglicht dem Dienstkonto die Verwendung der Cloud Build-Repositoryverbindung. `roles/logging.logWriter`: Ermöglicht dem Dienstkonto, Build-Logs zu schreiben. `roles/artifactregistry.writer`: Ermöglicht dem Dienstkonto, versionierte Paket-Bundles 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, Daten aus Ihrem verbundenen Git-Repository bei Ihrem Git-Anbieter zu lesen. Informationen zum Autorisieren der Verbindung finden Sie unter Verbindung zu einem Repository herstellen.
Name der Mitgliedschaft identifizieren	Wenn in einem Befehl nach einem `MEMBERSHIP_NAME` gefragt wird, verwenden Sie den Namen Ihres mit Distributed Cloud verbundenen Clusters. Sie können den Clusternamen mit dem Befehl `gcloud container fleet memberships list` ermitteln.
Cluster identifizieren	Bevor Sie einen Cluster mit einem Flottenpaket als Ziel festlegen, müssen Sie die `NodeSystemConfigUpdate`-Ressourcen auf jedem Knoten im Cluster anwenden und prüfen, wenn für Ihre Arbeitslasten eine Netzwerkkonfiguration auf Hostebene erforderlich ist, z. B. HugePages oder SR-IOV.
Git-Tags identifizieren	Der Rollout-Controller erfordert, dass Git-Tags im vollständigen semantischen Versionsformat (`major.minor.patch`) vorliegen. `v1.0.0` ist beispielsweise gültig, `v1` jedoch nicht.
Auf bestimmte Cluster ausrichten	Obwohl Cluster automatisch registriert werden, müssen Sie Labels manuell hinzufügen, wenn Sie mit Labelselektoren auf Teilmengen von Clustern ausgerichtet werden sollen.
Bereitstellungsstrategien	Verwenden Sie Labels und Varianten, um bestimmte Cluster als Ziel auszuwählen. Bei Distributed Cloud Connected beziehen sich die in Ihren Variantenvorlagen verwendeten Mitgliedschaftsmetadatenvariablen wie Projekt und Standort 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 dem Cluster zugeordnet 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 betrieblichen Aufgaben sind die Befehlssyntax und das Dienstverhalten für Distributed Cloud Connected und Standard-GKE identisch. Verwenden Sie bei der Ausführung dieser Anleitung die Einstellungen und Werte, die in der Tabelle im Abschnitt Verfahrensbedingte Unterschiede 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 können pausiert, fortgesetzt oder abgebrochen werden.
Ressourcenbündel und Releases prüfen: Debuggen Sie die Variantengenerierung und die Versionsverwaltung. Ressourcenpakete sind Container für Ihre Konfigurationen und Releases sind versionierte Instanzen dieser Pakete. Verwenden Sie den Befehl gcloud container fleet memberships get-credentials, um auf Ihren Cluster zuzugreifen, und dann kubectl, um den Status von RootSync im Cluster zu prüfen, um zu prüfen, ob die Bereitstellung auf Ihrer Hardware von Distributed Cloud Connected erfolgreich war.
Flottenpaket löschen: Entfernen Sie ein Flottenpaket und die zugehörigen verwalteten Ressourcen. Prüfen Sie, ob die verwalteten RootSync-Objekte, die dem Flottenpaket zugeordnet sind, aus Ihren Clustern entfernt wurden, um eine vollständige Entfernung zu gewährleisten.

Monitoring und Fehlerbehebung

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

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 Befehls gcloud container fleet packages list einen Link zu den Streaming-Logs für den Cloud Build-Job. Wenn ein Rollout im Status PENDING oder STALLED verbleibt, prüfen Sie die Verbindung der mit Distributed Cloud verbundenen Hardware, wie unter Fehlerbehebung bei mit Distributed Cloud verbundenen Geräten beschrieben.

Weitere Informationen zum Diagnostizieren von Fehlern im Zusammenhang mit Cloud Build finden Sie unter Build-Fehler beheben.

Synchronisierungsstatus im Cluster prüfen

Wenn Sie prüfen möchten, ob Ihr Cluster erfolgreich mit dem Flottenpaket synchronisiert wird, untersuchen Sie die RootSync-Ressource im Cluster. Der Name des RootSync-Objekts im Cluster ist identisch mit dem FLEET_PACKAGE_NAME, das 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

Bei einer erfolgreichen Synchronisierung wird der Status SYNCED angezeigt. 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.

Hilfe 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.