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 (Kubernetes Fleet) 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 bietet eine Kubernetes-Ressourcenverteilung für die Verwaltung von Kubernetes-Ressourcen. Mit Kubernetes Fleet können Sie Kubernetes-Ressourcen im Hubcluster erstellen und über Kubernetes-Kundenressourcen an ausgewählte Mitgliedscluster verteilen: MemberCluster und ClusterResourcePlacement.
Kubernetes Fleet unterstützt diese benutzerdefinierten Ressourcen basierend auf einer cloudeigenen Open Source-Lösung, die Sie in der Open Source-Fleet-Dokumentation nachlesen 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:
- Auswählen, welche Kubernetes-Ressourcen im Clusterbereich an Mitgliedscluster verteilt werden.
- Angeben von Platzierungsrichtlinien, um 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.
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 zur Funktionsweise dieses Features finden Sie in der Dokumentation zum 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 Open-Source-Fleet-Dokumentation in den Einschränkungen der Topologieüberfüllung.
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.
| Label | 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,EqoderNeverwenden, 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
AscendingoderDescendingsein. Wenn eineAscending-Reihenfolge verwendet wird, werden Mitgliedscluster mit niedrigeren beobachteten Werten bevorzugt. Wenn eineDescending-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:
| Cluster | Verfügbare CPU-Kapazität |
|---|---|
cluster-a |
100 |
cluster-b |
20 |
cluster-c |
10 |
In diesem Fall berechnet der Sortierer die folgenden Gewichtungen:
| Cluster | Verfügbare CPU-Kapazität | Berechnung | Weight |
|---|---|---|---|
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:
| Cluster | Kosten pro CPU-Kern |
|---|---|
cluster-a |
1 |
cluster-b |
0.2 |
cluster-c |
0.1 |
In diesem Fall berechnet der Sortierer die folgenden Gewichtungen:
| Cluster | Kosten pro CPU-Kern | Berechnung | Weight |
|---|---|---|---|
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 %% |
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.ExistsoderEqual.
Jede Toleranz wird verwendet, um einen oder mehrere spezifische Taints 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 Open-Source-Fleet-Dokumentation zu Toleranzen.
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 Open-Source-Fleet-Dokumentation zur Rolloutstrategie.
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
ClusterResourcePlacementObjekt können das Entfernen und Neuplanen einer Arbeitsauslastung auslösen.- Skalierungsvorgänge (Erhöhungen von
numberOfClustersohne andere Änderungen) platzieren Arbeitslasten nur auf neuen Clustern und wirken sich nicht auf vorhandene Platzierungen aus.
- Skalierungsvorgänge (Erhöhungen von
- 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.
- Ein neues Cluster, das berechtigt wird, kann die Platzierung auslösen, wenn es die Platzierungsrichtlinie erfüllt, z. B. eine
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
Azure Kubernetes Service