Freigeben über

Verwenden von ResourcePlacement zum Bereitstellen von ressourcen, die auf einen Namespace beschränkt sind (Vorschau)

In diesem Artikel wird die ResourcePlacement API beschrieben, die eine differenzierte Kontrolle über Namespace-bezogene Kubernetes-Ressourcen über Membercluster mithilfe von Azure Kubernetes Fleet Manager ermöglicht.

Von Bedeutung

Azure Kubernetes Fleet Manager Preview-Features sind auf Self-Service-, Opt-In-Basis verfügbar. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. Azure Kubernetes Fleet Manager Previews werden teilweise vom Kundensupport auf Best-Effort-Basis abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen.

Überblick

ResourcePlacement ist eine namespacebezogene API, die die dynamische Auswahl und die Multiclusterverteilung von Namespace-bezogenen Ressourcen ermöglicht. Es bietet eine differenzierte Kontrolle darüber, wie bestimmte Ressourcen in einem Namespace über Membercluster in einer Flotte verteilt werden.

Von Bedeutung

ResourcePlacement verwendet die placement.kubernetes-fleet.io/v1beta1-API-Version und befindet sich derzeit in der Vorschau. Einige in diesem Artikel gezeigte Funktionen, wie z. B. selectionScope in ClusterResourcePlacement, sind auch Teil der v1beta1-API und in der v1-API nicht verfügbar.

Wichtige Merkmale:

  • Namespacebereich: Sowohl das ResourcePlacement Objekt als auch die von ihm verwalteten Ressourcen sind innerhalb desselben Namespaces vorhanden.
  • Selektiv: Kann bestimmte Ressourcen nach Typ, Name oder Bezeichnung anstelle vollständiger Namespaces ausrichten.
  • Deklarativ: Verwendet die gleichen Platzierungsmuster wie ClusterResourcePlacement für ein konsistentes Verhalten.

A ResourcePlacement besteht aus drei Kernkomponenten:

  • Ressourcenauswahl: Definieren Sie, welche namespacebezogenen Ressourcen einbezogen werden sollen.
  • Platzierungsrichtlinie: Bestimmen Sie Zielcluster mithilfe der Strategien PickAll, PickFixed oder PickN.
  • Rolloutstrategie: Steuern, wie Änderungen über ausgewählte Cluster verteilt werden.

Gründe für die Verwendung von ResourcePlacement

ResourcePlacement eignet sich ideal für Szenarien, die eine präzise Kontrolle über namespacebezogene Ressourcen erfordern:

  • Selektive Ressourcenverteilung: Bereitstellen bestimmter ConfigMaps, Geheimer Schlüssel oder Dienste ohne Auswirkungen auf den gesamten Namespace.
  • Umgebungen mit mehreren Mandanten: Zulassen, dass verschiedene Teams ihre Ressourcen unabhängig innerhalb freigegebener Namespaces verwalten können.
  • Konfigurationsverwaltung: Verteilen von umgebungsspezifischen Konfigurationen in verschiedenen Clusterumgebungen.
  • Compliance und Governance: Wenden Sie unterschiedliche Richtlinien auf verschiedene Ressourcentypen innerhalb desselben Namensraums an.
  • Progressive Rollouts: Sichere Bereitstellung von Ressourcenupdates über Cluster hinweg mit Zero-Downtime-Strategien.

In Multiclusterumgebungen bestehen Workloads häufig aus clusterbezogenen und namespacebezogenen Ressourcen, die über verschiedene Cluster verteilt werden müssen. Während ClusterResourcePlacement (CRP) clusterweite Ressourcen effektiv, ganze Namespaces und deren Inhalte verarbeitet, gibt es Szenarien, in denen Sie präzisere Kontrolle über Namespace-bezogene Ressourcen innerhalb vorhandener Namespaces benötigen.

ResourcePlacement (RP) wurde entworfen, um diese Lücke zu schließen, indem Folgendes bereitgestellt wird:

  • Namespaceweite Ressourcenverwaltung: Zielspezifische Ressourcen innerhalb eines Namespaces, ohne dass sich dies auf den gesamten Namespace auswirkt.
  • Betriebsflexibilität: Teams können verschiedene Ressourcen innerhalb desselben Namespace unabhängig voneinander verwalten.
  • Ergänzende Funktionalität: Arbeiten Sie mit CRP zusammen, um eine vollständige Multicluster-Ressourcenverwaltungslösung bereitzustellen.

Hinweis

ResourcePlacement kann zusammen mit ClusterResourcePlacement im reinen Namespace-Modus verwendet werden. Sie können z. B. CRP verwenden, um den Namespace bereitzustellen, während Sie RP für eine differenzierte Verwaltung bestimmter Ressourcen wie umgebungsspezifische ConfigMaps oder Secrets innerhalb dieses Namespaces verwenden.

Verwendungsmuster für den realen Namespace

Während CRP davon ausgeht, dass Namespaces Anwendungsgrenzen darstellen, sind reale Verwendungsmuster oft 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.

Aspekt ResourcePlacement (RP) ClusterResourcePlacement (CRP)
Scope Nur auf Namespace-Ebene verfügbare Ressourcen Clusterweite Ressourcen (insbesondere Namespaces und deren Inhalt)
Ressource API-Objekt im Namespace-Bereich Clusterbereichs-API-Objekt
Auswahlgrenze Beschränkt auf Ressourcen innerhalb desselben Namespaces wie das RP Kann eine beliebige clusterweite Ressource auswählen
Typische Anwendungsfälle AI/ML-Aufträge, einzelne Workloads, spezifische ConfigMaps/Secrets, die unabhängige Platzierungsentscheidungen benötigen Anwendungsbundle, ganze Namespaces, clusterweite Richtlinien
Teamverantwortung Kann von Namespacebesitzern/Entwicklern verwaltet werden In der Regel von Plattformoperatoren verwaltet

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

Arbeiten mit ClusterResourcePlacement

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

Voraussetzungen für Namespaces

Von Bedeutung

ResourcePlacement kann namespacenbezogene Ressourcen nur in Clustern platzieren, die bereits über den Ziel-Namespace verfügen. Wir empfehlen die Verwendung von ClusterResourcePlacement für die Namespace-Einrichtung.

Typischer Workflow:

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

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

Hinweis

In den folgenden Beispielen wird die placement.kubernetes-fleet.io/v1beta1 API-Version verwendet. Das selectionScope: NamespaceOnly Feld ist ein Vorschaufeature, das in v1beta1 verfügbar ist und in der v1-API nicht verfügbar ist.

Plattformadministrator: Erstellen Sie zuerst den Namespace mithilfe von ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1beta1
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 Sie dann bestimmte Ressourcen im Namespace mithilfe von ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1beta1
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 Methoden

Befolgen Sie bei Verwendung von ResourcePlacement mit ClusterResourcePlacement, die folgenden bewährten Methoden:

  • Richten Sie zunächst Namespaces ein: Stellen Sie immer sicher, dass Namespaces über CRP bereitgestellt werden, bevor Sie Objekte erstellen ResourcePlacement .
  • Ü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: CRP- und RP-Platzierungsrichtlinien anpassen, um Konflikte zu vermeiden (z. B. wenn CRP Namespaces auf den Clustern A, B, C platziert, kann RP auf eine beliebige Teilmenge dieser Cluster abzielen).
  • 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:

  • Platzierungstypen: PickAll, PickFixedund PickN Strategien funktionieren für beide APIs identisch.
  • Rolloutstrategie: Steuern Sie, wie Updates sich über Cluster ausbreiten, mit denselben rollenden Update-Mechanismen.
  • Status und Observability: Ü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.

Ausführliche Informationen zu diesen Funktionen finden Sie in der ClusterResourcePlacement-Dokumentation.

Nächste Schritte

  • Last updated on