Kubernetes-Ressourcenplatzierung vom Hubcluster zu Mitgliedsclustern

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

Plattformadministratoren und -administratorinnen müssen häufig Kubernetes-Ressourcen auf mehrere Clustern aus verschiedenen Gründen 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 auf mehrere Cluster 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 Manager bietet eine Kubernetes-Ressourcenverteilung für die Verwaltung von Kubernetes-Ressourcen. Mit Fleet Manager können Sie Kubernetes-Ressourcen auf einem flottenverwalteten Hubcluster erstellen und diese über Kubernetes Custom Resources an ausgewählte Mitgliedscluster verteilen: MemberCluster und ClusterResourcePlacement.

Fleet Manager unterstützt diese benutzerdefinierten Ressourcen basierend auf der Open-Source-KubeFleet-Lösung, über die Sie mehr über die Dokumentationswebsite von KubeFleet erfahren können.

Einführung in ClusterResourcePlacement

Ein ClusterResourcePlacement-Objekt wird verwendet, um dem Fleet-Scheduler mitzuteilen, wie eine bestimmte Gruppe von clusterbezogenen Objekten aus dem Flottenhubcluster in Membercluster 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:

• Wählen Sie aus, welche Ressourcen weitergegeben werden sollen. Hierbei kann es sich um clusterbezogene Kubernetes-Ressourcen handeln, die mithilfe von Kubernetes Group Version Kind (GVK) -Verweisen definiert wurden, oder um einen Namespace, der den Namespace und alle zugehörigen Ressourcen verteilt.
• Geben Sie Richtlinien zur Platzierung an, um Mitglieder-Cluster auszuwählen. Diese Richtlinien können Cluster explizit nach Namen auswählen oder Cluster basierend auf Clusterbeschriftungen und -eigenschaften dynamisch auswählen.
• Angeben von Rolloutstrategien zum sicheren Rollout von Updates der ausgewählten Kubernetes-Ressourcen in mehreren Zielclustern.
• Zeigen Sie den Verteilungsfortschritt für jeden Zielcluster an.

Ein Beispiel ist in der folgenden Abbildung dargestellt.

Kapseln von Ressourcen

ClusterResourcePlacement unterstützt die Verwendung von ConfigMap, um bestimmte Kubernetes-Ressourcentypen zu umhüllen, damit sie auf dem Hubcluster ohne unbeabsichtigte Nebenwirkungen auf dem Hubcluster bereitgestellt werden können. Eine Liste der Ressourcentypen und informationen dazu, wie dieses Feature funktioniert, finden Sie in der Dokumentation zum KubeFleet-Umschlagobjekt.

Arten der Platzierung

Die folgenden Platzierungstypen stehen zur Verfügung, um die Anzahl der Cluster zu steuern, an welche die festgelegte Kubernetes-Ressource verteilt werden muss:

• PickFixed platziert die Ressourcen nach Namen in eine bestimmte Liste von Memberclustern.
• PickAll platziert die Ressource auf allen Mitgliedsclustern oder allen Mitgliedsclustern, die einem Kriterium entsprechen. Diese Richtlinie ist nützlich für die Platzierung von Infrastrukturworkloads, z. B. Clusterüberwachungs- oder Berichtsanwendungen.
• 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.

Platzierungstyp PickFixed

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.

clusterNames ist die einzige gültige Richtlinienoption für diesen Platzierungstyp.

Das folgende Beispiel zeigt, wie Sie den test-deployment-Namespace in Memberclustern den cluster1 und cluster2 bereitstellen.

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

Platzierungstyp PickAll

Sie können einen PickAll-Platzierungstyp verwenden, um eine Workload in allen Mitgliedsclustern in der Flotte oder in einer Teilmenge von Clustern bereitzustellen, die den von Ihnen festgelegten Kriterien entsprechen.

Beim Erstellen dieser Art von Platzierung können die folgenden Clusteraffinitätstypen angegeben werden:

• requiredDuringSchedulingIgnoredDuringExecution: Da diese Richtlinie während der Planung erforderlich ist, filtert sie das Cluster basierend auf den angegebenen Kriterien.

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

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

Platzierungstyp PickN

Der PickN-Platzierungstyp 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.

Beim Erstellen dieser Art von Platzierung können die folgenden Clusteraffinitätstypen angegeben werden:

• requiredDuringSchedulingIgnoredDuringExecution: Da diese Richtlinie während der Planung erforderlich ist, filtert sie das Cluster basierend auf den angegebenen Kriterien.
• preferredDuringSchedulingIgnoredDuringExecution: Da diese Richtlinie bevorzugt wird, aber während der Planung nicht erforderlich ist, bewertet sie Cluster basierend auf angegebenen Kriterien.

Sie können sowohl erforderliche als auch bevorzugte Affinitäten festlegen. Erforderliche Affinitäten verhindern die Platzierung an Clustern, die nicht übereinstimmen, und bevorzugte Affinitäten stellen die Sortierung gültiger Cluster bereit.

PickN mit Affinitäten

Verwenden von Affinitäten mit PickN Platzierungsrichtlinienfunktionen ähnlich wie die Verwendung von Affinitäten mit der Pod-Planung.

Das folgende Beispiel zeigt, wie Sie die Workload auf 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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-01
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 die Verfügbarkeitsanforderungen zu erfüllen. Verwenden Sie z. B. diese Einschränkungen, um Platzierungen über Regionen hinweg zu teilen oder Ringe zu aktualisieren. 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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-02
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Weitere Informationen finden Sie in der KubeFleet-Dokumentation zu Topologie-Spread-Einschränkungen.

Optionen für Platzierungsrichtlinien

In der Tabelle sind die verfügbaren Planungsrichtlinienfelder für jeden Platzierungstyp zusammengefasst.

Feld "Policy"	PickFixed	PickAll	Auswählen
placementType	✅	✅	✅
affinity	❌	✅	✅
clusterNames	✅	❌	❌
numberOfClusters	❌	❌	✅
topologySpreadConstraints	❌	❌	✅

Auswählen von Clustern basierend auf Bezeichnungen und Eigenschaften

Verfügbare Bezeichnungen und Eigenschaften zum Auswählen von Clustern

Bei Verwendung der PickN-Typen und PickAll-Platzierung können Sie die folgenden Bezeichnungen und Eigenschaften als Teil Ihrer Richtlinien verwenden.

Beschriftungen

Die folgenden Bezeichnungen werden automatisch allen Memberclustern hinzugefügt und können für die Zielclusterauswahl in Ressourcenplatzierungsrichtlinien verwendet werden.

Etikett	Beschreibung
fleet.azure.com/location	Azure-Region des Clusters (Westus)
fleet.azure.com/resource-group	Azure-Ressourcengruppe des Clusters (rg_prodapps_01)
fleet.azure.com/subscription-id	Azure-Abonnementbezeichner, in dem sich das Cluster befindet. Formatiert als UUID/GUID.

Sie können auch alle benutzerdefinierten Bezeichnungen verwenden, die Sie auf Ihre Cluster anwenden.

Eigenschaften

Die folgenden Eigenschaften sind für die Verwendung im Rahmen von Platzierungsrichtlinien verfügbar.

CPU- und Speichereigenschaften werden als Kubernetes-Ressourceneinheiten dargestellt.

Kosteneigenschaften sind Dezimalstellen, die Kosten pro Stunde in US-Dollar für Azure Compute darstellen, das für Knoten innerhalb des Clusters verwendet wird. Die Kosten basieren auf öffentlichen Azure-Preisen.

Eigenschaftenname	Beschreibung
kubernetes-fleet.io/node-count	Verfügbare Knoten im Membercluster.
resources.kubernetes-fleet.io/total-cpu	Gesamtanzahl der CPU-Ressourceneinheiten des Clusters.
resources.kubernetes-fleet.io/allocatable-cpu	Zuordnungsfähige CPU-Ressourceneinheiten des Clusters.
resources.kubernetes-fleet.io/available-cpu	Verfügbare CPU-Ressourceneinheiten des Clusters.
resources.kubernetes-fleet.io/total-memory	Gesamtspeicherressourceneinheit des Clusters.
resources.kubernetes-fleet.io/allocatable-memory	Zuordnungsfähige Einheiten der Speicherressource des Clusters.
resources.kubernetes-fleet.io/available-memory	Verfügbare Speicherressourceneinheiten des Clusters.
kubernetes.azure.com/per-cpu-core-cost	Die Kosten pro CPU-Kern des Clusters.
kubernetes.azure.com/per-gb-memory-cost	Die Kosten pro GiB-Speicher des Clusters.

Angeben von Auswahlvergleichskriterien

Wenn Sie Clustereigenschaften in einem Richtlinienkriterium verwenden, geben Sie Folgendes an:

• Name: Der Name der Eigenschaft, bei der es sich um eine der in Eigenschaften in diesem Artikel aufgeführten Eigenschaften handelt.

• Operator: Ein Operator, mit dem die Bedingung zwischen dem eingeschränkten/gewünschten Wert und dem beobachteten Wert im Cluster ausgedrückt wird. Die folgenden Operatoren werden derzeit unterstützt:

  • Gt (Größer als): Der beobachtete Wert eines Clusters der angegebenen Eigenschaft muss größer als der Wert in der Bedingung sein, damit er für die Ressourcenplatzierung ausgewählt werden kann.
  • Ge (Größer als oder gleich): Der beobachtete Wert eines Clusters der angegebenen Eigenschaft muss größer als der Wert in der Bedingung oder gleich diesem Wert sein, damit er für die Ressourcenplatzierung ausgewählt werden kann.
  • Lt (Kleiner als): Der beobachtete Wert eines Clusters der angegebenen Eigenschaft muss kleiner als der Wert in der Bedingung sein, damit er für die Ressourcenplatzierung ausgewählt werden kann.
  • Le (Kleiner als oder gleich): Der beobachtete Wert eines Clusters der angegebenen Eigenschaft muss kleiner als der Wert in der Bedingung oder gleich diesem Wert sein, damit er für die Ressourcenplatzierung ausgewählt werden kann.
  • Eq (Gleich): Der beobachtete Wert eines Clusters der angegebenen Eigenschaft muss gleich dem Wert in der Bedingung sein, damit er für die Ressourcenplatzierung ausgewählt werden kann.
  • Ne (Ungleich): Der beobachtete Wert eines Clusters der angegebenen Eigenschaft muss ungleich dem Wert in der Bedingung sein, damit er für die Ressourcenplatzierung ausgewählt werden kann.

  Wenn Sie den Operator Gt, Ge, Lt, Le, Eq oder Ne verwenden, muss die Liste der Werte in der Bedingung genau einen Wert aufweisen.

• Values: Eine Liste der möglichen Werte der Eigenschaft.

Fleet wertet jeden Cluster basierend auf den in der Bedingung angegebenen Eigenschaften aus. Wenn die unter requiredDuringSchedulingIgnoredDuringExecution aufgeführten Bedingungen nicht erfüllt werden, wird dieser Mitgliedscluster von der Ressourcenplatzierung ausgeschlossen.

Hinweis

Wenn ein Mitgliedscluster nicht über die in der Bedingung ausgedrückte Eigenschaft verfügt, wird die Bedingung automatisch als nicht erfüllt angesehen.

Hier ist eine Beispiel-Platzierungsrichtlinie, um nur Cluster mit fünf oder mehr Knoten auszuwählen.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Funktionsweise der Eigenschaftenbewertung

Wenn preferredDuringSchedulingIgnoredDuringExecution verwendet wird, priorisiert ein Eigenschaftensortierer alle Cluster in der Flotte basierend auf ihren Werten in aufsteigender oder absteigender Reihenfolge. Die für die Sortierung verwendeten Gewichtungen werden basierend auf dem angegebenen Wert berechnet.

Ein Eigenschaftensortierer besteht aus:

• Name: Name der Clustereigenschaft.
• Sortierreihenfolge: Die Sortierreihenfolge kann entweder Ascending oder Descending sein. Wenn eine Ascending-Reihenfolge verwendet wird, werden Mitgliedscluster mit niedrigeren beobachteten Werten bevorzugt. Wenn eine Descending-Reihenfolge verwendet wird, werden Mitgliedscluster mit höheren beobachteten Werten bevorzugt.

Absteigende Reihenfolge

Für die Sortierreihenfolge „Absteigend“ wird die proportionale Gewichtung mithilfe der folgenden Formel berechnet:

((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight

Beispiel: Sie möchten Cluster basierend auf der Eigenschaft der verfügbaren CPU-Kapazität in absteigender Reihenfolge priorisieren und verfügen über eine Flotte von drei Clustern mit der folgenden verfügbaren CPU:

Kluster	Verfügbare CPU-Kapazität
cluster-a	100
cluster-b	20
cluster-c	10

In diesem Fall berechnet der Sortierer die folgenden Gewichtungen:

Kluster	Verfügbare CPU-Kapazität	Berechnung	Gewicht
cluster-a	100	(100 - 10) / (100 - 10)	100 %%
cluster-b	20	(20 - 10) / (100 - 10)	11,11%
cluster-c	10	(10 - 10) / (100 - 10)	0 %

Aufsteigende Reihenfolge

Für die Sortierreihenfolge „Aufsteigend“ wird die proportionale Gewichtung mithilfe der folgenden Formel berechnet:

(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight

Beispiel: Sie möchten Cluster basierend auf den Kosten pro CPU-Kern in aufsteigender Reihenfolge priorisieren und verfügen über eine Flotte von drei Clustern mit den folgenden Kosten pro CPU-Kern:

Kluster	Kosten pro CPU-Kern
cluster-a	1
cluster-b	0.2
cluster-c	0,1

In diesem Fall berechnet der Sortierer die folgenden Gewichtungen:

Kluster	Kosten pro CPU-Kern	Berechnung	Gewicht
cluster-a	1	1 - ((1 - 0.1) / (1 - 0.1))	0 %
cluster-b	0.2	1 - ((0.2 - 0.1) / (1 - 0.1))	88,89%
cluster-c	0,1	1 - (0.1 - 0.1) / (1 - 0.1)	100 %%

Ressourcenmomentaufnahmen

Flottenmanager behält einen Verlauf der 10 zuletzt verwendeten Richtlinien für die Platzierungsplanung zusammen mit den bei der Platzierung ausgewählten Ressourcenversionen bei.

Diese Momentaufnahmen können mit mehrstufigen Rolloutstrategien verwendet werden, um die bereitgestellte Version zu steuern.

Weitere Informationen finden Sie in der Dokumentation zu Momentaufnahmen.

Verwenden von 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 Dokumentation zu Tolerationen.

Konfigurieren der Rolloutstrategie

Fleet verwendet eine rollierende Aktualisierungsstrategie, um zu steuern, wie Updates über Cluster hinweg eingeführt werden.

Im folgenden Beispiel führt der Flottenplaner Updates für jedes Cluster sequenziell aus und wartet mindestens unavailablePeriodSeconds zwischen Clustern. 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 weitergegeben – beispielsweise wird nicht bestätigt, dass von einer Bereitstellung erstellte Pods bereit sind.

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

Weitere Informationen finden Sie in der Dokumentation zu Rolloutstrategien.

Festlegen des Platzierungsstatus

Der Fleet-Scheduler aktualisiert Details und Status von Platzierungsentscheidungen auf das ClusterResourcePlacement Objekt. 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.

Sie können diese Informationen mithilfe des kubectl describe crp <name> Befehls anzeigen.

kubectl describe crp crp-1

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1
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änderungstrigger

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 neues Cluster, das berechtigt wird, kann die Platzierung auslösen, wenn es die Platzierungsrichtlinie erfüllt, z. B. eine PickAll-Richtlinie.
  • Ein Cluster mit einer Platzierung wird aus der Flotte entfernt. Je nach Richtlinie versucht der Scheduler, alle betroffenen Workloads auf verbleibenden Clustern zu platzieren, ohne vorhandene 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.

Nächste Schritte

• Verwenden Sie die Clusterressourcenplatzierung, um Workloads in mehreren Clustern bereitzustellen.
• Intelligente clusterübergreifende Platzierung von Kubernetes-Ressourcen basierend auf den Eigenschaften der Mitgliedscluster.
• Steuern der Vertreibung und Unterbrechung der Clusterressourcenplatzierung.
• Festlegung einer Rolloutstrategie für die Platzierung von Clusterressourcen.
• Häufig gestellte Fragen zur Platzierung von Clusterressourcen.