Domande frequenti relative al servizio Azure Kubernetes

Questo articolo tratta alcune domande frequenti relative al servizio Azure Kubernetes.

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 in più 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.

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

È possibile avere dimensioni diverse delle VM in un singolo cluster?

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

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 possa essere risolta. 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.

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

Nodi di Windows Server

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.

Esistono minacce per la sicurezza destinate al servizio Azure Kubernetes di cui tenere conto?

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

In che modo il piano di controllo gestito comunica con i nodi?

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.

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

Perché vengono creati due gruppi di risorse con servizio Azure Kubernetes?

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 cluster 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 bloccando gli utenti dalla modifica delle risorse gestite dal cluster del servizio Azure Kubernetes.

È possibile specificare un nome personalizzato per il gruppo di risorse nodo del servizio Azure Kubernetes?

Sì. Per impostazione predefinita, il servizio Azure Kubernetes assegna al gruppo di risorse nodo il nome MC_resourcegroupname_clustername_location, ma è anche possibile specificare un nome personalizzato.

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, usare il parametro --node-resource-group 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. Per altre informazioni, vedere la sezione successiva.

È 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, 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 altre informazioni, vedere Il servizio Azure Kubernetes offre un contratto di servizio?

Nota

In passato, il nome del tag "Proprietario" era riservato al servizio Azure Kubernetes per gestire l'IP pubblico assegnato all'indirizzo IP front-end del servizio di bilanciamento del carico. A questo punto, i servizi seguono usano il prefisso aks-managed. Per le risorse legacy, non usare i criteri di Azure per applicare il nome del tag "Proprietario". In caso contrario, tutte le risorse nella distribuzione del cluster del servizio Azure Kubernetes e le operazioni di aggiornamento verranno interrotte. Questa operazione non si applica alle risorse appena create.

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:

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

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

I webhook dei controller di ammissione possono influire sugli spazi dei nomi di kube-system e su quelli interni del servizio Azure Kubernetes?

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

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 eseguire contenitori Windows Server in servizio Azure Kubernetes?

Sì, i contenitori di Windows Server sono disponibili nel servizio Azure Kubernetes. Per eseguire i contenitori di Windows Server nel servizio Azure Kubernetes, creare un pool di nodi che esegue Windows Server come sistema operativo guest. I contenitori di Windows Server possono usare solo Windows Server 2019. Per iniziare, vedere Creare un cluster del servizio Azure Kubernetes con un pool di nodi di Windows Server.

Il supporto di Windows Server per il pool di nodi include alcune limitazioni che fanno parte di Windows Server upstream nel progetto Kubernetes. Per altre informazioni su queste limitazioni, vedere Limitazioni dei contenitori di Windows Server nel servizio Azure Kubernetes.

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

Il piano tariffario gratuito non ha un contrattodi servizio associato, ma ha un obiettivodel livello di servizio del 99,5%. I problemi di connettività temporanei vengono osservati se si verifica un aggiornamento, nodi non integri, manutenzione della piattaforma, un'applicazione sovraccarica il server API con richieste e così via. Per i carichi di lavoro cruciali e di produzione o se il carico di lavoro non tollera i riavvii del server API, è consigliabile usare il livello Standard, che include il contratto di servizio tempo di attività.

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

È possibile spostare o eseguire la migrazione del cluster tra tenant di Azure?

Lo spostamento del cluster del servizio Azure Kubernetes tra tenant non è attualmente supportato.

È possibile spostare o eseguire la migrazione del cluster tra sottoscrizioni?

Lo spostamento di cluster tra sottoscrizioni non è al momento supportato.

È possibile spostare i cluster del servizio Azure Kubernetes dalla sottoscrizione di Azure corrente a un'altra?

Lo spostamento del cluster del servizio Azure Kubernetes e delle risorse associate tra sottoscrizioni di Azure non è 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?

Lo spostamento o la ridenominazione del cluster del servizio Azure Kubernetes e delle risorse associate non sono supportati.

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

Perché la creazione/aggiornamento del cluster richiede molto tempo?

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 ripristinare il cluster dopo l'eliminazione?

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. Un esempio del secondo gruppo di risorse è MC_myResourceGroup_myAKSCluster_eastus.

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.

Che cos'è il supporto della piattaforma e che cosa include?

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. Il supporto della piattaforma non include alcun elemento correlato ai seguenti elementi:

• Funzionalità e componenti kubernetes
• Creazione di cluster o pool di nodi
• Aggiornamenti rapidi
• Correzioni di bug
• Patch di protezione
• Componenti ritirati

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

Il servizio Azure Kubernetes si basa sulle versioni e sulle patch di Kubernetes, ovvero un progetto Open Source che supporta solo una finestra temporale scorrevole di tre versioni secondarie. Il servizio Azure Kubernetes può garantire un supporto completo solo mentre tali versioni vengono gestite upstream. Poiché non sono presenti più patch prodotte upstream, il servizio Azure Kubernetes può lasciare tali versioni senza patch o creare una copia tramite fork. A causa di questa limitazione, l’assistenza della piattaforma non supporta nulla che si basi su Kubernetes upstream.

Il servizio Azure Kubernetes aggiorna automaticamente i cluster non supportati?

Il servizio Azure Kubernetes avvia anche 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. L'aggiornamento automatico di un cluster supportato dalla piattaforma a una versione supportata è abilitato per impostazione predefinita.

Ad esempio, kubernetes v1.25 esegue l'aggiornamento alla versione 1.26 durante la versione disponibile a livello generale della versione 1.29. Per ridurre al minimo le interruzioni, configurare le finestre di manutenzione. Per informazioni dettagliate sui canali di aggiornamento automatico, vedere Aggiornamento automatico.

Nel caso di pod/distribuzioni con lo stato 'NodeLost' o 'Unknown', è comunque possibile aggiornare il cluster?

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

Se un cluster include uno o più nodi arrestati o con uno stato non integro, è possibile eseguire un aggiornamento?

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

Dopo l'eliminazione di un cluster viene visualizzato l'errore [Errno 11001] getaddrinfo failed. Perché?

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.

Dopo un aggiornamento, si verificano arresti anomali ciclici dei pod e i probe di idoneità restituiscono un errore. Come si risolve il problema?

Verificare che l'entità servizio non sia scaduta. Vedere: Entità servizio del servizio Azure Kubernetes e Credenziali per l'aggiornamento del servizio Azure Kubernetes.

Il cluster funzionava ma improvvisamente non è possibile effettuare il provisioning di Load Balancer, montare PVC e così via?

Verificare che l'entità servizio non sia scaduta. Vedere: Entità servizio del servizio Azure Kubernetes e Credenziali per l'aggiornamento del servizio Azure Kubernetes.

È possibile ridimensionare il cluster del servizio Azure Kubernetes a zero?

È possibile arrestare completamente un cluster del servizio Azure Kubernetes in esecuzione, risparmiando sui rispettivi costi di calcolo. Inoltre, è anche possibile scegliere di ridimensionare o ridimensionare automaticamente tutti i Userpool di nodi o specifici su 0, mantenendo solo la configurazione del cluster necessaria.

Non è possibile ridimensionare direttamente i pool di nodi di sistema a zero.

È possibile usare le API del set di scalabilità di macchine virtuali per il ridimensionamento manuale?

No, le operazioni di ridimensionamento con le API del set di scalabilità di macchine virtuali non sono supportate. Usare le API del servizio Azure Kubernetes (az aks scale).

È possibile usare i set di scalabilità di macchine virtuali per il ridimensionamento manuale a zero nodi?

No, le operazioni di ridimensionamento con le API del set di scalabilità di macchine virtuali non sono supportate. È possibile usare l'API del servizio Azure Kubernetes per ridimensionare fino a zero pool di nodi non di sistema o arrestare il cluster.

È possibile arrestare o deallocare tutte le VM?

Anche se il servizio Azure Kubernetes include meccanismi di resilienza per tollerare una configurazione di questo tipo ed eseguire il successivo ripristino, questa configurazione non è consigliata. Arrestare invece il cluster.

È possibile usare estensioni di VM personalizzate?

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.

AKS archivia i dati dei clienti all'esterno dell'area del cluster?

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

Le immagini del servizio Azure Kubernetes sono necessarie per l'esecuzione come radice?

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

Che cos'è la modalità trasparente CNI (Azure Container Networking Interface) di Azure rispetto a modalità Bridge?

A partire dalla versione 1.2.0, Azure CNI imposta la modalità Trasparente come predefinita per le distribuzioni CNI linux a tenancy singola. La modalità Trasparente sostituisce la modalità bridge. Nelle sezioni modalità Bridge e Modalità trasparente seguenti vengono illustrate in dettaglio le differenze tra entrambe le modalità e i vantaggi e le limitazioni per la modalità Transparent in Azure CNI.

Modalità bridge

La modalità Bridge CNI di Azure crea un bridge L2 denominato "azure0" in modo "just-in-time". Tutte le interfacce della coppia pod veth sul lato host sono connesse a questo bridge. Pod-Pod all'interno della comunicazione tra macchine virtuali e il traffico rimanente passa attraverso questo bridge. Il bridge è un dispositivo virtuale di livello 2 che da solo non può ricevere o trasmettere nulla a meno che non si associano uno o più dispositivi reali. Per questo motivo, l'eth0 della macchina virtuale Linux deve essere convertita in un bridge subordinato in "azure0", che crea una topologia di rete complessa all'interno della macchina virtuale Linux. Come sintomo, CNI doveva gestire altre funzioni di rete, ad esempio gli aggiornamenti del server DNS.

L'esempio seguente mostra l'aspetto della configurazione della route IP in modalità Bridge. Indipendentemente dal numero di pod presenti nel nodo, esistono solo due route. La prima route indica che il traffico (escluso locale in azure0) passa al gateway predefinito della subnet tramite l'interfaccia con ip "src 10.240.0.4", ovvero l'indirizzo IP primario del nodo. Il secondo dice "10.20.x.x" spazio pod al kernel per decidere.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Modalità trasparente

La modalità Trasparente adotta un approccio semplice per configurare la rete Linux. In questa modalità, Azure CNI non modifica le proprietà dell'interfaccia eth0 nella macchina virtuale Linux. Questo approccio alla modifica delle proprietà di rete Linux consente di ridurre i problemi complessi relativi ai casi di angolo che i cluster potrebbero riscontrare con la modalità Bridge. In modalità Trasparente, Azure CNI crea e aggiunge interfacce di coppia pod veth sul lato host aggiunte alla rete host. La comunicazione tra pod e pod della macchina virtuale avviee tramite route IP aggiunte dall'interfaccia CNI. Essenzialmente, la comunicazione da pod a pod è superiore a livello 3 e le regole di routing L3 instradano il traffico dei pod.

Nell'esempio seguente viene illustrata l'installazione di una route IP in modalità Trasparente. L'interfaccia di ogni pod ottiene una route statica collegata, in modo che il traffico con l'INDIRIZZO IP del pod venga inviato direttamente all'interfaccia della coppia veth lato host del pod.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Vantaggi della modalità Trasparente

• Fornisce una mitigazione per le condizioni di corsa parallela del DNS conntrack ed evita i problemi di latenza DNS a 5 secondi senza la necessità di impostare il DNS locale del nodo (si può comunque utilizzare il DNS locale del nodo per motivi di prestazioni).
• Elimina la modalità bridge CNI di latenza DNS iniziale di 5 secondi introduce oggi a causa della configurazione del bridge "JUST-in-time".
• Uno dei casi di angolo in modalità Bridge è che Azure CNI non può continuare ad aggiornare il server DNS personalizzato elenca gli utenti aggiunti alla rete virtuale o alla scheda di interfaccia di rete. Questo scenario comporta la raccolta CNI solo della prima istanza dell'elenco di server DNS. Questo problema viene risolto in modalità Trasparente, perché CNI non modifica le proprietà eth0. Altre informazioni sono disponibili qui.
• Offre una migliore gestione del traffico UDP e della mitigazione per la tempesta di inondazioni UDP quando si verifica il timeout di ARP. In modalità Bridge, quando bridge non conosce un indirizzo MAC del pod di destinazione nella comunicazione da pod a pod all'interno della macchina virtuale, per impostazione predefinita, genera una tempesta del pacchetto a tutte le porte. Questo problema viene risolto in modalità Trasparente, perché non sono presenti dispositivi L2 nel percorso. Altre informazioni sono disponibili qui.
• La modalità trasparente offre prestazioni migliori nella comunicazione tra pod e pod di Intra VM in termini di velocità effettiva e latenza rispetto alla modalità Bridge.

Come evitare problemi di lentezza con l'impostazione della proprietà delle autorizzazioni quando il volume presenta numerosi file?

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.

È possibile usare librerie di crittografia FIPS con distribuzioni 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.

È possibile configurare gruppi di sicurezza di rete con il servizio Azure Kubernetes?

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.

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

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

Qual è lo scopo dell'estensione Linux del servizio Azure Kubernetes che viene visualizzata nelle istanze dei set di scalabilità di macchine virtuali Linux?

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.