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 che 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).
• NodeSecurityPatch (anteprima): aggiornamenti del sistema operativo dell'immagine del nodo che forniscono patch di sicurezza gestite 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

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

Le finestre di manutenzione non attivano gli aggiornamenti e gli aggiornamenti non iniziano immediatamente all'apertura di una finestra. Le finestre di manutenzione definiscono solo quando gli aggiornamenti possono essere applicati a un cluster.

Per altre informazioni, vedere la documentazione relativa alle finestre di manutenzione del cluster AKS.

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.

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.

È 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 dopo 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.

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.

Domande frequenti sulle distribuzioni automatizzate

In che modo questo si confronta con le distribuzioni automatizzate di AKS?

Le distribuzioni automatizzate del servizio Azure Kubernetes supportano solo un singolo cluster del servizio Azure Kubernetes in cui viene eseguito il carico di lavoro distribuito. Le distribuzioni automatizzate del Fleet Manager impostano le definizioni del carico di lavoro nel cluster hub del Fleet Manager, rendendole disponibili per la distribuzione ai cluster membri tramite il posizionamento delle risorse del cluster.

Le distribuzioni automatizzate di Fleet Manager richiedono anche l'uso di uno spazio dei nomi del cluster hub di Azure Container e del Registro Azure Container esistente.

È possibile connettersi più volte allo stesso repository Git?

Sì, è possibile connettersi più volte allo stesso repository per distribuire risorse o rami diversi dallo stesso repository.

Cartina stradale

La roadmap per la risorsa Fleet Manager di Azure Kubernetes è disponibile in GitHub.

Passaggi successivi

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