Flottenpakete

Mit der deklarativen API FleetPackage in Config Sync können Sie Flottenpakete in Clustern bereitstellen und verwalten, die in einer Flotte registriert sind. Ein Paket ist eine Reihe von Kubernetes-YAML-Manifesten, die Clusterkonfigurationen definieren. Mit Flottenpaketen können Sie Konfigurationsupdates für Ihre Flotte auf einmal oder schrittweise bereitstellen, um das Risiko von weitreichenden Ausfällen zu verringern.

Sie definieren jedes FleetPackage-Objekt einmal und aktualisieren dieses Paket dann mit neuen Überarbeitungen, wenn sich Ihre Konfigurationen ändern. Wenn Sie eine neue Version anwenden, erkennt der Flottenpaketdienst diese Änderungen automatisch und stellt sie in Ihren Zielclustern bereit.

Vorteile

Flottenpakete basieren auf Config Sync-Funktionen wie der automatischen Driftkorrektur und bieten die folgenden Vorteile:

• Ressourcen-Roll-out automatisieren: Nachdem Sie ein Flottenpaket eingerichtet haben, werden die Kubernetes-Ressourcen, auf die es verweist, automatisch vom Flottenpaketdienst auf allen Clustern bereitgestellt.

• Neue Cluster automatisch konfigurieren: Wenn Sie ein Flottenpaket konfigurieren und später neue Cluster zu einer Flotte hinzufügen, werden alle vom Flottenpaket definierten Ressourcen automatisch im neuen Cluster bereitgestellt.

• Kubernetes-Konfiguration im großen Maßstab verwalten: Anstatt Cluster einzeln zu verwalten, können Sie Flottenpakete verwenden, um Ressourcen in einer gesamten Flotte von Clustern bereitzustellen.

• Auswirkungen fehlerhafter Änderungen minimieren: Wählen Sie eine maximale Anzahl von Clustern aus, auf denen Ressourcen gleichzeitig bereitgestellt werden sollen. Sie können die Änderungen an jedem Cluster genau überwachen, um sicherzustellen, dass sich fehlerhafte Änderungen nicht auf die gesamte Flotte auswirken.

• Config Sync-Konfiguration vereinfachen: Flottenpakete verwenden Cloud Build zur Authentifizierung bei Git. Das bedeutet, dass Sie sich einmal pro Projekt authentifizieren, anstatt einmal pro RootSync- oder RepoSync-Objekt.

In den folgenden Szenarien ist es möglicherweise besser, Config Sync mit RootSync- oder RepoSync-Objekten anstelle von Flottenpaketen zu verwenden:

• Sie verwalten eine kleine Anzahl von Clustern.

• Sie benötigen mehr Kontrolle darüber, wie Ressourcen in Ihren Clustern bereitgestellt werden, als die Fleet Package API mit Labels und Varianten bietet.

Anforderungen und Einschränkungen

• Beim Konfigurieren eines Flottenpakets werden nur Git-Repositories als Source of Truth unterstützt.

• Die in Git gespeicherten Kubernetes-Ressourcen müssen den Endzustand der Ressource darstellen. Zusätzliche Overlays zum Transformieren der in Git gespeicherten Ressource werden nicht unterstützt. Weitere Informationen zu den Unterschieden zwischen diesen Ressourcen finden Sie unter Best Practice: WET-Repositories erstellen.

• Die FleetPackage API ist nur in der Region us-central1 verfügbar. Sie können weiterhin in Clustern in verschiedenen Regionen bereitstellen, müssen aber Cloud Build einrichten und die gcloud CLI in us-central1 konfigurieren.

• Die maximale Anzahl von Flottenpaketen beträgt 300 pro Projekt und Region.

Architektur

Sie können die FleetPackage API verwenden, um Kubernetes-Manifeste in einer Flotte von Clustern bereitzustellen. Die FleetPackage API verwendet Cloud Build, um Kubernetes-Ressourcen aus Ihrem Git-Repository zu synchronisieren und abzurufen. Der Flottenpaketdienst stellt diese Ressourcen dann in Ihren Clustern bereit.

Wie Varianten generiert werden

Flottenpakete verwenden ein System von Varianten, um verschiedene Kubernetes-Ressourcenkonfigurationen in verschiedenen Clustern oder Clustergruppen innerhalb Ihrer Flotte, aber aus demselben Git-Repository bereitzustellen.

In der FleetPackage-Spezifikation gibt es zwei Felder, die das Verhalten von Varianten steuern:

1. resourceBundleSelector.cloudBuildRepository.variantsPattern: Ein Glob-Muster, mit dem Dateien und Verzeichnisse in Ihrem Git-Repository gefunden werden (unter dem angegebenen path oder im Repository-Stammverzeichnis, wenn path weggelassen wird). Dieses Muster bestimmt, welche Dateien oder Verzeichnisse zu Varianten werden und welche Inhalte sie enthalten.
2. variantSelector.variantNameTemplate: Ein Ausdruck, der jeden Cluster in Ihrer Flotte einem der von variantsPattern generierten Variantennamen zuordnet. Diese Auswahl basiert auf den Metadaten der Flottenmitgliedschaft des Clusters.

variantsPattern-Abgleich

Das Feld variantsPattern ist erforderlich, um anzugeben, wie Varianten aus den in Ihrem Repository gespeicherten Konfigurationen generiert werden sollen. Der Abgleich erfolgt nach folgender Logik:

• Dateiübereinstimmung: Wenn das Muster mit einer YAML-Datei übereinstimmt, wird eine Variante erstellt.

  • Variantenname: Der Dateiname ohne die Erweiterung (z. B. wird prod-config.yaml zur Variante prod-config).
  • Inhalt der Variante: Der Inhalt dieser einzelnen Datei.

• Verzeichnisübereinstimmung: Wenn das Muster mit einem Verzeichnis übereinstimmt, wird eine Variante erstellt.

  • Name der Variante: Der Verzeichnisname (z. B. wird das Verzeichnis dev zur Variante dev).
  • Varianteninhalt: Die Kombination aller YAML-Dateien in diesem Verzeichnis und allen seinen Unterverzeichnissen, rekursiv.

Für Muster für den Dateiabgleich gelten die folgenden Einschränkungen:

• Keine rekursiven (doppelten) Platzhalter. Das Muster ** wird nicht unterstützt.
• Wenn ein Muster einen Punkt (.) enthält, muss darauf ein alphanumerisches Zeichen folgen.
• Muster dürfen keine einfachen Anführungszeichen (') enthalten.
• Variantennamen müssen eindeutig sein. Wenn Ihr Muster mit mehreren Dateien mit demselben Namen übereinstimmt (z. B. app1/deploy.yaml und app2/deploy.yaml), wird für beide versucht, eine Variante mit dem Namen deploy zu erstellen, was zu einem Namenskonflikt führt.

Betrachten Sie als Beispiel ein Repository mit der folgenden Struktur:

repo-root/
└── FleetPackages/
    └── clusters/
        ├── common-ingress.yaml
        ├── us-central1-a/
        │   ├── gke-1/
        │   │   ├── deployment.yaml
        │   │   └── service.yaml
        │   └── gke-2/
        │       ├── deployment.yaml
        │       └── service.yaml
        └── us-central1-b/
            ├── gke-1.yaml
            └── blue-green.yaml

Je nach Art des Datei- oder Verzeichnisabgleichs, den Sie in der Flottenpaketspezifikation definieren, können Sie verschiedene Dateien abgleichen und somit mit Ihren Clustern synchronisieren. Beispiel:

• variantsPattern: "*": Entspricht common-ingress.yaml, us-central1-a und us-central1-b. Generiert Varianten:

  • common-ingress (aus Datei)
  • us-central1-a (alle YAML-Dateien in diesem Ordner werden kombiniert)
  • us-central1-b (alle YAML-Dateien in diesem Ordner werden kombiniert)

• variantsPattern: "*.yaml": Entspricht common-ingress.yaml. Generiert Variante:

  • common-ingress

• variantsPattern: "us-*": Stimmt mit us-central1-a und us-central1-b überein. Generiert Varianten:

  • us-central1-a
  • us-central1-b

• variantsPattern: "us-central1-b/*.yaml": Entspricht us-central1-b/gke-1.yaml und us-central1-b/blue-green.yaml. Generiert Varianten:

  • gke-1
  • blue-green

variantNameTemplate-Abgleich

Nachdem Varianten definiert wurden, bestimmt das Feld variantNameTemplate im Abschnitt variantSelector, welche Variante auf jeden Cluster angewendet wird. Die Vorlage kann Variablen verwenden, um auf die folgenden Metadaten zur Flottenmitgliedschaft zuzugreifen:

• ${membership.name}: Der Name der Flottenmitgliedschaft des Clusters.
• ${membership.location}: Der Standort der Flottenmitgliedschaft.
• ${membership.project}: Das Projekt für die Flottenmitgliedschaft.
• ${membership.labels['KEY']}: Der Wert des Labels KEY für die Flottenmitgliedschaft.

Sehen Sie sich die folgenden Szenarien an, in denen Labels zum Abgleichen von Varianten verwendet werden:

• variantNameTemplate: "${membership.labels['env']}": Ein Cluster mit dem Label env: prod wird mit einer Variante namens prod synchronisiert.
• variantNameTemplate: "${membership.location}": Cluster werden mit Varianten synchronisiert, die ihrem Standort entsprechen (z. B. us-central1-a).
• variantNameTemplate: "default": Cluster werden mit einer Variante namens default synchronisiert. Das ist das Standardverhalten, wenn variantSelector weggelassen wird. Wenn Ihr Repository keine Datei mit dem Namen default.yaml oder kein Verzeichnis mit dem Namen „default“ enthält, wird nichts synchronisiert.

variantsPattern und variantNameTemplate kombinieren

Für eine erfolgreiche Bereitstellung müssen Sie dafür sorgen, dass die von Ihrem variantsPattern generierten Variantennamen Namen sind, mit denen Ihre Cluster durch Abgleich des variantNameTemplate synchronisiert werden können.

Wenn Sie beispielsweise Cluster basierend auf einem Umgebungslabels bereitstellen möchten, können Sie Ihr Git-Repository mit Verzeichnissen wie dev, staging und prod strukturieren. Sie würden dann die folgende Flottenpaketspezifikation verwenden:

resourceBundleSelector:
  cloudBuildRepository:
    # ... other fields
    path: "manifests"
    variantsPattern: "*" # Matches dev, staging, prod directories
variantSelector:
  variantNameTemplate: "${membership.labels['env']}"

Bei dieser Konfiguration erhält ein Cluster mit dem Label env: staging den Inhalt des Verzeichnisses manifests/staging/.

Bereitstellungsstrategien

Mit Flottenpaketen können Sie Ressourcen aus einem Git-Repository in Ihrer gesamten Clusterflotte bereitstellen. Sie können Ihr Flottenpaket auch so konfigurieren, dass Sie steuern, wie, wo und welche Art von Ressourcen bereitgestellt werden.

Im folgenden Abschnitt finden Sie Beispiele für verschiedene FleetPackage-Konfigurationen. Weitere Informationen zum Anwenden von Flottenpaketen finden Sie unter Flottenpakete bereitstellen.

Bereitstellung in allen Clustern einer Flotte

Im folgenden FleetPackage wird eine Rolling-Strategie verwendet, um Kubernetes-Ressourcen auf jeweils drei Clustern bereitzustellen und alle Cluster in einer Flotte anzusprechen:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
    tag: v1.0.0
    variantsPattern: "*.yaml"
    serviceAccount: projects/my-project/serviceAccounts/[e-mail]
target:
  fleet:
    project: projects/my-project
rolloutStrategy:
  rolling:
    maxConcurrent: 3
variantSelector:
  variantNameTemplate: deployment # matches a file named deployment.yaml

Bereitstellung in einer Teilmenge von Clustern

Im folgenden FleetPackage wird ein Labelselektor verwendet, um Kubernetes-Ressourcen nur in Clustern mit dem Mitgliedschaftslabel country bereitzustellen, das mit "us" in der Flotte übereinstimmt:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
    tag: v1.0.0
    variantsPattern: "*.yaml"
    serviceAccount: projects/my-project/serviceAccounts/[e-mail]
target:
  fleet:
    project: projects/my-project
    selector:
      matchLabels:
        country: "us"
rolloutStrategy:
  rolling:
    maxConcurrent: 3

Nächste Schritte

Flottenpakete bereitstellen