Kubernetes-Ressourcenverteilung vom Hubcluster zu Mitgliedsclustern (Vorschau)

  • Artikel

In diesem Artikel wird das Konzept der Kubernetes-Ressourcenverteilung von Hubclustern zu Mitgliedsclustern mithilfe von Azure Kubernetes Fleet Manager (Fleet) beschrieben.

Plattformadministratoren und -administratorinnen müssen häufig Kubernetes-Ressourcen in mehreren Clustern für verschiedene Gründe bereitstellen, z. B.:

  • Verwalten der Zugriffssteuerung mithilfe von Rollen und Rollenbindungen über mehrere Cluster hinweg.
  • Ausführen von Infrastrukturanwendungen wie Prometheus oder Flux, die sich auf allen Clustern befinden müssen.

Anwendungsentwickler und -entwicklerinnen müssen häufig aus verschiedenen Gründen Kubernetes-Ressourcen in mehreren Clustern bereitstellen, z. B.:

  • Bereitstellen einer Videobereitstellungsanwendung in mehreren Clustern in verschiedenen Regionen für eine geringe Latenz bei der Überwachung.
  • Bereitstellen einer Einkaufswagenanwendung in zwei gekoppelten Regionen, damit die Kundschaft während eines Ausfalls einer Region weiterhin einkaufen kann.
  • Bereitstellen einer Batchcomputeanwendung in Clustern mit kostengünstigen Spot-Knotenpools.

Es ist mühsam, diese Kubernetes-Ressourcen manuell in mehreren Clustern zu erstellen, zu aktualisieren und nachzuverfolgen. Fleet bietet eine Kubernetes-Ressourcenverteilung für die Verwaltung von Kubernetes-Ressourcen. Mit Fleet können Sie Kubernetes-Ressourcen im Hubcluster erstellen und über Kubernetes-Kundenressourcen an ausgewählte Mitgliedscluster verteilen: MemberCluster und ClusterResourcePlacement. Fleet unterstützt diese benutzerdefinierten Ressourcen basierend auf einer cloudnativen Open-Source-Multiclusterlösung. Weitere Informationen finden Sie in der Upstream-Fleet-Dokumentation.

Wichtig

Previewfunktionen von Azure Kubernetes Fleet Manager sind auf Self-Service-Basis per Aktivierung verfügbar. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von den Vereinbarungen zum Service Level und der eingeschränkten Garantie ausgeschlossen. Vorschauversionen von Azure Kubernetes Fleet Manager sind auf Best-Effort-Basis teilweise durch den Kundensupport abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen.

Ressourcenverteilungsworkflow

Diagramm: Weitergabe von Kubernetes-Ressourcen an Mitgliedscluster

Was ist ein MemberCluster?

Wenn ein Cluster in eine Flotte eingebunden wird, wird im Hubcluster eine entsprechende benutzerdefinierte MemberCluster-Ressource erstellt. Sie können diese benutzerdefinierte Ressource verwenden, um Zielcluster in der Ressourcenverteilung auszuwählen.

Die folgenden Bezeichnungen können für die Zielclusterauswahl bei der Ressourcenverteilung verwendet werden und werden automatisch allen Mitgliedsclustern hinzugefügt:

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Weitere Informationen finden Sie in der MemberCluster-API-Referenz.

Was ist ein ClusterResourcePlacement?

Ein ClusterResourcePlacement Objekt wird verwendet, um dem Fleet-Scheduler mitzuteilen, wie eine bestimmte Gruppe von clusterbezogenen Objekten aus dem Hub-Cluster in Member-Cluster platziert werden kann. Namespacebezogene Objekte wie Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets und PersistentVolumeClaims werden einbezogen, wenn der enthaltende Namespace ausgewählt ist.

Mit ClusterResourcePlacement haben Sie folgende Möglichkeiten:

  • Auswählen, welche Kubernetes-Ressourcen im Clusterbereich an Mitgliedscluster verteilt werden.
  • Angeben von Platzierungsrichtlinien, um eine Teilmenge oder alle Mitgliedscluster manuell oder automatisch als Zielcluster auszuwählen.
  • Angeben von Rolloutstrategien zum sicheren Rollout von Updates der ausgewählten Kubernetes-Ressourcen in mehreren Zielclustern.
  • Anzeigen des Verteilungsfortschritts für jeden Zielcluster.

Das ClusterResourcePlacement Objekt unterstützt die Verwendung von ConfigMap zur Umhüllung des Objekts um die Verbreitung an Mitgliedscluster ohne unbeabsichtigte Nebenwirkungen zu unterstützen. Zu den Auswahlmethoden gehören:

  • Gruppe, Version und Art: Alle Ressourcen des angegebenen Typs auswählen und platzieren.
  • Gruppe, Version, Art und Name: Wählen sie eine bestimmte Ressource eines bestimmten Typs aus, und platzieren Sie sie.
  • Gruppe, Version, Art und Bezeichnungen: Wählen Und platzieren Sie alle Ressourcen eines bestimmten Typs, die den bereitgestellten Bezeichnungen entsprechen.

Weitere Informationen finden Sie in der Referenz zur ClusterResourcePlacement-API.

Sobald Sie die Ressourcen ausgewählt haben, stehen mehrere Platzierungsrichtlinien zur Verfügung:

  • PickAll platziert die Ressourcen in alle verfügbaren Member-Cluster. Diese Richtlinie ist nützlich für die Platzierung von Infrastrukturworkloads, z. B. Clusterüberwachungs- oder Berichtsanwendungen.
  • PickFixed platziert die Ressourcen nach Namen in eine bestimmte Liste von Memberclustern.
  • PickN ist die flexibelste Platzierungsoption und ermöglicht die Auswahl von Clustern basierend auf Affinitäts- oder Topologieverteilungseinschränkungen und ist nützlich, wenn Workloads über mehrere geeignete Cluster verteilt werden, um sicherzustellen, dass die Verfügbarkeit gewünscht wird.

PickAll Platzierungsrichtlinien

Um eine Arbeitsauslastung in allen Mitgliedsclustern in der Flotte bereitzustellen (optional mit einer Reihe von Kriterien übereinstimmen), können Sie eine PickAll Platzierungsrichtlinie verwenden.

Das folgende Beispiel zeigt, wie Sie einen test-deployment Namespace und alle zugehörigen Objekte in allen Clustern bereitstellen, die mit environment: production Bezeichnungen versehen sind:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-1
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

Diese einfache Richtlinie verwendet den test-deployment Namespace und alle darin enthaltenen Ressourcen und stellt ihn mit der angegebenen environment Bezeichnung in allen Mitgliedsclustern in der Flotte bereit. Wenn alle Cluster erwünscht sind, können Sie den affinity Begriff vollständig entfernen.

PickFixed Platzierungsrichtlinien

Wenn Sie eine Workload in einer bekannten Gruppe von Memberclustern bereitstellen möchten, können Sie eine PickFixed Platzierungsrichtlinie verwenden, um die Cluster anhand des Namens auszuwählen.

Das folgende Beispiel zeigt, wie Sie den test-deployment Namespace in Memberclustern cluster1und cluster2 bereitstellen:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-2
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

PickN Platzierungsrichtlinien

Die PickN Platzierungsrichtlinie ist die flexibelste Option und ermöglicht die Platzierung von Ressourcen in einer konfigurierbaren Anzahl von Clustern basierend auf Affinitäten und Topologie-Spread-Einschränkungen.

PickN mit Affinitäten

Verwenden von Affinitäten mit PickN Platzierungsrichtlinienfunktionen ähnlich wie die Verwendung von Affinitäten mit der Pod-Planung. Sie können sowohl erforderliche als auch bevorzugte Affinitäten festlegen. Erforderliche Affinitäten verhindern die Platzierung an Clustern, die nicht mit den angegebenen Affinitäten übereinstimmen. Bevorzugte Affinitäten ermöglichen das Sortieren der Gruppe gültiger Cluster, wenn eine Platzierungsentscheidung getroffen wird.

Das folgende Beispiel zeigt, wie Sie die Arbeitsauslastung in drei Clustern bereitstellen. Nur Cluster mit der Bezeichnung critical-allowed: "true" sind gültige Platzierungsziele, wobei Cluster mit der Bezeichnung critical-level: 1 bevorzugt werden:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

PickN mit Beschränkungen der Topologieverteilung

Sie können Topologieverteilungseinschränkungen verwenden, um die Aufteilung der Clusterplatzierungen über Topologiegrenzen hinweg zu erzwingen, um Verfügbarkeitsanforderungen zu erfüllen (z. B. Teilen von Platzierungen über Regionen oder Aktualisierungsringe). Sie können Topologieverteilungseinschränkungen auch so konfigurieren, dass die Planung verhindert wird, wenn die Beschränkung nicht erfüllt werden kann (whenUnsatisfiable: DoNotSchedule) oder dass die Planung so gut wie möglich ist (whenUnsatisfiable: ScheduleAnyway).

Dieses folgende Beispiel zeigt, wie man eine bestimmte Gruppe von Ressourcen über mehrere Regionen hinweg verteilt und versucht, mehrere Mitgliedercluster mit unterschiedlichen Aktualisierungstagen zu planen:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Weitere Informationen finden Sie in der Dokumentation zur Verbreitung von Fleetbeschränkungen in der Upstreamtopologie.

Updatestrategie

Fleet verwendet eine rollierende Updatestrategie, um zu steuern, wie Updates über mehrere Clusterplatzierungen hinweg eingeführt werden.

Das folgende Beispiel zeigt, wie Sie eine rollierende Updatestrategie mithilfe der Standardeinstellungen konfigurieren:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Der Scheduler führt ein Rollup für jeden Cluster sequenziell durch, der mindestens unavailablePeriodSeconds zwischen Clustern wartet. Der Rolloutstatus wird als erfolgreich betrachtet, wenn alle Ressourcen ordnungsgemäß auf den Cluster angewendet wurden. Die Überprüfung des Rolloutstatus wird nicht an untergeordnete Ressourcen überlappend – beispielsweise wird nicht bestätigt, dass von einer Bereitstellung erstellte Pods bereit sind.

Weitere Informationen finden Sie in der Dokumentation zur Upstream-Rolloutstrategie Fleet.

Status der Platzierung

Der Fleet-Scheduler aktualisiert Details und Status von Platzierungsentscheidungen auf das ClusterResourcePlacement Objekt. Sie können diese Informationen mithilfe des kubectl describe crp <name> Befehls anzeigen. Die Ausgabe enthält die folgenden Informationen:

  • Die Bedingungen, die derzeit für die Platzierung gelten, einschließlich, wenn die Platzierung erfolgreich abgeschlossen wurde.
  • Ein Platzierungsstatusabschnitt für jeden Mitgliedscluster, der den Status der Bereitstellung für diesen Cluster anzeigt.

Das folgende Beispiel zeigt einen ClusterResourcePlacement, der den test Namespace und die test-1 ConfigMap in zwei Member-Clustern mithilfe vonPickN bereitgestellt hat. Die Platzierung wurde erfolgreich abgeschlossen, und die Ressourcen wurden in die aks-member-1 und aks-member-2 Cluster platziert.

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

Platzierungsänderungen

Der Fleet-Scheduler priorisiert die Stabilität bestehender Arbeitsauslastungsplatzierungen. Diese Priorisierung kann die Anzahl der Änderungen einschränken, die dazu führen, dass eine Arbeitsauslastung entfernt und neu geplant wird. Die folgenden Szenarien können Platzierungsänderungen auslösen:

  • Änderungen der Platzierungsrichtlinien im ClusterResourcePlacement Objekt können das Entfernen und Neuplanen einer Arbeitsauslastung auslösen.
    • Skalierungsvorgänge (Erhöhungen von numberOfClusters ohne andere Änderungen) platzieren Arbeitslasten nur auf neuen Clustern und wirken sich nicht auf vorhandene Platzierungen aus.
  • Clusteränderungen, einschließlich:
    • Ein neuer Cluster, der berechtigt wird, kann die Platzierung auslösen, wenn er die Platzierungsrichtlinie erfüllt, z. B. eine PickAll Richtlinie.
    • Ein Cluster mit einer Platzierung wird aus der Flotte entfernt, um alle betroffenen Arbeitslasten neu zu platzieren, ohne ihre anderen Platzierungen zu beeinträchtigen.

Nur Ressourcenänderungen (das Aktualisieren der Ressourcen oder das Aktualisieren des ResourceSelector Objekts ClusterResourcePlacement) werden schrittweise in vorhandenen Platzierungen eingeführt, aber die Neuplanung der Workload wird nicht ausgelöst.

Toleranzen

ClusterResourcePlacement Objekte unterstützen die Spezifikation von Toleranzen, die für das ClusterResourcePlacement-Objekt gelten. Jedes Toleranzobjekt umfasst folgende Felder:

  • key: Der Schlüssel der Toleranz.
  • value: Der Wert der Toleranz.
  • effect: Die Wirkung der Toleranz, z. B. NoSchedule.
  • operator: Der Operator der Toleranz, z. B. Exists oder Equal.

Jede Toleranz wird verwendet, um einen oder mehrere spezifischeTaints zu tolerieren, die auf ClusterResourcePlacement angewendet werden. Sobald alleTaints auf MemberCluster toleriert werden, kann die planende Person Ressourcen dann an den Cluster verteilen. Sie können keine Toleranzen aus einem ClusterResourcePlacement-Objekt aktualisieren oder entfernen, nachdem es erstellt wurde.

Weitere Informationen finden Sie in der Upstream-Fleet-Dokumentation.

Zugreifen auf die Kubernetes-API des Fleet-Ressourcenclusters

Wenn Sie Azure Kubernetes Fleet Manager-Ressource mit aktiviertem Hub-Cluster erstellt haben, kann sie zur zentralen Steuerung von Szenarien wie der Kubernetes-Objektpropagierung verwendet werden. Um auf die Kubernetes-API des Fleet-Ressourcenclusters zuzugreifen, führen Sie die Schritte in Zugreifen auf die Kubernetes-API der Fleet-Ressource mit Azure Kubernetes Fleet Manager aus.

Nächste Schritte

Einrichten der Kubernetes-Ressourcenverteilung vom Hubcluster zu Mitgliedsclustern