Questo articolo fornisce risposte ad alcune delle domande più comuni su servizio Azure Kubernetes (servizio Azure Kubernetes).
Supporto tecnico
Il servizio Azure Kubernetes offre un contratto di servizio?
Il servizio Azure Kubernetes fornisce garanzie di contratto di servizio nel piano tariffario Standard con la funzionalità Contratto di servizio tempo di attività.
Che cos'è il supporto della piattaforma e che cosa include?
Il supporto della piattaforma è un piano di supporto ridotto per i cluster n-3 versione non supportati. Il supporto della piattaforma include solo il supporto dell'infrastruttura di Azure.
Per altre informazioni, vedere i criteri di supporto della piattaforma.
Il servizio Azure Kubernetes aggiorna automaticamente i cluster non supportati?
Sì, il servizio Azure Kubernetes avvia gli aggiornamenti automatici per i cluster non supportati. Quando un cluster in una versione n-3 (dove n è la versione secondaria supportata più recente del servizio Azure Kubernetes disponibile a livello generale) sta per passare a n-4, il servizio Azure Kubernetes aggiorna automaticamente il cluster a n-2 per rimanere in un criterio di supporto del servizio Azure Kubernetes.
Per altre informazioni, vedere Versioni di Kubernetes supportate, Finestre di manutenzione pianificata e Aggiornamenti automatici.
È possibile eseguire contenitori Windows Server in servizio Azure Kubernetes?
Sì, il servizio Azure Kubernetes supporta i contenitori di Windows Server. Per altre informazioni, vedere Le domande frequenti su Windows Server nel servizio Azure Kubernetes.
È possibile applicare gli sconti per le prenotazioni di Azure ai nodi dell'agente del servizio Azure Kubernetes?
I nodi dell'agente del servizio Azure Kubernetes vengono fatturati come macchine virtuali (VM) di Azure standard. Se sono state acquistate prenotazioni di Azure per le dimensioni della macchina virtuale in uso nel servizio Azure Kubernetes, questi sconti vengono applicati automaticamente.
Operazioni
È possibile spostare o eseguire la migrazione del cluster tra tenant di Azure?
No Lo spostamento del cluster del servizio Azure Kubernetes tra tenant non è attualmente supportato.
È possibile spostare o eseguire la migrazione del cluster tra sottoscrizioni?
No Lo spostamento del cluster del servizio Azure Kubernetes tra sottoscrizioni non è attualmente supportato.
È possibile spostare il cluster del servizio Azure Kubernetes o le risorse dell'infrastruttura del servizio Azure Kubernetes in altri gruppi di risorse o rinominarli?
No Lo spostamento o la ridenominazione del cluster del servizio Azure Kubernetes e delle risorse associate non sono supportati.
È possibile ripristinare il cluster dopo averlo eliminato?
No Non è possibile ripristinare il cluster dopo l'eliminazione. Quando si elimina il cluster, vengono eliminati anche il gruppo di risorse del nodo e tutte le relative risorse.
Se si vuole mantenere una delle risorse, spostarle in un altro gruppo di risorse prima di eliminare il cluster. Se si vuole proteggersi da eliminazioni accidentali, è possibile bloccare il gruppo di risorse gestite del servizio Azure Kubernetes che ospita le risorse del cluster usando il blocco del gruppo di risorse Node.
È possibile ridimensionare il cluster del servizio Azure Kubernetes a zero?
È possibile arrestare completamente un cluster del servizio Azure Kubernetes in esecuzione o ridimensionare o ridimensionare automaticamente tutti o specifici User pool di nodi a zero.
Non è possibile ridimensionare direttamente i pool di nodi di sistema a zero.
È possibile usare le API del set di scalabilità di macchine virtuali per ridimensionare manualmente?
No Le operazioni di scalabilità che usano le API del set di scalabilità di macchine virtuali non sono supportate. È possibile usare le API del servizio Azure Kubernetes (az aks scale).
È possibile usare i set di scalabilità di macchine virtuali per ridimensionare manualmente fino a zero nodi?
No Le operazioni di scalabilità che usano le API del set di scalabilità di macchine virtuali non sono supportate. È possibile usare l'API del servizio Azure Kubernetes per ridimensionare i pool di nodi non di sistema a zero o arrestare il cluster .
È possibile arrestare o deallocare tutte le macchine virtuali?
No Questa configurazione non è supportata. Arrestare invece il cluster.
Perché vengono creati due gruppi di risorse con servizio Azure Kubernetes?
Il servizio Azure Kubernetes si basa su molte risorse dell'infrastruttura di Azure, tra cui set di scalabilità di macchine virtuali, reti virtuali e dischi gestiti. Queste integrazioni consentono di applicare molte delle funzionalità principali della piattaforma Azure all'interno dell'ambiente Kubernetes gestito fornito da AKS. Ad esempio, è possibile usare la maggior parte dei tipi di macchine virtuali di Azure direttamente con il servizio Azure Kubernetes ed è possibile usare prenotazioni di Azure per ricevere automaticamente sconti su tali risorse.
Per rendere disponibile questa architettura, ogni distribuzione del servizio Azure Kubernetes include due gruppi di risorse:
- Si crea il primo gruppo di risorse. Questo gruppo contiene solo la risorsa del servizio Kubernetes. Il provider di risorse del servizio Azure Kubernetes crea automaticamente il secondo gruppo di risorse durante la distribuzione. Un esempio del secondo gruppo di risorse è MC_myResourceGroup_myAKSCluster_eastus. Per informazioni su come specificare il nome di questo secondo gruppo di risorse, vedere la sezione successiva.
- Il secondo gruppo di risorse, noto come gruppo di risorse nodo, contiene tutte le risorse di infrastruttura associate al cluster, come ad esempio le macchine virtuali dei nodi Kubernetes, le risorse della rete virtuale e di archiviazione. Per impostazione predefinita, il gruppo di risorse nodo ha un nome simile a MC_myResourceGroup_myAKSCluster_eastus. Il servizio Azure Kubernetes elimina automaticamente il gruppo di risorse del nodo ogni volta che si elimina il cluster. Usare questo gruppo di risorse solo per le risorse che condividono il ciclo di vita del cluster.
Nota
La modifica di qualsiasi risorsa nel gruppo di risorse del nodo nel cluster del servizio Azure Kubernetes è un'azione non supportata e causerà errori di funzionamento del cluster. È possibile impedire che le modifiche vengano apportate al gruppo di risorse del nodo. Impedire agli utenti di modificare le risorse gestite dal cluster del servizio Azure Kubernetes.
È possibile specificare un nome personalizzato per il gruppo di risorse nodo del servizio Azure Kubernetes?
Per impostazione predefinita, il servizio Azure Kubernetes assegna un nome al gruppo di risorse del nodo MC_resourcegroupname_clustername_location, ma è possibile specificare il proprio nome.
Per specificare un nome personalizzato per il gruppo di risorse, installare l'estensione aks-preview versione 0.3.2 o successiva dell'interfaccia della riga di comando di Azure. Quando si crea un cluster del servizio Azure Kubernetes usando il comando , usare il az aks create--node-resource-group parametro e specificare un nome per il gruppo di risorse. Se si usa un modello di Azure Resource Manager per distribuire un cluster del servizio Azure Kubernetes, è possibile definire il nome del gruppo di risorse usando la nodeResourceGroup proprietà .
- Il provider di risorse di Azure crea automaticamente il gruppo di risorse secondario.
- È possibile specificare un nome di gruppo di risorse personalizzato solo quando si crea il cluster.
Quando si lavora con il gruppo di risorse del nodo, non è possibile:
- Specificare un gruppo di risorse esistente come gruppo di risorse del nodo.
- Specificare una sottoscrizione diversa per il gruppo di risorse nodo.
- Modificare il nome del gruppo di risorse del nodo dopo aver creato il cluster.
- Specificare i nomi delle risorse gestite nel gruppo di risorse del nodo.
- Modificare o eliminare i tag creati da Azure delle risorse gestite all'interno del gruppo di risorse del nodo.
È possibile modificare i tag e altre proprietà delle risorse del servizio Azure Kubernetes nel gruppo di risorse nodo?
È possibile che si verifichino errori di ridimensionamento e aggiornamento imprevisti se si modificano o si eliminano i tag creati da Azure e altre proprietà delle risorse nel gruppo di risorse del nodo. Il servizio Azure Kubernetes consente di creare e modificare tag personalizzati creati dagli utenti finali ed è possibile aggiungere tali tag quando si crea un pool di nodi. Potrebbe essere necessario creare o modificare tag personalizzati da assegnare ad esempio a una business unit o a un centro di costo. Un'altra opzione consiste nel creare criteri di Azure con un ambito nel gruppo di risorse gestite.
I tag creati da Azure vengono creati per i rispettivi servizi di Azure e devono essere sempre consentiti. Per il servizio Azure Kubernetes sono presenti i tag aks-managed e k8s-azure. La modifica di qualsiasi tag creato da Azure nelle risorse nel gruppo di risorse del nodo nel cluster del servizio Azure Kubernetes è un'azione non supportata, che interrompe il punto di disconnessione singolo (SLO).
Nota
In passato, il nome Owner del tag era riservato al servizio Azure Kubernetes per gestire l'indirizzo IP pubblico assegnato nell'indirizzo IP front-end del servizio di bilanciamento del carico. A questo punto, i servizi usano il aks-managed prefisso . Per le risorse legacy, non usare i criteri di Azure per applicare il nome del Owner tag. In caso contrario, tutte le risorse nella distribuzione del cluster del servizio Azure Kubernetes e le operazioni di aggiornamento verranno interrotte. Questa restrizione non si applica alle risorse appena create.
Perché nel cluster vengono visualizzate versioni Helm con prefisso gestito dal servizio Azure Kubernetes e perché il conteggio delle revisioni continua ad aumentare?
Il servizio Azure Kubernetes usa Helm per distribuire componenti al cluster. È possibile ignorare aks-managed in modo sicuro le versioni Helm con prefisso. È previsto e sicuro l'aumento continuo delle revisioni in queste versioni Helm.
Quote, limiti e disponibilità dell'area
In quali aree di Azure è attualmente disponibile il servizio Azure Kubernetes?
Per un elenco completo delle aree disponibili, vedere Aree e disponibilità del servizio Azure Kubernetes e disponibilità.
È possibile distribuire un cluster del servizio Azure Kubernetes tra più aree?
No I cluster del servizio Azure Kubernetes sono risorse a livello di area e non possono estendersi su aree. Per indicazioni su come creare un'architettura che include più aree, vedere procedure consigliate per la continuità aziendale e il ripristino di emergenza.
È possibile distribuire un cluster del servizio Azure Kubernetes tra zone di disponibilità?
Sì, è possibile distribuire un cluster del servizio Azure Kubernetes in una o più zone di disponibilità nelle aree che le supportano.
È possibile avere dimensioni diverse delle VM in un singolo cluster?
Sì, è possibile usare dimensioni di vm diverse nel cluster del servizio Azure Kubernetes creando più pool di nodi.
Qual è il limite di dimensioni per un'immagine del contenitore nel servizio Azure Kubernetes?
Il servizio Azure Kubernetes non imposta un limite per le dimensioni dell'immagine del contenitore. Ma più grande è l'immagine, maggiore è la domanda di memoria. Una dimensione maggiore potrebbe potenzialmente superare i limiti di risorse o la memoria complessiva disponibile dei nodi di lavoro. Per impostazione predefinita, la memoria per le dimensioni della macchina virtuale Standard_DS2_v2 per un cluster del servizio Azure Kubernetes è impostata su 7 GiB.
Quando un'immagine del contenitore è eccessivamente grande, come nell'intervallo di terabyte (TB), kubelet potrebbe non essere in grado di eseguirne il pull dal registro contenitori a un nodo a causa della mancanza di spazio su disco.
Per i nodi di Windows Server, Windows Update non viene eseguito automaticamente e non applica gli aggiornamenti più recenti. È necessario eseguire un aggiornamento nel cluster e nei pool di nodi di Windows Server nel cluster del servizio Azure Kubernetes. Segui una pianificazione regolare in base al ciclo di rilascio di Windows Update e al tuo processo di convalida. Questo processo di aggiornamento crea nodi che eseguono l'immagine e le patch più recenti di Windows Server e quindi rimuove i nodi meno recenti. Per altre informazioni su questo processo, vedere Aggiornare un pool di nodi nel servizio Azure Kubernetes.
Le immagini del servizio Azure Kubernetes sono necessarie per l'esecuzione come radice?
Le immagini seguenti hanno requisiti funzionali per l'esecuzione come radice e le eccezioni devono essere archiviate per tutti i criteri:
- mcr.microsoft.com/oss/kubernetes/coredns
- mcr.microsoft.com/azuremonitor/containerinsights/ciprod
- mcr.microsoft.com/oss/calico/node
- mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi
Sicurezza, accesso e identità
È possibile limitare chi ha accesso al server API Kubernetes?
Sì, sono disponibili due opzioni per limitare l'accesso al server API:
- Usare gli intervalli IP autorizzati del server API se si vuole mantenere un endpoint pubblico per il server API, ma limitare l'accesso a un set di intervalli IP attendibili.
- Usare un cluster privato se si vuole limitare l'accessibilità del server API solo dall'interno della rete virtuale.
Gli aggiornamenti della sicurezza vengono applicati ai nodi agente servizio Azure Kubernetes?
Il servizio Azure Kubernetes applica patch CVEs con una correzione fornitore ogni settimana. Le CVE senza una correzione sono in attesa di una correzione fornitore prima che possano essere risolte. Le immagini del servizio Azure Kubernetes vengono aggiornate automaticamente entro 30 giorni. È consigliabile applicare un'immagine del nodo aggiornata a una frequenza regolare per assicurarsi che le immagini e le patch del sistema operativo più recenti siano applicate e aggiornate. È possibile eseguire questa attività:
- Manualmente tramite il portale di Azure o l'interfaccia della riga di comando di Azure.
- Aggiornando il cluster servizio Azure Kubernetes. Il cluster aggiorna automaticamente i nodi di blocco e svuotamento . Porta quindi online un nuovo nodo con l'immagine Ubuntu più recente e una nuova versione di patch o una versione secondaria di Kubernetes. Per altre informazioni, vedere Aggiornare un cluster del servizio Azure Kubernetes.
- Usando un aggiornamento dell'immagine del nodo.
Esistono minacce per la sicurezza che riguardano il servizio Azure Kubernetes di cui è necessario tenere conto?
Microsoft fornisce indicazioni per altre azioni che è possibile eseguire per proteggere i carichi di lavoro tramite servizi come Microsoft Defender per contenitori. Per informazioni sulle minacce alla sicurezza correlate al servizio Azure Kubernetes e a Kubernetes, vedere La nuova campagna su larga scala è destinata a Kubeflow (8 giugno 2021).
Il servizio Azure Kubernetes archivia i dati dei clienti all'esterno dell'area del cluster?
No Tutti i dati vengono archiviati nell'area del cluster.
Come è possibile evitare problemi lenti con l'impostazione della proprietà delle autorizzazioni quando il volume presenta numerosi file?
Tradizionalmente, se il pod è in esecuzione come utente nonroot (che deve essere), è necessario specificare un fsGroup parametro all'interno del contesto di sicurezza del pod in modo che il volume sia leggibile e scrivibile dal pod. Per altre informazioni su questo requisito, vedere Configurare un contesto di sicurezza per un pod o un contenitore.
Un effetto collaterale dell'impostazione fsGroup è che ogni volta che viene montato un volume, Kubernetes deve usare i chown() comandi e chmod() in modo ricorsivo per tutti i file e le directory all'interno del volume (con alcune eccezioni). Questo scenario si verifica anche se la proprietà del gruppo del volume corrisponde già al parametro richiesto fsGroup . Questa configurazione potrebbe essere costosa per volumi di grandi dimensioni con molti file di piccole dimensioni, il che può richiedere molto tempo per l'avvio dei pod. Questo scenario era un problema noto prima della versione 1.20. La soluzione alternativa consiste nell'impostare il pod per l'esecuzione come radice:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 0
fsGroup: 0
Il problema è stato risolto con Kubernetes versione 1.20. Per altre informazioni, vedere Kubernetes 1.20: Controllo granulare delle modifiche alle autorizzazioni per i volumi.
Rete
In che modo il piano di controllo gestito comunica con i nodi?
Il servizio Azure Kubernetes usa una comunicazione tunnel sicura per consentire api-server ai singoli kubelet dei nodi e di comunicare, anche in reti virtuali separate. Il tunnel viene protetto tramite la crittografia reciproca Transport Layer Security. Il tunnel principale corrente usato dal servizio Azure Kubernetes è Konnectivity, noto in precedenza come apiserver-network-proxy. Verificare che tutte le regole di rete seguano le regole di rete necessarie di Azure e i nomi di dominio completi (FQDN).
I pod possono usare il nome di dominio completo del server API anziché l'IP del cluster?
Sì, è possibile aggiungere l'annotazione kubernetes.azure.com/set-kube-service-host-fqdn ai pod per impostare la KUBERNETES_SERVICE_HOST variabile sul nome di dominio del server API anziché sull’IP del servizio nel cluster. Questa modifica è utile nei casi in cui il cluster in uscita viene eseguito tramite un firewall di livello 7. Un esempio è quando si usa Firewall di Azure con le regole dell'applicazione.
È possibile configurare gruppi di sicurezza di rete con il servizio Azure Kubernetes?
Il servizio Azure Kubernetes non applica i gruppi di sicurezza di rete (NSG) alla subnet e non modifica alcun gruppo di sicurezza di rete associato a tale subnet. Il servizio Azure Kubernetes modifica solo le impostazioni del gruppo di sicurezza di rete dell'interfaccia di rete. Se si usa l'interfaccia CNI (Container Network Interface), è necessario assicurarsi anche che le regole di sicurezza nei gruppi di sicurezza di rete consentano il traffico tra gli intervalli CIDR (ClassLess Interdomain Routing) del nodo e dei pod. Se si usa kubenet, è anche necessario assicurarsi che le regole di sicurezza nei gruppi di sicurezza di rete consentano il traffico tra il nodo e il CIDR del pod. Per altre informazioni, vedere Gruppi di sicurezza di rete.
Come funziona la sincronizzazione dell'ora nel servizio Azure Kubernetes?
I nodi del servizio Azure Kubernetes eseguono il servizio chrony, che esegue il pull del tempo dall'host locale. I contenitori eseguiti nei pod ottengono il tempo dai nodi del servizio Azure Kubernetes. Le applicazioni aperte all'interno di un contenitore usano il tempo dal contenitore del pod.
Componenti aggiuntivi, estensioni e integrazioni
È possibile usare estensioni di VM personalizzate?
No Il servizio Azure Kubernetes è un servizio gestito. La modifica delle risorse IaaS (Infrastructure as a Service) non è supportata. Per installare componenti personalizzati, usare le API e i meccanismi di Kubernetes. Ad esempio, usare DaemonSets per installare tutti i componenti necessari.
Quali controller di ammissione Kubernetes supporta servizio Azure Kubernetes? È possibile aggiungere o rimuovere i controller di ammissione?
Il servizio Azure Kubernetes supporta i seguenti controller di ammissione:
NamespaceLifecycleLimitRangerServiceAccountDefaultIngressClassDefaultStorageClassDefaultTolerationSecondsMutatingAdmissionWebhookValidatingAdmissionWebhookResourceQuotaPodNodeSelectorPodTolerationRestrictionExtendedResourceToleration
Attualmente non è possibile modificare l'elenco di controller di ammissione nel servizio Azure Kubernetes.
È possibile usare webhook dei controller di ammissione nel servizio Azure Kubernetes?
Sì, è possibile usare webhook dei controller di ammissione nel servizio Azure Kubernetes. È consigliabile escludere gli spazi dei nomi interni del servizio Azure Kubernetes, contrassegnati con l'etichetta control-plane . Ad esempio:
namespaceSelector:
matchExpressions:
- key: control-plane
operator: DoesNotExist
Il servizio Azure Kubernetes esegue il firewall in uscita del server API in modo che i webhook del controller di ammissione siano accessibili dall'interno del cluster.
I webhook del controller di ammissione possono influire sugli spazi dei nomi kube-system e interni del servizio Azure Kubernetes?
Per proteggere la stabilità del sistema e impedire ai controller di ammissione personalizzati di influire sui servizi interni nello spazio dei nomi, il kube-system servizio Azure Kubernetes dispone di un'applicazione di ammissione, che esclude kube-system automaticamente e gli spazi dei nomi interni del servizio Azure Kubernetes. Questo servizio garantisce che i controller di ammissione personalizzati non influiscano sui servizi eseguiti in kube-system.
Se si dispone di un caso d'uso critico per la distribuzione di un elemento kube-system in (non consigliato) a supporto del webhook di ammissione personalizzato, è possibile aggiungere l'etichetta o l'annotazione seguente in modo che l'applicazione delle ammissioni lo ignori:
- Etichetta:
"admissions.enforcer/disabled": "true" - Annotazione:
"admissions.enforcer/disabled": true
Azure Key Vault è integrato in servizio Azure Kubernetes?
Il provider di Azure Key Vault per il driver CSI dell'archivio segreti offre l'integrazione nativa di Azure Key Vault nel servizio Azure Kubernetes.
È possibile usare librerie di crittografia FIPS con distribuzioni nel servizio Azure Kubernetes?
I nodi abilitati con FIPS (Federal Information Processing Standards) sono ora supportati nei pool di nodi basati su Linux. Per altre informazioni, vedere Aggiungere un pool di nodi abilitato per FIPS.
Come vengono aggiornati i componenti aggiuntivi del servizio Azure Kubernetes?
Qualsiasi patch, inclusa una patch di sicurezza, viene applicata automaticamente al cluster del servizio Azure Kubernetes. Qualsiasi cosa più grande di una patch, ad esempio modifiche di versione principali o secondarie (che possono avere modifiche di rilievo agli oggetti distribuiti), vengono aggiornate quando si aggiorna il cluster se è disponibile una nuova versione. Per informazioni su quando è disponibile una nuova versione, vedere Note sulla versione del servizio Azure Kubernetes.
Qual è lo scopo dell'estensione Linux del servizio Azure Kubernetes installata nelle istanze dei set di scalabilità di macchine virtuali Linux?
L'estensione Linux del servizio Azure Kubernetes è un'estensione di macchina virtuale di Azure che installa e configura gli strumenti di monitoraggio nei nodi del ruolo di lavoro Kubernetes. L'estensione viene installata in tutti i nodi Linux nuovi ed esistenti. Configura gli strumenti di monitoraggio seguenti:
- Utilità di esportazione di nodi: raccoglie i dati di telemetria hardware dalla macchina virtuale e la rende disponibile usando un endpoint delle metriche. Quindi, uno strumento di monitoraggio, ad esempio Prometheus, può raschiare queste metriche.
-
Node-problem-detector: mira a rendere visibili vari problemi di nodo ai livelli upstream nello stack di gestione del cluster. Si tratta di un'unità di sistema eseguita in ogni nodo, rileva i problemi del nodo e li segnala al server API del cluster usando
EventseNodeConditions. - ig: framework open source basato su eBPF per il debug e l'osservazione dei sistemi Linux e Kubernetes. Fornisce un set di strumenti (o gadget) che raccolgono informazioni rilevanti che gli utenti possono usare per identificare la causa di problemi di prestazioni, arresti anomali o altre anomalie. In particolare, l'indipendenza da Kubernetes consente agli utenti di usarla anche per il debug dei problemi del piano di controllo.
Questi strumenti consentono di fornire un'osservabilità intorno a molti problemi correlati all'integrità dei nodi, ad esempio:
- Problemi del daemon di infrastruttura: Servizio NTP inattivo
- Problemi hardware: CPU, memoria o disco non valido
- Problemi del kernel: Deadlock del kernel, file system danneggiato
- Problemi di runtime del contenitore: Daemon di runtime non risponde
L'estensione non richiede l'accesso in uscita aggiuntivo a URL, indirizzi IP o porte oltre i requisiti di uscita del servizio Azure Kubernetes documentati. Non richiede autorizzazioni speciali concesse in Azure.
kubeconfig Usa per connettersi al server API per inviare i dati di monitoraggio raccolti.
Risolvere i problemi del cluster
Perché l'eliminazione del cluster richiede molto tempo?
La maggior parte dei cluster viene eliminata su richiesta dell'utente. In alcuni casi, in particolare nei casi in cui si usa il proprio gruppo di risorse o si eseguono attività tra gruppi di risorse, l'eliminazione può richiedere più tempo o persino avere esito negativo. Se si verifica un problema con le eliminazioni, verificare che non siano presenti blocchi nel gruppo di risorse. Assicurarsi anche che tutte le risorse esterne al gruppo di risorse non siano associate al gruppo di risorse.
Perché la creazione o l'aggiornamento del cluster richiede molto tempo?
Se si verificano problemi con la creazione e l'aggiornamento dei cluster, assicurarsi di non avere criteri o vincoli di servizio assegnati che potrebbero impedire al cluster del servizio Azure Kubernetes di gestire risorse come macchine virtuali, servizi di bilanciamento del carico o tag.
Se sono presenti pod o distribuzioni in stati NodeLost o Sconosciuti, è comunque possibile aggiornare il cluster?
È possibile, ma non è consigliabile. Eseguire aggiornamenti quando lo stato del cluster è noto e integro.
Se si dispone di un cluster con uno o più nodi in uno stato non integro o se è stato arrestato, è possibile eseguire un aggiornamento?
No Eliminare o rimuovere tutti i nodi che si trovano in uno stato di errore o in altro modo dal cluster prima dell'aggiornamento.
Si è tentato di eliminare il cluster, ma viene visualizzato l'errore "[Errno 11001] getaddrinfo failed".
In genere, questo errore si verifica se si dispone di uno o più gruppi di sicurezza di rete in uso che sono ancora associati al cluster. Rimuoverli e tentare di eliminare nuovamente il cluster.
È stato eseguito un aggiornamento, ma ora i pod si trovano in cicli di arresto anomalo e i probe di idoneità hanno esito negativo.
Verificare che l'entità servizio non sia scaduta. Per altre informazioni, vedere Entità servizio del servizio Azure Kubernetes e credenziali di aggiornamento del servizio Azure Kubernetes.
Il cluster funzionava, ma improvvisamente non è possibile effettuare il provisioning di servizi di bilanciamento del carico o montare attestazioni di volume persistente.
Verificare che l'entità servizio non sia scaduta. Per altre informazioni, vedere Entità servizio del servizio Azure Kubernetes e credenziali di aggiornamento del servizio Azure Kubernetes.
