**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Scopri come funziona EKS Auto Mode Utilizza questo capitolo per scoprire come funzionano i componenti dei cluster di Amazon EKS Auto Mode. **Topics** + [Informazioni sulle istanze gestite della modalità automatica di Amazon EKS](automode-learn-instances.md) + [Informazioni su identità e accesso in modalità automatica di EKS](auto-learn-iam.md) + [Informazioni sulla rete VPC e sul bilanciamento del carico in modalità automatica di EKS](auto-networking.md) # Informazioni sulle istanze gestite della modalità automatica di Amazon EKS Questo argomento spiega come Amazon EKS Auto Mode gestisce EC2 le istanze Amazon nel tuo cluster EKS. Quando abiliti la modalità automatica EKS, le risorse di calcolo del cluster vengono automaticamente fornite e gestite da EKS, cambiando il modo in cui interagisci con le EC2 istanze che fungono da nodi nel cluster. Comprendere come la modalità automatica di Amazon EKS gestisce le istanze è essenziale per pianificare la strategia di implementazione dei carichi di lavoro e le procedure operative. A differenza delle EC2 istanze tradizionali o dei gruppi di nodi gestiti, queste istanze seguono un modello di ciclo di vita diverso in cui EKS si assume la responsabilità di molti aspetti operativi, limitando al contempo determinati tipi di accesso e personalizzazione. La modalità automatica di Amazon EKS automatizza le attività di routine per la creazione di nuove EC2 istanze e le collega come nodi al cluster EKS. La modalità automatica EKS rileva quando un carico di lavoro non può adattarsi ai nodi esistenti e crea una nuova istanza. EC2 La modalità automatica di Amazon EKS è responsabile della creazione, dell'eliminazione e dell'applicazione di patch EC2 alle istanze. Sei responsabile dei container e dei pod implementati sull’istanza. EC2 Le istanze create da EKS Auto Mode sono diverse dalle altre EC2 istanze, sono istanze gestite. Queste istanze gestite sono di proprietà di EKS e sono più limitate. Non puoi accedere o installare direttamente il software sulle istanze gestite dalla modalità automatica EKS. AWS suggerisce di eseguire EKS Auto Mode o Karpenter autogestito. Puoi installarli sia durante una migrazione che in una configurazione avanzata. Se hai già installato entrambi, configura i pool di nodi in modo tale che i carichi di lavoro siano associati a Karpenter o modalità automatica EKS. Per ulteriori informazioni, consulta le [istanze EC2 gestite da Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) nella guida per l' EC2 utente di Amazon. ## Tabella di confronto | Istanza standard EC2 | Istanza gestita dalla modalità automatica EKS | | --- | --- | | Sei responsabile dell’applicazione di patch e dell’aggiornamento dell’istanza. | AWS corregge e aggiorna automaticamente l'istanza. | | EKS non è responsabile del software sull’istanza. | EKS è responsabile di determinati software sull’istanza, come `kubelet`, il runtime del container e il sistema operativo. | | È possibile eliminare l' EC2 istanza utilizzando l' EC2 API. | EKS determina il numero di istanze implementate nell’account. Se elimini un carico di lavoro, EKS ridurrà il numero di istanze nell’account. | | È possibile utilizzare SSH per accedere all' EC2 istanza. | Puoi implementare pod e container nell’istanza gestita. | | Puoi determinare il sistema operativo e l’immagine (AMI). | AWS determina il sistema operativo e l'immagine. | | Puoi implementare carichi di lavoro che si basano sulle funzionalità di Windows o Ubuntu. | Puoi distribuire container basati su Linux, ma senza dipendenze specifiche del sistema operativo. | | Puoi determinare il tipo e la famiglia di istanze da avviare. | AWS determina il tipo e la famiglia di istanze da avviare. Puoi utilizzare un pool di nodi per limitare i tipi di istanze tra cui la modalità automatica EKS effettua la selezione. | Le seguenti funzionalità sono valide sia per le istanze gestite che per le EC2 istanze standard: + È possibile visualizzare l'istanza nella AWS console. + Puoi utilizzare lo storage delle istanze come storage temporaneo per i carichi di lavoro. ### Supporto AMI Con EKS Auto Mode, AWS determina l'immagine (AMI) utilizzata per i nodi di calcolo. AWS monitora il lancio delle nuove versioni AMI EKS Auto Mode. Se riscontri problemi di carico di lavoro relativi a una versione AMI, crea una richiesta di supporto. Per ulteriori informazioni, consulta [Creazione di casi di supporto e gestione dei casi](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) nella AWS Support User Guide. In genere, EKS rilascia una nuova AMI ogni settimana contenente CVE e correzioni di sicurezza. ## Riferimento all’istanza supportata dalla modalità automatica EKS La modalità automatica EKS crea solo istanze dei tipi supportati e che soddisfano un requisito di dimensione minima. modalità automatica di EKS supporta i tipi di istanza indicati di seguito: | Family | Tipi di istanza | | --- | --- | | Compute Optimized (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5d, c5d annuncio, c5n, c4 | | General Purpose (M) | m8i, m8i-flex, m8a, m8gn, 8mb, m8gd, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6m, m6m, m6idn, m6id, m6gd, m5a, m5a, m5, m5n, m5dn, m5d, m5zn, m4 | | Memory Optimized (R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5a, r5d, r5a, r5a, r5d, r5a, r5d, r5a, r5a, r5d, r5a, r5d, r5a, r5a, r5d, r5a, r5d, r5a, r5a, r5d, r5a, r5d, r5a, r5d, r5a, r5a, r5b, 5ad, 5d, 4r | | Burstable (T) | t4g, t3, t3a, t2 | | High Memory (Z/X) | z1d, x8g, x2gd | | Storage Optimized (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn | | P/G/Inf/TrnCalcolo accelerato () | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n | | High Performance Computing (X2) | x2iezn, x2iedn, x2idn | Inoltre, EKS Auto Mode creerà solo EC2 istanze che soddisfano i seguenti requisiti: + Più di 1 CPU + Le dimensioni delle istanze non sono nano, micro o piccole Per ulteriori informazioni, consulta le [convenzioni di denominazione dei tipi di EC2 istanze di Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html). ## Servizio di metadati dell’istanza + La modalità automatica EKS viene applicata IMDSv2 con un limite di hop pari a 1 per impostazione predefinita, aderendo alle AWS migliori pratiche di sicurezza. + Questa configurazione predefinita non può essere modificata in modalità automatica. + Per i componenti aggiuntivi che in genere richiedono l'accesso a IMDS, fornite i parametri (come la AWS regione) durante l'installazione per evitare le ricerche IMDS. Per ulteriori informazioni, consulta [Determina i campi che puoi personalizzare per i componenti aggiuntivi Amazon EKS](kubernetes-field-management.md). + Se un Pod richiede assolutamente l’accesso IMDS quando viene eseguito in modalità automatica, il Pod deve essere configurato per funzionare con `hostNetwork: true`. Ciò consente al Pod di accedere direttamente al servizio di metadati dell’istanza. + Considerare le implicazioni sulla sicurezza quando si concede ai Pod l’accesso ai metadati dell’istanza. Per ulteriori informazioni su Amazon EC2 Instance Metadata Service (IMDS), consulta le opzioni di [Configurazione delle opzioni del servizio di metadati dell'istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) nella *Amazon EC2 * User Guide. ## Considerazioni + Se lo storage temporaneo configurato in NodeClass è più piccolo dello storage NVMe locale per l'istanza, EKS Auto Mode elimina la necessità di una configurazione manuale eseguendo automaticamente le seguenti azioni: + Utilizza un volume inferiore di dati Amazon EBS (20 GiB) per ridurre i costi. + Formatta e configura l'archiviazione NVMe locale per l'uso temporaneo dei dati. Ciò include la configurazione di un array RAID 0 se sono presenti più unità. NVMe + Quando `ephemeralStorage.size` è uguale o superiore alla NVMe capacità locale, si verificano le seguenti azioni: + La modalità automatica salta il volume EBS piccolo. + Le NVMe unità sono esposte direttamente al carico di lavoro. + La modalità automatica di Amazon EKS non supporta le seguenti azioni del servizio AWS Fault Injection: + `ec2:RebootInstances` + `ec2:SendSpotInstanceInterruptions` + `ec2:StartInstances` + `ec2:StopInstances` + `ec2:TerminateInstances` + `ec2:PauseVolumeIO` + La modalità automatica di Amazon EKS supporta le azioni EKS Pod del servizio AWS Fault Injection. Per ulteriori informazioni, consulta [Managing AWS Fault Injection Service e Usa](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) [le azioni FIS aws:eks:pod](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) nella Guida per l' AWS utente di Resilience Hub. + Non devi installare il `Neuron Device Plugin` sui nodi della modalità automatica EKS. Se hai altri tipi di nodi nel cluster, devi configurare il plug-in Neuron Device in modo tale che non venga eseguito su nodi in modalità automatica. Per ulteriori informazioni, consulta [Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode](associate-workload.md). # Informazioni su identità e accesso in modalità automatica di EKS Questo argomento descrive i ruoli e le autorizzazioni di Identity and Access Management (IAM) necessari per utilizzare modalità automatica di EKS. La modalità automatica di EKS utilizza due ruoli IAM primari: un ruolo IAM del cluster e uno del nodo. Questi ruoli lavorano in combinazione con EKS Pod Identity e le voci di accesso EKS per fornire una gestione completa degli accessi per i cluster EKS. Quando configuri la modalità automatica EKS, dovrai configurare questi ruoli IAM con autorizzazioni specifiche che consentano ai AWS servizi di interagire con le risorse del cluster. Ciò include le autorizzazioni per la gestione delle risorse di elaborazione, dei volumi di archiviazione, dei bilanciatori del carico e dei componenti di rete. La comprensione di queste configurazioni dei ruoli è essenziale per il corretto funzionamento e la sicurezza del cluster. In EKS Auto Mode, i ruoli AWS IAM vengono mappati automaticamente alle autorizzazioni Kubernetes tramite le voci di accesso EKS, eliminando la necessità di configurazioni manuali o associazioni personalizzate. `aws-auth` ConfigMaps Quando crei un nuovo cluster in modalità auto, EKS crea automaticamente le autorizzazioni Kubernetes corrispondenti utilizzando le voci Access, assicurando che i AWS servizi e i componenti del cluster abbiano i livelli di accesso appropriati sia all'interno del sistema di autorizzazione che in Kubernetes. AWS Questa integrazione automatizzata riduce la complessità della configurazione e aiuta a prevenire i problemi relativi alle autorizzazioni che si verificano comunemente durante la gestione dei cluster EKS. ## Ruolo IAM del cluster Il ruolo Cluster IAM è un ruolo AWS Identity and Access Management (IAM) utilizzato da Amazon EKS per gestire le autorizzazioni per i cluster Kubernetes. Questo ruolo concede ad Amazon EKS le autorizzazioni necessarie per interagire con altri AWS servizi per conto del cluster e viene configurato automaticamente con le autorizzazioni Kubernetes utilizzando le voci di accesso EKS. + È necessario collegare AWS le politiche IAM a questo ruolo. + La modalità automatica di EKS assegna automaticamente le autorizzazioni Kubernetes a questo ruolo utilizzando le voci di accesso EKS. + Con EKS Auto Mode, AWS suggerisce di creare un singolo ruolo Cluster IAM per AWS account. + AWS suggerisce di assegnare un nome a questo ruolo`AmazonEKSAutoClusterRole`. + Questo ruolo richiede le autorizzazioni per più AWS servizi per gestire le risorse, inclusi volumi EBS, Elastic Load Balancer e istanze. EC2 + La configurazione suggerita per questo ruolo include più politiche IAM AWS gestite, correlate alle diverse funzionalità di EKS Auto Mode. + `AmazonEKSComputePolicy` + `AmazonEKSBlockStoragePolicy` + `AmazonEKSLoadBalancingPolicy` + `AmazonEKSNetworkingPolicy` + `AmazonEKSClusterPolicy` Per ulteriori informazioni sul ruolo Cluster IAM e sulle politiche IAM AWS gestite, consulta: + [AWS politiche gestite per Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md) Per ulteriori informazioni sull’accesso a Kubernetes, consulta: + [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md) ## Ruolo IAM del nodo Il ruolo Node IAM è un ruolo AWS Identity and Access Management (IAM) utilizzato da Amazon EKS per gestire le autorizzazioni per i nodi di lavoro nei cluster Kubernetes. Questo ruolo concede EC2 alle istanze che funzionano come nodi Kubernetes le autorizzazioni necessarie per interagire con AWS servizi e risorse e viene configurato automaticamente con le autorizzazioni RBAC di Kubernetes utilizzando le voci di accesso EKS. + È necessario collegare le politiche IAM a questo ruolo. AWS + La modalità automatica di EKS assegna automaticamente le autorizzazioni Kubernetes RBAC a questo ruolo utilizzando le voci di accesso EKS. + AWS suggerisce di assegnare un nome a questo ruolo`AmazonEKSAutoNodeRole`. + Con EKS Auto Mode, AWS suggerisce di creare un singolo ruolo IAM Node per AWS account. + Questo ruolo dispone di autorizzazioni limitate. Le autorizzazioni chiave includono l’assunzione di un ruolo Pod Identity e l’estrazione di immagini da ECR. + AWS suggerisce le seguenti politiche IAM AWS gestite: + `AmazonEKSWorkerNodeMinimalPolicy` + `AmazonEC2ContainerRegistryPullOnly` Per ulteriori informazioni sul ruolo IAM del cluster e sulle politiche IAM AWS gestite, consulta: + [AWS politiche gestite per Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Ruolo IAM del nodo Amazon EKS](create-node-role.md) Per ulteriori informazioni sull’accesso a Kubernetes, consulta: + [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md) ## Ruolo collegato al servizio Amazon EKS utilizza un ruolo collegato ai servizi (SLR) per determinate operazioni. Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. I ruoli collegati ai servizi sono predefiniti da Amazon EKS e includono tutte le autorizzazioni richieste dal servizio per chiamare altri AWS servizi per tuo conto. AWS crea e configura automaticamente la reflex. Puoi eliminare un SLR solo dopo aver eliminato le risorse correlate. Questa procedura protegge le risorse di Amazon EKS perché non puoi rimuovere involontariamente delle autorizzazioni di accesso alle risorse. La policy SLR concede ad Amazon EKS le autorizzazioni per osservare ed eliminare i componenti principali dell'infrastruttura: EC2 risorse (istanze, interfacce di rete, gruppi di sicurezza), risorse ELB (sistemi di bilanciamento del carico, gruppi target), CloudWatch funzionalità (registrazione e metriche) e ruoli IAM con prefisso «eks». Consente inoltre il networking privato degli endpoint tramite l'associazione di VPC/hosted zone e include autorizzazioni per il monitoraggio e la pulizia delle risorse con tag EKS. EventBridge Per ulteriori informazioni, consulta: + [AWS politica gestita: Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) + [Autorizzazioni del ruolo collegato ai servizi per Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) ## Tag personalizzati per AWS le risorse EKS Auto Per impostazione predefinita, le politiche gestite relative alla modalità automatica EKS non consentono l'applicazione di tag definiti dall'utente alle AWS risorse fornite da Auto Mode. Se si desidera applicare tag definiti dall'utente alle AWS risorse, è necessario assegnare autorizzazioni aggiuntive al ruolo Cluster IAM con autorizzazioni sufficienti per creare e modificare tag sulle risorse. AWS Di seguito è riportato un esempio di policy che consentirà l’accesso ai tag senza restrizioni: ### Visualizzare un esempio di policy sui tag personalizzata ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Compute", "Effect": "Allow", "Action": [ "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateLaunchTemplate" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-node-class-name": "*", "aws:RequestTag/eks:kubernetes-node-pool-name": "*" } } }, { "Sid": "Storage", "Effect": "Allow", "Action": [ "ec2:CreateVolume", "ec2:CreateSnapshot" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:snapshot/*" ], "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "Networking", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-cni-node-name": "*" } } }, { "Sid": "LoadBalancer", "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateRule", "ec2:CreateSecurityGroup" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldProtection", "Effect": "Allow", "Action": [ "shield:CreateProtection" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldTagResource", "Effect": "Allow", "Action": [ "shield:TagResource" ], "Resource": "arn:aws:shield::*:protection/*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } } ] } ``` ## Riferimento alla policy di accesso Per ulteriori informazioni sulle autorizzazioni di Kubernetes utilizzate dalla modalità automatica di EKS, consulta [Rivedere le autorizzazioni della policy di accesso](access-policy-permissions.md). # Informazioni sulla rete VPC e sul bilanciamento del carico in modalità automatica di EKS Questo argomento spiega come configurare le funzionalità di rete e bilanciamento del carico del cloud privato virtuale (VPC) in modalità automatica di EKS. Sebbene modalità automatica di EKS gestisca automaticamente la maggior parte dei componenti di rete, puoi comunque personalizzare alcuni aspetti della configurazione di rete del cluster tramite risorse `NodeClass` e annotazioni del bilanciatore del carico. Quando utilizzi EKS Auto Mode, AWS gestisce la configurazione VPC Container Network Interface (CNI) e il provisioning del load balancer per il tuo cluster. Puoi influenzare i comportamenti di rete definendo oggetti `NodeClass` e applicando annotazioni specifiche alle risorse Service e Ingress, mantenendo al contempo il modello operativo automatizzato fornito dalla modalità automatica di EKS. ## Funzionalità di rete modalità automatica di EKS ha una nuova funzionalità di rete che gestisce la rete di nodi e pod. Puoi configurarlo creando un oggetto `NodeClass` di Kubernetes. Le opzioni di configurazione per il precedente AWS VPC CNI non si applicheranno alla modalità automatica EKS. ### Configura la rete con una `NodeClass` La risorsa `NodeClass` in modalità automatica di EKS ti consente di personalizzare alcuni aspetti della funzionalità di rete. Tramite `NodeClass`, puoi specificare le selezioni dei gruppi di sicurezza, controllare il posizionamento dei nodi nelle sottoreti VPC, impostare le policy SNAT, configurare le policy di rete e abilitare la registrazione degli eventi di rete. Questo approccio mantiene il modello operativo automatizzato della modalità automatica di EKS fornendo al contempo flessibilità per la personalizzazione della rete. Puoi usare una `NodeClass` per: + Selezionare un gruppo di sicurezza per i nodi + Controllare come vengono posizionati i nodi nelle sottoreti VPC + Impostare la policy SNAT del nodo su `random` o `disabled` + Abilitare le *policy di rete* Kubernetes, tra cui: + Impostare la policy di rete su Rifiuto per default o Autorizzazione per default + Abilitare la registrazione degli eventi di rete su un file. + Isolare il traffico dei pod dal traffico del nodo collegando i pod a diverse sottoreti. Scopri come [creare un Amazon EKS NodeClass](create-node-class.md). ### Considerazioni La modalità automatica di EKS supporta: + Policy di rete EKS. + Le opzioni `HostPort` e `HostNetwork` per i pod di Kubernetes. + Nodi e pod in sottoreti pubbliche o private. + Memorizzazione nella cache di query DNS sul nodo. La modalità automatica di EKS **non** supporta: + Gruppi di sicurezza per pod (SGPP). Per applicare gruppi di sicurezza separati al traffico Pod in modalità automatica, usa `NodeClass` invece `podSecurityGroupSelectorTerms` in. Per ulteriori informazioni, consulta [Sottoreti e gruppi di sicurezza separati per i pod](create-node-class.md#pod-subnet-selector). + Rete personalizzata nella `ENIConfig`. Puoi inserire i pod in più sottoreti o isolarli esclusivamente dal traffico dei nodi con [Sottoreti e gruppi di sicurezza separati per i pod](create-node-class.md#pod-subnet-selector). + Configurazioni warm IP, warm prefix e warm ENI. + Configurazione minima delle destinazioni IP. + Altre configurazioni supportate dal AWS VPC CNI open source. + Configurazioni delle policy di rete come la personalizzazione del timer conntrack (l’impostazione predefinita è 300 s). + Esportazione dei registri degli eventi di rete in. CloudWatch ### Gestione delle risorse di rete EKS Auto Mode gestisce prefissi, indirizzi IP e gestione dell'interfaccia di rete monitorando NodeClass le risorse per le configurazioni di rete. Il servizio esegue automaticamente diverse operazioni sulle chiavi: **Delega del prefisso** EKS Auto Mode utilizza per impostazione predefinita la delega dei prefissi (/28 prefissi) per il networking dei pod e mantiene un pool caldo predefinito di risorse IP scalabile in base al numero di pod pianificati. Quando viene rilevata la frammentazione della sottorete dei pod, Auto Mode fornisce indirizzi IP secondari (/32). Grazie a questo algoritmo di rete pod predefinito, Auto Mode calcola il numero massimo di pod per nodo in base al numero ENIs e al tipo di istanza IPs supportati (presupponendo il caso peggiore di frammentazione). Per ulteriori informazioni sul numero massimo di indirizzi IP ENIs e IPs per istanza, consulta [Numero massimo di indirizzi IP per interfaccia di rete nella Guida per](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) l'utente di EC2. Le famiglie di istanze di nuova generazione (Nitro v6 e successive) sono generalmente aumentate IPs per tipo di istanza ENIs e la modalità Auto Mode regola di conseguenza il calcolo del numero massimo di pod. Per IPv6 i cluster, viene utilizzata solo la delega dei prefissi e la modalità automatica utilizza sempre un limite massimo di pod di 110 pod per nodo. **Gestione del tempo di raffreddamento** Il servizio implementa un pool di cooldown per prefissi o indirizzi secondari IPv4 che non sono più in uso. Dopo la scadenza del tempo di raffreddamento, queste risorse vengono rilasciate nuovamente al VPC. Tuttavia, se i pod riutilizzano queste risorse durante il tempo di raffreddamento, vengono ripristinate dal pool di raffreddamento. **IPv6 Support** Per IPv6 i cluster, EKS Auto Mode fornisce un `/80` IPv6 prefisso per nodo sull'interfaccia di rete principale. Quando viene utilizzato`podSubnetSelectorTerms`, il prefisso viene invece allocato su un'interfaccia di rete secondaria nella sottorete del pod. Il servizio garantisce inoltre una corretta gestione e rimozione di oggetti inutili di tutte le interfacce di rete. ## Sistema di bilanciamento del carico Si configurano gli AWS Elastic Load Balancer forniti da EKS Auto Mode utilizzando annotazioni sulle risorse Service e Ingress. Per ulteriori informazioni, consulta [Creare e IngressClass configurare un Application Load Balancer](auto-configure-alb.md) o [Usa Annotazioni del servizio per configurare Network Load Balancer](auto-configure-nlb.md). ### Considerazioni sul bilanciamento del carico con la modalità automatica di EKS + La modalità di targeting predefinita è la modalità IP, non la modalità istanza. + La modalità automatica di EKS supporta solo la modalità del gruppo di sicurezza per Network Load Balancer. + AWS non supporta la migrazione dei load balancer dal controller di bilanciamento del carico autogestito alla gestione tramite EKS Auto AWS Mode. + Il campo `networking.ingress.ipBlock` nella specifica `TargetGroupBinding` non è supportato. + Se i nodi worker utilizzano gruppi di sicurezza personalizzati (non schemi di denominazione `eks-cluster-sg- `), il ruolo del cluster richiede autorizzazioni IAM aggiuntive. La policy predefinita gestita da EKS consente solo a EKS di modificare i gruppi di sicurezza denominati `eks-cluster-sg-`. Senza l'autorizzazione a modificare i gruppi di sicurezza personalizzati, EKS non può aggiungere le regole di ingresso richieste che consentono al ALB/NLB traffico di raggiungere i pod. #### Considerazioni su CoredNS EKS Auto Mode non utilizza la tradizionale implementazione CoredNS per fornire la risoluzione DNS all'interno del cluster. Invece, i nodi Auto Mode utilizzano CoredNS in esecuzione come servizio di sistema direttamente su ciascun nodo. Se si esegue la transizione di un cluster tradizionale alla modalità automatica, è possibile rimuovere la distribuzione CoredNS dal cluster una volta che i carichi di lavoro sono stati spostati nei nodi in modalità automatica. **Importante** Se si prevede di mantenere un cluster con nodi in modalità automatica e non in modalità automatica, è necessario mantenere la distribuzione CoredNS. I nodi non in modalità automatica si affidano ai tradizionali pod CoreDNS per la risoluzione DNS, in quanto non possono accedere al servizio DNS a livello di nodo fornito da Auto Mode.