Domande frequenti - Gestione flotta Kubernetes di Azure

Si applica a: ✔️ Fleet Manager ✔️ Fleet Manager con cluster hub

Questo articolo illustra le domande frequenti su Gestione flotta Kubernetes di Azure.

Domande frequenti sul servizio Fleet Manager

Fleet Manager è una risorsa regionale o globale?

Fleet Manager è una risorsa a livello di area. Il supporto per il failover a livello di area per i casi d'uso del ripristino di emergenza è nella roadmap.

Quanti cluster è possibile aggiungere a Fleet Manager?

Fleet Manager (con o senza un cluster hub) supporta l'aggiunta di un massimo di 1.000 cluster Kubernetes. I cluster membri possono essere una combinazione di Servizio Azure Kubernetes e Kubernetes abilitato per Arc.

Se si vuole che Fleet Manager supporti più di 1.000 cluster, aggiungere commenti e suggerimenti.

Quali cluster Kubernetes è possibile aggiungere come membri?

Fleet Manager consente agli utenti autorizzati di aggiungere qualsiasi cluster AKS, AKS Automatic o Kubernetes abilitato per Arc in qualsiasi sottoscrizione e regione di Azure, purché la sottoscrizione di Azure sia associata allo stesso tenant Microsoft Entra ID del Fleet Manager.

Fleet Manager supporta le identità gestite?

Sì, Fleet Manager supporta sia le identità gestite assegnate dal sistema che quelle assegnate dall'utente. Per altre informazioni, vedere la documentazione sull’utilizzo di identità gestite con Fleet Manager.

Cosa accade quando si modifica l'identità del cluster di un cluster aggiunto?

La modifica dell'identità di un cluster membro interrompe la comunicazione tra Fleet Manager e il cluster membro. Mentre l'agente membro usa la nuova identità per comunicare con Fleet Manager, Fleet Manager deve comunque essere consapevole della nuova identità. Eseguire questo comando per risolvere:

az fleet member create \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${MEMBER_NAME} \
    --member-cluster-id ${MEMBER_CLUSTER_ID}

Relazione con Kubernetes abilitato per Azure Arc

Fleet Manager supporta sia i cluster AKS ospitati in Azure sia i cluster Kubernetes abilitati per Azure Arc come cluster membri.

Relazione con i cluster del servizio Azure Kubernetes

Il servizio Azure Kubernetes semplifica la distribuzione di un cluster Kubernetes gestito in Azure tramite l'offload del sovraccarico operativo in Azure. Come servizio Kubernetes ospitato, Azure gestisce attività critiche quali il monitoraggio dell'integrità e la manutenzione. Poiché il piano di controllo Kubernetes è gestito da Azure, devi solo mantenere i nodi degli agenti. I carichi di lavoro effettivi vengono eseguiti nei cluster del servizio Azure Kubernetes.

Azure Kubernetes Fleet Manager consente di gestire scenari su larga scala e multi-cluster per i cluster del servizio Azure Kubernetes. Azure Kubernetes Fleet Manager offre una rappresentazione di gruppo per i cluster del servizio Azure Kubernetes e consente agli utenti di orchestrare gli aggiornamenti del cluster, la propagazione delle risorse Kubernetes e il bilanciamento del carico multi-cluster. I carichi di lavoro utente non possono essere eseguiti nel cluster hub di Fleet Manager.

È possibile provisionare nuovi cluster AKS da Fleet Manager?

La creazione e la gestione completa dei nuovi cluster AKS è prevista nella nostra roadmap. Fornisci commenti e suggerimenti se il supporto per la creazione del cluster è uno scenario importante per te.

È necessario gestire gli aggiornamenti per il cluster hub di Fleet Manager?

No. Il cluster hub di Fleet Manager è una risorsa gestita da Microsoft. Microsoft aggiorna automaticamente il cluster hub alla versione più recente di Kubernetes o all'immagine del nodo non appena diventano disponibili.

Se si tenta di aggiornare o modificare il cluster hub (ovvero un cluster del servizio Azure Kubernetes a nodo singolo denominato hub), un set di regole di negazione impedisce l'applicazione delle modifiche.

Perché il cluster hub Fleet Manager è passato da Failed to Running?

Il cluster hub di Fleet Manager è un cluster AKS gestito da Microsoft creato nella tua sottoscrizione. Non è necessario eseguire alcuna azione nel cluster hub.

Se si verifica un problema nel provisioning o nel funzionamento del cluster dell'hub, può entrare nello stato Failed.

Fleet Manager riallinea automaticamente il cluster hub nell'ambito delle normali operazioni periodiche del servizio, che possono portare il cluster hub in uno stato Running.

Quando un cluster hub è Failed non genera alcun costo, ma quando passa a Running si genera un costo.

Aggiornamenti di più cluster - Domande frequenti automatizzate o manuali

Quali cluster supportano gli aggiornamenti multi-cluster?

Quali canali di aggiornamento AKS supporta Fleet Manager?

Fleet Manager supporta i seguenti canali di aggiornamento di AKS:

• Rapido: aggiornamenti per l'ultimo rilascio di Kubernetes supportato da AKS (N).
• Stabile: aggiornamenti per il canale stabile di Kubernetes (N-1) dove "N" è la versione più recente di Kubernetes supportata da AKS.
• NodeImage: VHD dell'immagine del nodo aggiornato con patch (correzioni di bug e sicurezza) con rilascio settimanale.
• TargetKubernetesVersion (patch Kubernetes): aggiorna i cluster alla versione patch più recente della versione di destinazione specificata quando la patch è disponibile. Supporta le versioni secondarie di Kubernetes disponibili solo tramite il servizio Azure Kubernetes Long-Term Support (LTS).
• SecurityPatch (immagini Linux del nodo): aggiornamenti del sistema operativo delle immagini Linux del nodo che forniscono patch di sicurezza gestita da AKS applicate al VHD esistente in uso nel nodo.

Canali AKS attualmente non supportati:

• Non gestito: aggiornamenti del sistema operativo delle immagini dei nodi applicati direttamente tramite il meccanismo di patching integrato del sistema operativo (solo per i nodi Linux). Attualmente non sono previsti piani per Fleet Manager per supportare questa opzione.

La versione secondaria di Kubernetes presente nel mio profilo di aggiornamento automatico non è più supportata dalla community. Cosa posso fare?

È possibile:

• Consentire il supporto a lungo termine (LTS) nel profilo di aggiornamento automatico e abilitarlo per tutti i cluster della flotta che si desidera mantenere sulla versione secondaria specifica. Assicurarsi che solo i cluster LTS siano inclusi nella strategia di aggiornamento usata.
• Aggiornare il profilo di aggiornamento automatico a una nuova versione secondaria di Kubernetes di destinazione. I cluster vengono aggiornati alla patch più recente nella versione secondaria di Kubernetes specificata al rilascio.

Per informazioni sull'abilitazione di LTS nei profili di aggiornamento automatico, vedere Aggiornamenti della versione di Kubernetes di destinazione. Per informazioni sull'abilitazione di LTS nei cluster gestiti, vedere Supporto a lungo termine.

Cosa accade se si lasciano abilitati gli aggiornamenti automatici del cluster del AKS (Azure Kubernetes Service)?

Se si mantiene abilitato l'aggiornamento automatico del cluster AKS, l'aggiornamento viene eseguito da Fleet Manager o dall'aggiornamento automatico del cluster AKS, a seconda di quale dei due viene eseguito per primo.

Fleet Manager non modifica la configurazione delle impostazioni di aggiornamento automatico del cluster AKS.

Se si desidera che Fleet Manager gestisca gli aggiornamenti automatici, disabilitare l'aggiornamento automatico su ogni cluster AKS membro.

Supporto per la finestra di manutenzione del cluster AKS

Una finestra di manutenzione definisce quando un cluster può essere aggiornato in modo sicuro.

Fleet Manager rispetta le impostazioni della finestra di manutenzione per cluster per ogni cluster membro.

Quando si apre una finestra di manutenzione, gli aggiornamenti non vengono avviati immediatamente. I motivi includono:

• Limiti di concorrenza: anche se si apre una finestra di manutenzione, un cluster potrebbe non essere aggiornato a causa delle impostazioni di concorrenza per la strategia.
• Polling regolare: Fleet Manager interroga la presenza di finestre di manutenzione aperte ogni 60 minuti, quindi il tempo di attesa massimo dall'apertura di una finestra è di 60 minuti.

Qual è l'ambito degli aggiornamenti coerenti dell'immagine del nodo?

La coerenza dei nodi è garantita solo per tutti i cluster contenuti in una singola esecuzione di aggiornamento in cui si sceglie l'opzione consistent image .

Non esiste alcuna garanzia di coerenza per le versioni dell'immagine del nodo in esecuzioni di aggiornamento separate.

Come è possibile scoprire quali immagini del nodo sono state usate in un'esecuzione di aggiornamento?

L'esecuzione dell'aggiornamento elenca le immagini del nodo selezionate usate per l'esecuzione. È possibile accedere a queste informazioni anche se l'esecuzione dell'aggiornamento non è stata avviata.

È possibile selezionare più immagini di nodo perché pool di nodi diversi operano in tutti i cluster selezionati per l'aggiornamento.

Per trovare le immagini selezionate, usare questo comando interfaccia della riga di comando di Azure:

az fleet updaterun show \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${UPDATE_RUN_NAME} \
    --query "status.nodeImageSelection.selectedNodeImageVersions"

È anche possibile usare l'opzione View JSON nella pagina Panoramica dell'esecuzione degli aggiornamenti nel portale di Azure per visualizzare i dati non elaborati per un'esecuzione di aggiornamento.

L'esecuzione dell'aggiornamento è in sospeso da molto tempo. Cosa dovrei fare?

Le esecuzioni degli aggiornamenti di Fleet Manager possono essere state sospese per molti motivi. È possibile visualizzare lo stato di un aggiornamento eseguito tramite il portale di Azure oppure seguendo la documentazione sul monitoraggio.

I due motivi più comuni per gli stati in sospeso lunghi sono:

• Finestre di manutenzione del cluster membro: se la finestra di manutenzione di un cluster membro non è aperta, l'esecuzione dell'aggiornamento entra in uno stato sospeso. Questa sospensione blocca il completamento del gruppo o della fase di aggiornamento fino all'apertura della finestra di manutenzione successiva. Per continuare l'esecuzione dell'aggiornamento, saltare manualmente il cluster. Se si ignora il cluster, non è sincronizzato con il resto dei cluster membri nell'esecuzione dell'aggiornamento.

• Versione di Kubernetes o dell'immagine del nodo non disponibile nell'area di Azure: se la nuova versione di Kubernetes o dell'immagine del nodo non viene pubblicata nell'area di Azure in cui si trova un cluster membro, l'esecuzione dell'aggiornamento entra in stato di attesa. È possibile controllare il tracker di rilascio AKS per visualizzare lo stato regionale della versione. Anche se è possibile ignorare il cluster membro, se sono presenti altri cluster nella stessa area Azure non possono essere aggiornati.

L'esecuzione dell'aggiornamento automatico è iniziata, quindi è passata immediatamente in stato di attesa. Perché?

Vedere la domanda precedente.

Si è provato a generare un'esecuzione di aggiornamento dal profilo di aggiornamento automatico, ma non è possibile visualizzare l'esecuzione dell'aggiornamento.

Quando si genera manualmente un'esecuzione di aggiornamento da un profilo di aggiornamento automatico, l'esecuzione dell'aggiornamento risultante potrebbe esistere già.

Questo scenario può verificarsi se il profilo di aggiornamento automatico ha generato automaticamente l'esecuzione dell'aggiornamento o se l'esecuzione dell'aggiornamento è stata generata manualmente in precedenza.

Il nome dell'esecuzione dell'aggiornamento generato si basa sulla specifica di aggiornamento del profilo di aggiornamento automatico che cambia solo quando vengono aggiornate le proprietà, ad esempio l'immagine del nodo o la versione di Kubernetes.

Questo problema si riscontra più comunemente nel portale Azure, dove l'esecuzione di aggiornamento esistente non è quella più recente. Se si riscontra questo problema e non è possibile trovare l'esecuzione di aggiornamento, usare interfaccia della riga di comando di Azure per generare l'esecuzione e visualizzare il nome dell'esecuzione di aggiornamento. Microsoft prevede di risolvere questo problema nel portale di Azure in futuro.

Se si genera un'esecuzione di aggiornamento e ne esiste già una, l'esecuzione di aggiornamento esistente non viene modificata.

La modifica della strategia di aggiornamento non ha modificato le esecuzioni di aggiornamento esistenti che l'hanno usata. Perché no?

Quando si crea un'esecuzione di aggiornamento, la strategia viene copiata nell'esecuzione dell'aggiornamento in modo che le modifiche apportate alla strategia non influiscano sull'esecuzione degli aggiornamenti.

Come si impedisce a un singolo errore del cluster di arrestare l'intera esecuzione dell'aggiornamento?

Usare l'impostazione maxAllowedFailures nelle fasi e nei gruppi della strategia di aggiornamento (disponibile a partire dall'API versione 2026-06-02-preview). Questa impostazione consente di specificare il numero di errori dei cluster membri tollerati prima che il gruppo o la fase vengano considerati non riusciti. I valori possono essere un numero intero fisso (ad esempio, "3") o una percentuale (ad esempio, "25%"). Se non è impostato o è "0", un singolo errore arresta l'intera esecuzione.

Per altre informazioni, vedere Numero massimo di errori consentiti (anteprima).

Perché l'esecuzione dell'aggiornamento o il gruppo risultano come Completati anche se i membri non sono riusciti?

Quando si imposta maxAllowedFailures, Fleet Manager valuta solo il numero di aggiornamenti dei membri non riusciti. Non applica un tasso minimo di successo. Un'esecuzione di aggiornamento, una fase o un gruppo possono quindi terminare Completed anche se alcuni o tutti i membri hanno avuto esito negativo, purché la soglia configurata non venga superata quando Fleet Manager prende decisioni di pianificazione.

Questo risultato è previsto e intenzionale, non un bug. Controllare sempre FailureCount, gli stati a livello di membro e le cause dell'errore prima di considerare l'implementazione come integra. Per la maggior parte delle strategie di aggiornamento, le soglie basate su percentuale sono più facili da ragionare rispetto ai valori assoluti.

Quali regole e limitazioni è necessario conoscere quando si usa maxAllowedFailures?

Tenere presenti le regole seguenti:

• La funzionalità è disponibile a partire dall'API versione 2026-06-02-preview.
• Quando si deseleziona maxAllowedFailures o lo si imposta su "0", Fleet Manager adotta il comportamento fail-fast e si interrompe dopo il primo aggiornamento di un membro che non va a buon fine.
• La soglia viene valutata solo in base al numero di errori. Non applica un tasso minimo di successo.
• Un'esecuzione, una fase o un gruppo può mostrare Completed anche quando si verificano errori, purché la soglia configurata non venga superata.
• FailureCount può essere maggiore di maxAllowedFailures quando gli aggiornamenti vengono eseguiti in parallelo, perché più aggiornamenti dei membri potrebbero non riuscire prima che Fleet Manager arresti la pianificazione di più lavoro.
• Le soglie a livello di fase e a livello di gruppo vengono valutate in modo indipendente e gli errori a livello di fase vengono aggregati in tutti i gruppi nella fase.
• Per la maggior parte delle implementazioni, le soglie basate su percentuale sono più facili da ragionare e ridimensionare meglio rispetto ai numeri fissi, soprattutto in gruppi di piccole dimensioni.

È possibile preapprovare un'approvazione?

No. È possibile approvare un aggiornamento solo dopo aver verificato che i cluster membri siano pronti per l'aggiornamento o che l'aggiornamento sia stato completato correttamente. Se volete autorizzare in anticipo, considerate di non includere per nulla un'approvazione nella vostra strategia.

Le approvazioni scadono?

No, le approvazioni devono attendere fino a quando non vengono concesse. Non è possibile configurare un intervallo di tempo per le approvazioni.

È possibile ignorare un'approvazione?

Se si desidera ignorare gli aggiornamenti dei cluster membri insieme all'approvazione del controllo dell'accesso, ignorare il gruppo o la fase che include. Se si desidera procedere con gli aggiornamenti, è necessario concedere l'approvazione.

Come si elimina un'approvazione?

Come nella domanda precedente, se si vuole procedere con un aggiornamento, è necessario concedere l'approvazione. Se si sta tentando di ripulire la risorsa gate sottostante, è necessario eliminare l'esecuzione di aggiornamento associata, operazione che elimina tutti i gate collegati all'esecuzione di aggiornamento.

È possibile configurare un'approvazione post-fase insieme a un'attesa post-fase?

Sì. L'attesa successiva alla fase inizia contemporaneamente all'approvazione. Entrambi devono essere completati prima che l'esecuzione dell'aggiornamento continui.

È possibile aggiungere approvazioni alle strategie di aggiornamento esistenti?

Sì. È possibile modificare la strategia esistente per includere le approvazioni. Tuttavia, le esecuzioni di aggiornamento esistenti create tramite la strategia non vengono aggiornate.

In che modo le attività di controllo dell'avvio pianificato interagiscono con le finestre di manutenzione del cluster del servizio Azure Kubernetes?

I blocchi di avvio pianificati e le finestre di manutenzione pianificate del cluster AKS sono controlli indipendenti. Entrambe le condizioni devono essere soddisfatte prima che un cluster avvii l'aggiornamento. Ad esempio, se una fase di avvio pianificata si conclude alle 2:00, ma la finestra di manutenzione di un cluster non si apre fino alle 6:00, il cluster attende fino alle 6:00 per iniziare il proprio aggiornamento.

Come è possibile controllare l'ordine degli aggiornamenti del cluster in un'esecuzione di aggiornamento?

Le etichette dei membri e i gruppi di aggiornamento sono due modi diversi per selezionare i cluster inclusi in ogni fase e gruppo della strategia di aggiornamento. Ogni cluster membro può essere assegnato a un gruppo di aggiornamento, ma può avere più etichette. Le etichette dei membri (usando memberSelector) offrono maggiore flessibilità e supportano scenari di selezione complessi, pertanto è consigliabile selezionare i membri della flotta per le strategie di aggiornamento. Per altre informazioni, vedere Raggruppare i cluster usando le etichette dei membri.

È necessario specificare i gruppi se si imposta un selettore di membri a livello di fase?

No. Quando si imposta memberSelector su una fase senza definire alcun gruppo, tutti i cluster corrispondenti vengono considerati come un singolo gruppo. La fase maxConcurrency controlla il numero di cluster che aggiornano simultaneamente. È sufficiente definire i gruppi all'interno di una fase se si desidera partizionare i membri corrispondenti in subset paralleli con impostazioni di concorrenza diverse.

Cosa accade per aggiornare i gruppi se si imposta un selettore di membri a livello di gruppo?

Se si imposta memberSelector a livello di gruppo, il campo name del gruppo viene usato solo come identificatore per la registrazione e la creazione di report sullo stato. Il memberSelector ha la precedenza sul nome del gruppo di aggiornamento quando si selezionano i cluster per il gruppo.

Domande frequenti sul posizionamento delle risorse del cluster

È possibile selezionare le risorse all'interno di uno spazio dei nomi per la propagazione?

Sì. Fleet Manager supporta il posizionamento delle risorse sia con ambito di cluster che con ambito di spazio dei nomi.

• ClusterResourcePlacement: propaga risorse con ambito cluster e interi spazi dei nomi (inclusi tutti i relativi contenuti) ai cluster membri. Per altre informazioni, vedere Uso di ClusterResourcePlacement per distribuire risorse con ambito cluster.
• ResourcePlacement: fornisce un controllo con granularità fine per selezionare e propagare risorse specifiche con ambito spazio dei nomi (ad esempio ConfigMaps, Secrets, Deployments) all'interno di uno spazio dei nomi. Per altre informazioni, vedere Utilizzo di ResourcePlacement per implementare risorse con ambito del namespace.

Cartina stradale

La roadmap Azure Kubernetes Fleet Manager è disponibile in GitHub. Il team accoglie le richieste di funzionalità, le domande e i report sui bug.

Passaggi successivi

• Creare una flotta e aggiungere cluster membri.
• Guide alla risoluzione dei problemi per Fleet Manager.