Übersicht über den Fleet Manager-Hubcluster

Wenn diese Option aktiviert ist, dient der Fleet Manager-Hubcluster als zentraler Verwaltungspunkt für die Kubernetes-Ressourcenverteilung über Mitgliedscluster mithilfe der Ressourcenplatzierung.

Was sind Flottenmanager-Hubcluster?

In Azure Kubernetes Fleet Manager spielen Hubcluster eine entscheidende Rolle beim Verwalten mehrerer Mitgliedscluster, aber sie sind optional.

Der Hub-Cluster erleichtert die Platzierung von Ressourcen und die verwalteten Namespaces der Flotte über eine verwaltete Version von KubeFleet.

In dieser Konfiguration besteht eine Flotte aus den folgenden Komponenten:

Ein Diagramm der Flottenressource, wenn sie mit einem Hubcluster konfiguriert ist, einschließlich des Hubcluster-Agents und des Mitgliedscluster-Agents.

  • Flottenhub-Agent: Ein Kubernetes-Controller, der alle flottenbezogenen benutzerdefinierten Ressourcen (CRs) im Hubcluster erstellt und miteinander in Einklang bringt.
  • Flottenmitglied-Agent: Ein Kubernetes-Controller, der alle flottenbezogenen CRs in den Mitgliedsclustern erstellt und miteinander in Einklang bringt. Dieser Controller ruft die neuesten CRs aus dem Hubcluster ab und synchronisiert die Mietgliedcluster konsistent mit dem gewünschten Zustand.

Hubclusterkonfiguration

Ein Fleet Manager-Hubcluster ist ein vollständig verwalteter Azure Kubernetes Service (AKS)-Cluster mit den folgenden Eigenschaften:

  • Clustername und Standort: Der Hubcluster wird immer benannt hub und in derselben Azure-Region wie der Fleet Manager erstellt.
  • Azure-Ressourcengruppe für Hubcluster: Die Hubcluster-AKS-Ressource wird in einer verwalteten Ressourcengruppe mit dem Benennungsformat FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}erstellt.
  • Azure-Ressourcengruppe für Hubclusterressourcen: Wie jeder AKS-Cluster verfügt der Hubcluster über Azure-Ressourcen wie einen VM-Skalierungssatz für einen Agentknotenpool und ein virtuelles Netzwerk, das in einer verwalteten Ressourcengruppe mit dem Benennungsformat MC_FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}erstellt wird.
  • Hubclusterknoten: Der Hubcluster verfügt über einen Knotenpool mit einem einzelnen Knoten, auf dem Azure Linux ausgeführt wird. Der Knoten führt keine Pods aus und wirkt sich nicht auf die Leistung des Hubclusters aus. Beim Erstellen eines Hubclusters über die Azure CLI können Sie den SKU-Typ des Knotens virtuelle Computer (VM) mithilfe des --vm-size Parameters auswählen.
  • Netzwerkkonfiguration: Öffentliche Hubcluster verfügen über einen öffentlichen API-Server mit einer zugeordneten öffentlichen IP-Adresse. Bei der Konfiguration für den privaten Zugriff ist der API-Server nur über ein virtuelles Azure-Netzwerk zugänglich.

Hubclustereinschränkungen

Der Hubcluster verfügt über die folgenden Einschränkungen, die sicherstellen, dass er für die Ressourcenverteilung und -verwaltung wie erforderlich funktioniert:

  • Befehlsaufruf deaktiviert: Die Verwendung des Befehlsaufrufs über die Azure CLI (az aks command invoke) ist für Hubcluster deaktiviert.
  • Lokale Authentifizierung deaktiviert: Der Zugriff über den Administrator kubeconfig ist deaktiviert, wodurch sichergestellt wird, dass die Authentifizierung ausschließlich über die Microsoft Entra-ID verarbeitet wird und die Sicherheit durch zentrale Zugriffssteuerung verbessert wird. Verwenden Sie az fleet get-credentials, um die kubeconfig für den Hub-Cluster zu erhalten.
  • Zuordnungen verweigern: Änderungen an der Azure-Konfiguration des Hubclusters und der zugehörigen Ressourcen werden über Azure Deny Assignments blockiert. Die folgenden Verweigerungszuweisungen werden verwendet:
    • Wird auf die Hubcluster-Ressourcengruppe angewendet, wodurch Benutzer daran gehindert werden, den Hubcluster zu ändern.
    • kubernetes.azure.com/{guid} (optional): Diese Ablehnungszuweisung verhindert, dass Benutzer die Hub-Cluster-AKS-Ressourcen (Virtual Machine Scale Sets, Netzwerke) ändern, wie in Sperrung der AKS-Knotenressourcengruppe beschrieben ist.
  • Angewendete Ressourcen werden nicht instanziiert: Der Hubcluster plant keine angewendeten Kubernetes-Ressourcen auf den Hubclusterknoten. Einige Kubernetes-Ressourcen müssen mithilfe eines Umschlagobjekts angewendet werden, um Nebeneffekte auf dem Hubcluster zu vermeiden. Weitere Informationen zu Umschlagobjekten finden Sie in der Dokumentation von Envelope Objects.

Einschränkungen für den Zugriff auf geschützte Ressourcen

Important

Ab dem 31. Januar 2027 verweigern Fleet Manager-Hubcluster den Zugriff auf geschützte vom Dienst verwaltete Ressourcen und privilegierte Schnittstellen. Diese Einschränkungen gelten zusätzlich zu der rollenbasierten Zugriffssteuerung in Azure (Azure RBAC). Eine Azure Rollenzuweisung, die zuvor eine Anfrage zugelassen hat, überschreibt diese Einschränkungen nicht.

Die folgenden Kubernetes-API-Anfragen werden verweigert:

  • Alle Anfragen zur Identitätsimitation.
  • Alle anderen Vorgänge als get, list und watch in Namespaces mit Namen, die mit fleet- oder kube- beginnen.
  • get, list und watch Anforderungen für Pods, Secrets, Dienstkonten, Rollen und Rollenbindungen in Namespaces mit Namen, die mit fleet- oder kube- beginnen.
  • Namespaceübergreifende list und watch Anfragen für Pods, Secrets, Dienstkonten, Rollen und Rollenbindungen.
  • Schreiben Sie Anfragen für Clusterrollen und Clusterrollenbindungen.
  • Lese- und Schreibanforderungen an die nodes/proxy Unterressource.
  • Schreibanforderungen für die Überprüfung von Zulassungsrichtlinien, die Überprüfung von Zulassungsrichtlinienbindungen und die Überprüfung von Webhook-Konfigurationen mit Namen, die mit dem Präfix fleet-builtin- beginnen.
  • Anforderungen zum Löschen von Sammlungen zum Validieren von Zulassungsrichtlinien, zum Validieren von Bindungen für Zulassungsrichtlinien und zum Validieren von Webhook-Konfigurationen.

Andere unterstützte Vorgänge in vom Kunden verwalteten Namespaces bleiben verfügbar.

Identifizieren von betroffenen Fleet Manager-Ressourcen und Automatisierung

Eine Flotten-Manager-Ressource ist potenziell betroffen, wenn der Hub-Cluster für diese Ressource aktiviert ist. Verwenden Sie Azure Resource Graph Explorer, um diese Ressourcen zu finden:

Resources
| where type =~ "microsoft.containerservice/fleets"
| where isnotnull(properties.hubProfile)
| project id, name, subscriptionId, resourceGroup, location

Das Vorhandensein eines Hubclusters bedeutet nicht unbedingt, dass Sie Maßnahmen ergreifen müssen. Sie sind nur betroffen, wenn Ihre Benutzer, Skripts, Controller oder CI/CD-Pipelines eine der eingeschränkten Anfragen an den Hubcluster senden.

Überprüfen Sie die Automatisierung, die auf den Hub-Cluster zugreift:

  • Optionen oder Header für Identitätsübernahme, einschließlich --as und --as-group.
  • Anfragen an nodes/proxy.
  • Zugriff auf Namespaces mit Namen, die mit fleet- oder kube- beginnen.
  • Clusterweite oder --all-namespaces List- und Watch-Anfragen für geschützte Ressourcen.
  • Änderungen an Clusterrollen oder Clusterrollenbindungen.
  • Änderungen an Überprüfungsressourcen mit Namen, die mit fleet-builtin- beginnen.
  • Löschen der Sammlung von Validierungsressourcen.

Aktualisierung der betroffenen Automatisierung

Vor dem 31. Januar 2027:

  • Verschieben Sie kundeneigene Ressourcen und Automatisierung aus Namespaces mit Namen, die mit fleet- oder kube- beginnen.
  • Listen- und Watch-Anfragen für Pods, Secrets, Dienstkonten, Rollen und Rollenbindungen auf vom Kunden verwaltete Namespaces begrenzen.
  • Für die Ressourcenplatzierung schließen Sie Clusterrollen und Clusterrollenbindungen in ein ClusterResourceEnvelope ein. Weitere Informationen finden Sie unter Umschlagobjekte verwenden, um Ressourcen sicher zu platzieren.
  • Verwenden Sie für den programmgesteuerten Zugriff auf den Hubcluster eine dedizierte Microsoft Entra-Identität, weisen Sie ihr die Fleet Manager-RBAC-Rolle mit den geringsten erforderlichen Berechtigungen zu, und verwenden Sie keine Identitätsvortäuschung.
  • Verwenden Sie die nodes/proxy Unterressource nicht mehr.
  • Ändern Sie keine Überprüfungsressourcen, deren Namen mit fleet-builtin- beginnen.
  • Ersetzen Sie das Löschen von Überprüfungsressourcen durch Anfragen, die auf kundenseitig verwaltete Ressourcen beschränkt sind.
  • Testen Sie die aktualisierte Automatisierung vor dem Durchsetzungsdatum.

Wenn Sie die betroffene Automatisierung vor dem 31. Januar 2027 nicht aktualisieren, erhalten die eingeschränkten Anfragen Antworten mit „Autorisierung verweigert“. Skripts, Controller, Bereitstellungen oder operative Workflows, die von diesen Anfragen abhängen, können fehlschlagen oder es wiederholt versuchen. Wenn Sie keine eingeschränkten Vorgänge verwenden, ist keine Aktion erforderlich.

Kundenseitige Anforderungen

Damit der Fleet Manager Hub-Cluster mit den aktuellen Patches erstellen und auf dem neuesten Stand halten kann, stellen Sie Folgendes sicher:

  • Die Azure-Richtlinie blockiert die Clustererstellung nicht. Der Hub-Cluster ist ein verwalteter AKS-Cluster. Wenn Sie keine AKS-Cluster erstellen können, können Sie keinen Fleet Manager-Hubcluster erstellen.

  • Das Abonnement verfügt über ein ausreichendes Kontingent. Während des Clusterupgrades ist eine zusätzliche VM-Instanz des Hub-Cluster-Knotens erforderlich. Weitere Informationen zum Erhöhen des Kontingents finden Sie in der Dokumentation zu Kontingenten.

  • Hubcluster verfügt über Internetzugriff. Für die Installation von Updates ist ausgehende Konnektivität erforderlich. Private Hubs in Netzwerken mit benutzerdefiniertem Routing (UDR) oder Firewallregeln blockieren möglicherweise ausgehende Verbindungen. Weitere Informationen zur ausgehenden Konnektivität finden Sie in der Dokumentation zur ausgehendem Netzwerkkonnektivität in AKS.

  • Es ist nicht erforderlich, Updates für den Fleet Manager-Hubcluster zu verwalten. Microsoft aktualisiert den Hubcluster automatisch auf die neueste Version von Kubernetes oder Knotenimage, sobald sie von AKS verfügbar werden. Updateversionen können auf der AKS Release Tracker nachverfolgt werden.

Verwandte Inhalte

  • Zuletzt aktualisiert um