Domande frequenti relative al servizio Azure KubernetesFrequently asked questions about Azure Kubernetes Service (AKS)

Questo articolo tratta alcune domande frequenti relative al servizio Azure Kubernetes.This article addresses frequent questions about Azure Kubernetes Service (AKS).

In quali aree di Azure è attualmente disponibile il servizio Azure Kubernetes?Which Azure regions currently provide AKS?

Per un elenco completo delle aree disponibili, vedere Aree e disponibilità del servizio Azure Kubernetes e disponibilità.For a complete list of available regions, see AKS regions and availability.

È possibile distribuire un cluster del servizio Azure Kubernetes tra più aree?Can I spread an AKS cluster across regions?

No.No. I cluster AKS sono risorse a livello di area e non possono estendersi in aree.AKS clusters are regional resources and can't span regions. 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.See best practices for business continuity and disaster recovery for guidance on how to create an architecture that includes multiple regions.

È possibile distribuire un cluster del servizio Azure Kubernetes tra zone di disponibilità?Can I spread an AKS cluster across availability zones?

Sì.Yes. È possibile distribuire un cluster del servizio Azure Kubernetes in una o più zone di disponibilità nelle aree che le supportano.You can deploy an AKS cluster across one or more availability zones in regions that support them.

È possibile limitare chi ha accesso al server API Kubernetes?Can I limit who has access to the Kubernetes API server?

Sì.Yes. Sono disponibili due opzioni per limitare l'accesso al server API:There are two options for limiting access to the API server:

  • 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.Use API Server Authorized IP Ranges if you want to maintain a public endpoint for the API server but restrict access to a set of trusted IP ranges.
  • Usare un cluster privato per limitare il server API in modo che sia accessibile solo dall'interno della rete virtuale.Use a private cluster if you want to limit the API server to only be accessible from within your virtual network.

È possibile avere dimensioni diverse delle VM in un singolo cluster?Can I have different VM sizes in a single cluster?

Sì, è possibile usare dimensioni diverse delle macchine virtuali nel cluster del servizio Azure Kubernetes creando più pool di nodi.Yes, you can use different virtual machine sizes in your AKS cluster by creating multiple node pools.

Gli aggiornamenti della sicurezza vengono applicati ai nodi agente servizio Azure Kubernetes?Are security updates applied to AKS agent nodes?

Azure applica automaticamente le patch di sicurezza ai nodi Linux del cluster in base a una pianificazione notturna.Azure automatically applies security patches to the Linux nodes in your cluster on a nightly schedule. Tuttavia, l'utente è responsabile di assicurarsi che questi nodi Linux vengano riavviati in modo obbligatorio.However, you're responsible for ensuring that those Linux nodes are rebooted as required. Sono disponibili diverse opzioni per il riavvio dei nodi:You have several options for rebooting nodes:

Nodi di Windows ServerWindows Server nodes

Per i nodi di Windows Server, Windows Update non viene eseguito automaticamente per applicare gli aggiornamenti più recenti.For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. 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.On a regular schedule around the Windows Update release cycle and your own validation process, you should perform an upgrade on the cluster and the Windows Server node pool(s) in your AKS cluster. Questo processo di aggiornamento crea nodi che eseguono la versione più recente dell'immagine e delle patch di Windows Server e quindi rimuove i nodi precedenti.This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. Per altre informazioni su questo processo, vedere Aggiornare un pool di nodi nel servizio Azure Kubernetes.For more information on this process, see Upgrade a node pool in AKS.

Perché vengono creati due gruppi di risorse con servizio Azure Kubernetes?Why are two resource groups created with AKS?

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.AKS builds upon a number of Azure infrastructure resources, including virtual machine scale sets, virtual networks, and managed disks. In questo modo è possibile sfruttare molte funzionalità essenziali della piattaforma Azure all'interno dell'ambiente Kubernetes gestito fornito dal servizio Azure Kubernetes.This enables you to leverage many of the core capabilities of the Azure platform within the managed Kubernetes environment provided by 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.For example, most Azure virtual machine types can be used directly with AKS and Azure Reservations can be used to receive discounts on those resources automatically.

Per rendere disponibile questa architettura, ogni distribuzione del servizio Azure Kubernetes include due gruppi di risorse:To enable this architecture, each AKS deployment spans two resource groups:

  1. Si crea il primo gruppo di risorse.You create the first resource group. Questo gruppo contiene solo la risorsa del servizio Kubernetes.This group contains only the Kubernetes service resource. Il provider di risorse del servizio Azure Kubernetes crea automaticamente il secondo gruppo di risorse durante la distribuzione.The AKS resource provider automatically creates the second resource group during deployment. Un esempio del secondo gruppo di risorse è MC_myResourceGroup_myAKSCluster_eastus.An example of the second resource group is MC_myResourceGroup_myAKSCluster_eastus. Per informazioni su come specificare il nome di questo secondo gruppo di risorse, vedere la sezione successiva.For information on how to specify the name of this second resource group, see the next section.
  2. Il secondo gruppo di risorse, noto come gruppo di risorse nodo, contiene tutte le risorse di infrastruttura associate al cluster,The second resource group, known as the node resource group, contains all of the infrastructure resources associated with the cluster. come ad esempio le macchine virtuali dei nodi Kubernetes, le risorse della rete virtuale e di archiviazione.These resources include the Kubernetes node VMs, virtual networking, and storage. Per impostazione predefinita, il gruppo di risorse nodo ha un nome simile a MC_myResourceGroup_myAKSCluster_eastus.By default, the node resource group has a name like MC_myResourceGroup_myAKSCluster_eastus. AKS Elimina automaticamente la risorsa del nodo ogni volta che il cluster viene eliminato, quindi deve essere usato solo per le risorse che condividono il ciclo di vita del cluster.AKS automatically deletes the node resource whenever the cluster is deleted, so it should only be used for resources that share the cluster's lifecycle.

È possibile specificare un nome personalizzato per il gruppo di risorse nodo del servizio Azure Kubernetes?Can I provide my own name for the AKS node resource group?

Sì.Yes. 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.By default, AKS will name the node resource group MC_resourcegroupname_clustername_location, but you can also provide your own name.

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.To specify your own resource group name, install the aks-preview Azure CLI extension version 0.3.2 or later. Quando si crea un cluster AKS usando il comando AZ AKS create , usare il --node-resource-group parametro e specificare un nome per il gruppo di risorse.When you create an AKS cluster by using the az aks create command, use the --node-resource-group parameter and specify a name for the resource group. 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.If you use an Azure Resource Manager template to deploy an AKS cluster, you can define the resource group name by using the nodeResourceGroup property.

  • Il gruppo di risorse secondario viene creato automaticamente dal provider di risorse di Azure nella propria sottoscrizione.The secondary resource group is automatically created by the Azure resource provider in your own subscription.
  • È possibile specificare un nome di gruppo di risorse personalizzato solo quando si crea il cluster.You can specify a custom resource group name only when you're creating the cluster.

Quando si lavora con il gruppo di risorse del nodo, tenere presente che non è possibile:As you work with the node resource group, keep in mind that you can't:

  • Specificare un gruppo di risorse esistente come gruppo di risorse del nodo.Specify an existing resource group for the node resource group.
  • Specificare una sottoscrizione diversa per il gruppo di risorse nodo.Specify a different subscription for the node resource group.
  • Cambiare il nome del gruppo di risorse nodo dopo la creazione del cluster.Change the node resource group name after the cluster has been created.
  • Specificare i nomi delle risorse gestite nel gruppo di risorse del nodo.Specify names for the managed resources within the node resource group.
  • Modificare o eliminare i tag creati da Azure delle risorse gestite all'interno del gruppo di risorse del nodo.Modify or delete Azure-created tags of managed resources within the node resource group. Per altre informazioni, vedere la sezione successiva.(See additional information in the next section.)

È possibile modificare i tag e altre proprietà delle risorse del servizio Azure Kubernetes nel gruppo di risorse nodo?Can I modify tags and other properties of the AKS resources in the node resource group?

La modifica o l'eliminazione di tag creati da Azure e di altre proprietà delle risorse nel gruppo di risorse nodo può generare risultati imprevisti, ad esempio errori di dimensionamento e di aggiornamento.If you modify or delete Azure-created tags and other resource properties in the node resource group, you could get unexpected results such as scaling and upgrading errors. AKS consente di creare e modificare tag personalizzati creati dagli utenti finali ed è possibile aggiungere tali tag quando si Crea un pool di nodi.AKS allows you to create and modify custom tags created by end users, and you can add those tags when creating a node pool. Potrebbe essere necessario creare o modificare tag personalizzati da assegnare ad esempio a una business unit o a un centro di costo.You might want to create or modify custom tags, for example, to assign a business unit or cost center. Questa operazione può essere eseguita anche creando criteri di Azure con un ambito nel gruppo di risorse gestite.This can also be achieved by creating Azure Policies with a scope on the managed resource group.

Tuttavia, la modifica di eventuali tag creati da Azure sulle risorse nel gruppo di risorse nodo nel cluster AKS è un'azione non supportata, che interrompe l'obiettivo del livello di servizio (SLO).However, modifying any Azure-created tags on resources under the node resource group in the AKS cluster is an unsupported action, which breaks the service-level objective (SLO). Per altre informazioni, vedere Il servizio Azure Kubernetes offre un contratto di servizio?For more information, see Does AKS offer a service-level agreement?

Quali controller di ammissione Kubernetes supporta servizio Azure Kubernetes?What Kubernetes admission controllers does AKS support? È possibile aggiungere o rimuovere i controller di ammissione?Can admission controllers be added or removed?

Il servizio Azure Kubernetes supporta i seguenti controller di ammissione:AKS supports the following admission controllers:

  • NamespaceLifecycleNamespaceLifecycle
  • LimitRangerLimitRanger
  • ServiceAccountServiceAccount
  • DefaultStorageClassDefaultStorageClass
  • DefaultTolerationSecondsDefaultTolerationSeconds
  • MutatingAdmissionWebhookMutatingAdmissionWebhook
  • ValidatingAdmissionWebhookValidatingAdmissionWebhook
  • ResourceQuotaResourceQuota
  • PodNodeSelectorPodNodeSelector
  • PodTolerationRestrictionPodTolerationRestriction
  • ExtendedResourceTolerationExtendedResourceToleration

Attualmente non è possibile modificare l'elenco di controller di ammissione nel servizio Azure Kubernetes.Currently, you can't modify the list of admission controllers in AKS.

È possibile usare webhook dei controller di ammissione nel servizio Azure Kubernetes?Can I use admission controller webhooks on AKS?

Sì, è possibile usare webhook dei controller di ammissione nel servizio Azure Kubernetes.Yes, you may use admission controller webhooks on AKS. È consigliabile escludere gli spazi dei nomi AKS interni, contrassegnati con l' etichetta del piano di controllo.It's recommended you exclude internal AKS namespaces, which are marked with the control-plane label. Ad esempio, aggiungere quanto segue alla configurazione del webhook:For example, by adding the below to the webhook configuration:

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

AKS firewall il server API in uscita in modo che i webhook del controller di ammissione debbano essere accessibili dal cluster.AKS firewalls the API server egress so your admission controller webhooks need to be accessible from within the cluster.

I webhook dei controller di ammissione possono influire sugli spazi dei nomi di kube-system e su quelli interni del servizio Azure Kubernetes?Can admission controller webhooks impact kube-system and internal AKS namespaces?

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.To protect the stability of the system and prevent custom admission controllers from impacting internal services in the kube-system, namespace AKS has an Admissions Enforcer, which automatically excludes kube-system and AKS internal namespaces. Questo servizio garantisce che i controller di ammissione personalizzati non influiscano sui servizi in esecuzione in kube-system.This service ensures the custom admission controllers don't affect the services running in kube-system.

Se si ha un caso d'uso critico per una distribuzione obbligatoria in kube-system (scelta non consigliata), che è necessario coprire con il webhook di ammissione personalizzato, è possibile aggiungere l'etichetta o l'annotazione seguente in modo che Admissions Enforcers lo ignori.If you have a critical use case for having something deployed on kube-system (not recommended) which you require to be covered by your custom admission webhook, you may add the below label or annotation so that Admissions Enforcer ignores it.

Etichetta "admissions.enforcer/disabled": "true" o annotazione "admissions.enforcer/disabled": trueLabel: "admissions.enforcer/disabled": "true" or Annotation: "admissions.enforcer/disabled": true

Azure Key Vault è integrato in servizio Azure Kubernetes?Is Azure Key Vault integrated with AKS?

Il servizio Azure Kubernetes non è attualmente integrato in modalità nativa in Azure Key Vault.AKS isn't currently natively integrated with Azure Key Vault. Tuttavia, il provider di Azure Key Vault per l'archivio di segreti CSI consente l'integrazione diretta dai pod di Kubernetes ai segreti di Key Vault.However, the Azure Key Vault provider for CSI Secrets Store enables direct integration from Kubernetes pods to Key Vault secrets.

È possibile eseguire contenitori Windows Server in servizio Azure Kubernetes?Can I run Windows Server containers on AKS?

Sì, i contenitori di Windows Server sono disponibili nel servizio Azure Kubernetes.Yes, Windows Server containers are available on AKS. Per eseguire i contenitori di Windows Server nel servizio Azure Kubernetes, creare un pool di nodi che esegue Windows Server come sistema operativo guest.To run Windows Server containers in AKS, you create a node pool that runs Windows Server as the guest OS. I contenitori di Windows Server possono usare solo Windows Server 2019.Windows Server containers can use only Windows Server 2019. Per iniziare, vedere Creare un cluster del servizio Azure Kubernetes con un pool di nodi di Windows Server.To get started, see Create an AKS cluster with a Windows Server node pool.

Il supporto di Windows Server per il pool di nodi include alcune limitazioni che fanno parte di Windows Server upstream nel progetto Kubernetes.Windows Server support for node pool includes some limitations that are part of the upstream Windows Server in Kubernetes project. Per altre informazioni su queste limitazioni, vedere Limitazioni dei contenitori di Windows Server nel servizio Azure Kubernetes.For more information on these limitations, see Windows Server containers in AKS limitations.

Il servizio Azure Kubernetes offre un contratto di servizio?Does AKS offer a service-level agreement?

AKS fornisce garanzie per il contratto di servizio come funzionalità facoltativa del componente aggiuntivo con contratto di servizio con tempo di esecuzione.AKS provides SLA guarantees as an optional add-on feature with Uptime SLA.

È possibile applicare gli sconti per le prenotazioni di Azure ai nodi dell'agente del servizio Azure Kubernetes?Can I apply Azure reservation discounts to my AKS agent nodes?

I nodi dell'agente AKS vengono fatturati come macchine virtuali standard di Azure, pertanto se sono state acquistate prenotazioni di Azure per le dimensioni della macchina virtuale in uso nel servizio contenitore di Azure, tali sconti vengono applicati automaticamente.AKS agent nodes are billed as standard Azure virtual machines, so if you've purchased Azure reservations for the VM size that you're using in AKS, those discounts are automatically applied.

È possibile spostare o eseguire la migrazione del cluster tra tenant di Azure?Can I move/migrate my cluster between Azure tenants?

Lo stato di trasferimento del cluster AKS tra i tenant non è al momento supportato.Moving your AKS cluster between tenants is currently unsupported.

È possibile spostare o eseguire la migrazione del cluster tra sottoscrizioni?Can I move/migrate my cluster between subscriptions?

Lo spostamento di cluster tra sottoscrizioni non è al momento supportato.Movement of clusters between subscriptions is currently unsupported.

È possibile spostare i cluster del servizio Azure Kubernetes dalla sottoscrizione di Azure corrente a un'altra?Can I move my AKS clusters from the current Azure subscription to another?

Lo stato di trasferimento del cluster AKS e delle risorse associate tra le sottoscrizioni di Azure non è supportato.Moving your AKS cluster and its associated resources between Azure subscriptions isn't supported.

È possibile spostare il cluster AKS o le risorse dell'infrastruttura AKS in altri gruppi di risorse o rinominarli?Can I move my AKS cluster or AKS infrastructure resources to other resource groups or rename them?

Lo stato di trasferimento o ridenominazione del cluster AKS e delle risorse associate non è supportato.Moving or renaming your AKS cluster and its associated resources isn't supported.

Perché l'eliminazione del cluster richiede molto tempo?Why is my cluster delete taking so long?

La maggior parte dei cluster viene eliminata in seguito alla richiesta dell'utente. In alcuni casi, in particolare quando i clienti usano un gruppo di risorse personalizzato o eseguono l'eliminazione di attività tra più gruppi di risorse, l'operazione può richiedere più tempo oppure non riesce.Most clusters are deleted upon user request; in some cases, especially where customers are bringing their own Resource Group, or doing cross-RG tasks deletion can take additional time or fail. In caso di problemi con le eliminazioni, verificare che non siano presenti blocchi sull'RG, che tutte le risorse esterne all'RG siano dissociate dall'RG e così via.If you have an issue with deletes, double-check that you do not have locks on the RG, that any resources outside of the RG are disassociated from the RG, and so on.

Nel caso di pod/distribuzioni con lo stato 'NodeLost' o 'Unknown', è comunque possibile aggiornare il cluster?If I have pod / deployments in state 'NodeLost' or 'Unknown' can I still upgrade my cluster?

È possibile, ma AKS non lo consiglia.You can, but AKS doesn't recommend this. Gli aggiornamenti devono essere eseguiti quando lo stato del cluster è noto e integro.Upgrades should be performed when the state of the cluster is known and healthy.

Se un cluster include uno o più nodi arrestati o con uno stato non integro, è possibile eseguire un aggiornamento?If I have a cluster with one or more nodes in an Unhealthy state or shut down, can I perform an upgrade?

No, eliminare o rimuovere tutti i nodi in uno stato di errore o rimossi in altro modo dal cluster prima di eseguire l'aggiornamento.No, delete/remove any nodes in a failed state or otherwise removed from the cluster prior to upgrading.

Dopo l'eliminazione di un cluster viene visualizzato l'errore [Errno 11001] getaddrinfo failed. Perché?I ran a cluster delete, but see the error [Errno 11001] getaddrinfo failed

In genere, questo problema è dovuto al fatto che gli utenti hanno uno o più gruppi di sicurezza di rete ancora in uso e associati al cluster.Most commonly, this is caused by users having one or more Network Security Groups (NSGs) still in use and associated with the cluster. Rimuoverli e ritentare l'eliminazione.Remove them and attempt the delete again.

Dopo un aggiornamento, si verificano arresti anomali ciclici dei pod e i probe di idoneità restituiscono un errore. Come si risolve il problema?I ran an upgrade, but now my pods are in crash loops, and readiness probes fail?

Verificare che l'entità servizio non sia scaduta.Confirm your service principal hasn't expired. Vedere: AKS Service Principal e AKS Update Credentials.See: AKS service principal and AKS update credentials.

Il mio cluster funzionava, ma improvvisamente non riesce a effettuare il provisioning di LoadBalancers, montare PVC e così via?My cluster was working, but suddenly can't provision LoadBalancers, mount PVCs, etc.?

Verificare che l'entità servizio non sia scaduta.Confirm your service principal hasn't expired. Vedere: AKS Service Principal e AKS Update Credentials.See: AKS service principal and AKS update credentials.

È possibile ridimensionare il cluster AKS a zero?Can I scale my AKS cluster to zero?

È possibile arrestare completamente un cluster AKS in esecuzione, risparmiando sui rispettivi costi di calcolo.You can completely stop a running AKS cluster, saving on the respective compute costs. Inoltre, è anche possibile scegliere di ridimensionare o ridimensionare automaticamente tutti i User pool di nodi o specifici in 0, mantenendo solo la configurazione del cluster necessaria.Additionally, you may also choose to scale or autoscale all or specific User node pools to 0, maintaining only the necessary cluster configuration. Non è possibile ridimensionare direttamente i pool di nodi di sistema a zero.You can't directly scale system node pools to zero.

È possibile usare le API del set di scalabilità di macchine virtuali per il ridimensionamento manuale?Can I use the virtual machine scale set APIs to scale manually?

No, le operazioni di ridimensionamento con le API del set di scalabilità di macchine virtuali non sono supportate.No, scale operations by using the virtual machine scale set APIs aren't supported. Usare le API del servizio Azure Kubernetes (az aks scale).Use the AKS APIs (az aks scale).

È possibile usare I set di scalabilità di macchine virtuali per scalare manualmente fino a zero nodi?Can I use virtual machine scale sets to manually scale to zero nodes?

No, le operazioni di ridimensionamento con le API del set di scalabilità di macchine virtuali non sono supportate.No, scale operations by using the virtual machine scale set APIs aren't supported. È possibile usare l'API AKS per la scalabilità a zero pool di nodi non di sistema o per arrestare il cluster .You can use the AKS API to scale to zero non-system node pools or stop your cluster instead.

È possibile arrestare o deallocare tutte le VM?Can I stop or de-allocate all my VMs?

Sebbene AKS includa meccanismi di resilienza per supportare tale configurazione ed eseguire il ripristino da tale configurazione, questa non è una configurazione supportata.While AKS has resilience mechanisms to withstand such a config and recover from it, this isn't a supported configuration. Arrestare invece il cluster .Stop your cluster instead.

È possibile usare estensioni di VM personalizzate?Can I use custom VM extensions?

L'agente di Log Analytics è supportato perché è un'estensione gestita da Microsoft.The Log Analytics agent is supported because it's an extension managed by Microsoft. In caso contrario, AKS è un servizio gestito e la manipolazione delle risorse IaaS non è supportata.Otherwise no, AKS is a managed service, and manipulation of the IaaS resources isn't supported. Per installare i componenti personalizzati, usare le API e i meccanismi di Kubernetes.To install custom components, use the Kubernetes APIs and mechanisms. Ad esempio, usare gli elementi daemonset per installare i componenti richiesti.For example, use DaemonSets to install required components.

AKS archivia i dati dei clienti al di fuori dell'area del cluster?Does AKS store any customer data outside of the cluster's region?

La funzionalità che consente di archiviare i dati dei clienti in una singola area è attualmente disponibile solo nell'area Asia sudorientale (Singapore) del Asia Pacifico Geo.The feature to enable storing customer data in a single region is currently only available in the Southeast Asia Region (Singapore) of the Asia Pacific Geo. Per tutte le altre aree i dati dei clienti vengono archiviati in Geo.For all other regions, customer data is stored in Geo.

Le immagini AKS sono necessarie per l'esecuzione come radice?Are AKS images required to run as root?

Ad eccezione delle due immagini seguenti, le immagini AKS non devono essere eseguite come radice:Except for the following two images, AKS images aren't required to run as root:

  • mcr.microsoft.com/oss/kubernetes/corednsmcr.microsoft.com/oss/kubernetes/coredns
  • mcr.microsoft.com/azuremonitor/containerinsights/ciprodmcr.microsoft.com/azuremonitor/containerinsights/ciprod

Che cos'è la modalità trasparente di Azure CNI rispetto alla modalità Bridge?What is Azure CNI Transparent Mode vs. Bridge Mode?

Da v 1.2.0 Azure CNI avrà la modalità Transparent come predefinita per le distribuzioni CNI di Linux con tenant singolo.From v1.2.0 Azure CNI will have Transparent mode as default for single tenancy Linux CNI deployments. La modalità trasparente sostituisce la modalità Bridge.Transparent mode is replacing bridge mode. In questa sezione verranno illustrate in dettaglio le differenze relative a entrambe le modalità e quali sono i vantaggi e le limitazioni per l'uso della modalità trasparente in Azure CNI.In this section, we will discuss more about the differences about both modes and what are the benefits/limitation for using Transparent mode in Azure CNI.

Modalità BridgeBridge mode

Come suggerisce il nome, in modalità Bridge Azure CNI, in un modo "just in Time", creerà un Bridge L2 denominato "azure0".As the name suggests, bridge mode Azure CNI, in a "just in time" fashion, will create a L2 bridge named "azure0". Tutte le interfacce delle coppie Pod lato host veth saranno connesse a questo Bridge.All the host side pod veth pair interfaces will be connected to this bridge. Quindi Pod-Pod la comunicazione tra macchine virtuali e il traffico rimanente passa attraverso questo Bridge.So Pod-Pod intra VM communication and the remaining traffic goes through this bridge. Il Bridge in questione è un dispositivo virtuale di livello 2 che non è in grado di ricevere o trasmettere, a meno che non venga associato uno o più dispositivi reali.The bridge in question is a layer 2 virtual device that on its own cannot receive or transmit anything unless you bind one or more real devices to it. Per questo motivo, eth0 della VM Linux deve essere convertita in un Bridge subordinato a "azure0".For this reason, eth0 of the Linux VM has to be converted into a subordinate to "azure0" bridge. In questo modo viene creata una topologia di rete complessa all'interno della VM Linux e come sintomo CNI ha dovuto occuparsi di altre funzioni di rete come l'aggiornamento del server DNS e così via.This creates a complex network topology within the Linux VM and as a symptom CNI had to take care of other networking functions like DNS server update and so on.

Topologia in modalità Bridge

Di seguito è riportato un esempio di come viene visualizzata la configurazione della route IP in modalità Bridge.Below is an example of how the ip route setup looks like in Bridge mode. Indipendentemente dal numero di Pod del nodo, saranno presenti solo due route.Regardless of how many pods the node has, there will only ever be two routes. Il primo dice che tutto il traffico, escluso il locale in azure0, viene indirizzato al gateway predefinito della subnet tramite l'interfaccia con IP "src 10.240.0.4" (che è l'IP primario del nodo) e la seconda la parola "10.20. x. x" Pod per il kernel per la decisione del kernel.The first one saying, all traffic excluding local on azure0 will go to the default gateway of the subnet through the interface with ip "src 10.240.0.4" (which is Node primary IP) and the second one saying "10.20.x.x" Pod space to kernel for kernel to decide.

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à trasparenteTransparent mode

La modalità trasparente prevede un approccio semplice per la configurazione della rete Linux.Transparent mode takes a straight forward approach to setting up Linux networking. In questa modalità, Azure CNI non modificherà alcuna proprietà dell'interfaccia eth0 nella VM Linux.In this mode, Azure CNI won't change any properties of eth0 interface in the Linux VM. Questo approccio minimo per modificare le proprietà di rete di Linux consente di ridurre i problemi di casi d'angolo complessi che i cluster potrebbero affrontare con la modalità Bridge.This minimal approach of changing the Linux networking properties helps reduce complex corner case issues that clusters could face with Bridge mode. In modalità trasparente, Azure CNI creerà e aggiungerà veth le interfacce di coppia pod sul lato host che verranno aggiunte alla rete host.In Transparent Mode, Azure CNI will create and add host-side pod veth pair interfaces that will be added to the host network. La comunicazione da Pod a Pod tra macchine virtuali avviene tramite route IP che i CNI aggiungono.Intra VM Pod-to-Pod communication is through ip routes that the CNI will add. Essenzialmente la comunicazione da Pod a Pod è basata sul livello 3 e il traffico Pod viene instradato in base alle regole di routing L3.Essentially Pod-to-Pod communication is over layer 3 and pod traffic is routed by L3 routing rules.

Topologia in modalità trasparente

Di seguito è riportato un esempio di configurazione della route IP in modalità trasparente. ogni interfaccia del Pod otterrà una route statica collegata in modo che il traffico con l'indirizzo IP di destinazione come Pod venga inviato direttamente all'interfaccia della coppia lato host del Pod veth .Below is an example ip route setup of transparent mode, each Pod's interface will get a static route attached so that traffic with dest IP as the Pod will be sent directly to the Pod's host side veth pair interface.

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à trasparenteBenefits of transparent mode

  • Fornisce la mitigazione per la conntrack race condition parallela DNS e la prevenzione di problemi di latenza DNS di 5 secondi senza la necessità di configurare il DNS locale del nodo. per motivi di prestazioni, è comunque possibile utilizzare il DNS locale del nodo.Provides mitigation for conntrack DNS parallel race condition and avoidance of 5-sec DNS latency issues without the need to set up node local DNS (you may still use node local DNS for performance reasons).
  • Elimina la latenza DNS iniziale di 5 secondi che la modalità Bridge CNI introduce oggi grazie alla configurazione del Bridge "just-in-Time".Eliminates the initial 5-sec DNS latency CNI bridge mode introduces today due to "just in time" bridge setup.
  • Uno dei casi estremi in modalità Bridge è che Azure CNI non è in grado di aggiornare il server DNS personalizzato elenca gli utenti Aggiungi a VNET o NIC.One of the corner cases in bridge mode is that the Azure CNI can't keep updating the custom DNS server lists users add to either VNET or NIC. In questo modo, CNI preleva solo la prima istanza dell'elenco di server DNS.This results in the CNI picking up only the first instance of the DNS server list. Risolto in modalità trasparente perché CNI non modifica alcuna proprietà eth0.Solved in Transparent mode as CNI doesn't change any eth0 properties. Per altre informazioni, vedere qui.See more here.
  • Fornisce una gestione migliore del traffico UDP e della mitigazione per il Storm Flood di 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 tra macchine virtuali, in base alla progettazione, questa operazione comporta Storm del pacchetto per tutte le porte.Provides better handling of UDP traffic and mitigation for UDP flood storm when ARP times out. In bridge mode, when bridge doesn't know a MAC address of destination pod in intra-VM Pod-to-Pod communication, by design, this results in storm of the packet to all ports. Risolto in modalità trasparente perché non sono presenti dispositivi L2 nel percorso.Solved in Transparent mode as there are no L2 devices in path. Per altre informazioni, vedere qui.See more here.
  • La modalità trasparente garantisce prestazioni migliori in termini di velocità effettiva e latenza rispetto alla modalità Bridge tra macchine virtuali intra-pod.Transparent mode performs better in Intra VM Pod-to-Pod communication in terms of throughput and latency when compared to bridge mode.

Come evitare l'impostazione di proprietà delle autorizzazioni lente quando il volume contiene numerosi file?How to avoid permission ownership setting slow issues when the volume has a lot of files?

Tradizionalmente, se il Pod viene eseguito come utente non root (che dovrebbe essere), è necessario specificare un oggetto fsGroup all'interno del contesto di sicurezza del Pod, in modo che il volume possa essere leggibile e scrivibile dal Pod.Traditionally if your pod is running as a non-root user (which you should), you must specify a fsGroup inside the pod’s security context so that the volume can be readable and writable by the Pod. Questo requisito viene trattato in modo più dettagliato in questo argomento.This requirement is covered in more detail in here.

Un effetto collaterale dell'impostazione fsGroup è che, ogni volta che un volume viene montato, Kubernetes deve essere ricorsivo chown() e chmod() tutti i file e le directory all'interno del volume, con alcune eccezioni indicate di seguito.But one side-effect of setting fsGroup is that, each time a volume is mounted, Kubernetes must recursively chown() and chmod() all the files and directories inside the volume - with a few exceptions noted below. Ciò si verifica anche se la proprietà del gruppo del volume corrisponde già alla richiesta fsGroup e può essere piuttosto costosa per i volumi di grandi dimensioni con un numero elevato di file di piccole dimensioni, causando molto tempo per l'avvio di Pod.This happens even if group ownership of the volume already matches the requested fsGroup, and can be pretty expensive for larger volumes with lots of small files, which causes pod startup to take a long time. Questo scenario è un problema noto prima della versione 1.20 e la soluzione alternativa consiste nell'impostare l'esecuzione del pod come radice:This scenario has been a known problem before v1.20 and the workaround is setting the Pod run as root:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Il problema è stato risolto da Kubernetes v 1.20, vedere Kubernetes 1,20: controllo granulare delle modifiche delle autorizzazioni per i volumi per altri dettagli.The issue has been resolved by Kubernetes v1.20, refer Kubernetes 1.20: Granular Control of Volume Permission Changes for more details.