Domande frequenti sul servizio Azure Kubernetes

Il servizio Azure Kubernetes fornisce garanzie di contratto di servizio nel piano tariffario Standard con la funzionalità Contratto di servizio tempo di attività.

Il supporto della piattaforma è un piano di supporto ridotto per i cluster di versione "N-3" non supportati. Il supporto della piattaforma include solo il supporto dell'infrastruttura di Azure.

Per altre informazioni, vedere i criteri di supporto della piattaforma.

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 più recente della disponibilità generale del servizio Azure Kubernetes) 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.

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.

I nodi dell'agente del servizio Azure Kubernetes vengono fatturati come macchine virtuali 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.

No, lo spostamento del cluster del servizio Azure Kubernetes tra tenant non è attualmente supportato.

No, lo spostamento del cluster del servizio Azure Kubernetes tra sottoscrizioni non è attualmente supportato.

No, lo spostamento o la ridenominazione del cluster del servizio Azure Kubernetes e le risorse associate non sono supportate.

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 nodo.

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

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).

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 .

No, questa non è una configurazione supportata. Arrestare invece il cluster.

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). Il servizio Azure Kubernetes si basa su una serie di risorse dell'infrastruttura di Azure, inclusi i set di scalabilità di macchine virtuali, le reti virtuali e i 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, la maggior parte dei tipi di macchine virtuali di Azure può essere usata direttamente con il servizio Azure Kubernetes ed è possibile usare le 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:

1. 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.
2. 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. È consigliabile usare questo gruppo di risorse solo per le risorse che condividono il ciclo di vita del cluster.

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 [az aks create][az-aks-create], usare il --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 proprietà nodeResourceGroup.

• 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, tenere presente che non è possibile:

• Specificare un gruppo di risorse esistente come gruppo di risorse del nodo.
• Specificare una sottoscrizione diversa per il gruppo di risorse nodo.
• Cambiare il nome del gruppo di risorse nodo dopo la creazione del 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 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, che è possibile aggiungere durante la creazione di 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).

Per un elenco completo delle aree disponibili, vedere Aree e disponibilità del servizio Azure Kubernetes e disponibilità.

No, i cluster del servizio Azure Kubernetes sono risorse a livello di area e non possono estendersi su aree. Per le istruzioni su come creare un'architettura che includa più aree, vedere le procedure consigliate per la continuità aziendale e il ripristino di emergenza.

Sì, è possibile distribuire un cluster del servizio Azure Kubernetes in una o più zone di disponibilità nelle aree che le supportano.

Sì, è possibile usare dimensioni diverse delle macchine virtuali nel cluster del servizio Azure Kubernetes creando più pool di nodi.

Il servizio Azure Kubernetes non imposta un limite per le dimensioni dell'immagine del contenitore. Tuttavia, è importante comprendere che più grande è l'immagine del contenitore, maggiore è la richiesta 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 Terabyte (TBS), 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. In base a una pianificazione regolare secondo il ciclo di rilascio di Windows Update e per il processo di convalida interno, è consigliabile eseguire un aggiornamento nel cluster e nei pool del nodi di Windows Server nel servizio Azure Kubernetes. Il processo di aggiornamento crea nodi che eseguono l'immagine e le patch di Windows Server più recenti, successivamente rimuove i nodi meno recenti. Per altre informazioni su questo processo, vedere Aggiornare un pool di nodi nel servizio Azure Kubernetes.

Le immagini seguenti hanno requisiti funzionali per "Esegui 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

Sì, sono disponibili due opzioni per limitare l'accesso al server API:

• Usare gli intervalli IP autorizzati del server API per mantenere un endpoint pubblico per il server API ma limitare l'accesso a un set di indirizzi IP attendibili.
• Usare un cluster privato per limitare il server API in modo che sia accessibile solo dall'interno della rete virtuale.

Il servizio Azure Kubernetes applica patch CVEs con una "correzione fornitore" ogni settimana. Le CVE senza una correzione sono in attesa di una "correzione del fornitore" per la risoluzione. Le immagini del servizio Azure Kubernetes vengono aggiornate automaticamente all'interno di 30 giorni. È consigliabile applicare un'immagine del nodo aggiornata a cadenza regolare per assicurarsi che le immagini e le patch del sistema operativo più recenti siano applicate e aggiornate. A questo scopo, è possibile usando uno dei metodi seguenti:

• Manualmente tramite il portale di Azure o l'interfaccia della riga di comando di Azure.
• Aggiornando il cluster servizio Azure Kubernetes. Gli aggiornamenti del cluster bloccano e svuotano i nodi, quindi portano un nuovo nodo online con l'immagine Ubuntu più recente e una nuova versione della patch o una versione secondaria di Kubernetes. Per altre informazioni, vedere Aggiornare un cluster del servizio Azure Kubernetes.
• Usando l'aggiornamento dell'immagine del nodo.

Microsoft fornisce indicazioni per altre azioni che è possibile eseguire per proteggere i carichi di lavoro tramite servizi come Microsoft Defender per contenitori. La minaccia di sicurezza seguente è correlata al servizio Azure Kubernetes e a Kubernetes di cui tenere conto:

• La nuova campagna su larga scala è destinata a Kubeflow (8 giugno 2021).

No, tutti i dati vengono archiviati nell'area del cluster.

Tradizionalmente se il pod è in esecuzione come utente nonroot (che è necessario), è necessario specificare un fsGroup all'interno del contesto di sicurezza del pod in modo che il volume possa essere leggibile e scrivibile dal pod. Questo requisito è trattato in modo più dettagliato qui.

Un effetto collaterale dell'impostazione fsGroup è che ogni volta che viene montato un volume, Kubernetes deve essere ricorsivo chown() e chmod() tutti i file e le directory all'interno del volume (con alcune eccezioni indicate di seguito). Questo scenario si verifica anche se la proprietà del gruppo del volume corrisponde già all'oggetto richiesto fsGroup. Può essere costoso per volumi di grandi dimensioni con molti file di piccole dimensioni, il che può causare l'avvio del pod richiedere molto tempo. Questo scenario è stato un problema noto prima della versione 1.20 e la soluzione alternativa consiste nell'impostare pod 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.

Il servizio Azure Kubernetes usa una comunicazione tunnel sicura per consentire ai kubelet api-server e ai singoli nodi di comunicare anche in reti virtuali separate. Il tunnel è protetto tramite la crittografia mTLS. 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 e i nomi di dominio completi necessari di Azure.

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. Ciò è utile nei casi in cui l'uscita del cluster viene eseguita tramite un firewall di livello 7, ad esempio quando si usa Firewall di Azure con le regole dell'applicazione.

Il servizio Azure Kubernetes non applica gruppi di sicurezza di rete (NSG) alla sua subnet e non modifica i NSG associati a tale subnet. Il servizio Azure Kubernetes modifica solo le impostazioni dei gruppi di sicurezza di rete. Se si usa CNI, è anche necessario assicurarsi che le regole di sicurezza nei gruppi di sicurezza di rete consentano il traffico tra gli intervalli CIDR del nodo e del 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.

I nodi del servizio Azure Kubernetes eseguono il servizio “chrony”, che esegue il pull del tempo dal localhost. I contenitori in esecuzione nei pod ottengono il tempo dai nodi del servizio Azure Kubernetes. Le applicazioni avviate all'interno di un contenitore usano il tempo dal contenitore del pod.

No, AKS è un servizio gestito e la manipolazione delle risorse IaaS non è supportata. Per installare componenti personalizzati, usare le API e i meccanismi di Kubernetes. Ad esempio, usare DaemonSet per installare i componenti necessari.

Il servizio Azure Kubernetes supporta i seguenti controller di ammissione:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Attualmente non è possibile modificare l'elenco di 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 del servizio Azure Kubernetes interni, contrassegnati con l'etichetta del piano di controllo. Ad esempio:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

Il servizio Azure Kubernetes esegue il firewall del server API in uscita, in modo che i webhook del controller di ammissione siano accessibili dall'interno del cluster.

Per proteggere la stabilità del sistema ed evitare che i controller di ammissione personalizzati influiscano sui servizi interni in kube-system, lo spazio dei nomi del servizio Azure Kubernetes include la funzionalità Admissions Enforcer, che esclude automaticamente gli spazi dei nomi di kube-system e quelli interni del servizio Azure Kubernetes. Questo servizio garantisce che i controller di ammissione personalizzati non influiscano sui servizi in esecuzione in kube-system.

Se si ha un caso d'uso critico per la distribuzione di qualcosa su kube-system (non consigliato) a supporto del webhook di ammissione personalizzato, si può aggiungere la seguente etichetta o annotazione in modo che Admissions Enforcer la ignori.

Etichetta "admissions.enforcer/disabled": "true" o annotazione "admissions.enforcer/disabled": true

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.

I nodi abilitati per FIPS sono ora supportati nei pool di nodi basati su Linux. Per altre informazioni, vedere Aggiungere un pool di nodi abilitato per FIPS.

Qualsiasi patch, inclusa una patch di sicurezza, viene applicata automaticamente al cluster del servizio Azure Kubernetes. Qualsiasi elemento più grande di una patch, ad esempio modifiche di versione principali o secondarie (che possono avere modifiche di rilievo agli oggetti distribuiti), viene aggiornato quando si aggiorna il cluster se è disponibile una nuova versione. È possibile trovare quando è disponibile una nuova versione visitando le note sulla versione del servizio Azure Kubernetes.

L'estensione AKS Linux è un'estensione di Azure VM che installa e configura gli strumenti di monitoraggio sui nodi 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 lo rende disponibile usando un endpoint delle metriche. Uno strumento di monitoraggio, ad esempio Prometheus, è quindi in grado di evitare 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 Eventi e NodeConditions.
• 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) progettati per raccogliere informazioni pertinenti, consentendo agli utenti di 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. Usa kubeconfig per connettersi al server API per inviare i dati di monitoraggio raccolti.

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à cross-RG, l'eliminazione può richiedere più tempo o persino avere esito negativo. In caso di problemi con le eliminazioni, verificare che non siano presenti blocchi sul gruppo di risorse, che le eventuali risorse esterne siano state disassociate dal gruppo di risorse e così via.

Se si verificano problemi con le operazioni di creazione e aggiornamento del 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, tag e così via.

È possibile, ma non è consigliabile. È consigliabile eseguire aggiornamenti quando lo stato del cluster è noto e integro.

No, eliminare/rimuovere nodi in uno stato di errore o in altro modo dal cluster prima dell'aggiornamento.

In genere, questo errore si verifica se si dispone di uno o più gruppi di sicurezza di rete (NSG) ancora in uso associati al cluster. Rimuoverli e provare a ripetere l'eliminazione.

Verificare che l'entità servizio non sia scaduta. Vedere Entità servizio del servizio Azure Kubernetes e credenziali di aggiornamento del servizio Azure Kubernetes.

Verificare che l'entità servizio non sia scaduta. Vedere Entità servizio del servizio Azure Kubernetes e credenziali di aggiornamento del servizio Azure Kubernetes.