Einführung in die intelligente Ressourcenplatzierung von Azure Kubernetes Fleet Manager

Gilt für ✔️ Flottenmanager mit Hubcluster

Die Verwaltung von Kubernetes-Ressourcen über mehrere Cluster hinweg stellt sowohl Plattformadministratoren als auch Anwendungsentwicklern erhebliche Herausforderungen dar. Da Organisationen ihre Kubernetes-Infrastruktur über einen einzelnen Cluster hinaus skalieren, treten häufig Komplexitäten im Zusammenhang mit der Ressourcenverteilung, Konsistenz und manuellem Verwaltungsaufwand auf. Der traditionelle Ansatz, jeden Cluster unabhängig voneinander zu verwalten, schafft Betriebssilos, die immer schwieriger zu halten sind, wenn die Flottengröße wächst.

Plattformadministratoren müssen aus verschiedenen Gründen häufig Kubernetes-Ressourcen auf mehreren Clustern bereitstellen, darunter:

• 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 und möglicherweise fehleranfällig, Kubernetes-Ressourcen über mehrere Cluster manuell zu erstellen, zu aktualisieren und nachzuverfolgen.

In diesem Artikel erfahren Sie, wie Sie die intelligente Ressourcenplatzierungsfunktion von Fleet Manager verwenden können, um die Verteilung von Cluster- und Namespace-bezogenen Kubernetes-Ressourcen über Mitgliedscluster in einer Flotte hinweg zu verwalten.

Die Ressourcenplatzierungsfähigkeit des Flottenmanagers basiert auf dem KubeFleet CNCF-Projekt.

Übersicht über den Ressourcenplatzierungsprozess

Führen Sie die folgenden Schritte aus, um die intelligente Ressourcenplatzierung von Fleet Manager zu verwenden:

1. Phasenressourcen auf Hubcluster: Verwenden Sie die fortlaufende Bereitstellung, GitOps oder eine ähnliche Methode, um die Manifeste für Ressourcenverteilungen auf dem Fleet Manager-Hubcluster anzuwenden.
2. Erstellen Sie eine Ressourcenplatzierung: Erstellen Sie ein Platzierungsmanifest, das die Ressource auswählt, und definiert eine Richtlinie zum Auswählen der Membercluster, die die Ressource erhalten.
3. Wenden Sie die Ressourcenplatzierung auf Hubcluster an: Wenden Sie das Platzierungsmanifest auf den Hubcluster an, um mit der Verteilung der Ressource zu beginnen.
4. Flottenmanager plant Ressourcen: Flottenmanager beobachtet die Ressourcenplatzierung und den ausgewählten Umfang und führt die Verteilung der Ressourcen durch.
5. Beobachten Sie die Verteilung über die Ressourcenplatzierung: Fragen Sie die Ressourcenplatzierung auf dem Hubcluster ab, um den Status der Ressource nach dem Rollout zu überprüfen.

Fleet Manager verfügt über eine Azure Portalerfahrung für die Ressourcenplatzierung, die eine visuellere Darstellung des Rollouts bietet.

Ressourcenplatzierungskomponenten

Eine Ressourcenplatzierung besteht unabhängig vom Bereich (Cluster oder Namespace) aus den folgenden Komponenten:

• Ressourcenselektoren: Wählen Sie die Ressourcen aus, die über resourceSelectors einbezogen werden sollen.
• Platzierungsrichtlinie: Definieren Sie, wie Cluster mithilfe von placementType unter Verwendung eines der Typen PickAll, PickFixed oder PickN ausgewählt werden.
• Rolloutstrategie: Steuern Sie, wie Ressourcen über ausgewählte Cluster hinweg unter Einbeziehung einer optionalen strategy ausgerollt werden.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll   

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Ressourcenselektoren

Wählen Sie Ressourcen aus, indem Sie innerhalb einer Platzierung eine oder mehrere resourceSelectors verwenden. Jede Ressourcenauswahl kann Folgendes angeben:

• Group, Version, Kind (GVK):Der Typ der kubernetes-Ressource, die ausgewählt werden soll.
• Name: Der Name einer bestimmten Ressource.
• Label-Selektoren: Labels, die mehrere Ressourcen zuordnen.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Platzierungsrichtlinie

Die Ressourcenplatzierung von Fleet Manager unterstützt die folgenden Platzierungsrichtlinientypen, um zu steuern, wie Cluster ausgewählt werden:

• PickFixed platziert Ressourcen mithilfe ihrer Clusternamen in Mitgliedsclustern.
• PickAll platziert Ressourcen 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. Sie können Cluster basierend auf Affinitäts- oder Topologie-Spreadeinschränkungen auswählen. Verwenden Sie diese Richtlinie, wenn Sie Workloads über mehrere ähnliche Cluster verteilen, um sicherzustellen, dass die Verfügbarkeit beibehalten wird.

Platzierungstyp PickFixed

Verwenden Sie PickFixed, um die Cluster anhand des Namens auszuwählen. Geben Sie Namen im clusterNames Array an.

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Platzierungstyp PickAll

Verwenden Sie PickAll, um Ressourcen auf alle Mitgliedscluster oder auf alle Cluster zu verteilen, die einem von Ihnen angegebenen Kriterium entsprechen.

Wenn Sie diesen Platzierungstyp erstellen, geben Sie die folgenden Clusteraffinitätstypen an:

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

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production

Platzierungstyp PickN

Verwenden Sie PickN, um Ressourcen auf eine konfigurierbare Anzahl von Clustern basierend auf Affinitäten und Topologie-Spread-Einschränkungen zu verteilen.

Wenn Sie diesen Platzierungstyp erstellen, geben Sie die folgenden Clusteraffinitätstypen an:

• 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. Bevorzugte Affinitäten stellen die Sortierung übereinstimmener Cluster bereit.

PickN mit Affinitäten

Die Verwendung von Affinitäten mit einer PickN Platzierungsrichtlinie entspricht der Verwendung von Affinitäten beim Pod-Scheduling in einem einzelnen Kubernetes-Cluster.

Das folgende Beispiel zeigt, wie Sie eine Ressource 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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-critical-preferences
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-critical-preferences
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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 Topologieausbreitungseinschränkungen

Verwenden Sie Topologie-Spread-Einschränkungen, um Platzierungen über Topologiegrenzen hinweg zu erzwingen, um Verfügbarkeitsanforderungen zu erfüllen.

Mit der whenUnsatisfiable Eigenschaft können Sie das Verhalten von Spreadeinschränkungen der Topologie konfigurieren:

• DoNotSchedule: Wenn die Einschränkung nicht erfüllt werden kann, schlägt die Platzierungsanforderung fehl.
• ScheduleAnyway: Wenn die Einschränkung nicht erfüllt werden kann, platzieren Sie Ressourcen trotzdem.

Das folgende Beispiel zeigt, wie Sie Ressourcen über mehrere Azure Regionen verteilen und versuchen, mehrere Mitgliedercluster mit unterschiedlichen Aktualisierungstagen mithilfe einer benutzerdefinierten Bezeichnung updateDayzu planen.

Wenn die Verteilung über Azure-Regionen nicht eingehalten werden kann, schlägt die Platzierung fehl. Wenn die updateDay Einschränkung nicht erfüllt ist, erfolgt die Platzierung weiterhin.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-locations-updates
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-locations-updates
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

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

Auswählen von Clustern mithilfe von Bezeichnungen und Eigenschaften

Die intelligente Ressourcenplatzierung von Fleet Manager bietet eine Reihe leistungsstarker Kriterien, die Sie verwenden können, wenn Sie bestimmen, wie Cluster bei Verwendung der PickN Und PickAll Platzierungstypen ausgewählt werden sollen. In diesem Abschnitt erfahren Sie, wie Sie diese Optionen verwenden, um Richtlinien zu erstellen, die Ihren Anforderungen entsprechen.

Optionen für Platzierungsrichtlinien

In der folgenden Tabelle sind die verfügbaren Planungsrichtlinienfelder für jeden Platzierungstyp aufgeführt.

Mitglieder-Cluster-Labels

Sie können die MemberCluster Ressource auf dem Hubcluster wie jede Kubernetes-Ressource bezeichnen.

Darüber hinaus fügt Fleet Manager allen Mitgliedsclustern automatisch die folgenden schreibgeschützten Labels hinzu.

Clustereigenschaften

Verwenden Sie die folgenden Eigenschaften als Teil von Platzierungsrichtlinien.

• Kubernetes-Ressourceneinheiten stellen CPU- und Speichereigenschaften dar. Weitere Informationen finden Sie unter "Ressourceneinheiten" in Kubernetes.

• Kosteneigenschaften sind Dezimalwerte, die die Kosten pro Stunde in US-Dollar für die Azure-Rechenressourcen darstellen, die von Knoten innerhalb des Clusters verwendet werden. Die Kosten basieren auf den öffentlichen Azure-Preisen.

Auswahlvergleichskriterien

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

• Name: Name der Eigenschaft, die eine der in Eigenschaften in diesem Artikel aufgeführten Eigenschaften ist.

• Operator: Ein Operator, der die Bedingung zwischen der Einschränkung oder dem gewünschten Wert und dem beobachteten Wert im Cluster ausdrückt. 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 (Nicht gleich): Der beobachtete Wert eines Clusters der angegebenen Eigenschaft darf nicht dem Wert in der Bedingung entsprechen, bevor 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.

Flotte wertet jeden Cluster basierend auf den Eigenschaften aus, die Sie in der Bedingung angeben. Wenn ein Cluster die unter requiredDuringSchedulingIgnoredDuringExecutionaufgeführten Bedingungen nicht erfüllt, schließt Fleet den Cluster von der Ressourcenplatzierung aus.

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-pickall-five-nodes
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-five-nodes
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Funktionsweise der Eigenschaftenbewertung

Bei Verwendung preferredDuringSchedulingIgnoredDuringExecutionsortiert ein Eigenschaftssortierer 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 von Ihnen angegebenen Wert berechnet.

Ein Eigenschaftensortierer besteht aus:

• Name: Name der Clustereigenschaft.
• Sortierreihenfolge: Die Sortierreihenfolge kann entweder Ascending oder Descending sein. Wenn Sie die Reihenfolge Ascending verwenden, werden Mitgliedscluster mit niedrigeren beobachteten Werten bevorzugt. Bei Verwendung der Descending-Sortierung werden Mitgliedscluster mit höherem beobachtetem Wert bevorzugt.

Weitere Informationen finden Sie in der KubeFleet-Dokumentation zur eigenschaftsbasierten Planung.

Konfigurieren der Rolloutstrategie

Die Ressourcenplatzierung von Fleet Manager verwendet eine Standardstrategie RollingUpdate , um zu steuern, wie Ressourcen an Mitgliedscluster verteilt werden.

Im folgenden Beispiel wird die Platzierung sequenziell auf jeden Mitgliedscluster verteilt, wobei zwischen Clustern mindestens unavailablePeriodSeconds gewartet wird.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pick-all-rolling
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Der Rolloutstatus wird als erfolgreich betrachtet, wenn alle Ressourcen ordnungsgemäß auf den Cluster angewendet werden. Dieser Status vererbt nicht den Status untergeordneter Ressourcen und bestätigt daher nicht, dass Pods, die in einem Mitgliedscluster von einem Deployment erstellt wurden, bereit sind.

Weitere Informationen finden Sie in der Dokumentation zu Rolloutstrategien.

Verwenden von Tolerierungen

Sie können Mitgliedscluster genauso mit Taints versehen, wie Sie Knoten in einem Cluster mit Taints versehen.

Ressourcenplatzierungen unterstützen die Verwendung von Toleranzen, bei denen jede Toleranz aus den folgenden Feldern besteht:

• 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 Tolerierung wird verwendet, um einen oder mehrere spezifische Taints zu tolerieren, die auf einen MemberCluster angewendet werden. Sobald alle Taints toleriert werden, kann der Fleet Manager Ressourcen an den Mitgliedscluster verteilen.

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: test-ns
spec:
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-ns
      version: v1
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Weitere Informationen finden Sie in der Dokumentation zu Tolerationen.

Verwenden von Umschlagressourcen

Der Fleet Manager Hub Cluster ist auch ein Kubernetes-Cluster. Sie wenden zuerst alle Ressourcen an, die Sie auf den Hubcluster verteilen möchten. Dieser Ansatz kann dazu führen:

1. Unbeabsichtigte Nebenwirkungen: ValidatingWebhookConfigurations, MutatingWebhookConfigurations oder Admission Controller werden im Hubcluster aktiv und können potenziell Hubclustervorgänge abfangen und beeinflussen.

2. Sicherheitsrisiken: RBAC-Ressourcen (Rollen, ClusterRoles, RoleBindings, ClusterRoleBindings), die für Mitgliedscluster vorgesehen sind, könnten Berechtigungen auf dem Hub-Cluster gewähren oder einschränken.

3. Ressourcenlimits: Für Mitgliedscluster definierte ResourceQuotas, FlowSchemas oder LimitRanges gelten für den Hub-Cluster.

Um unnötige Nebenwirkungen zu vermeiden, bietet Fleet Manager benutzerdefinierte Umschlagressourcen (ClusterResourceEnvelope und ResourceEnvelope), um Objekte umzuschließen und diese potenziellen Probleme zu vermeiden.

Sie wenden die Umschlagressource auf den Hubcluster an, aber die darin enthaltenen Ressourcen werden extrahiert und angewendet, wenn sie Mitgliedscluster erreichen.

Weitere Informationen finden Sie in der Dokumentation Umschließende Objekte.

Festlegen des Platzierungsstatus

Die Ressourcenplatzierung von Fleet Manager bietet zwei Möglichkeiten, den Status je nach Zugriffsebene und Anforderungen des Hubclusters anzuzeigen:

kubectl describe resourceplacement place-cmap-1

kubectl describe clusterresourceplacement 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

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-with-status-reporting
spec:
  statusReportingScope: NamespaceAccessible
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll

kubectl describe clusterresourceplacementstatuses.v1beta1.placement.kubernetes-fleet.io crp-with-status-reporting -n my-app

Platzierungsänderungstrigger

Der Scheduler des Fleet Manager priorisiert die Stabilität der Platzierung vorhandener Ressourcen. Diese Priorität beschränkt die Anzahl der Änderungen, die eine Ressource entfernen und neu planen.

Die folgenden Szenarien können Platzierungsänderungen auslösen:

• Platzierungsrichtlinienänderungen in der Ressourcenplatzierung (ClusterResourcePlacement oder ResourcePlacement) können das Entfernen und Neuplanen einer Ressource auslösen.
  • Scale-out-Vorgänge (Erhöhen von numberOfClusters ohne sonstige Änderungen) platzieren Workloads ausschließlich auf neuen Clustern und wirken sich nicht auf bestehende Platzierungen aus.
• Mitgliederclusteränderungen, einschließlich:
  • Ein neuer Mitgliedscluster, der geeignet wird und die Platzierungsrichtlinie erfüllt, z. B. eine PickAll-Richtlinie.
  • Entfernung eines Mitgliedsclusters aus der Flotte. Je nach Richtlinie versucht der Scheduler, alle betroffenen Ressourcen auf verbleibenden Clustern zu platzieren, ohne vorhandene Platzierungen zu beeinträchtigen.

Das Aktualisieren der ausgewählten Ressourcen (z. B. das Ändern eines Deployment) oder das Aktualisieren der resourceSelector in einer Ressourcenplatzierung bewirkt, dass Fleet Manager vorhandene Platzierungen schrittweise ausrollt, löst aber keine Neuplanung (d. h. ein Wechseln der ausgewählten Cluster) der Ressource aus.

Zusammenarbeit mit ResourcePlacement und ClusterResourcePlacement

Dabei ClusterResourcePlacement wird davon ausgegangen, dass Namespaces Anwendungsgrenzen darstellen, reale Verwendungsmuster sind häufig komplexer. Organisationen verwenden häufig Namespaces als Teamgrenzen und nicht als Anwendungsgrenzen, was zu mehreren Herausforderungen führt, die ResourcePlacement direkt behandelt werden:

Namespaces mit mehreren Anwendungen: In vielen Organisationen enthält ein einzelner Namespace mehrere unabhängige Anwendungen im Besitz desselben Teams. Diese Anwendungen könnten haben:

• Unterschiedliche Lebenszyklusanforderungen (eine Anwendung benötigt möglicherweise häufige Updates, während eine andere stabil bleibt).
• Verschiedene Clusterplatzierungsanforderungen (Entwicklung im Vergleich zu Produktionsanwendungen).
• Unabhängige Skalierung und Ressourcenanforderungen.
• Separate Compliance- oder Governanceanforderungen.

Individuelle Planungsentscheidungen: Viele Workloads, insbesondere KI/ML-Aufträge, erfordern individuelle Planungsentscheidungen:

• KI-Aufträge: Machine Learning-Workloads bestehen häufig aus kurzlebigen, ressourcenintensiven Aufträgen, die basierend auf der Verfügbarkeit von Clusterressourcen, der GPU-Verfügbarkeit oder der Datenlokalität geplant werden müssen.
• Batcharbeitslasten: Verschiedene Batchaufträge innerhalb desselben Namespaces können auf verschiedene Clustertypen basierend auf rechentechnischen Anforderungen ausgerichtet sein.

Vollständige Steuerung des Anwendungsteams: ResourcePlacement Bietet Anwendungsteams die direkte Kontrolle über ihre Ressourcenplatzierung, ohne dass ein Plattformteam eingreifen muss:

• Self-Service-Vorgänge: Teams können ihre eigenen Ressourcenverteilungsstrategien verwalten.
• Unabhängige Bereitstellungszyklen: Verschiedene Anwendungen innerhalb eines Namespaces können unabhängige Rolloutzeitpläne haben.
• Granulare Überschreibungsfunktionen: Teams können Ressourcenkonfigurationen pro Cluster anpassen, ohne dass dies Auswirkungen auf andere Anwendungen im Namespace hat.

Dieser granulare Ansatz stellt sicher, dass ResourcePlacement sich an verschiedene Organisationsstrukturen und Arbeitsauslastungsmuster anpassen kann, während die Einfachheit und Leistungsfähigkeit des Fleet-Scheduling-Frameworks erhalten bleibt.

Wichtige Unterschiede zwischen ResourcePlacement und ClusterResourcePlacement

Die folgende Tabelle hebt die wichtigsten Unterschiede zwischen ResourcePlacement und ClusterResourcePlacement hervor.

Sowohl ResourcePlacement als auch ClusterResourcePlacement teilen die gleichen Kernfunktionen in Bezug auf alle anderen Aspekte, die nicht in der Unterschiedstabelle aufgeführt sind.

Beispielszenario mit ResourcePlacement und ClusterResourcePlacement

ResourcePlacement arbeitet mit ClusterResourcePlacement (CRP) zusammen, um eine vollständige Multicluster-Ressourcenverwaltungslösung bereitzustellen. Das Verständnis dieser Beziehung ist entscheidend für ein effektives Flottenmanagement.

Typischer Workflow:

1. Plattformadministratoren: Verwenden Sie ClusterResourcePlacement, um Namespaces in der gesamten Flotte bereitzustellen.
2. Anwendungsteams: Verwenden Sie ResourcePlacement, um bestimmte Ressourcen innerhalb dieser eingerichteten Namespaces zu verwalten.

Die folgenden Beispiele zeigen, wie CRP und RP koordiniert werden.

Plattformadministrator: Erstellen Sie den Namespace mithilfe von ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: app-namespace-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
  policy:
    placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.

Anwendungsteam: Verwalten bestimmter Ressourcen innerhalb des Namespace mithilfe von ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Bewährte Praktiken für ResourcePlacement und ClusterResourcePlacement

Wenn Sie ResourcePlacement mit ClusterResourcePlacement verwenden, beachten Sie die folgenden bewährten Vorgehensweisen:

• Richten Sie zuerst Namespaces ein: Stellen Sie vor dem Erstellen von ResourcePlacement Objekten immer Namespaces über CRP bereit.
• Überwachen von Abhängigkeiten: Verwenden Sie die Flottenüberwachung, um sicherzustellen, dass CRPs auf Namespaceebene gesund sind, bevor abhängige RPs bereitgestellt werden.
• Richtlinien koordinieren: Richten Sie die CRP- und RP-Platzierungsrichtlinien aufeinander aus, um Konflikte zu vermeiden. Wenn Z. B. CRP den Namespace auf Cluster A, B und C platziert, kann RP eine beliebige Teilmenge dieser Cluster als Ziel festlegen.
• Teamgrenzen: Verwenden Sie CRP für plattformverwaltete Ressourcen (Namespaces, RBAC) und RP für anwendungsverwaltete Ressourcen (App-Konfigurationen, geheime Schlüssel).

Durch diesen koordinierten Ansatz wird sichergestellt, dass ResourcePlacement die Flexibilität bietet, die Teams benötigen, während die grundlegende Infrastruktur, die von Plattformbetreibern verwaltet wird, beibehalten wird.

Ressourcenauswahl, Platzierung und Rollout

ResourcePlacement verwendet die gleichen Platzierungsmuster wie ClusterResourcePlacement:

• Platzierungsrichtlinie: PickAll, PickFixedund PickN Richtlinien funktionieren für beide APIs identisch.
• Rolloutstrategie: Steuern Sie, wie Updates sich über Cluster ausbreiten, mit denselben rollenden Update-Mechanismen.
• Status und Beobachtbarkeit: Überwachen Sie den Bereitstellungsfortschritt mithilfe von kubectl describe resourceplacement <name> -n <namespace>.
• Erweiterte Features: Verwendung von Tolerationen, Ressourcenüberschreibungen, Topologie-Spreadeinschränkungen und Affinitätsregeln.

Der Hauptunterschied liegt im Ressourcenauswahlbereich . Während ClusterResourcePlacement typischerweise ganze Namespaces und deren Inhalte auswählt, bietet ResourcePlacement eine differenzierte Kontrolle über einzelne ressourcenbezogene Namespaces.

:::zone-end

Nächste Schritte

• Verwenden Sie die Ressourcenplatzierung von Fleet Manager, um Workloads in mehreren Clustern bereitzustellen.
• Verwenden von ResourcePlacement zum Bereitstellen von Namespace-bezogenen Ressourcen.
• Intelligente clusterübergreifende Platzierung von Kubernetes-Ressourcen basierend auf den Eigenschaften der Mitgliedscluster.
• Steuerung von Verdrängung und Störung bei der Ressourcenplatzierung.
• Definition einer Rolloutstrategie für eine Ressourcenplatzierung.
• Häufig gestellte Fragen zur Ressourcenplatzierung des Flottenmanagers.