Panoramica del cluster hub di Gestione flotta

Se abilitato, il cluster hub Gestione flotta funge da punto di gestione centrale per la propagazione delle risorse Kubernetes tra cluster membri usando il posizionamento delle risorse.

Che cosa sono i cluster hub di Fleet Manager?

In Azure Kubernetes Fleet Manager i cluster hub svolgono un ruolo fondamentale nella gestione di più cluster membri, ma sono facoltativi.

Il cluster hub facilita l'allocazione delle risorse e i namespace gestiti dalla flotta tramite una versione gestita di KubeFleet.

In questa configurazione, una flotta è costituita dai componenti seguenti:

• fleet-hub-agent: è un controller Kubernetes che crea e riconcilia tutte le risorse personalizzate correlate alla flotta nel cluster hub.
• fleet-member-agent: è un controller Kubernetes che crea e riconcilia tutte le risorse personalizzate correlate alla flotta nei cluster membri. Questo controller esegue il pull delle risorse personalizzate più recenti dal cluster hub e riconcilia in modo coerente i cluster membri in modo che corrispondano allo stato desiderato.

Configurazione del cluster hub

Un cluster hub di Gestione flotta è un cluster del servizio Azure Kubernetes completamente gestito con le proprietà seguenti:

• Nome e posizione del cluster: il cluster hub viene sempre denominato hub e viene creato nella stessa area di Azure di Gestione flotta.
• Gruppo di risorse di Azure per il cluster hub: la risorsa del cluster hub del servizio Azure Kubernetes viene creata in un gruppo di risorse gestite con il formato di denominazione FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}.
• Gruppo di risorse di Azure per le risorse del cluster hub: come qualsiasi cluster del servizio Azure Kubernetes, il cluster hub include risorse di Azure, ad esempio un set di scalabilità di macchine virtuali del pool di nodi agente e una rete virtuale creati in un gruppo di risorse gestite con il formato di denominazione MC_FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}.
• Nodo del cluster hub: il cluster hub ha un pool di nodi con un singolo nodo che esegue Azure Linux. Il nodo non esegue pod e non influisce sulle prestazioni del cluster hub. Quando si crea un cluster hub dall'interfaccia della riga di comando di Azure, è possibile scegliere il tipo di SKU della macchina virtuale del nodo usando il parametro --vm-size.
• Configurazione di rete: i cluster dell'hub pubblico hanno un server API pubblico, con un indirizzo IP pubblico associato. Se configurato per l'accesso privato, il server API è accessibile solo tramite una rete virtuale di Azure.

Restrizioni del cluster hub

Il cluster hub presenta le restrizioni seguenti che assicurano che funzioni come necessario per la propagazione e la gestione delle risorse:

• Chiamata di comando disabilitata: l'uso della chiamata di comando tramite l'interfaccia della riga di comando di Azure (az aks command invoke) è disabilitato per i cluster hub.
• Autenticazione locale disabilitata: l'accesso tramite amministratore kubeconfig è disabilitato per assicurare che l'autenticazione venga gestita esclusivamente tramite Microsoft Entra ID, migliorando la sicurezza attraverso la centralizzazione del controllo di accesso. Usare az fleet get-credentials per ottenere il kubeconfig per il cluster hub.
• Assegnazioni di rifiuto: le modifiche apportate alla configurazione di Azure del cluster hub e alle risorse associate vengono bloccate tramite assegnazioni di rifiuto di Azure. Vengono usate le assegnazioni di rifiuto seguenti:
  • FLRG-DenyAssignments-{guid}: applicato al gruppo di risorse del cluster hub per impedire agli utenti di modificare il cluster hub.
  • kubernetes.azure.com/{guid} (facoltativo): questa assegnazione di rifiuto impedisce agli utenti di modificare le risorse del servizio Azure Kubernetes del cluster hub (set di scalabilità di macchine virtuali, reti), come descritto in Blocco del gruppo di risorse del nodo del servizio Azure Kubernetes.
• Risorse applicate non create con un'istanza: il cluster hub non pianifica le risorse Kubernetes applicate al nodo del cluster hub. Alcune risorse Kubernetes devono essere applicate usando un oggetto envelope per evitare effetti collaterali nel cluster hub. Per altre informazioni sugli oggetti envelope, vedere la documentazione relativa agli oggetti Envelope.

Restrizioni di accesso alle risorse protette

Le richieste API Kubernetes seguenti vengono negate:

• Tutte le richieste di impersonificazione dell'identità.
• Tutte le operazioni diverse da get, liste watch negli spazi dei nomi con nomi che iniziano con fleet- o kube-.
• get, liste watch le richieste per pod, segreti, account del servizio, ruoli e associazioni di ruolo negli spazi dei nomi con nomi che iniziano con fleet- o kube-.
• Cross-namespace list and watch requests for pods, secrets, service accounts, roles, and role bindings.
• Richieste di scrittura per i ruoli del cluster e le associazioni dei ruoli del cluster.
• Richieste di lettura e scrittura per la sottorisorsa nodes/proxy.
• Scrivere richieste per convalidare i criteri di ammissione, le associazioni dei criteri di ammissione e le configurazioni webhook con nomi che iniziano con fleet-builtin-.
• Richieste di eliminazione di raccolte per i criteri di ammissione con convalida, le associazioni dei criteri di ammissione con convalida e le configurazioni dei webhook di convalida.

Altre operazioni supportate negli spazi dei nomi gestiti dal cliente rimangono disponibili.

Identificare le risorse e l'automazione di Fleet Manager interessate

Una risorsa Fleet Manager è potenzialmente interessata se dispone di un cluster hub abilitato. Usare Azure Resource Graph Explorer per trovare queste risorse:

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

La presenza di un cluster hub non significa necessariamente che sia necessario intervenire. Il problema riguarda solo i casi in cui utenti, script, controller o pipeline CI/CD inviano una delle richieste soggette a restrizioni al cluster hub.

Esaminare l'automazione che accede al cluster hub per:

• Opzioni o intestazioni di impersonificazione, inclusi --as e --as-group.
• Richieste a nodes/proxy.
• Accesso ai namespace con nomi che iniziano con fleet- o kube-.
• Richieste di elenco e monitoraggio a livello di cluster o con --all-namespaces per le risorse protette.
• Modifiche ai ruoli del cluster o alle associazioni di ruoli del cluster.
• Modifiche alle risorse di convalida con nomi che iniziano con fleet-builtin-.
• Eliminazione di raccolte di risorse di convalida.

Aggiornare l'automazione interessata

Prima del 31 gennaio 2027:

• Spostare le risorse di proprietà del cliente e l'automazione fuori dai namespace con nomi che iniziano con fleet- o kube-.
• Limitare le richieste di elenco e monitoraggio di pod, segreti, account di servizio, ruoli e associazioni di ruoli agli spazi dei nomi gestiti dal cliente.
• Per il posizionamento delle risorse, racchiudere i ruoli del cluster e le associazioni dei ruoli del cluster in un ClusterResourceEnvelope. Per altre informazioni, vedere Usare oggetti envelope per posizionare le risorse in modo sicuro.
• Per l'accesso programmatico al cluster hub, utilizzare un'identità Microsoft Entra dedicata, assegnarle il ruolo RBAC Fleet Manager con i privilegi minimi necessari ed evitare l'impersonificazione dell'identità.
• Interrompi l'uso della nodes/proxy sottorisorsa.
• Non modificare le risorse di convalida con nomi che iniziano con fleet-builtin-.
• Sostituire le richieste di eliminazione di raccolte di risorse di convalida con richieste limitate alle risorse gestite dal cliente.
• Testa l'automazione aggiornata prima della data di entrata in vigore.

Se non si aggiorna l'automazione interessata entro il 31 gennaio 2027, le relative richieste soggette a restrizioni riceveranno risposte di autorizzazione negata. Gli script, i controller, le distribuzioni o i flussi di lavoro operativi che dipendono da tali richieste potrebbero non funzionare o riprovare ripetutamente. Se non si usano operazioni con restrizioni, non è necessaria alcuna azione.

Requisiti dei clienti

Per consentire a Fleet Manager di creare e mantenere i cluster hub up-to-date con le patch più recenti, assicurarsi che:

• Azure Policy non blocca la creazione di un cluster. Il cluster hub è un cluster AKS gestito. Se non puoi creare cluster AKS, non puoi creare un cluster hub di Fleet Manager.

• La sottoscrizione ha una quota sufficiente. Durante il processo di aggiornamento del nodo del cluster hub è necessaria un'istanza aggiuntiva di VM. Per altre informazioni sull'aumento della quota, vedere la documentazione sulla quota.

• Il cluster hub ha accesso a Internet. Per installare gli aggiornamenti, è necessaria la connettività in uscita. Gli hub privati nelle reti con route definite dall'utente o regole del firewall potrebbero bloccare la connettività in uscita. Per altre informazioni sulla connettività in uscita, vedere la documentazione sulla rete in uscita del servizio Azure Kubernetes.

• Non è necessario gestire gli aggiornamenti per il cluster hub di Gestione flotta. Microsoft aggiorna automaticamente il cluster hub alla versione più recente di Kubernetes o all'immagine del nodo quando diventano disponibili dal servizio Azure Kubernetes. Le versioni di aggiornamento possono essere rilevate nel rilevatore di versioni del servizio Azure Kubernetes.

Contenuti correlati

• Posizionamento intelligente delle risorse Kubernetes tra cluster in base alle proprietà dei cluster membri.
• Accedere all'API Kubernetes del cluster hub di Fleet Manager.
• Domande frequenti su Gestione flotta.