**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à.
# Automate cluster infrastructure with EKS Auto Mode
**Suggerimento**
[Registrati](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) ai prossimi workshop Amazon EKS Auto Mode.
EKS Auto Mode estende la AWS gestione dei cluster Kubernetes oltre il cluster stesso, AWS per consentire anche la configurazione e la gestione dell'infrastruttura che consente il corretto funzionamento dei carichi di lavoro. Puoi delegare le decisioni chiave sull'infrastruttura e sfruttare l'esperienza di for operations. AWS day-to-day L'infrastruttura cluster gestita da AWS include molte funzionalità di Kubernetes come componenti principali, al contrario dei componenti aggiuntivi, come la scalabilità automatica delle risorse di elaborazione, la rete di pod e servizi, il bilanciamento del carico delle applicazioni, il DNS del cluster, lo storage a blocchi e il supporto per GPU.
Per iniziare, è possibile implementare un nuovo cluster con modalità automatica EKS o abilitare la modalità automatica EKS su un cluster esistente. Puoi distribuire, aggiornare o modificare i tuoi cluster EKS Auto Mode usando eksctl, la AWS CLI, EKS APIs o i tuoi strumenti Console di gestione AWS preferiti. infrastructure-as-code
Con la modalità automatica EKS, puoi continuare a usare gli strumenti compatibili con Kubernetes che preferisci. EKS Auto Mode si integra con AWS servizi come Amazon EC2, Amazon EBS ed ELB, AWS sfruttando risorse cloud che seguono le migliori pratiche. Queste risorse vengono dimensionate automaticamente, ottimizzate in termini di costi e aggiornate regolarmente per contribuire a ridurre al minimo i costi operativi e le spese generali.
## Funzionalità
modalità automatica di EKS offre le seguenti funzionalità di alto livello:
**Ottimizzazione della gestione dei cluster Kubernetes**: la modalità automatica EKS semplifica la gestione di EKS fornendo cluster pronti per la produzione con un sovraccarico operativo minimo. Con la modalità automatica EKS, puoi eseguire carichi di lavoro impegnativi e dinamici in sicurezza, senza bisogno di una profonda conoscenza di EKS.
**Disponibilità delle applicazioni**: modalità automatica di EKS aggiunge o rimuove dinamicamente i nodi nel cluster EKS in base alle esigenze delle applicazioni Kubernetes. Questo riduce al minimo la necessità di pianificare manualmente la capacità e garantisce la disponibilità delle applicazioni.
**Efficienza**: EKS Auto Mode è progettata per ottimizzare i costi di elaborazione rispettando al contempo la flessibilità definita dai requisiti dell'utente e del carico di lavoro. NodePool Inoltre, termina le istanze non utilizzate e consolida i carichi di lavoro su altri nodi per migliorare l’efficienza in termini di costi.
**Sicurezza**: EKS Auto Mode utilizza AMIs dati considerati immutabili per i nodi. Questi applicano AMIs software bloccati, abilitano i controlli di accesso SELinux obbligatori e forniscono file system root di sola lettura. Inoltre, i nodi avviati dalla modalità automatica EKS hanno una durata massima di 21 giorni (che può essere ridotta), dopodiché vengono sostituiti automaticamente con nuovi nodi. Questo approccio migliora il livello di sicurezza grazie al riciclo regolare dei nodi, in linea con le best practice già adottate da molti clienti.
**Aggiornamenti automatici**: EKS Auto Mode mantiene il cluster Kubernetes, i nodi e i relativi componenti aggiornati con le patch più recenti, rispettando al contempo i Pod Disruption Budgets () e Disruption Budgets () configurati. PDBs NodePool NDBs Fino alla durata massima di 21 giorni, potrebbe essere necessario intervenire se il blocco o altre configurazioni impediscono gli aggiornamenti. PDBs
**Componenti gestiti**: EKS Auto Mode include Kubernetes e funzionalità AWS cloud come componenti principali che altrimenti dovrebbero essere gestiti come componenti aggiuntivi. Sono inclusi il supporto integrato per l’assegnazione degli indirizzi IP dei pod, le policy di rete dei pod, i servizi DNS locali, i componenti aggiuntivi GPU, i controlli di integrità e lo storage EBS CSI.
**Personalizzabile NodePools e NodeClasses**: se il carico di lavoro richiede modifiche alle configurazioni di archiviazione, elaborazione o rete, è possibile creare configurazioni personalizzate utilizzando la modalità automatica EKS. NodePools NodeClasses Sebbene non sia necessario modificare le impostazioni predefinite NodePools NodeClasses, è possibile aggiungere nuove configurazioni personalizzate NodePools o NodeClasses affiancarle a quelle predefinite per soddisfare i requisiti specifici.
## Componenti automatici
La modalità automatica EKS semplifica il funzionamento dei cluster Amazon EKS automatizzando i componenti chiave dell’infrastruttura. L’attivazione della modalità automatica EKS riduce ulteriormente le attività di gestione dei cluster EKS.
Di seguito è riportata una lista di componenti del piano dati che sono automatizzati:
+ **Calcolo**: per molti carichi di lavoro, con la modalità automatica EKS puoi dimenticarti di molti aspetti relativi al calcolo per i cluster EKS. Ciò include:
+ **Nodi:** i nodi della modalità automatica EKS sono progettati per essere trattati come dispositivi. La modalità automatica EKS esegue le seguenti operazioni:
+ Sceglie un’AMI appropriata configurata con molti servizi necessari per eseguire i carichi di lavoro senza bisogno di intervento.
+ Blocca l'accesso ai file sull'AMI utilizzando la modalità di SELinux applicazione e un file system root di sola lettura.
+ Impedisce l’accesso diretto ai nodi disabilitando l’accesso SSH o SSM.
+ Include il supporto GPU, con driver del kernel e plugin separati per NVIDIA e Neuron, che consente carichi di lavoro ad alte prestazioni. GPUs
+ Gestisce automaticamente gli [avvisi di interruzione delle istanze Spot EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) e gli eventi di integrità delle istanze EC2
+ **Dimensionamento automatico**: basandosi sul dimensionamento automatico di [Karpenter](https://karpenter.sh/docs/), la modalità automatica EKS monitora i Pod non programmabili e consente l’implementazione di nuovi nodi per eseguire tali pod. Quando i carichi di lavoro vengono terminati, la modalità automatica EKS interrompe e termina in modo dinamico i nodi quando non sono più necessari, ottimizzando l’uso delle risorse.
+ **Aggiornamenti**: il controllo dei nodi semplifica la capacità della modalità automatica EKS di offrire patch di sicurezza e aggiornamenti del sistema operativo e dei componenti in base alle esigenze. Tali aggiornamenti sono progettati per ridurre al minimo le interruzioni dei carichi di lavoro. EKS Auto Mode impone una durata massima dei nodi di 21 giorni per garantire software e. up-to-date APIs
+ **Bilanciamento del carico**: modalità automatica di EKS semplifica il bilanciamento del carico integrandosi con il servizio Elastic Load Balancing di Amazon, automatizzando il provisioning e la configurazione dei bilanciatori di carico per i servizi Kubernetes e le risorse Ingress. Supporta funzionalità avanzate per Application e Network Load Balancer, ne gestisce il ciclo di vita e le dimensiona in base alle esigenze del cluster. Questa integrazione fornisce una soluzione di bilanciamento del carico pronta per la produzione conforme alle AWS migliori pratiche, che consente di concentrarsi sulle applicazioni anziché sulla gestione dell'infrastruttura.
+ **Storage**: modalità automatica di EKS configura automaticamente lo storage temporaneo impostando i tipi di volume, le dimensioni dei volumi, le policy di crittografia e le policy di eliminazione alla chiusura del nodo.
+ **Rete**: modalità automatica di EKS automatizza le attività di rete critiche per quanto riguarda la connettività dei pod e dei servizi. Ciò include IPv4/IPv6 support e l'uso di blocchi CIDR secondari per estendere gli spazi degli indirizzi IP.
+ **Identity and Access Management**: non è necessario installare l’agente EKS Pod Identity sui cluster in modalità automatica di EKS.
Per ulteriori informazioni su questi componenti, consulta [Scopri come funziona EKS Auto Mode](auto-reference.md).
## Configurazione
Sebbene modalità automatica di EKS gestisca in modo efficace la maggior parte dei servizi del piano dati senza alcun intervento da parte tua, potrebbero esserci casi in cui desideri modificare il comportamento di alcuni di questi servizi. Puoi modificare la configurazione dei cluster della modalità automatica di EKS nei seguenti modi:
+ **Kubernetes DaemonSets**: anziché modificare i servizi installati sui nodi, puoi invece utilizzare i daemonset Kubernetes. I daemonset sono progettati per essere gestiti da Kubernetes, ma vengono eseguiti su ogni nodo del cluster. In questo modo, puoi aggiungere servizi speciali per il monitoraggio o la sorveglianza dei nodi.
+ **Personalizzati NodePools e NodeClasses**: sono predefiniti e NodeClasses sono configurati da EKS Auto Mode NodePools e non è necessario modificarli. Per personalizzare il comportamento dei nodi, puoi creare casi NodeClasses aggiuntivi NodePools o da utilizzare come:
+ La selezione di tipi di istanze specifici (ad esempio, processori accelerati o istanze Spot EC2).
+ L’isolamento dei carichi di lavoro per scopi di sicurezza o di monitoraggio dei costi.
+ La configurazione di impostazioni di storage temporaneo come IOPS, dimensioni e throughput.
+ **Bilanciamento del carico**: alcuni servizi, come il bilanciamento del carico, che modalità automatica di EKS esegue come oggetti Kubernetes, possono essere configurati direttamente sui cluster della modalità automatica di EKS.
Per ulteriori informazioni sulle opzioni di configurazione della modalità automatica di EKS, consulta [Configurazione delle impostazioni della modalità automatica EKS](settings-auto.md).
## Modello di responsabilità condivisa
Il modello di responsabilità AWS condivisa definisce le responsabilità di sicurezza AWS e conformità tra i clienti. Le immagini e il testo seguenti mettono a confronto e contrappongono AWS le differenze tra cliente e responsabilità tra la modalità EKS Auto e la modalità standard EKS.
![\[Modello di responsabilità condivisa con la modalità automatica di EKS e modalità standard\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/eksautosrm.png)
La modalità automatica di EKS trasferisce gran parte della responsabilità condivisa per l’infrastruttura Kubernetes dai clienti ad AWS. Con EKS Auto Mode, AWS si assume maggiori responsabilità per la sicurezza del cloud, che una volta era responsabilità del cliente e ora è condivisa. I clienti possono ora concentrarsi maggiormente sulle proprie applicazioni AWS gestendo al contempo l'infrastruttura sottostante.
**Responsabilità del cliente**
Con la modalità automatica di EKS, i clienti continuano a mantenere la responsabilità dei container delle applicazioni, inclusi disponibilità, sicurezza e monitoraggio. Mantengono inoltre il controllo sull’infrastruttura VPC e sulla configurazione del cluster EKS. Questo modello consente ai clienti di concentrarsi su problemi specifici delle applicazioni delegando al contempo la gestione dell'infrastruttura del cluster a. AWS Le funzionalità opzionali per nodo possono essere incluse nei cluster tramite componenti aggiuntivi. AWS
** AWS responsabilità**
Con EKS Auto Mode, AWS amplia la propria responsabilità includendo la gestione di diversi componenti critici aggiuntivi rispetto a quelli già gestiti nei cluster EKS che non utilizzano la modalità automatica. In particolare, modalità automatica di EKS si occupa della configurazione, della gestione, della sicurezza e del dimensionamento delle istanze EC2 avviate, nonché delle funzionalità del cluster per il bilanciamento del carico, la gestione degli indirizzi IP, la policy di rete e lo storage a blocchi. I seguenti componenti sono gestiti da AWS EKS Auto Mode:
+ Istanze **EC2 con lancio automatico in modalità: AWS gestisce l'intero ciclo di vita dei nodi sfruttando le istanze** gestite di Amazon EC2. Le istanze gestite da EC2 si assumono la responsabilità della configurazione del sistema operativo, dell’applicazione di patch, del monitoraggio e del mantenimento dell’integrità. In questo modello, sia l’istanza stessa che il sistema operativo guest in esecuzione su di essa sono di responsabilità di AWS. [I nodi utilizzano varianti di Bottlerocket ottimizzate per l'esecuzione di contenitori.](https://aws.amazon.com/bottlerocket) AMIs I Bottlerocket AMIs dispongono di software bloccato, file system root immutabili e accesso sicuro alla rete (per impedire comunicazioni dirette tramite SSH o SSM).
+ **Funzionalità del cluster**: AWS gestisce la scalabilità automatica dell'elaborazione, il networking Pod con l'applicazione delle policy di rete, l'integrazione di Elastic Load Balancing e la configurazione dei driver di archiviazione.
+ **Cluster Control Plane**: AWS continua a gestire il server API Kubernetes, il cross-account e il database etcd, come con EKS ENIs standard.
+ **Foundation Services and Global Infrastructure**: AWS è responsabile dei servizi di elaborazione, archiviazione, rete e monitoraggio sottostanti, nonché dell'infrastruttura globale di regioni, zone locali e edge location.
# Creare un cluster con la modalità automatica Amazon EKS
Questo capitolo spiega come creare un cluster Amazon EKS con la modalità automatica abilitata utilizzando vari strumenti e interfacce. La modalità automatica semplifica la creazione di cluster grazie alla configurazione e alla gestione automatiche dell’infrastruttura di calcolo, della rete e dell’archiviazione del cluster. Si imparerà come creare un cluster con la modalità automatica utilizzando la AWS CLI, la Console di gestione AWS o lo strumento a riga di comando eksctl.
**Nota**
La modalità automatica EKS richiede la versione 1.29 o successive di Kubernetes.
Scegliere lo strumento preferito in base alle esigenze: la Console di gestione AWS offre un’interfaccia visiva ideale per scoprire le funzionalità della modalità automatica EKS e creare singoli cluster. La AWS CLI è la soluzione ideale per attività di scripting e automazione, in particolare quando si integra la creazione di cluster in flussi di lavoro o pipeline CI/CD esistenti. Lo strumento CLI eksctl offre un’esperienza nativa per Kubernetes ed è consigliato agli utenti che hanno familiarità con gli strumenti Kubernetes e che desiderano operazioni a riga di comando semplificate con impostazioni predefinite ragionevoli.
Prima di iniziare, assicurarsi di aver installato e configurato i prerequisiti necessari, incluse le autorizzazioni IAM adeguate per creare cluster EKS. Per ulteriori informazioni su come installare strumenti CLI come `kubectl`, `aws` e `eksctl`, consultare [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
È possibile utilizzare la AWS CLI, la Console di gestione AWS o lo strumento CLI eksctl per creare un cluster con la modalità automatica Amazon EKS.
**Topics**
+ [
# Crea un cluster di EKS Auto Mode con la CLI di eksctl
](automode-get-started-eksctl.md)
+ [
# Crea un cluster EKS Auto Mode con la AWS CLI
](automode-get-started-cli.md)
+ [
# Crea un cluster di EKS Auto Mode con la Console di gestione AWS
](automode-get-started-console.md)
# Crea un cluster di EKS Auto Mode con la CLI di eksctl
Questo argomento ti mostra come creare un cluster di Amazon EKS Auto Mode con l’interfaccia a riga di comando (CLI) di eksctl. Puoi creare un cluster Auto Mode eseguendo un singolo comando CLI o applicando un file di configurazione YAML. Entrambi i metodi offrono le stesse funzionalità, con l’approccio YAML che offre un controllo più granulare sulle impostazioni del cluster.
La CLI di eksctl semplifica il processo di creazione e gestione dei cluster di EKS Auto Mode gestendo la creazione e la configurazione delle risorse AWS sottostanti. Prima di procedere, assicurati di avere le credenziali AWS e le autorizzazioni necessarie configurate sul computer locale. Questa guida presuppone che tu abbia una certa familiarità con i concetti base di Amazon EKS e che gli strumenti CLI richiesti siano già stati installati.
**Nota**
Devi installare la versione `0.195.0` o una versione successiva di eksctl. Per ulteriori informazioni, consulta [eksctl releases](https://github.com/eksctl-io/eksctl/releases) su GitHub.
## Crea un cluster di EKS Auto Mode con un comando CLI
Devi avere l’installazione degli strumenti `aws` ed `eksctl`. Devi aver effettuato l’accesso ad AWS CLI con autorizzazioni sufficienti per gestire le risorse AWS tra cui: istanze EC2, reti EC2, cluster EKS e ruoli IAM. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
Esegui il seguente comando per creare un nuovo cluster di EKS Auto Mode con
```
eksctl create cluster --name= --enable-auto-mode
```
## Crea un cluster di EKS Auto Mode con un file YAML
Devi avere l’installazione degli strumenti `aws` ed `eksctl`. Devi aver effettuato l’accesso ad AWS CLI con autorizzazioni sufficienti per gestire le risorse AWS tra cui: istanze EC2, reti EC2, cluster EKS e ruoli IAM. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
Esamina le opzioni di configurazione di EKS Auto Mode nella risorsa ClusterConfig di esempio qui sotto. Per la specifica completa di ClusterConfig, consulta [eksctl documentation](https://eksctl.io/usage/creating-and-managing-clusters/).
AWS suggerisce di abilitare EKS Auto Mode. Se è la prima volta che crei un cluster di EKS Auto Mode, lascia il `nodeRoleARN` non precisato per creare un ruolo IAM del nodo per EKS Auto Mode. Se disponi già di un ruolo IAM del nodo nell’account AWS, AWS suggerisce di riutilizzarlo.
AWS suggerisce di non specificare alcun valore per `nodePools`. EKS Auto Mode creerà pool di nodi predefiniti. Puoi utilizzare l’API Kubernetes per creare pool di nodi aggiuntivi.
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
Salva il file `ClusterConfig` con nome `cluster.yaml` e usa il seguente comando per creare il cluster:
```
eksctl create cluster -f cluster.yaml
```
# Crea un cluster EKS Auto Mode con la AWS CLI
I cluster della modalità automatica di EKS automatizzano le attività di routine di gestione del cluster l’elaborazione, l’archiviazione e la rete. Ad esempio, i cluster della modalità automatica di EKS rilevano automaticamente quando sono necessari nodi aggiuntivi ed effettuano il provisioning di nuove istanze EC2 per soddisfare le richieste di carico di lavoro.
Questo argomento illustra la creazione di un nuovo cluster EKS Auto Mode utilizzando la AWS CLI e, facoltativamente, la distribuzione di un carico di lavoro di esempio.
## Prerequisiti
+ La versione più recente dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo. Per verificare la versione attuale, usa `aws --version`. Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [configurazione rapida](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) con aws configure nella Guida per l'utente dell'interfaccia a riga di AWS comando.
+ Accedi alla CLI con autorizzazioni IAM sufficienti per creare AWS risorse tra cui politiche IAM, ruoli IAM e cluster EKS.
+ Lo strumento da riga di comando kubectl installato sul tuo dispositivo. AWS suggerisce di utilizzare la stessa versione di kubectl della versione Kubernetes del cluster EKS. Per installare o aggiornare kubectl, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md).
## Specifica le sottoreti VPC
La modalità automatica di Amazon EKS implementa i nodi nelle sottoreti VPC. Quando si crea un cluster EKS, devi specificare le sottoreti VPC in cui verranno implementati i nodi. Puoi utilizzare le sottoreti VPC predefinite nel tuo AWS account o creare un VPC dedicato per carichi di lavoro critici.
+ AWS suggerisce di creare un VPC dedicato per il cluster. Informazioni su come [Creazione di un Amazon VPC per il cluster Amazon EKS.](creating-a-vpc.md).
+ La console EKS aiuta a creare un nuovo VPC. Informazioni su come [Crea un cluster di EKS Auto Mode con la Console di gestione AWS](automode-get-started-console.md).
+ In alternativa, puoi utilizzare il VPC predefinito del tuo AWS account. Usa le seguenti istruzioni per trovare la IDs sottorete.
### Per trovare la sottorete IDs del tuo VPC predefinito
**Utilizzo della AWS CLI:**
1. Esegui il comando seguente per elencare il VPC di default e le relative sottoreti:
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. Salva l'output e annota la ** IDssottorete**.
Output di esempio:
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## Ruoli IAM per cluster della modalità automatica di EKS
### Ruolo IAM del cluster
EKS Auto Mode richiede un ruolo Cluster IAM per eseguire azioni nell' AWS account, come il provisioning di nuove istanze EC2. È necessario creare questo ruolo per concedere a EKS le autorizzazioni necessarie. AWS consiglia di allegare le seguenti politiche AWS gestite al ruolo Cluster IAM:
+ [EKSComputePolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingPolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterPolitica di Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### Ruolo IAM del nodo
Quando creai un cluster della modalità automatica di EKS, specifichi un ruolo IAM del nodo. Quando modalità automatica di EKS crea nodi per elaborare carichi di lavoro in sospeso, a ogni nuovo nodo di istanza EC2 viene assegnato il ruolo IAM del nodo. Questo ruolo consente al nodo di comunicare con EKS, ma in genere non è accessibile ai carichi di lavoro in esecuzione sul nodo.
Se desideri concedere le autorizzazioni ai carichi di lavoro in esecuzione su un nodo, usa EKS Pod Identity. Per ulteriori informazioni, consulta [Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS](pod-identities.md).
Devi creare questo ruolo e allegare la seguente politica AWS gestita:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
La modalità automatica di EKS richiede anche un ruolo collegato ai servizi, che viene creato e configurato automaticamente da AWS. Per ulteriori informazioni, consulta [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md).
## Creazione di un ruolo IAM per un cluster della modalità automatica di EKS
### Passaggio 1: creazione della policy di attendibilità
Crea una policy di attendibilità che consenta al servizio Amazon EKS di assumere tale ruolo. Salva la policy come `trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Passaggio 2: creazione del ruolo IAM
Usa la policy di attendibilità per creare il ruolo IAM del cluster:
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### Passaggio 3: annotazione del ruolo ARN
Recupera e salva l’ARN del nuovo ruolo per usarlo nelle fasi successive:
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### Passaggio 4: collegamento delle policy obbligatorie
Allega le seguenti politiche AWS gestite al ruolo Cluster IAM per concedere le autorizzazioni necessarie:
**EKSClusterPolitica di Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputePolitica di Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingPolitica di Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
## Creazione di un ruolo IAM per un nodo modalità automatica di EKS
### Passaggio 1: creazione della policy di attendibilità
Crea una policy di attendibilità che consenta al servizio Amazon EKS di assumere tale ruolo. Salva la policy come `node-trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Passaggio 2: creare il ruolo IAM del nodo
Utilizza il **node-trust-policyfile.json** del passaggio precedente per definire quali entità possono assumere il ruolo. Per creare il ruolo IAM del nodo, esegui il seguente comando:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Passaggio 3: annotazione del ruolo ARN
Una volta creato il ruolo, recupera e salva l’ARN del ruolo IAM del nodo. Sarà necessario usare questo ARN nei passaggi successivi. Usa il seguente comando per ottenere l’ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Passaggio 4: collegamento delle policy obbligatorie
Allega le seguenti policy AWS gestite al ruolo Node IAM per fornire le autorizzazioni necessarie:
**Amazon EKSWorker NodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**Amazon EC2 ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## Creazione di un cluster della modalità automatica di EKS
### Panoramica di
Per creare un cluster EKS Auto Mode utilizzando la AWS CLI, sono necessari i seguenti parametri:
+ `cluster-name`: il nome del cluster.
+ `k8s-version`: la versione di Kubernetes (ad esempio, 1.31).
+ `subnet-ids`: sottorete IDs identificata nei passaggi precedenti.
+ `cluster-role-arn`: ARN del ruolo IAM del cluster.
+ `node-role-arn`: ARN del ruolo IAM del nodo.
#### Configurazioni predefinite del cluster
Esaminare questi valori e funzionalità predefiniti prima di creare il cluster:
+ `nodePools`: modalità automatica di EKS include pool di nodi generici e predefiniti di sistema. Maggiori informazioni sui [Node Pools](create-node-pool.md).
**Nota:** i pool di nodi in modalità automatica di EKS differiscono dai gruppi di nodi gestiti di Amazon EKS ma possono coesistere nello stesso cluster.
+ `computeConfig.enabled`: automatizza le attività di elaborazione di routine, come la creazione e l’eliminazione di istanze EC2.
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`: automatizza le attività di bilanciamento del carico, includendo la creazione e l’eliminazione dei bilanciatori del carico elastico.
+ `storageConfig.blockStorage.enabled`: automatizza le attività di archiviazione, come la creazione e l’eliminazione di volumi Amazon EBS.
+ `accessConfig.authenticationMode`: richiede voci di accesso EKS. Maggiori informazioni su [EKS authentication modes](grant-k8s-access.md).
#### Esegui il comando
Usa il comando seguente per creare il cluster:
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### Verifica lo stato del cluster
#### Fase 1: verificare la creazione del cluster
Esegui il comando seguente per verificare lo stato del cluster. La creazione del cluster richiede in genere 15 minuti.
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### Fase 2: aggiornare kubeconfig
Una volta che il cluster è pronto, aggiorna il file kubeconfig locale per consentire a `kubectl` di comunicare con il cluster. Questa configurazione utilizza la AWS CLI per l'autenticazione.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### Fase 3: verificare i pool di nodi
Elenca i pool di nodi nel cluster con il comando seguente:
```
kubectl get nodepools
```
## Fasi successive
+ Informazioni su [deploy a sample workload](automode-workload.md) nel nuovo cluster della modalità automatica di EKS.
# Crea un cluster di EKS Auto Mode con la Console di gestione AWS
La creazione di un cluster di EKS Auto Mode nella Console di gestione AWS richiede meno configurazione rispetto ad altre opzioni. EKS si integra con AWS IAM e le reti VPC per aiutarti a creare le risorse associate a un cluster EKS.
Hai due opzioni per creare un cluster nella console:
+ Configurazione rapida (con EKS Auto Mode)
+ Configurazione personalizzata
Questo argomento illustra come creare un cluster di EKS Auto Mode utilizzando l’opzione di configurazione rapida.
## Crea un EKS Auto Mode utilizzando l’opzione di configurazione rapida
Deve aver effettuato l’accesso a Console di gestione AWS con autorizzazioni sufficienti per gestire risorse AWS tra cui: istanze EC2, reti EC2, cluster EKS e ruoli IAM.
1. Passa alla console EKS
1. Fai clic su **Crea cluster**.
1. Conferma che l’opzione di **configurazione rapida** è selezionata
1. Determina i seguenti valori o usare i valori predefiniti per un cluster di test.
+ **Nome** del cluster
+ Versione di Kubernetes
1. Seleziona il ruolo IAM del cluster. Se è la prima volta che hai creato un cluster di EKS Auto Mode, utilizza l’opzione **Crea ruolo consigliato**.
+ Facoltativamente, puoi riutilizzare un singolo ruolo IAM del cluster nell’account AWS per tutti i cluster di EKS Auto Mode.
+ Il ruolo IAM del cluster include le autorizzazioni necessarie affinché EKS Auto Mode gestisca le risorse, tra cui istanze EC2, volumi EBS e bilanciatori del carico EC2.
+ L’opzione **Crea ruolo consigliato** precompila tutti i campi con i valori consigliati. Seleziona **Avanti** e poi **Crea**. Il ruolo utilizzerà il nome `AmazonEKSAutoClusterRole` suggerito.
+ Se recentemente hai creato un nuovo ruolo, usa l’icona **Aggiorna** per ricaricare il menu a discesa di selezione del ruolo.
1. Seleziona il ruolo IAM del nodo. Se è la prima volta che hai creato un cluster di EKS Auto Mode, utilizza l’opzione **Crea ruolo consigliato**.
+ Facoltativamente, puoi riutilizzare un singolo ruolo IAM del nodo nell’account AWS per tutti i cluster di EKS Auto Mode.
+ Il ruolo IAM del nodo include le autorizzazioni necessarie per la connessione dei nodi Auto Mode al cluster. Il ruolo IAM del nodo deve includere le autorizzazioni per recuperare le immagini ECR per i container.
+ L’opzione **Crea ruolo consigliato** precompila tutti i campi con i valori consigliati. Seleziona **Avanti** e poi **Crea**. Il ruolo utilizzerà il nome `AmazonEKSAutoNodeRole` suggerito.
+ Se recentemente hai creato un nuovo ruolo, usa l’icona **Aggiorna** per ricaricare il menu a discesa di selezione del ruolo.
1. Seleziona il VPC per il cluster di EKS Auto Mode. Scegli **Crea VPC** per creare un nuovo VPC per EKS oppure scegli un VPC creato in precedenza per EKS.
+ Se utilizzi la console VPC per creare un nuovo VPC, AWS suggerisce di creare almeno un gateway NAT per zona di disponibilità. In caso contrario, puoi usare tutte le altre impostazioni predefinite.
+ Per ulteriori informazioni e dettagli sui requisiti del cluster IPv6, consulta [Creazione di un Amazon VPC per il cluster Amazon EKS.](creating-a-vpc.md).
1. (opzionale) EKS Auto Mode popola automaticamente le sottoreti private per il VPC selezionato. Puoi rimuovere le sottoreti indesiderate.
+ EKS seleziona automaticamente le sottoreti private dal VPC seguendo le migliori pratiche. Facoltativamente, puoi selezionare sottoreti aggiuntive dal VPC, come quelle pubbliche.
1. (facoltativo) Seleziona **Visualizza impostazioni predefinite di configurazione rapida** per esaminare tutti i valori di configurazione per il nuovo cluster. La tabella indica che alcuni valori non sono modificabili dopo la creazione del cluster.
1. Selezionare **Creazione di un cluster**. Il completamento della creazione del cluster potrebbe richiedere quindici minuti.
## Fasi successive
+ Informazioni su [Deploy a Sample Workload to your EKS Auto Mode cluster](sample-storage-workload.md)
# Abilita EKS Auto Mode sui cluster EKS esistenti
Puoi abilitare EKS Auto Mode sui cluster EKS esistenti.
**AWS supporta le seguenti migrazioni:**
+ Migrazione da Karpenter ai nodi EKS Auto Mode. Per ulteriori informazioni, consulta [Eseguire la migrazione da Karpenter alla modalità automatica di EKS utilizzando kubectl](auto-migrate-karpenter.md).
+ Migrazione dai gruppi di nodi gestiti EKS ai nodi EKS Auto Mode. Per ulteriori informazioni, consulta [Eseguire la migrazione dai gruppi di nodi gestiti EKS a EKS Auto Mode](auto-migrate-mng.md).
+ Migrazione da EKS Fargate alla EKS Auto Mode. Per ulteriori informazioni, consulta [Eseguire la migrazione da EKS Fargate alla modalità automatica di EKS](auto-migrate-fargate.md).
**AWS non supporta le seguenti funzionalità:**
+ Migrazione di volumi dal controller CSI EBS (utilizzando il componente aggiuntivo Amazon EKS) al controller CSI EBS di EKS Auto Mode (gestito da EKS Auto Mode). I PVC realizzati con uno non possono essere montati con l’altro, perché utilizzano due diversi provider di volumi Kubernetes.
+ Il [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (progetto AWS Labs) consente la migrazione tra StorageClass CSI EBS standard (`ebs.csi.aws.com`) ed EKS StorageClass CSI EBS automatica di EKS (`ebs.csi.eks.amazonaws.com`). Tieni presente che la migrazione richiede l’eliminazione e la ricreazione delle risorse PersistentVolumeClaim/PersistentVolume esistenti, pertanto la convalida in un ambiente non di produzione è essenziale prima dell’implementazione.
+ Migrazione dei sistemi di bilanciamento del carico da AWS Load Balancer Controller a EKS Auto Mode
Puoi installare AWS Load Balancer Controller su un cluster Amazon EKS Auto Mode. Utilizza le opzioni `IngressClass` o `loadBalancerClass` per associare le risorse Service e Ingress al Load Balancer Controller o a EKS Auto Mode.
+ Migrazione di cluster EKS con CNI alternativi o altre configurazioni di rete non supportate
## Materiale di riferimento per le migrazioni
Utilizza il seguente riferimento sulla migrazione per configurare le risorse Kubernetes in modo che siano di proprietà di controller autogestiti o EKS Auto Mode.
| Funzionalità | Risorsa | Campo | Autogestito | EKS Auto Mode |
| --- | --- | --- | --- | --- |
| Storage a blocchi | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Sistema di bilanciamento del carico | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Sistema di bilanciamento del carico | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Sistema di bilanciamento del carico | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Sistema di bilanciamento del carico | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Calcolo | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## Migration di volumi EBS
Durante la migrazione dei carichi di lavoro a EKS Auto Mode, è necessario gestire la migrazione dei volumi EBS a causa di diversi provisioner di driver CSI:
+ Provisioner EKS Auto Mode: `ebs.csi.eks.amazonaws.com`
+ Provisioner CSI EBS open source: `ebs.csi.aws.com`
Segui questi passaggi per migrare i volumi persistenti:
1. **Modifica la policy di conservazione dei volumi**: modifica la versione della piattaforma esistente `persistentVolumeReclaimPolicy` in `Retain` per garantire che il volume EBS sottostante non venga eliminato.
1. **Rimuovi la versione della piattaforma da Kubernetes**: elimina la vecchia risorsa della versione mantenendo intatto il volume EBS effettivo.
1. **Crea una nuova versione della piattaforma con provisioning statico**: crea una nuova versione che faccia riferimento allo stesso volume EBS ma funzioni con il driver CSI di destinazione.
1. **Associa a un nuovo PVC**: crea un nuovo PVC che faccia riferimento in modo specifico alla versione della tua piattaforma utilizzando il campo `volumeName`.
### Considerazioni
+ Assicurati che le tue applicazioni siano interrotte prima di iniziare questa migrazione.
+ Esegui il backup dei dati prima di iniziare il processo di migrazione.
+ Questo processo deve essere eseguito per ogni volume persistente.
+ Il carico di lavoro deve essere aggiornato per utilizzare il nuovo PVC.
## Migrazione dei bilanciatori del carico
Non è possibile trasferire direttamente i bilanciatori del carico esistenti da AWS Load Balancer Controller autogestito a EKS Auto Mode. Devi invece implementare una strategia di implementazione blu/verde. Questo comporta il mantenimento della configurazione del bilanciatore del carico esistente e la creazione di nuovi sistemi di bilanciamento del carico sotto il controller gestito.
Per ridurre al minimo le interruzioni del servizio, consigliamo un approccio di trasferimento del traffico basato su DNS. Innanzitutto, crea nuovi sistemi di bilanciatore del carico utilizzando EKS Auto Mode e mantenendo operativa la configurazione esistente. Quindi, utilizza il routing DNS (come Route 53) per spostare gradualmente il traffico dai vecchi sistemi di bilanciatore del carico a quelli nuovi. Una volta completata la migrazione del traffico e verificata la nuova configurazione, puoi disattivare i vecchi sistemi di bilanciatore del carico e il controller autogestito.
# Abilita modalità automatica di EKS su un cluster esistente
In questo argomento viene descritto come abilitare la modalità automatica di Amazon EKS sui cluster Amazon EKS esistenti. L’attivazione di Auto Mode su un cluster esistente richiede l’aggiornamento delle autorizzazioni IAM e la configurazione delle impostazioni principali della modalità automatica di EKS. Dopo l’abilitazione, puoi iniziare a eseguire la migrazione dei carichi di lavoro di elaborazione esistenti per sfruttare le operazioni semplificate e la gestione automatizzata dell’infrastruttura di Auto Mode.
**Importante**
Verifica di aver installato la versione minima richiesta di alcuni componenti aggiuntivi di Amazon EKS prima di abilitare la modalità automatica di EKS. Per ulteriori informazioni, consulta [Versioni richieste del componente aggiuntivo](#auto-addons-required).
Prima di iniziare, assicurati di disporre dell’accesso da amministratore al cluster Amazon EKS e delle autorizzazioni per modificare i ruoli IAM. I passaggi descritti in questo argomento illustrano come abilitare la modalità automatica utilizzando Console di gestione AWS o la AWS CLI.
## Console di gestione AWS
È necessario accedere alla AWS console con l'autorizzazione a gestire IAM, EKS e EC2 le risorse.
**Nota**
Il ruolo IAM del cluster di un cluster EKS non può essere modificato dopo la creazione del cluster. modalità automatica di EKS richiede autorizzazioni aggiuntive per questo ruolo. Devi allegare policy aggiuntive al ruolo attuale.
### Aggiorna il ruolo IAM del cluster
1. Apri la pagina di panoramica del cluster in Console di gestione AWS.
1. In **ARN del ruolo IAM del cluster**, seleziona **Visualizza in IAM**.
1. Dall’elenco a discesa **Aggiungi autorizzazioni**, scegli **Allega policy**.
1. Utilizza la casella **Ricerca** per trovare e selezionare le seguenti policy:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. Seleziona **Aggiungi autorizzazioni**.
1. Dalla scheda **Relazioni di attendibilità**, seleziona **Modifica policy di attendibilità**
1. Inserisci la seguente policy di attendibilità del ruolo IAM del cluster e seleziona **Aggiorna policy**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Abilita modalità automatica di EKS
1. Apri la pagina di panoramica del cluster in Console di gestione AWS.
1. In **modalità automatica di EKS**, seleziona **Gestisci**
1. Attiva **modalità automatica di EKS**.
1. Dal menu a discesa **Pool di nodi EKS**, seleziona i pool di nodi predefiniti da creare.
+ Maggiori informazioni sui pool di nodi in modalità automatica di EKS. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
1. Se in precedenza hai creato un ruolo IAM EKS Auto Mode Node su questo AWS account, selezionalo nel menu a discesa **Node IAM Role**. Se non hai mai creato questo ruolo in precedenza, seleziona **Crea ruolo consigliato** e seguire i passaggi.
## AWS CLI
### Prerequisiti
+ Il ruolo IAM del cluster EKS esistente deve includere autorizzazioni sufficienti per la modalità automatica di EKS, come le seguenti policy:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ Il ruolo IAM del cluster deve avere una policy di attendibilità aggiornata che includa l’operazione `sts:TagSession`. Per ulteriori informazioni sulla creazione di un ruolo IAM del cluster, consulta [Crea un cluster EKS Auto Mode con la AWS CLI](automode-get-started-cli.md).
+ `aws` CLI installata, con accesso effettuato e una versione sufficiente. È necessario disporre dell'autorizzazione per gestire IAM, EKS e EC2 risorse. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
### Procedura
Utilizza i seguenti comandi per abilitare modalità automatica di EKS su un cluster esistente.
**Nota**
Le funzionalità di calcolo, archiviazione a blocchi e bilanciamento del carico devono essere tutte abilitate o disabilitate nella stessa richiesta.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## Versioni richieste del componente aggiuntivo
Se intendi abilitare modalità automatica di EKS su un cluster esistente, potrebbe dover aggiornare alcuni componenti aggiuntivi. Nota:
+ Questo vale solo per i cluster esistenti che passano alla modalità automatica di EKS .
+ I nuovi cluster creati con la modalità automatica di EKS abilitata non richiedono questi aggiornamenti.
Se hai installato uno dei seguenti componenti aggiuntivi, assicurati che abbia almeno la versione minima specificata:
| Nome del componente aggiuntivo | Versione minima richiesta |
| --- | --- |
| Plug-in della CNI di Amazon VPC per Kubernetes | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/auto-enable-existing.html) |
| Driver CSI per Amazon EBS | v1.37.0-eksbuild.1 |
| Controller di snapshot CSI | v8.1.0-eksbuild.2 |
| EKS Pod Identity Agent | v1.3.4-eksbuild.1 |
Per ulteriori informazioni, consulta [Aggiornamento di un componente aggiuntivo di Amazon EKS](updating-an-add-on.md).
## Fasi successive
+ Per eseguire la migrazione dei carichi di lavoro di Manage Node Group, consulta [Eseguire la migrazione dai gruppi di nodi gestiti EKS a EKS Auto Mode](auto-migrate-mng.md).
+ Per eseguire la migrazione da Self-Managed Karpenter, consulta [Eseguire la migrazione da Karpenter alla modalità automatica di EKS utilizzando kubectl](auto-migrate-karpenter.md).
# Eseguire la migrazione da Karpenter alla modalità automatica di EKS utilizzando kubectl
Questo argomento illustra il processo di migrazione dei carichi di lavoro da Karpenter alla modalità automatica di Amazon EKS utilizzando kubectl. La migrazione può essere eseguita gradualmente, consentendo di spostare i carichi di lavoro al proprio ritmo, mantenendo al contempo la stabilità del cluster e la disponibilità delle applicazioni durante la transizione.
L' step-by-stepapproccio descritto di seguito consente di eseguire Karpenter ed EKS Auto Mode fianco a fianco durante il periodo di migrazione. Questa strategia a doppio funzionamento aiuta a garantire una transizione fluida consentendoti di convalidare il comportamento del carico di lavoro in modalità automatica di EKS prima di disattivare completamente Karpenter. Puoi eseguire la migrazione delle applicazioni singolarmente o in gruppo, garantendo la flessibilità necessaria per soddisfare i requisiti operativi specifici e la tolleranza al rischio.
## Prerequisiti
Prima di iniziare la migrazione, assicurati di avere:
+ Karpenter v1.1 o versioni successive deve essere installato sul cluster. Per ulteriori informazioni, consulta [Upgrading to 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110) nei documenti di Karpenter.
+ `kubectl` installato e connesso al cluster. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
Questo argomento presuppone che tu abbia familiarità con Karpenter e. NodePools Per ulteriori informazioni, consulta [Karpenter Documentation](https://karpenter.sh/).
## Fase 1: abilitare modalità automatica di EKS sul cluster
Abilita la modalità automatica EKS sul tuo cluster esistente utilizzando la AWS CLI o la console di gestione. Per ulteriori informazioni, consulta [Abilita modalità automatica di EKS su un cluster esistente](auto-enable-existing.md).
**Nota**
Durante l’abilitazione della modalità automatica di EKS, non abilitare il nodepool `general purpose` in questa fase durante la transizione. Questo pool di nodi non è selettivo.
Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
## Fase 2: Creare una modalità automatica EKS alterata NodePool
Crea una nuova modalità NodePool per EKS Auto con una macchia. Ciò garantisce che i pod esistenti non vengano programmati automaticamente sui nuovi nodi della modalità automatica di EKS. Questo pool di nodi utilizza `NodeClass` integrato `default` in modalità automatica di EKS. Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
Esempio di pool di nodi con taint:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
Aggiorna i requisiti per il pool di nodi in modo tale che corrispondano alla configurazione di Karpenter da cui stai eseguendo la migrazione. Devi soddisfare almeno un requisito.
## Fase 3: aggiornare i carichi di lavoro per la migrazione
Identifica e aggiorna i carichi di lavoro che desideri migrare alla modalità automatica di EKS . Aggiungi sia le tolleranze che i selettori di nodi a questi carichi di lavoro:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
Questa modifica consente di pianificare il carico di lavoro sui nuovi nodella modalità automatica di EKS.
La modalità automatica di EKS utilizza etichette diverse rispetto a Karpenter. Le etichette relative alle istanze EC2 gestite iniziano con. `eks.amazonaws.com` Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
## Fase 4: migrare gradualmente i carichi di lavoro
Ripeti la fase 3 per ogni carico di lavoro di cui desideri eseguire la migrazione. Ciò consente di spostare i carichi di lavoro individualmente o in gruppo, in base ai requisiti e alla tolleranza al rischio.
## Passaggio 5: rimuovere il Karpenter originale NodePool
Una volta migrati tutti i carichi di lavoro, puoi rimuovere il Karpenter originale: NodePool
```
kubectl delete nodepool
```
## Passaggio 6: rimuovere la contaminazione dalla modalità automatica EKS (opzionale) NodePool
Se desideri che la modalità automatica EKS diventi l'impostazione predefinita per i nuovi carichi di lavoro, puoi rimuovere la contaminazione dalla modalità automatica EKS: NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## Fase 7: rimuovere i selettori di nodi dai carichi di lavoro (facoltativo)
Se hai rimosso la macchia dalla modalità automatica EKS NodePool, puoi facoltativamente rimuovere i selettori dei nodi dai tuoi carichi di lavoro, poiché la modalità automatica EKS è ora l'impostazione predefinita:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## Fase 8: disinstallare Karpenter dal cluster
Le fasi per rimuovere Karpenter dipendono da come l’hai installato. Per ulteriori informazioni, consulta [Karpenter install instructions](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter).
# Eseguire la migrazione dai gruppi di nodi gestiti EKS a EKS Auto Mode
Quando si esegue la transizione del cluster Amazon EKS per utilizzare EKS Auto Mode, puoi eseguire la migrazione senza problemi i carichi di lavoro esistenti dai gruppi di nodi gestiti (MNG) utilizzando lo strumento CLI eksctl. Questo processo garantisce la disponibilità continua delle applicazioni mentre EKS Auto Mode ottimizza le risorse di calcolo. La migrazione può essere eseguita con interruzioni minime delle applicazioni in esecuzione.
Questo argomento illustra le fasi per drenare in sicurezza i pod dai gruppi di nodi gestiti esistenti e consentire a EKS Auto Mode di riprogrammarli sulle nuove istanze di cui è appena stato effettuato il provisioning. Seguendo questa procedura, puoi sfruttare il consolidamento intelligente del carico di lavoro di EKS Auto Mode mantenendo al contempo la disponibilità dell’applicazione durante la migrazione.
## Prerequisiti
+ Cluster con EKS Auto Mode abilitata
+ `eksctl` CLI installato e connesso al cluster. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
+ Karpenter non è installato nel cluster.
## Procedura
Utilizza il seguente comando `eksctl` CLI per avviare i pod di drenaggio dalle istanze del gruppo di nodi gestiti esistente. EKS Auto Mode creerà nuovi nodi per supportare i pod spostati.
```
eksctl delete nodegroup --cluster= --name=
```
Dovrai eseguire questo comando per ogni gruppo di nodi gestiti nel cluster.
Per ulteriori informazioni su questo comando, consulta [Deleting and draining nodegroups](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) nei documenti di eksctl.
# Eseguire la migrazione da EKS Fargate alla modalità automatica di EKS
Questo argomento descrive il processo di migrazione dei carichi di lavoro da EKS Fargate alla modalità automatica di Amazon EKS utilizzando `kubectl`. La migrazione può essere eseguita gradualmente, consentendo di spostare i carichi di lavoro al proprio ritmo, mantenendo al contempo la stabilità del cluster e la disponibilità delle applicazioni durante la transizione.
L' step-by-stepapproccio descritto di seguito consente di eseguire EKS Fargate e EKS Auto Mode fianco a fianco durante il periodo di migrazione. Questa strategia a doppio funzionamento aiuta a garantire una transizione fluida consentendo di convalidare il comportamento del carico di lavoro in modalità automatica di EKS prima di disattivare completamente EKS Fargate. Puoi eseguire la migrazione delle applicazioni singolarmente o in gruppo, garantendo la flessibilità necessaria per soddisfare i requisiti operativi specifici e la tolleranza al rischio.
## Confronto tra Amazon EKS Auto Mode ed EKS e AWS Fargate
Amazon EKS con AWS Fargate rimane un'opzione per i clienti che desiderano utilizzare EKS, ma Amazon EKS Auto Mode è l'approccio consigliato in futuro. La modalità automatica di EKS è completamente conforme a Kubernetes e supporta tutte le primitive Kubernetes a monte e gli strumenti di piattaforma come Istio, che Fargate non è in grado di supportare. Inoltre, modalità automatica di EKS supporta completamente tutte le opzioni di acquisto del runtime EC2, incluse GPU e istanze Spot, consentendo ai clienti di sfruttare gli sconti EC2 negoziati e altri meccanismi di risparmio. Queste funzionalità non sono disponibili quando si utilizza EKS con Fargate.
Inoltre, modalità automatica di EKS consente ai clienti di ottenere lo stesso modello di isolamento di Fargate, utilizzando le funzionalità di pianificazione di Kubernetes standard per garantire che ogni istanza EC2 esegua un singolo container di applicazioni. Adottando la modalità Auto di Amazon EKS, i clienti possono sfruttare tutti i vantaggi dell'esecuzione di Kubernetes su AWS una piattaforma completamente conforme a Kubernetes che offre la flessibilità necessaria per sfruttare l'intera gamma di opzioni di acquisto e EC2, pur mantenendo la facilità d'uso e l'astrazione dalla gestione dell'infrastruttura fornite da Fargate.
### Raggiungere un isolamento simile a quello di Fargate in modalità automatica EKS
Per replicare il modello di isolamento dei pod di Fargate, in cui ogni pod viene eseguito su una propria istanza dedicata, puoi utilizzare i vincoli di diffusione della topologia di Kubernetes. Questo è l'approccio consigliato per controllare la distribuzione dei pod tra i nodi:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
In questa configurazione:
+ `maxSkew: 1`assicura che la differenza nel numero di pod tra due nodi qualsiasi sia al massimo 1, distribuendo efficacemente un pod per nodo
+ `topologyKey: kubernetes.io/hostname`definisce il nodo come dominio della topologia
+ `whenUnsatisfiable: DoNotSchedule`impedisce la pianificazione se il vincolo non può essere soddisfatto
+ `minDomains: 1`assicura l'esistenza di almeno un dominio (nodo) prima della pianificazione
EKS Auto Mode eseguirà automaticamente il provisioning di nuove istanze EC2 secondo necessità per soddisfare questo vincolo, fornendo lo stesso modello di isolamento di Fargate e dandoti accesso all'intera gamma di tipi di istanze EC2 e opzioni di acquisto.
In alternativa, puoi utilizzare le regole anti-affinità dei pod per un isolamento più rigoroso:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
La `podAntiAffinity` regola `requiredDuringSchedulingIgnoredDuringExecution` garantisce che non sia `app: isolated-app` possibile programmare due pod con l'etichetta sullo stesso nodo. Questo approccio offre garanzie di isolamento rigide simili a quelle di Fargate.
## Prerequisiti
Prima di iniziare la migrazione, assicurarti di aver:
+ configurato un cluster con Fargate. Per ulteriori informazioni, consulta [Inizia a usare AWS Fargate per il tuo cluster](fargate-getting-started.md);
+ installato e connesso `kubectl` al cluster. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Fase 1: Verificare il cluster Fargate
1. Verifica se il cluster EKS con Fargate è in esecuzione:
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. Verifica i pod in esecuzione:
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. Create un’implementazione in un file chiamato `deployment_fargate.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Applica l’implementazione:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Verifica i pod e le implementazioni:
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. Verifica il nodo:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## Fase 2: Abilitare modalità automatica di EKS sul cluster
1. Abilita la modalità automatica EKS sul tuo cluster esistente utilizzando la AWS CLI o la console di gestione. Per ulteriori informazioni, consulta [Abilita modalità automatica di EKS su un cluster esistente](auto-enable-existing.md).
1. Verifica il nodepool:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Fase 3: Aggiornare i carichi di lavoro per la migrazione
Identifica e aggiorna i carichi di lavoro che desideri migrare alla modalità automatica di EKS .
Per eseguire la migrazione di un carico di lavoro da Fargate alla modalità automatica di EKS , applica l’annotazione `eks.amazonaws.com/compute-type: ec2`. Ciò garantisce che il carico di lavoro non venga programmato da Fargate, nonostante il profilo Fargate, e venga interrotto dalla modalità automatica EKS. NodePool Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
1. Modifica le implementazioni (ad esempio, il file `deployment_fargate.yaml`) per cambiare il tipo di elaborazione in `ec2`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Applica l’implementazione. Questa modifica consente di pianificare il carico di lavoro sui nuovi nodella modalità automatica di EKS:
```
kubectl apply -f deployment_fargate.yaml
```
1. Verifica che l’implementazione sia in esecuzione nel cluster della modalità automatica di EKS:
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Verifica che non sia in esecuzione alcun nodo Fargate e che l’implementazione sia in esecuzione nei nodi gestiti dalla modalità automatica di EKS:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## Fase 4: Migrare gradualmente i carichi di lavoro
Ripeti la fase 3 per ogni carico di lavoro di cui desideri eseguire la migrazione. Ciò consente di spostare i carichi di lavoro individualmente o in gruppo, in base ai requisiti e alla tolleranza al rischio.
## Fase 5: Rimuovere il profilo Fargate originale
Una volta eseguita la migrazione di tutti i carichi di lavoro, puoi rimuovere il profilo `fargate` originale. Sostituisci ** con il nome del tuo profilo Fargate:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Fase 6: Ridurre verticalmente CoreDNS
Poiché modalità automatica di EKS gestisce CoreDNS, puoi ridurre verticalmente l’implementazione `coredns` fino a 0:
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# Esegui carichi di lavoro di esempio nei cluster della modalità automatica di EKS
Questo capitolo fornisce esempi di come implementare diversi tipi di carichi di lavoro nei cluster Amazon EKS in esecuzione in Auto Mode. Gli esempi illustrano i principali schemi di carico di lavoro, tra cui applicazioni di esempio, applicazioni web con bilanciamento del carico, carichi di lavoro stateful che utilizzano l’archiviazione persistente, e carichi di lavoro con requisiti di posizionamento dei nodi specifici. Ogni esempio include manifesti completi e istruzioni di step-by-step distribuzione che è possibile utilizzare come modelli per le proprie applicazioni.
Prima di procedere con gli esempi, assicurati di avere un cluster EKS in esecuzione in modalità automatica e di aver installato la AWS CLI e kubectl. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md). Gli esempi presuppongono una conoscenza base dei concetti di Kubernetes e dei comandi kubectl.
Puoi utilizzare questi esempi basati su casi d’uso per eseguire carichi di lavoro in cluster della modalità automatica di EKS.
[Implementazione di un esempio di carico di lavoro di decompressione in un cluster con modalità automatica di Amazon EKS](automode-workload.md)
Mostra come implementare un carico di lavoro di esempio in un cluster della modalità automatica di EKS utilizzando i comandi `kubectl`.
[Implementa un carico di lavoro del bilanciatore del carico esemplificativo in EKS Auto Mode](auto-elb-example.md)
Mostra come implementare una versione containerizzata del gioco 2048 su Amazon EKS.
[Implementazione di un carico di lavoro stateful esemplificativo in modalità automatica EKS](sample-storage-workload.md)
Mostra come implementare un’applicazione stateful di esempio in un cluster della modalità automatica di EKS.
[Implementare un carico di lavoro accelerato](auto-accelerated.md)
Mostra come distribuire carichi di lavoro con accelerazione hardware nei nodi gestiti da EKS Auto Mode.
[Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode](associate-workload.md)
Mostra come utilizzare un’annotazione per controllare se un carico di lavoro viene implementato nei nodi gestiti dalla modalità automatica di EKS.
# Implementazione di un esempio di carico di lavoro di decompressione in un cluster con modalità automatica di Amazon EKS
In questo tutorial imparerai come implementare un carico di lavoro di esempio su un cluster con modalità automatica EKS e osservare come esegue automaticamente il provisioning delle risorse di calcolo necessarie. Utilizzerai `kubectl` i comandi per osservare il comportamento del cluster e vedere in prima persona come la modalità automatica semplifica le operazioni di Kubernetes su. AWS Al termine di questo tutorial, capirai come la modalità automatica EKS risponde alle distribuzioni dei carichi di lavoro gestendo automaticamente le risorse di calcolo sottostanti, senza richiedere la configurazione manuale dei gruppi di nodi.
## Prerequisiti
+ Un cluster della modalità automatica di Amazon EKS. Annota il nome e la regione del cluster. AWS
+ Un principale IAM, come ad esempio un utente o un ruolo, con autorizzazioni sufficienti per gestire le risorse di rete, di elaborazione ed EKS.
+ Per ulteriori informazioni, consulta [Creating roles and attaching policies in the IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) nella Guida per l’utente IAM.
+ `aws` CLI installata e configurata con un’identità IAM.
+ `kubectl` CLI installata e connessa al cluster.
+ Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Passaggio 1: rivedere le risorse di elaborazione esistenti (facoltativo)
Innanzitutto, usa `kubectl` per elencare i pool di nodi sul cluster.
```
kubectl get nodepools
```
Output di esempio:
```
general-purpose
```
In questo tutorial, implementeremo un carico di lavoro configurato per usare il pool di nodi `general-purpose`. Questo pool di nodi è integrato nella modalità automatica EKS e include impostazioni predefinite ragionevoli per carichi di lavoro generici, come microservizi e applicazioni web. Puoi creare un pool di nodi personalizzato. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
Poi, utilizza `kubectl` per elencare i nodi collegati al tuo cluster.
```
kubectl get nodes
```
Se hai appena creato un cluster con modalità automatica EKS, non avrai nodi.
In questo tutorial implementerai un carico di lavoro di esempio. Se non ci sono nodi o il carico di lavoro non può essere gestito dai nodi esistenti, la modalità automatica EKS provvederà a fornire un nuovo nodo.
## Passaggio 2: implementare un’applicazione di esempio sul cluster
Esamina la seguente implementazione di Kubernetes e salvala come `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
Il selettore `eks.amazonaws.com/compute-type: auto` richiede che il carico di lavoro sia implementato su un nodo della modalità automatica di Amazon EKS.
Applica l’implementazione al cluster.
```
kubectl apply -f inflate.yaml
```
## Passaggio 3: vedere gli eventi di Kubernetes
Utilizza il seguente comando per vedere gli eventi di Kubernetes, inclusa la creazione di un nuovo nodo. Usa `ctrl+c` per interrompere la visione degli eventi.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Utilizza `kubectl` per elencare nuovamente i nodi collegati al tuo cluster. Prendi nota del nodo appena creato.
```
kubectl get nodes
```
## Passaggio 4: Visualizza i nodi e le istanze nella console AWS
È possibile visualizzare i nodi EKS Auto Mode nella console EKS e le EC2 istanze associate nella EC2 console.
EC2 Le istanze distribuite da EKS Auto Mode sono limitate. Non puoi eseguire comandi arbitrari sui nodi della modalità automatica EKS.
## Passaggio 5: eliminare l’implementazione
Per eliminare un’implementazione, usa `kubectl`
```
kubectl delete -f inflate.yaml
```
Se non ci sono altri carichi di lavoro implementati nel cluster, il nodo creato dalla modalità automatica EKS sarà vuoto.
Nella configurazione predefinita, la modalità automatica EKS rileva i nodi che rimangono vuoti per trenta secondi e li termina.
Utilizza `kubectl` o la EC2 console per confermare che l'istanza associata è stata eliminata.
# Implementa un carico di lavoro del bilanciatore del carico esemplificativo in EKS Auto Mode
Questa guida mostra come implementare una versione containerizzata del gioco 2048 su Amazon EKS, completa di bilanciamento del carico e accessibilità a Internet.
## Prerequisiti
+ Un cluster EKS Auto Mode
+ `kubectl` configurato per interagire con il cluster
+ Autorizzazioni IAM appropriate per la creazione di risorse ALB
## Fase 1: Creazione del namespace
Innanzitutto, crea un namespace dedicato per l’applicazione di gioco 2048.
Creare un file denominato `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Applica la configurazione del namespace:
```
kubectl apply -f 01-namespace.yaml
```
## Fase 2: Implementazione dell’applicazione
L’applicazione esegue più repliche del container del gioco 2048.
Creare un file denominato `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**Nota**
Se ricevi un errore durante il caricamento dell’immagine `public.ecr.aws/l6m2t8p7/docker-2048:latest`, conferma che il ruolo IAM del nodo dispone delle autorizzazioni sufficienti per estrarre immagini da ECR. Per ulteriori informazioni, consulta [Ruolo IAM del nodo](auto-learn-iam.md#auto-learn-node-iam-role). Inoltre, l’immagine `docker-2048` nell’esempio è un’immagine `x86_64` e non sarà eseguita su altre architetture.
**Componenti chiave:**
+ Implementa 5 repliche dell’applicazione
+ Utilizza un’immagine ECR pubblica
+ Richiede 0,5 core CPU per pod
+ Espone la porta 80 per il traffico HTTP
Applica l’implementazione:
```
kubectl apply -f 02-deployment.yaml
```
## Fase 3: Creazione del servizio
Il servizio espone l’implementazione alla rete di cluster.
Creare un file denominato `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Componenti chiave:**
+ Crea un servizio NodePort
+ Mappa la porta 80 alla porta 80 del container
+ Utilizza il selettore di etichette per trovare i pod
Applica il servizio:
```
kubectl apply -f 03-service.yaml
```
## Fase 4: Configurazione del bilanciamento del carico
Configurerai un ingresso per esporre l’applicazione a Internet.
Innanzitutto, crea la `IngressClass`. Creare un file denominato `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**Nota**
EKS Auto Mode richiede i tag di sottorete per identificare le sottoreti pubbliche e private.
Se hai creato il cluster con `eksctl`, disponi già di questi tag.
Informazioni su come [Assegnazione di tag alle sottoreti per la modalità automatica EKS](tag-subnets-auto.md).
Poi, crea la risorsa Ingress. Creare un file denominato `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Componenti chiave:**
+ Crea un ALB connesso a Internet
+ Utilizza il tipo di destinazione IP per l’instradamento diretto al pod
+ Instrada tutto il traffico (/) al servizio di gioco
Applica le configurazioni di ingresso:
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Fase 5: Verifica dell’implementazione
1. Controlla che tutti i pod siano in esecuzione:
```
kubectl get pods -n game-2048
```
1. Verifica che il servizio sia stato creato:
```
kubectl get svc -n game-2048
```
1. Ottieni l’endpoint di ALB:
```
kubectl get ingress -n game-2048
```
Il campo ADDRESS nell’output di ingresso mostrerà l’endpoint di ALB. Attendi 2-3 minuti affinché l’ALB effettui il provisioning e registri tutti gli obiettivi.
## Fase 6: Accesso al gioco
Apri il browser web e accedi all’URL dell’endpoint di ALB della fase precedente. Dovresti vedere l’interfaccia di gioco 2048.
## Fase 7: Eliminazione
Per rimuovere tutte le risorse create in questo tutorial:
```
kubectl delete namespace game-2048
```
Questo eliminerà tutte le risorse nel namespace, incluse le risorse di implementazione, di servizio e di ingresso.
## Cosa succede dietro le quinte
1. L’implementazione crea 5 pod che eseguono il gioco 2048
1. Il servizio fornisce un accesso stabile alla rete a questi pod
1. EKS Auto Mode:
+ Crea un Application Load Balancer in AWS
+ Configura i gruppi di destinazione per i pod
+ Imposta le regole di instradamento per indirizzare il traffico al servizio
## Risoluzione dei problemi
Se il gioco non si carica:
+ Assicurati che tutti i pod siano in esecuzione: `kubectl get pods -n game-2048`
+ Verifica lo stato di ingresso: `kubectl describe ingress -n game-2048`
+ Verifica i controlli dell’integrità di ALB: Verificare lo stato del gruppo di destinazione nella Console AWS
# Implementazione di un carico di lavoro stateful esemplificativo in modalità automatica EKS
Questo tutorial ti guiderà nella distribuzione di un’applicazione stateful esemplificativa nel tuo cluster di modalità automatica EKS. L’applicazione scrive marche temporali su un volume persistente, dimostrando le funzionalità automatiche di provisioning e persistenza dei volumi EBS di modalità automatica EKS.
## Prerequisiti
+ Un cluster in modalità automatica EKS
+ AWS CLI configurata con le autorizzazioni appropriate
+ Installazione e configurazione di `kubectl`.
+ Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Passaggio 1: configurazione dell’ambiente
1. Imposta le variabili di ambiente:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Aggiorna kubeconfig:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Passaggio 2: creazione della classe di archiviazione
`StorageClass` definisce in che modo la modalità automatica EKS fornirà i volumi EBS.
Modalità automatica EKS non crea un `StorageClass` per te. Devi creare una `StorageClass` che faccia riferimento a `ebs.csi.eks.amazonaws.com` per utilizzare la funzionalità di archiviazione di modalità automatica EKS.
1. Creare un file denominato `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Applica: `StorageClass`
```
kubectl apply -f storage-class.yaml
```
**componenti chiave**
+ `provisioner: ebs.csi.eks.amazonaws.com`: utilizza modalità automatica EKS
+ `volumeBindingMode: WaitForFirstConsumer`: ritarda la creazione del volume fino a quando un pod non ne ha bisogno
+ `type: gp3`: specifica il tipo di volume EBS
+ `encrypted: "true"`: EBS utilizzerà la chiave `aws/ebs` predefinita per crittografare i volumi creati con questa classe. Questo passaggio è facoltativo, ma è consigliato.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes userà questa classe di archiviazione per impostazione predefinita, a meno che non sia specificata una classe di volume diversa su una dichiarazione di volume persistente. Fai attenzione quando imposti questo valore se stai migrando da un altro controller di archiviazione (facoltativo).
## Passaggio 3: creazione della dichiarazione di volume persistente
Il PVC richiede l’archiviazione da `StorageClass`.
1. Creare un file denominato `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Applica il PVC:
```
kubectl apply -f pvc.yaml
```
**Componenti chiave:**
+ `accessModes: ReadWriteOnce`: il volume può essere montato da un nodo alla volta
+ `storage: 8Gi`: richiede un volume da 8 GiB
+ `storageClassName: auto-ebs-sc`: riferimenti su `StorageClass` abbiamo creato
## Passaggio 4: implementare un’applicazione
L’implementazione esegue un container che scrive marche temporali nel volume persistente.
1. Creare un file denominato `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Applica l’implementazione:
```
kubectl apply -f deployment.yaml
```
**Componenti chiave:**
+ Semplice container bash che scrive una marca temporale su un file
+ Monta il PVC su `/data`
+ Richiede 1 core CPU
+ Utilizza il selettore di nodi per i nodi gestiti da EKS
## Passaggio 5: verificare la configurazione
1. Verifica che il pod sia in esecuzione:
```
kubectl get pods -l app=inflate-stateful
```
1. Verifica che il PVC sia legato:
```
kubectl get pvc auto-ebs-claim
```
1. Controlla il volume EBS:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Verifica che i dati siano scritti:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Passaggio 6: pulizia
Eseguire il comando riportato di seguito per rimuovere tutte le risorse create in questo tutorial:
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Cosa succede dietro le quinte
1. Il PVC richiede l’archiviazione da `StorageClass`
1. Quando è il pod è pianificato:
1. La modalità automatica EKS fornisce un volume EBS
1. Crea PersistentVolume
1. Collega il volume al nodo
1. Il pod monta il volume e inizia a scrivere le marche temporali
## Controller di snapshot
La modalità automatica EKS è compatibile con lo Snapshotter di CSI Kubernetes, noto anche come controller di snapshot. Tuttavia, la modalità automatica EKS non include il controller di snapshot. L’utente è responsabile dell’installazione e della configurazione del controller di snapshot. Per ulteriori informazioni, consulta [Abilitare la funzionalità snapshot per i volumi CSI](csi-snapshot-controller.md).
Leggi quanto segue `VolumeSnapshotClass` che fa riferimento alla capacità di archiviazione della modalità automatica EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Scopri di più su Snapshotter di CSI Kubernetes.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# Implementare un carico di lavoro accelerato
Questo tutorial dimostra come la modalità automatica di Amazon EKS semplifica l'avvio di carichi di lavoro con accelerazione hardware. La modalità automatica di Amazon EKS semplifica le operazioni oltre il cluster stesso automatizzando i componenti chiave dell’infrastruttura che forniscono funzionalità di elaborazione, rete, bilanciamento del carico, storage e accesso e gestione delle identità pronte all’uso.
La modalità Auto di Amazon EKS include i driver e i plug-in di dispositivo necessari per determinati tipi di istanze, come i driver NVIDIA e AWS Neuron. Non è necessario installare o aggiornare questi componenti.
modalità automatica di EKS gestisce automaticamente i driver per questi acceleratori:
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferenza](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [Istanze EC2 accelerate NVIDIA GPUs su Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**Nota**
La modalità automatica di EKS include il plug-in di dispositivo NVIDIA per Kubernetes. Questo plug-in viene eseguito automaticamente e non è visibile come daemon impostato nel cluster.
Supporto di reti avanzate:
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
La modalità automatica di Amazon EKS elimina la difficoltà della gestione dei driver dell’acceleratore e dei plug-in di dispositivo.
Puoi anche trarre vantaggio dai risparmi sui costi ridimensionando il cluster fino a zero. Puoi configurare modalità automatica di EKS per terminare le istanze quando non è in esecuzione alcun carico di lavoro. Ciò è utile per i carichi di lavoro di inferenza basati su batch.
Di seguito viene fornito un esempio di come avviare carichi di lavoro accelerati con la modalità automatica di Amazon EKS.
## Prerequisiti
+ Un cluster Kubernetes con la modalità automatica di Amazon EKS configurata.
+ Una classe del nodo `default` EKS creata quando i pool di nodi gestiti da `general-purpose` o `system` sono abilitati.
## Fase 1: Implementare un carico di lavoro GPU
In questo esempio, creerai un file NodePool per carichi di lavoro basati su NVIDIA che richiede 45 GB di memoria GPU. Con la modalità automatica di EKS, utilizzi i vincoli di pianificazione di Kubernetes per definire i requisiti delle istanze.
Per distribuire la modalità automatica di Amazon EKS `NodePool` e l'esempio`workload`, esamina quanto segue NodePool e la definizione di Pod e salva con nome `nodepool-gpu.yaml` e `pod.yaml` nome:
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Il selettore `eks.amazonaws.com/compute-type: auto` richiede che il carico di lavoro sia implementato su un nodo della modalità automatica di Amazon EKS. NodePool Inoltre, imposta una caratteristica che consente di programmare solo pod con tolleranze per GPUs Nvidia.
Applica il carico di lavoro NodePool and al tuo cluster.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
Verrà visualizzato l’output seguente:
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Attendi qualche secondo e controlla i nodi del cluster. Ora dovresti vedere un nuovo nodo fornito nel cluster della modalità automatica di Amazon EKS:
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Fase 2: Convalida
Puoi vedere che la modalità automatica di Amazon EKS ha lanciato un `g6e.2xlarge` anziché un `g6.2xlarge` in quanto il carico di lavoro richiedeva un’istanza con l40s `GPU`, in base ai seguenti vincoli di pianificazione di Kubernetes:
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
Ora, analizzare i log dei container, eseguendo il seguente comando:
```
kubectl logs nvidia-smi
```
Output di esempio:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Puoi vedere che il container ha rilevato che è in esecuzione su un’istanza con una GPU `NVIDIA` e che non hai dovuto installare alcun driver di dispositivo, poiché questa è gestita dalla modalità automatica di Amazon EKS.
## Fase 3: Pulizia
Per rimuovere tutti gli oggetti creati, usa `kubectl` per eliminare la distribuzione di esempio e NodePool quindi il nodo viene terminato:
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## Esempio NodePools di riferimento
### Crea un NVIDIA NodePool
Quanto segue NodePool definisce:
+ Solo istanze di avvio della famiglia `g6e` e `g6`
+ Consolidare i nodi quando sono vuoti per 1 ora
+ Il valore di 1 ora per `consolodateAfter` supporta carichi di lavoro con picchi e riduce il tasso di abbandono dei nodi. Puoi eseguire l’ottimizzazione di `consolidateAfter` in base ai requisiti del carico di lavoro.
**Esempio NodePool con famiglia di istanze GPU e consolidamento**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
Invece di impostare il `eks.amazonaws.com/instance-gpu-name`, puoi utilizzare `eks.amazonaws.com/instance-family` per specificare la famiglia di istanze. Per altre etichette note che influenzano la revisione della pianificazione, consultare [Etichette supportate da EKS Auto Mode](create-node-pool.md#auto-supported-labels).
Se hai requisiti di storage specifici, puoi ottimizzare lo storage `iops` temporaneo dei nodi `size` e `throughput` crearne uno personalizzato a cui fare riferimento nel. [NodeClass](create-node-class.md) NodePool [Scopri di più sulle opzioni configurabili. NodeClass ](create-node-class.md)
**Esempio di configurazione di archiviazione per NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Definisci AWS Trainium e AWS Inferentia NodePool
Di seguito NodePool è riportato un `eks.amazonaws.com/instance-category` set che indica solo le istanze di avvio delle famiglie Inferentia e Trainium:
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# Configurazione delle impostazioni della modalità automatica EKS
Questo capitolo descrive come configurare aspetti specifici dei cluster in modalità automatica Amazon Elastic Kubernetes Service (EKS). Sebbene la modalità automatica EKS gestisca automaticamente la maggior parte dei componenti dell’infrastruttura, è possibile personalizzare alcune funzionalità per soddisfare i requisiti del tuo carico di lavoro.
Utilizzando le opzioni di configurazione descritte in questo argomento, è possibile modificare le impostazioni di rete, le risorse di calcolo e i comportamenti di bilanciamento del carico, mantenendo al contempo i vantaggi della gestione automatizzata dell’infrastruttura. Prima di apportare modifiche alla configurazione, esamina le opzioni disponibili nelle sezioni seguenti per determinare l’approccio più adatto alle tue esigenze.
| Quali funzionalità vuoi configurare? | Opzione di configurazione |
| --- | --- |
| **Rete e archiviazione dei nodi** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Creazione di una classe di nodi per Amazon EKS](create-node-class.md) |
| **Risorse di calcolo dei nodi** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md) |
| **Pool di nodi a capacità statica** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Pool di nodi a capacità statica in modalità EKS Auto](auto-static-capacity.md) |
| **Impostazioni Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Creare e IngressClass configurare un Application Load Balancer](auto-configure-alb.md) |
| **Impostazioni Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Usa Annotazioni del servizio per configurare Network Load Balancer](auto-configure-nlb.md) |
| **Impostazioni della classe di archiviazione** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Crea una classe di archiviazione](create-storage-class.md) |
| **Controlla l’utilizzo dell’ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS](auto-odcr.md) |
| **Sicurezza avanzata del nodo** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/settings-auto.html) | [Configurare le impostazioni di sicurezza avanzate per i nodi](auto-advanced-security.md) |
# Creazione di una classe di nodi per Amazon EKS
Le classi di nodi Amazon EKS sono modelli che forniscono un controllo granulare sulla configurazione dei nodi gestiti dalla modalità automatica di EKS. Una classe di nodi definisce le impostazioni a livello di infrastruttura che si applicano ai gruppi di nodi del cluster EKS, tra cui la configurazione di rete, le impostazioni di storage e il tagging delle risorse. Questo argomento mostra come creare e configurare una classe di nodi per soddisfare i tuoi requisiti operativi specifici.
Quando è necessario personalizzare le modalità di provisioning e configurazione delle istanze EC2 da parte della modalità automatica di EKS oltre le impostazioni predefinite, la creazione di una classe di nodi fornisce un controllo preciso sui parametri critici dell’infrastruttura. Ad esempio, è possibile specificare il posizionamento di sottoreti private per una maggiore sicurezza, configurare lo storage temporaneo delle istanze per carichi di lavoro sensibili alle prestazioni o applicare tag personalizzati per l’allocazione dei costi.
## Creazione di una classe di nodi
Per creare una `NodeClass`, segui questi passaggi:
1. Crea un file YAML (ad esempio, `nodeclass.yaml`) con la configurazione della classe di nodi
1. Applica la configurazione al cluster utilizzando `kubectl`
1. Fai riferimento alla classe di nodi nella configurazione del tuo pool di nodi. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
`kubectl` deve essere installato e configurato. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
### Esempio di classe di nodi di base
Ecco un esempio di classe di nodi:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
Ciò NodeClass aumenta la quantità di storage temporaneo sul nodo.
Applica questa configurazione usando:
```
kubectl apply -f nodeclass.yaml
```
Poi fai riferimento alla classe di nodi nella configurazione del pool di nodi. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
## Creazione di una voce di accesso alla classe di nodi
Se crei una classe di nodi personalizzata, devi creare una voce di accesso EKS per consentire ai nodi di unirsi al cluster. Quando si utilizzano la classe di nodi e i pool di nodi integrati, EKS crea automaticamente le voci di accesso.
Per informazioni sul funzionamento delle voci di accesso, consulta [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md).
Quando si creano voci di accesso per le classi di nodi della modalità automatica di EKS, è necessario usare il tipo di voce di accesso `EC2`.
### Creazione di un accesso con CLI
**Per creare una voce di accesso per i nodi EC2 e associare la policy dei nodi di EKS Auto:**
Aggiorna i comandi CLI seguenti con il nome del cluster e l’ARN del ruolo del nodo. Il ruolo del nodo ARN viene specificato nella classe di nodi YAML.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Crea un ingresso di accesso con CloudFormation
**Per creare una voce di accesso per i nodi EC2 e associare la policy dei nodi di EKS Auto:**
Aggiorna quanto segue CloudFormation con il nome del cluster e l'ARN del ruolo del nodo. Il ruolo del nodo ARN viene specificato nella classe di nodi YAML.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
[Per informazioni sulla distribuzione degli CloudFormation stack, consulta Guida introduttiva a CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## Specifiche della classe di nodi
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws: kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Considerazioni
+ Se vuoi verificare la quantità di storage locale di cui dispone un’istanza, puoi descrivere il nodo per visualizzare la risorsa di storage temporaneo.
+ **Crittografia dei volumi**: EKS utilizza la chiave KMS personalizzata configurata per crittografare il volume root di sola lettura dell'istanza e il volume di dati. read/write
+ **Sostituisci il ruolo IAM del nodo**: se modifichi il ruolo IAM del nodo associato a `NodeClass`, dovrai creare una nuova voce d’accesso. EKS crea automaticamente una voce d’accesso per il ruolo IAM del nodo durante la creazione del cluster. Il ruolo IAM del nodo richiede la policy di accesso di `AmazonEKSAutoNodePolicy` EKS. Per ulteriori informazioni, consulta [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md).
+ **densità massima di pod**: EKS limita il numero massimo di pod su un nodo a 110. Questo limite viene applicato dopo il calcolo del numero massimo di pod attuale. Per ulteriori informazioni, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md).
+ **Tag**: se vuoi propagare i tag da Kubernetes a EC2, devi configurare autorizzazioni IAM aggiuntive. Per ulteriori informazioni, consulta [Informazioni su identità e accesso in modalità automatica di EKS](auto-learn-iam.md).
+ **Classe di nodi predefinita**: non assegnare un nome alla classe di nodi `default` personalizzata. Questo perché la modalità automatica di EKS include una `NodeClass` denominata `default` che viene fornita automaticamente quando si abilita almeno un `NodePool` integrato. Per informazioni sull’abilitazione dei `NodePools`, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
+ **comportamento di `subnetSelectorTerms` con più sottoreti**: se esistono più sottoreti che soddisfano le condizioni di `subnetSelectorTerms` o che vengono fornite tramite ID, la modalità automatica di EKS crea nodi distribuiti tra le sottoreti.
+ [Se le sottoreti si trovano in zone di disponibilità diverse (AZs), puoi utilizzare le funzionalità di Kubernetes come i [vincoli di diffusione della topologia Pod e il routing con riconoscimento della topologia per distribuire rispettivamente i pod](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) e il traffico tra le zone.](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)
+ Se *nella stessa AZ* sono presenti più sottoreti che corrispondono al `subnetSelectorTerms`, la modalità automatica di EKS crea pod su ciascun nodo distribuito tra le sottoreti in quella AZ. La modalità automatica di EKS crea interfacce di rete secondarie su ogni nodo nelle altre sottoreti della stessa AZ. Decide in base al numero di indirizzi IP disponibili in ciascuna sottorete, per usare le sottoreti in modo più efficiente. Non è tuttavia possibile specificare quale sottorete viene usata dalla modalità automatica di EKS per ogni Pod; se hai bisogno che i Pod funzionino in sottoreti specifiche, usa [Sottoreti e gruppi di sicurezza separati per i pod](#pod-subnet-selector).
## Sottoreti e gruppi di sicurezza separati per i pod
I `podSecurityGroupSelectorTerms` campi `podSubnetSelectorTerms` and consentono configurazioni di rete avanzate consentendo ai Pod di utilizzare sottoreti e gruppi di sicurezza diversi rispetto ai rispettivi nodi. Entrambi i campi devono essere specificati insieme. Questa separazione offre maggiore controllo sul routing del traffico di rete e sulle policy di sicurezza.
**Nota**
Questa funzionalità è diversa dalla funzionalità [Security Groups for Pods](security-groups-for-pods.md) (SGPP) utilizzata con AWS VPC CNI per il calcolo in modalità automatica non EKS. SGPP non è supportato in modalità automatica EKS. Utilizza invece `podSecurityGroupSelectorTerms` in `NodeClass` per applicare gruppi di sicurezza separati al traffico Pod. I gruppi di sicurezza si applicano a `NodeClass` livello, vale a dire tutti i Pod sui nodi che li utilizzano `NodeClass` condividono gli stessi gruppi di sicurezza Pod.
### Come funziona
Quando configuri `podSubnetSelectorTerms` e`podSecurityGroupSelectorTerms`:
1. L'ENI principale del nodo utilizza le sottoreti e i gruppi di sicurezza di e. `subnetSelectorTerms` `securityGroupSelectorTerms` A questa interfaccia viene assegnato solo l'indirizzo IP del nodo.
1. EKS Auto Mode crea sottoreti secondarie ENIs corrispondenti`podSubnetSelectorTerms`, con i gruppi di sicurezza allegati`podSecurityGroupSelectorTerms`. Gli indirizzi IP dei pod vengono allocati da questi secondari ENIs utilizzando i prefissi /28 per impostazione predefinita, con fallback automatico sul secondario IPs (/32) quando non è disponibile un blocco di prefisso contiguo. Se `ipv4PrefixSize` è impostato su in, vengono utilizzati solo quelli secondari. `"32"` `advancedNetworking` IPs
1. I gruppi di sicurezza specificati in `podSecurityGroupSelectorTerms` si applicano al traffico Pod all'interno del VPC. Per il traffico destinato all'esterno del VPC, i Pod utilizzano l'ENI principale del nodo (e i relativi gruppi di sicurezza) perché la traduzione degli indirizzi di rete di origine (SNAT) traduce l'IP del Pod nell'IP del nodo. È possibile modificare questo comportamento con il campo in. `snatPolicy` `NodeClass`
### Casi d’uso
Usa `podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms` quando ne hai bisogno:
+ Applica diversi gruppi di sicurezza per controllare il traffico per nodi e Pod separatamente.
+ Separa il traffico dell'infrastruttura (node-to-node comunicazione) dal traffico delle applicazioni (Pod-to-Pod comunicazione).
+ Applicare configurazioni di rete diverse alle sottoreti dei nodi rispetto alle sottoreti Pod.
+ Configurare i proxy inversi o il filtraggio di rete in modo specifico per il traffico dei nodi senza influire sul traffico dei Pod. Utilizza `advancedNetworking` e `certificateBundles` per definire il tuo proxy inverso e qualsiasi certificato autofirmato o privato per il proxy.
### Configurazione di esempio
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Considerazioni relative a sottoreti Pod e gruppi di sicurezza separati
+ **Ambito del gruppo** di sicurezza: i gruppi di sicurezza di `podSecurityGroupSelectorTerms` sono collegati al secondario ENIs e si applicano al traffico Pod all'interno del VPC. Quando SNAT è abilitato (impostazione predefinita`snatPolicy: Random`), il traffico in uscita dal VPC viene tradotto nell'indirizzo IP ENI primario del nodo, quindi i gruppi di sicurezza del nodo si applicano `securityGroupSelectorTerms` invece a quel traffico. Se lo imposti`snatPolicy: Disabled`, i Pod utilizzano i propri indirizzi IP per tutto il traffico e devi assicurarti che i gruppi di routing e sicurezza siano configurati di conseguenza.
+ **NodeClassgranularità a livello** di. I gruppi di sicurezza Pod si applicano a tutti i Pod programmati sui nodi che utilizzano il. `NodeClass` Per applicare gruppi di sicurezza diversi a carichi di lavoro diversi, crea `NodePool` risorse `NodeClass` e strumenti separati e utilizza contaminazioni, tolleranze o selettori di nodi per pianificare i carichi di lavoro sui nodi appropriati.
+ **Densità di pod ridotta**: è possibile eseguire un minor numero di pod su ciascun nodo perché l'interfaccia di rete principale del nodo è riservata all'IP del nodo e non può essere utilizzata per i pod.
+ **Limitazioni del selettore di sottorete**: lo standard `subnetSelectorTerms` e le `securityGroupSelectorTerms` configurazioni non si applicano alla selezione della sottorete Pod o del gruppo di sicurezza.
+ **Pianificazione della rete**: assicurati che lo spazio degli indirizzi IP sia adeguato sia nella sottorete del nodo che in quella del pod per supportare i requisiti del tuo carico di lavoro.
+ **Configurazione del routing**: verifica che la tabella di routing e la lista di controllo degli accessi (ACL) delle sottoreti del pod siano configurate correttamente per la comunicazione tra il nodo e le sottoreti del pod.
+ **Zone di disponibilità**: verifica di aver creato sottoreti Pod su più sottoreti. AZs Se utilizzi una sottorete Pod specifica, deve trovarsi nella stessa AZ della sottorete di nodi AZ.
## Modalità IP secondaria per Pod
Il `ipv4PrefixSize` campo consente configurazioni di rete avanzate allocando solo indirizzi IP secondari ai nodi. Questa funzionalità non assegna prefissi (/28) ai nodi e mantiene un solo IP secondario come minimo. IPTarget
### Casi d’uso
Usa `ipv4PrefixSize` quando devi:
+ **Utilizzo IP ridotto**: verrà riscaldato solo un indirizzo IP in ogni nodo.
+ **Riduzione del tasso di produzione dei pod**: la velocità di creazione dei pod non è una delle principali preoccupazioni.
+ **Nessuna frammentazione del prefisso: la frammentazione** causata dal prefisso è una delle principali preoccupazioni o ostacola l'utilizzo della modalità automatica.
### Configurazione di esempio
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### Considerazioni sulla modalità IP secondaria
+ **Velocità di creazione dei pod ridotta**: poiché viene riscaldato solo un IP secondario, il servizio IPAM richiede più tempo per il provisioning IPs quando vengono creati più pod.
## Disabilita l' IPv4 uscita dai pod nei cluster. IPv6 IPv6
Il `enableV4Egress` campo è `true` di default. Per IPv6 i cluster Auto Mode, la funzione può essere disabilitata in modo che Auto Mode non crei un'interfaccia di sola uscita per i pod IPv4 . IPv6 Questo è importante perché l'interfaccia di IPv4 uscita non è soggetta all'applicazione delle politiche di rete. Le politiche di rete vengono applicate solo sull'interfaccia principale del Pod (eth0).
### Casi d’uso
Usa `enableV4Egress` quando devi:
+ **Usa IPv6 Cluster**: il traffico IPv4 in uscita è consentito per impostazione predefinita.
+ **Usa la politica di rete**: attualmente la politica di rete EKS non supporta il dual stack. La disabilitazione `enableV4Egress` può impedire al traffico dei pod di uscire in modo imprevisto. IPv4
### Configurazione di esempio
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Considerazioni sulla disabilitazione di EnableV4Egress
+ **Politica di rete nel cluster: i IPv6 cluster** consentono il traffico per impostazione predefinita. IPv6 IPv4 L'impostazione `enableV4Egress: false` blocca il traffico in IPv4 uscita, fornendo una maggiore sicurezza, specialmente se utilizzata con le politiche di rete.
# Crea un pool di nodi per EKS Auto Mode
I pool di nodi Amazon EKS forniscono un modo flessibile per gestire le risorse di calcolo nel cluster Kubernetes. Questo argomento mostra come creare e configurare pool di nodi usando Karpenter, uno strumento di provisioning dei nodi che aiuta a ottimizzare il dimensionamento dei cluster e l’utilizzo delle risorse. Con la risorsa NodePool di Karpenter, puoi definire requisiti specifici per le tue risorse di calcolo, inclusi i tipi di istanze, le zone di disponibilità, le architetture e i tipi di capacità.
Non è possibile modificare il `system` integrato e i pool di nodi `general-purpose`. È solo possibile abilitarli o disabilitarli. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
La specifica NodePool permette un controllo granulare delle risorse di elaborazione del cluster EKS tramite diverse etichette e requisiti supportati. Queste comprendono opzioni per specificare le categorie di istanze EC2, le configurazioni della CPU, le zone di disponibilità, le architetture (ARM64/AMD64) e i tipi di capacità (spot o on-demand). È inoltre possibile impostare limiti di risorse per l’utilizzo della CPU e della memoria, garantendo che il cluster rimanga entro i limiti operativi richiesti.
EKS Auto Mode sfrutta le note etichette Kubernetes per offrire metodi coerenti e standardizzati di identificazione delle caratteristiche dei nodi. Queste etichette, come `topology.kubernetes.io/zone` per le zone di disponibilità e `kubernetes.io/arch` per l’architettura della CPU, seguono le convenzioni stabilite da Kubernetes. Inoltre, le etichette specifiche EKS (precedute dal prefisso `eks.amazonaws.com/`) estendono questa funzionalità con attributi specifici AWS quali tipi di istanza, produttori di CPU, capacità GPU e specifiche di rete. Questo sistema di etichettatura standardizzato consente un’integrazione ottimale con gli strumenti Kubernetes esistenti, fornendo al tempo stesso una profonda integrazione dell’infrastruttura AWS.
## Creazione di NodePool
Segui i seguenti passaggi per creare un NodePool per il cluster Amazon EKS:
1. Crea un file YAML denominato `nodepool.yaml` con la configurazione NodePool richiesta. Puoi utilizzare la configurazione di esempio seguente.
1. Applica il NodePool al cluster:
```
kubectl apply -f nodepool.yaml
```
1. Verificare che il NodePool sia stato creato correttamente:
```
kubectl get nodepools
```
1. (Facoltativo) Monitora lo stato del NodePool:
```
kubectl describe nodepool default
```
Assicurati che il NodePool faccia riferimento a una NodeClass valida ed esistente nel tuo cluster. NodeClass definisce configurazioni specifiche AWS per le risorse di calcolo. Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
## NodePool di esempio
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Etichette supportate da EKS Auto Mode
EKS Auto Mode supporta le seguenti etichette note.
**Nota**
EKS Auto Mode utilizza etichette diverse rispetto a Karpenter. Le etichette relative alle istanze gestite da EC2 iniziano con `eks.amazonaws.com`.
| Etichetta | Esempio | Descrizione |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | Regione AWS |
| node.kubernetes.io/instance-type | g4dn.8xlarge | Tipo di istanza AWS |
| kubernetes.io/arch | amd64 | Le architetture sono definite dai [valori GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) sull’istanza |
| karpenter.sh/capacity-type | spot | I tipi di capacità includono `spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Tipi di istanze che usano un hypervisor specifico |
| eks.amazonaws.com/compute-type | auto | Identifica i nodi gestiti da EKS Auto Mode |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Tipi di istanza che supportano (o non supportano) la crittografia in transito |
| eks.amazonaws.com/instance-category | g | Tipi di istanza della stessa categoria, in genere la stringa che precede il numero di generazione |
| eks.amazonaws.com/instance-generation | 4 | Numero di generazione del tipo di istanza in una categoria di istanza |
| eks.amazonaws.com/instance-family | g4dn | Tipi di istanza con proprietà simili ma quantità di risorse differenti |
| eks.amazonaws.com/instance-size | 8xlarge | Tipi di istanza con quantità di risorse simili ma proprietà differenti |
| eks.amazonaws.com/instance-cpu | 32 | Numero di CPU sull’istanza |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Nome del produttore della CPU |
| eks.amazonaws.com/instance-memory | 131072 | Numero di mebibyte di memoria sull’istanza |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | Numero [massimo di megabit](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) di EBS disponibili sull’istanza |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | Numero di [megabit di base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponibili sull’istanza |
| eks.amazonaws.com/instance-gpu-name | t4 | Nome della GPU nell’istanza, se disponibile |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Nome del produttore della GPU |
| eks.amazonaws.com/instance-gpu-count | 1 | Numero di GPU nell’istanza |
| eks.amazonaws.com/instance-gpu-memory | 16384 | Numero di mebibyte di memoria sulla GPU |
| eks.amazonaws.com/instance-local-nvme | 900 | Gibibyte di storage nvme locale nell’istanza |
**Nota**
EKS Auto Mode supporta solo certe istanze e prevede dei requisiti minimi di dimensione. Per ulteriori informazioni, consulta [Riferimento all’istanza supportata dalla modalità automatica EKS](automode-learn-instances.md#auto-supported-instances).
## Etichette non supportate da EKS Auto Mode
EKS Auto Mode non supporta le seguenti etichette.
+ EKS Auto Mode supporta soltanto Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Disattivare i pool di nodi integrati
Se crei pool di nodi personalizzati, puoi disattivare i pool di nodi integrati. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
## Cluster senza pool di nodi integrati
Puoi creare un cluster senza pool di nodi integrati. È utile quando l’organizzazione ha creato pool di nodi personalizzati.
**Nota**
Quando crei un cluster senza pool di nodi integrati, il provisioning di NodeClass `default` non viene eseguito automaticamente. Sarà necessario creare una NodeClass personalizzata. Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
**Panoramica:**
1. Crea un cluster EKS con i valori `nodePools` e `nodeRoleArn` vuoti.
+ Esempio eksctl `autoModeConfig`:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Per ulteriori informazioni, consulta [Crea un cluster di EKS Auto Mode con la CLI di eksctl](automode-get-started-eksctl.md)
1. Crea una classe di nodi personalizzata con un ruolo del nodo ARN
+ Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md)
1. Crea una voce di accesso per la classe di nodi personalizzata
+ Per ulteriori informazioni, consulta [Creazione di una voce di accesso alla classe di nodi](create-node-class.md#auto-node-access-entry)
1. Crea un pool di nodi personalizzato come descritto sopra.
## Interruzione
Puoi configurare EKS Auto Mode in modo che interrompa i nodi tramite NodePool in diversi modi. Puoi usare `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` o `spec.template.spec.expireAfter`. Puoi anche limitare l’interruzione di EKS Auto Mode tramite il `spec.disruption.budgets` del NodePool. Puoi inoltre controllare le finestre temporali e il numero di nodi simultanei interrotti. Per istruzioni sulla configurazione di questo comportamento, consulta la pagina [Disruption](https://karpenter.sh/docs/concepts/disruption/) nella documentazione di Karpenter.
Puoi configurare l’interruzione per i pool di nodi per:
+ Identifica le istanze sottoutilizzate e consolida i carichi di lavoro.
+ Crea un budget per le interruzioni dei pool di nodi per limitare le interruzioni dei nodi causate da deviazioni, vuoto e consolidamento.
Per impostazione predefinita, EKS Auto Mode:
+ Consolida le istanze sottoutilizzate.
+ Termina le istanze dopo 336 ore.
+ Imposta un budget unico per le interruzioni pari al 10% dei nodi.
+ Permette la sostituzione dei nodi a causa della deriva quando viene rilasciata una nuova AMI in Auto Mode, cosa che avviene circa una volta alla settimana.
## Periodo di tolleranza della terminazione
Quando un `terminationGracePeriod` non è definito esplicitamente su un EKS Auto NodePool, il sistema applica automaticamente un periodo di tolleranza della terminazione predefinito di 24 ore al NodeClaim associato. Sebbene i clienti EKS Auto non vedranno un termine `terminationGracePeriod` predefinito nelle loro configurazioni NodePool personalizzate, osserveranno questo valore predefinito su NodeClaim. La funzionalità rimane coerente sia che il periodo di tolleranza sia impostato esplicitamente sul NodePool sia che sia predefinito sul NodeClaim, garantendo così un comportamento prevedibile di terminazione dei nodi in tutto il cluster.
# Pool di nodi a capacità statica in modalità EKS Auto
La modalità automatica di Amazon EKS supporta pool di nodi a capacità statica che mantengono un numero fisso di nodi indipendentemente dalla domanda del pod. I pool di nodi con capacità statica sono utili per carichi di lavoro che richiedono capacità prevedibile, istanze riservate o requisiti di conformità specifici in cui è necessario mantenere un ingombro dell'infrastruttura coerente.
A differenza dei pool di nodi dinamici che si ridimensionano in base alle richieste di pianificazione dei pod, i pool di nodi con capacità statica mantengono il numero di nodi configurati.
## Configurare un pool di nodi con capacità statica
Per creare un pool di nodi con capacità statica, imposta il `replicas` campo nelle tue NodePool specifiche. Il `replicas` campo definisce il numero esatto di nodi che il pool di nodi manterrà. Scopri [Esempi](#static-capacity-examples) come configurare`replicas`.
## Considerazioni sulla capacità statica del pool di nodi
I pool di nodi con capacità statica presentano diversi vincoli e comportamenti importanti:
**Vincoli di configurazione:**
+ **Impossibile cambiare modalità**: una volta impostato `replicas` un pool di nodi, non è possibile rimuoverlo. Il pool di nodi non può passare dalla modalità statica a quella dinamica.
+ **Limiti di risorse limitati**: nella sezione dei limiti è supportato solo il `limits.nodes` campo. I limiti di CPU e memoria non sono applicabili.
+ **Nessun campo di peso**: il `weight` campo non può essere impostato su pool di nodi con capacità statica poiché la selezione dei nodi non si basa sulla priorità.
**Comportamento operativo:**
+ **Nessun consolidamento**: i nodi nei pool di capacità statici non vengono presi in considerazione per il consolidamento.
+ **Operazioni di scalabilità: le operazioni di scalabilità** evitano i budget relativi alle interruzioni dei nodi, ma rispettano comunque i requisiti. PodDisruptionBudgets
+ **Sostituzione** dei nodi: i nodi vengono comunque sostituiti per eventuali variazioni (come gli aggiornamenti AMI) e per scadenza in base alla configurazione.
## Best practice
**Pianificazione della capacità:**
+ Impostato su un `limits.nodes` valore superiore `replicas` a per consentire il ridimensionamento temporaneo durante le operazioni di sostituzione dei nodi.
+ Quando imposti i limiti, considera la capacità massima necessaria durante la deriva dei nodi o gli aggiornamenti AMI.
**Selezione dell'istanza:**
+ Utilizza tipi di istanze specifici quando hai istanze riservate o requisiti hardware specifici.
+ Evita requisiti eccessivamente restrittivi che potrebbero limitare la disponibilità delle istanze durante la scalabilità.
**Gestione delle interruzioni:**
+ Configura i budget appropriati per le interruzioni per bilanciare la disponibilità con le operazioni di manutenzione.
+ Considerate la tolleranza della vostra applicazione per la sostituzione dei nodi quando impostate le percentuali di budget.
**Monitoraggio:**
+ Monitora regolarmente il `status.nodes` campo per garantire il mantenimento della capacità desiderata.
+ Imposta avvisi per quando il numero effettivo di nodi si discosta dalle repliche desiderate.
**Distribuzione delle zone:**
+ Per un'elevata disponibilità, distribuisci la capacità statica su più zone di disponibilità.
+ Quando si crea un pool di nodi con capacità statica che si estende su più zone di disponibilità, EKS Auto Mode distribuisce i nodi tra le zone specificate, ma non è garantito che la distribuzione sia uniforme.
+ Per una distribuzione prevedibile e uniforme tra le zone di disponibilità, crea pool di nodi con capacità statica separati, ciascuno collegato a una zona di disponibilità specifica utilizzando il requisito. `topology.kubernetes.io/zone`
+ Se hai bisogno di 12 nodi distribuiti uniformemente su tre zone, crea tre pool di nodi con 4 repliche ciascuno, anziché un pool di nodi con 12 repliche su tre zone.
## Scalabilità di un pool di nodi con capacità statica
È possibile modificare il numero di repliche in un pool di nodi con capacità statica utilizzando il `kubectl scale` comando:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
In caso di ridimensionamento, EKS Auto Mode terminerà i nodi in modo corretto, rispettando PodDisruptionBudgets e consentendo la riprogrammazione dei pod in esecuzione sui nodi rimanenti.
## Monitora i pool di nodi con capacità statica
Utilizzate i seguenti comandi per monitorare i pool di nodi con capacità statica:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
Il `status.nodes` campo mostra il numero attuale di nodi gestiti dal pool di nodi, che dovrebbe corrispondere al `replicas` numero desiderato in condizioni normali.
## Risoluzione dei problemi
**I nodi non raggiungono le repliche desiderate:**
+ Controlla se il `limits.nodes` valore è sufficiente
+ Verifica che i requisiti non limitino eccessivamente la selezione delle istanze
+ Controlla le quote AWS di servizio per i tipi di istanze e le regioni che stai utilizzando
**La sostituzione dei nodi richiede troppo tempo:**
+ Modifica i budget per le interruzioni per consentire più sostituzioni simultanee
+ Controlla se PodDisruptionBudgets stanno impedendo la chiusura del nodo
**Chiusura imprevista del nodo:**
+ Rivedi le impostazioni `expireAfter` e `terminationGracePeriod`
+ Verifica la presenza di interruzioni manuali dei nodi o di eventi AWS di manutenzione
## Esempi
### Pool di nodi con capacità statica di base
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Capacità statica con tipi di istanze specifici
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Pool di nodi con capacità statica multizona
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Capacità statica con riserva di capacità
L'esempio seguente mostra come utilizzare un pool di nodi di capacità statica con una prenotazione di capacità EC2. Per ulteriori informazioni sull'utilizzo di EC2 Capacity Reservations con EKS Auto Mode, consulta. [Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS](auto-odcr.md)
`NodeClass`definizione del `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`facendo riferimento a quanto sopra `NodeClass` e utilizzando`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Creare e IngressClass configurare un Application Load Balancer
La modalità automatica di EKS automatizza le attività di routine per il bilanciamento del carico, inclusa l’esposizione delle app del cluster a Internet.
AWS suggerisce di utilizzare Application Load Balancers (ALB) per servire il traffico HTTP e HTTPS. Gli Application Load Balancer possono instradare le richieste in base al contenuto della richiesta. Per ulteriori informazioni sugli Application Load Balancer, consulta [What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
EKS Auto Mode crea e configura Application Load Balancer (). ALBs Ad esempio, modalità automatica di EKS crea un bilanciatore del carico quando crei un oggetto Kubernetes `Ingress` e lo configura per indirizzare il traffico verso il carico di lavoro del cluster.
**Panoramica**
1. Crea un carico di lavoro da esporre a Internet.
1. Crea una `IngressClassParams` risorsa, specificando valori di configurazione AWS specifici come il certificato da utilizzare per le SSL/TLS sottoreti VPC.
1. Creare una risorsa `IngressClass`, specificando che modalità automatica di EKS sarà il controller della risorsa.
1. Crea una risorsa `Ingress` da associare a un percorso e una porta HTTP a un carico di lavoro del cluster.
La modalità automatica di EKS creerà un Application Load Balancer che punta al carico di lavoro specificato nella risorsa `Ingress`, utilizzando la configurazione del bilanciatore del carico specificata nella risorsa `IngressClassParams`.
## Prerequisiti
+ La modalità automatica di EKS su un cluster Amazon EKS
+ Kubectl configurato per connettersi al cluster
+ Puoi usare `kubectl apply -f ` per applicare i file di configurazione di esempio YAML riportati di seguito al cluster.
**Nota**
La modalità automatica di EKS richiede i tag di sottorete per identificare le sottoreti pubbliche e private.
Se hai creato il cluster con `eksctl`, disponi già di questi tag.
Informazioni su come [Assegnazione di tag alle sottoreti per la modalità automatica EKS](tag-subnets-auto.md).
## Fase 1: Creare un carico di lavoro
Per iniziare, crea un carico di lavoro da esporre a Internet. Può trattarsi di qualsiasi risorsa di Kubernetes che serve il traffico HTTP, ad esempio un’implementazione o un servizio.
Questo esempio utilizza un semplice servizio HTTP chiamato `service-2048` che ascolta sulla porta `80`. Creare questo servizio e la sua implementazione applicando il seguente manifesto, `2048-deployment-service.yaml`:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Applica la configurazione al cluster:
```
kubectl apply -f 2048-deployment-service.yaml
```
Le risorse sopra elencate verranno create nel namespace predefinito. Puoi verificarlo eseguendo il comando seguente:
```
kubectl get all -n default
```
## Fase 2: Creare IngressClassParams
Crea un `IngressClassParams` oggetto per specificare opzioni di configurazione AWS specifiche per l'Application Load Balancer. In questo esempio, creiamo una risorsa `IngressClassParams` denominata `alb` (che verrà utilizzata nella fase successiva) che specifica lo schema del bilanciatore del carico come `internet-facing` in un file chiamato `alb-ingressclassparams.yaml`.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Applica la configurazione al cluster:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Fase 3: Creare IngressClass
Crea un file `IngressClass` che faccia riferimento ai valori di configurazione AWS specifici impostati nella `IngressClassParams` risorsa in un file denominato`alb-ingressclass.yaml`. Annotare il nome della `IngressClass`. In questo esempio, sia `IngressClass` che `IngressClassParams` sono denominati `alb`.
Utilizzare l’annotazione `is-default-class` per controllare se le risorse `Ingress` devono utilizzare questa classe per impostazione predefinita.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Per ulteriori informazioni sulle opzioni di configurazione, consultare [IngressClassParams Riferimento](#ingress-reference).
Applica la configurazione al cluster:
```
kubectl apply -f alb-ingressclass.yaml
```
## Fase 4: Creare Ingress
Creare una risorsa `Ingress` in un file denominato `alb-ingress.yaml`. Lo scopo di questa risorsa è associare percorsi e porte sull’Application Load Balancer ai carichi di lavoro del cluster. Per questo esempio, creiamo una risorsa `Ingress` denominata `2048-ingress` che instrada il traffico verso un servizio denominato `service-2048` sulla porta 80.
Per ulteriori informazioni sulla configurazione di questa risorsa, consultare [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) nella documentazione su Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Applica la configurazione al cluster:
```
kubectl apply -f alb-ingress.yaml
```
## Fase 5: Controllare lo stato
Utilizza `kubectl` per trovare lo stato di `Ingress`. Prima che il bilanciatore del carico sia disponibile, potrebbero essere necessari alcuni minuti.
Utilizza il nome della risorsa `Ingress` impostata nella fase precedente. Esempio:
```
kubectl get ingress 2048-ingress
```
Una volta che la risorsa è pronta, recuperare il nome di dominio del bilanciatore del carico.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Per visualizzare il servizio in un browser web, esamina la porta e il percorso specificati nel file di ripristino `Ingress`.
## Fase 6: Eliminazione
Per eliminare il bilanciatore del carico, utilizza il seguente comando:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS Auto Mode eliminerà automaticamente il sistema di bilanciamento del carico associato nel tuo AWS account.
## IngressClassParams Riferimento
La tabella seguente è un riferimento rapido per le opzioni di configurazione più comunemente utilizzate.
| Campo | Description | Valore di esempio |
| --- | --- | --- |
| `scheme` | Definisce se l’ALB è interno o esposto a Internet | `internet-facing` |
| `namespaceSelector` | Limita quali namespace possono utilizzarlo IngressClass | `environment: prod` |
| `group.name` | Raggruppa più ingressi per condividere un singolo ALB | `retail-apps` |
| `ipAddressType` | Imposta il tipo di indirizzo IP per ALB | `dualstack` |
| `subnets.ids` | Elenco di sottoreti per la distribuzione ALB IDs | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Filtri di tag per selezionare le sottoreti per ALB | `Environment: prod` |
| `certificateARNs` | ARNs di certificati SSL da utilizzare | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Tag personalizzati per le risorse AWS | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Attributi specifici del bilanciatore del carico | `idle_timeout.timeout_seconds: 60` |
## Considerazioni
+ Non è possibile utilizzare Annotations su un PC IngressClass per configurare i sistemi di bilanciamento del carico con EKS Auto Mode. IngressClass la configurazione deve essere eseguita tramite. IngressClassParams Tuttavia, è possibile utilizzare le annotazioni sulle singole risorse Ingress per configurare il comportamento del load balancer (ad `alb.ingress.kubernetes.io/security-group-prefix-lists` esempio o). `alb.ingress.kubernetes.io/conditions.*`
+ Non è possibile impostare [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)con EKS Auto Mode.
+ È necessario aggiornare il ruolo Cluster IAM per abilitare la propagazione dei tag dalle risorse Kubernetes alle risorse Load AWS Balancer. Per ulteriori informazioni, consulta [Tag personalizzati per AWS le risorse EKS Auto](auto-learn-iam.md#tag-prop).
+ Per informazioni sull'associazione di risorse a EKS Auto Mode o al Load AWS Balancer Controller autogestito, vedere. [Materiale di riferimento per le migrazioni](migrate-auto.md#migration-reference)
+ Per informazioni sulla risoluzione dei problemi con i bilanciatori del carico, consulta [Risoluzione dei problemi della modalità automatica di EKS](auto-troubleshoot.md).
+ Per ulteriori considerazioni sull’utilizzo della funzionalità di bilanciamento del carico della modalità automatica di EKS, consulta [Sistema di bilanciamento del carico](auto-networking.md#auto-lb-consider).
Le tabelle seguenti forniscono un confronto dettagliato delle modifiche IngressClassParams, delle annotazioni di Ingress e delle TargetGroupBinding configurazioni per EKS Auto Mode. Queste tabelle evidenziano le principali differenze tra la capacità di bilanciamento del carico della modalità automatica di EKS e il controller del bilanciatore del carico open source, comprese le modifiche alla versione dell’API, le funzionalità obsolete e i nomi dei parametri aggiornati.
### IngressClassParams
| Precedente | Novità | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifica alla versione dell’API |
| `spec.certificateArn` | `spec.certificateARNs` | Support per più certificati ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Schema di corrispondenza delle sottoreti modificato |
| `spec.listeners.listenerAttributes` | Non supportata | Non ancora supportato dalla modalità automatica di EKS |
### Annotazioni di ingresso
| Precedente | Novità | Description |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Non supportata | Utilizzare `spec.ingressClassName` su oggetti di ingresso |
| `alb.ingress.kubernetes.io/group.name` | Non supportata | Specificate i gruppi IngressClass solo in |
| `alb.ingress.kubernetes.io/waf-acl-id` | Non supportata | Usare invece WAF v2 |
| `alb.ingress.kubernetes.io/web-acl-id` | Non supportata | Usare invece WAF v2 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Non supportata | Integrazione Shield disattivata |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Non supportata | Il tipo di autenticazione OIDC non è attualmente supportato |
### TargetGroupBinding
| Precedente | Novità | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifica alla versione dell’API |
| `spec.targetType` facoltativo | `spec.targetType` obbligatorio | Specifica esplicita del tipo di destinazione |
| `spec.networking.ingress.from` | Non supportata | Non supporta più NLB senza gruppi di sicurezza |
Per utilizzare la TargetGroupBinding funzionalità personalizzata, devi etichettare il gruppo target con il tag eks: eks-cluster-name tag with cluster name per concedere al controller le autorizzazioni IAM necessarie. Tieni presente che il controller eliminerà il gruppo di destinazione quando la TargetGroupBinding risorsa o il cluster vengono eliminati.
# Usa Annotazioni del servizio per configurare Network Load Balancer
Scopri come configurare Network Load Balancer (NLB) in Amazon EKS utilizzando le annotazioni del servizio di Kubernetes. Questo argomento spiega le annotazioni supportate da EKS Auto Mode per personalizzare il comportamento NLB, tra cui accessibilità Internet, controlli di integrità, SSL/TLS terminazione e modalità di targeting IP.
Quando crei un servizio Kubernetes di tipo `LoadBalancer` in modalità automatica EKS, EKS effettua automaticamente il provisioning e configura un AWS Network Load Balancer in base alle annotazioni specificate. Questo approccio dichiarativo ti consente di gestire le configurazioni del bilanciatore del carico direttamente tramite i manifesti di Kubernetes, mantenendo l’infrastruttura come pratiche di codice.
EKS Auto Mode gestisce il provisioning di Network Load Balancer per impostazione predefinita per tutti i servizi di tipo LoadBalancer : non è richiesta alcuna installazione o configurazione di controller aggiuntivi. La specifica `loadBalancerClass: eks.amazonaws.com/nlb` viene impostata automaticamente come impostazione predefinita del cluster, semplificando il processo di implementazione e mantenendo la compatibilità con i carichi di lavoro di Kubernetes esistenti.
**Nota**
La modalità automatica di EKS richiede i tag di sottorete per identificare le sottoreti pubbliche e private.
Se hai creato il cluster con `eksctl`, disponi già di questi tag.
Informazioni su come [Assegnazione di tag alle sottoreti per la modalità automatica EKS](tag-subnets-auto.md).
## Servizio di esempio
Per ulteriori informazioni sulla risorsa `Service` di Kubernetes, consulta [Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/service/).
Consulta la risorsa di esempio `Service` riportata di seguito:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Annotazioni di uso comune
La tabella seguente elenca le annotazioni di uso comune supportate dalla modalità automatica di EKS. La modalità automatica di EKS potrebbe non supportare tutte le annotazioni.
**Suggerimento**
Tutte le seguenti annotazioni devono avere il prefisso `service.beta.kubernetes.io/`
| Campo | Description | Esempio |
| --- | --- | --- |
| `aws-load-balancer-type` | Specifica il tipo di bilanciatore del carico. Utilizza `external` per nuove implementazioni. | `external` |
| `aws-load-balancer-nlb-target-type` | Speciifica se indirizzare il traffico verso le istanze del nodo o direttamente verso il pod. IPs Utilizza `instance` per implementazioni standard o `ip` per l’instradamento diretto ai pod. | `instance` |
| `aws-load-balancer-scheme` | Controlla se il bilanciatore del carico è interno o esposto a Internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protocollo di controllo dell’integrità per il gruppo di destinazione. Le opzioni più comuni sono `TCP` (impostazione predefinita) o `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Il percorso HTTP per i controlli di integrità quando si utilizza HTTP/HTTPS il protocollo. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Porta utilizzata per i controlli dell’integrità. Può essere un numero di porta specifico o `traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Specifica in quali sottoreti creare il bilanciatore del carico. Può usare sottoreti IDs o nomi. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN del certificato SSL di Certificate Manager for AWS HTTPS/TLS. | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Specifica quali porte devono utilizzare SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Intervalli CIDR autorizzati ad accedere al bilanciatore del carico. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | AWS Tag aggiuntivi da applicare al sistema di bilanciamento del carico e alle risorse correlate. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Speciifica se il load balancer utilizza IPv4 o dual-stack (\$1). IPv4 IPv6 | `ipv4` o `dualstack` |
## Considerazioni
+ È necessario aggiornare il ruolo Cluster IAM per abilitare la propagazione dei tag dalle risorse Kubernetes alle risorse Load AWS Balancer. Per ulteriori informazioni, consulta [Tag personalizzati per AWS le risorse EKS Auto](auto-learn-iam.md#tag-prop).
+ Per informazioni sull'associazione di risorse a EKS Auto Mode o al Load AWS Balancer Controller autogestito, vedere. [Materiale di riferimento per le migrazioni](migrate-auto.md#migration-reference)
+ Per informazioni sulla risoluzione dei problemi con i bilanciatori del carico, consulta [Risoluzione dei problemi della modalità automatica di EKS](auto-troubleshoot.md).
+ Per ulteriori considerazioni sull’utilizzo della funzionalità di bilanciamento del carico della modalità automatica di EKS, consulta [Sistema di bilanciamento del carico](auto-networking.md#auto-lb-consider).
Durante la migrazione alla modalità automatica di EKS per il bilanciamento del carico, sono necessarie diverse modifiche nelle annotazioni dei servizi e nelle configurazioni delle risorse. Le tabelle seguenti descrivono le differenze principali tra le implementazioni precedenti e quelle nuove, includendo le opzioni non supportate e le alternative consigliate.
### Annotazioni dei servizi
| Precedente | Novità | Description |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Non supportata | Usa `spec.loadBalancerSourceRanges` sul servizio |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Non supportata | Usa `spec.loadBalancerClass` sul servizio |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Non supportata | Utilizzare `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` |
| Vari attributi del bilanciatore del carico | Non supportata | Utilizzare `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Non supportata | Usa invece `service.beta.kubernetes.io/aws-load-balancer-attributes` |
Per eseguire la migrazione dalle annotazioni obsolete degli attributi del bilanciatore del carico, consolida queste impostazioni nell’annotazione `service.beta.kubernetes.io/aws-load-balancer-attributes`. Questa annotazione accetta un elenco di coppie chiave-valore separato da virgole per vari attributi del bilanciatore del carico. Ad esempio, per specificare la registrazione degli accessi e il bilanciamento del carico tra zone, utilizzate il seguente formato:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Questo formato consolidato offre un modo più coerente e flessibile per configurare gli attributi del bilanciatore del carico riducendo al contempo il numero di singole annotazioni necessarie. Rivedi le configurazioni del servizio esistenti e aggiornale per utilizzare questo formato consolidato.
### TargetGroupBinding
| Precedente | Novità | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Modifica alla versione dell’API |
| `spec.targetType` facoltativo | `spec.targetType` obbligatorio | Specifica esplicita del tipo di destinazione |
| `spec.networking.ingress.from` | Non supportata | Non supporta più NLB senza gruppi di sicurezza |
Nota: per utilizzare la TargetGroupBinding funzionalità personalizzata, è necessario etichettare il gruppo di destinazione con il tag con il `eks:eks-cluster-name` nome del cluster per concedere al controller le autorizzazioni IAM necessarie. Tieni presente che il controller eliminerà il gruppo di destinazione quando la TargetGroupBinding risorsa o il cluster vengono eliminati.
# Crea una classe di archiviazione
Una `StorageClass` in Amazon EKS Auto Mode definisce come i volumi Amazon EBS vengono forniti automaticamente quando le applicazioni richiedono uno storage persistente. In questa pagina viene spiegato come creare e configurare una `StorageClass` che funzioni con Amazon EKS Auto Mode per il provisioning dei volumi EBS.
Configurando una `StorageClass`, è possibile specificare le impostazioni predefinite per i volumi EBS, inclusi il tipo di volume, la crittografia, gli IOPS e altri parametri di storage. Puoi anche configurare l'utilizzo delle `StorageClass` chiavi AWS KMS per la gestione della crittografia.
EKS Auto Mode non crea una `StorageClass` per te. Devi creare una `StorageClass` che faccia riferimento a `ebs.csi.eks.amazonaws.com` per usare la funzionalità di storage di EKS Auto Mode.
Per prima cosa, crea un file denominato `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Poi applica la classe di archiviazione al cluster.
```
kubectl apply -f storage-class.yaml
```
**Componenti chiave:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: usa EKS Auto Mode
+ `allowedTopologies`: specificando `matchLabelExpressions` in modo che corrisponda con `eks.amazonaws.com/compute-type:auto`, se i pod richiedono un volume su cui effettuare il provisioning automatico usando Auto Mode, i pod non verranno pianificati su nodi non automatici.
+ `volumeBindingMode: WaitForFirstConsumer`: ritarda la creazione del volume fino a quando un pod non ne ha bisogno
+ `type: gp3`: specifica il tipo di volume EBS
+ `encrypted: "true"`: EBS crittograferà tutti i volumi creati usando la `StorageClass`. EBS userà l’alias chiave predefinito `aws/ebs`. Per ulteriori informazioni, consulta [How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) nella Guida per l’utente di Amazon EBS. Questo valore è opzionale ma consigliato.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes userà questa classe di archiviazione per impostazione predefinita, a meno che non venga specificata una classe di volume diversa su una dichiarazione di volume persistente. Questo valore è facoltativo. Presta attenzione quando imposti questo valore se stai effettuando la migrazione da un controller di storage diverso.
## Usa la chiave KMS autogestita per crittografare i volumi EBS
Per usare una chiave KMS autogestita per crittografare i volumi EBS automatizzati da EKS Auto Mode, bisogna:
1. Creare una chiave KMS gestita dal cliente.
+ Per ulteriori informazioni, consulta [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) o [How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) nella Guida per gli utenti di KMS.
1. Creare una nuova policy che consenta l’accesso alla chiave KMS.
+ Usa la policy IAM di esempio riportata di seguito per creare la policy. Inserisci l’ARN della nuova chiave KMS autogestita. Per ulteriori informazioni, consulta [Creazione di ruoli e collegamento di politiche (console) nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) per l'utente AWS IAM.
1. Collegare la policy al ruolo del cluster EKS.
+ Usa la AWS console per trovare l'ARN dell'EKS Cluster Role. Le informazioni relative al ruolo sono visibili nella sezione **Panoramica**. Per ulteriori informazioni, consulta [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md).
1. Aggiornare la `StorageClass` per fare riferimento all’ID della chiave KMS nel campo `parameters.kmsKeyId`.
### Esempio di policy IAM KMS autogestita
Aggiorna i valori seguenti nella policy riportata di seguito:
+ ``— L'ID AWS del tuo account, ad esempio `111122223333`
+ ``— La AWS regione del cluster, ad esempio `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Esempio di `StorageClass` KMS gestita dal cliente
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## Guida di riferimento per i parametri `StorageClass`
Per informazioni generali sulle risorse `StorageClass` di Kubernetes, consulta [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/) nella documentazione di Kubernetes.
THe `parameters`la sezione della `StorageClass` risorsa è specifica per AWS. Utilizza la tabella seguente per esaminare le opzioni disponibili.
| Parameters | Valori | Predefinita | Description |
| --- | --- | --- | --- |
| “csi.storage.k8s.io/fstype” | xfs, ext2, ext3, ext4 | ext4 | Tipo di file system che verrà formattato al momento della creazione del volume. Questo parametro prevede la distinzione tra maiuscole e minuscole. |
| “type” | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | Tipo di volume EBS. |
| “iopsPerGB” | | | Operazioni di I/O al secondo per GiB. Può essere specificato per IO1 IO2, e GP3 volumi. |
| «Consenti automaticamente IOPSPerGBIncrease» | true, false | false | Quando`"true"`, il driver CSI aumenta gli IOPS per un volume troppo basso per rientrare nell'intervallo IOPS supportato da. `iopsPerGB * ` AWS Ciò consente al provisioning dinamico di avere sempre esito positivo, anche quando l’utente specifica una capacità PVC o un valore `iopsPerGB` troppo bassi. D’altra parte, ciò potrebbe comportare costi aggiuntivi, poiché tali volumi hanno un IOPS superiore a quello richiesto in `iopsPerGB`. |
| “iops” | | | Operazioni di I/O al secondo. Può essere specificato per IO1 IO2, e volumi. GP3 |
| “throughput” | | 125 | Velocità di trasmissione effettiva in MiB/S. Efficace solo quando è specificato il tipo di volume gp3. |
| “encrypted” | true, false | false | Se il volume deve essere crittografato o no. I valori validi sono “true” o “false”. |
| “blockExpress” | true, false | false | Permette la creazione di Volumi io2 Block Express. |
| "kmsKeyId" | | | L’ARN completo della chiave da usare per la crittografia del volume. Se non specificato, AWS utilizzerà la chiave KMS predefinita per la regione in cui si trova il volume. Si tratta di una chiave generata automaticamente chiamata `/aws/ebs` se non viene modificata. |
| “blockSize” | | | La dimensione del blocco da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| “inodeSize” | | | La dimensione dell’inode da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| "bytesPerInode" | | | `bytes-per-inode` da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4`. |
| "numberOfInodes" | | | `number-of-inodes` da utilizzare per la formattazione del filesystem sottostante. Supportata solo sui nodi linux e con fstype `ext2`, `ext3`, `ext4`. |
| «BigAllocext4" | true, false | false | Modifica il filesystem `ext4` per usare l’allocazione di blocchi in cluster abilitando l’opzione di formattazione `bigalloc`. Attenzione: `bigalloc` potrebbe non essere completamente supportato dal kernel Linux del nodo. |
| «ClusterSizeext4» | | | La dimensione del cluster da usare per formattare un filesystem `ext4` quando la funzionalità `bigalloc` è abilitata. Nota: il parametro `ext4BigAlloc` deve essere impostato su true |
Per ulteriori informazioni, consulta [AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md) Driver su. GitHub
## Considerazioni
**Nota**
È possibile distribuire carichi di lavoro solo in base alla modalità EKS Auto Mode sui nodi EKS Auto Mode StorageClasses . Se hai un cluster con tipi misti di nodi, devi configurare i carichi di lavoro in modo che vengano eseguiti solo sui nodi EKS Auto Mode. Per ulteriori informazioni, consulta [Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode](associate-workload.md).
La funzionalità di storage a blocchi di EKS Auto Mode è diversa da quella del driver CSI EBS.
+ Provisioning statico
+ Se desideri utilizzare volumi EBS creati esternamente con EKS Auto Mode, devi aggiungere manualmente un AWS tag con la chiave `eks:eks-cluster-name` e il valore del nome del cluster.
+ Taint startup del nodo
+ Non è possibile usare la funzionalità taint startup del nodo per impedire la pianificazione dei pod prima che la capacità di storage sia pronta
+ Tag personalizzati su volumi con provisioning dinamico
+ Non è possibile usare il flag CLI extra-tag per configurare tag personalizzati su volumi EBS con provisioning dinamico
+ Puoi usare l’assegnazione di tag `StorageClass` per aggiungere tag personalizzati. EKS Auto Mode aggiungerà tag alle risorse associate. AWS Dovrai aggiornare il ruolo del IAM cluster per i tag personalizzati. Per ulteriori informazioni, consulta [Tag personalizzati per AWS le risorse EKS Auto](auto-learn-iam.md#tag-prop).
+ Metriche sulle prestazioni dettagliate di EBS
+ Non puoi accedere alle metriche di Prometheus per le prestazioni dettagliate di EBS
## Installa il componente aggiuntivo CSI Snapshot Controller
EKS Auto Mode è compatibile con il componente aggiuntivo CSI Snapshot Controller di Amazon EKS.
AWS suggerisce di configurare questo componente aggiuntivo per l'esecuzione nel pool di `system` nodi integrato.
Per ulteriori informazioni, consulta:
+ [Eseguire componenti aggiuntivi critici su istanze dedicate](critical-workload.md)
+ [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md)
+ [Abilitare la funzionalità snapshot per i volumi CSI](csi-snapshot-controller.md)
### Per installare il controller di snapshot nel pool di nodi di sistema
1. Apri il tuo cluster EKS nella console AWS
1. Nella scheda **Componenti aggiuntivi**, seleziona **Ottieni altri componenti aggiuntivi**
1. Seleziona il controller **CSI Snapshot** e poi **Avanti**
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, seleziona **Impostazioni di configurazione opzionali** per visualizzare lo **schema di configurazione dei componenti aggiuntivi**
1. Inserisci il seguente yaml per associare il controller di snapshot al pool di nodi `system`. Il controller di snapshot include una tolleranza per il taint `CriticalAddonsOnly`.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Seleziona **Avanti**
1. Esamina la configurazione del componente aggiuntivo, poi seleziona **Crea**
# Disabilita modalità automatica di EKS
Puoi disabilita modalità automatica di EKS su un cluster EKS esistente. Si tratta di un’operazione distruttiva.
+ EKS interromperà tutte le EC2 istanze gestite da EKS Auto Mode.
+ EKS eliminerà tutti i bilanciatori del carico gestiti dalla modalità automatica di EKS.
+ EKS **non** eliminerà i volumi EBS forniti dalla modalità automatica di EKS.
modalità automatica di EKS è progettato per gestire completamente le risorse che crea. Gli interventi manuali potrebbero impedire alla modalità automatica di EKS di ripulire completamente tali risorse quando è disabilitata. Ad esempio, se hai fatto un riferimento a un gruppo di sicurezza gestito da regole esterne del gruppo di sicurezza e ti dimentica di rimuovere quel riferimento prima di disabilitare modalità automatica di EKS per un cluster, il gruppo di sicurezza gestito verrà divulgato (non verrà eliminato). Le fasi seguenti descrivono come rimuovere un gruppo di sicurezza trapelato se ciò dovesse accadere.
## Disattiva la modalità automatica EKS (console)AWS
1. Apri la pagina di panoramica del cluster in Console di gestione AWS.
1. In **modalità automatica di EKS**, seleziona **Gestisci**
1. Attiva **modalità automatica di EKS** su `off`.
Se un gruppo di sicurezza gestito non viene eliminato al termine di questo processo, puoi eliminarlo manualmente utilizzando le descrizioni in [Elimina un gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Disattiva la modalità automatica EKS (AWS CLI)
Utilizza il seguente comando per disabilitare modalità automatica di EKS su un cluster esistente.
Devi aver installato `aws` CLI ed essere connesso con autorizzazioni sufficienti per gestire i cluster EKS. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
**Nota**
Le funzionalità di calcolo, archiviazione a blocchi e bilanciamento del carico devono essere tutte abilitate o disabilitate nella stessa richiesta.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Puoi verificare se non è stato possibile eliminare un gruppo di sicurezza della modalità automatica di EKS divulgato dopo aver disabilitato modalità automatica di EKS nel modo seguente:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Poi, per eliminare il gruppo di sicurezza:
```
aws ec2 delete-security-group --group-name=
```
# Aggiornare la versione Kubernetes di un cluster di Amazon EKS Auto Mode
Questo argomento ti spiega come aggiornare la versione di Kubernetes per il cluster Auto Mode. Auto Mode semplifica il processo di aggiornamento delle versioni gestendo il coordinamento degli aggiornamenti del piano di controllo con la sostituzione dei nodi, mantenendo al contempo la disponibilità del carico di lavoro attraverso i budget relativi all’interruzione dei pod.
Quando si aggiorna un cluster Auto Mode, molti componenti che tradizionalmente richiedevano aggiornamenti manuali vengono ora gestiti come parte del servizio. Comprendere gli aspetti automatizzati del processo di aggiornamento e le proprie responsabilità aiuta a garantire una transizione fluida delle versioni per il cluster.
## Informazioni sugli aggiornamenti con EKS Auto Mode
Dopo che hai avviato un aggiornamento del piano di controllo, EKS Auto Mode aggiornerà i nodi del cluster. Alla scadenza dei nodi, EKS Auto Mode li sostituirà con nuovi nodi. I nuovi nodi hanno la nuova versione di Kubernetes corrispondente. EKS Auto Mode rispetta i budget relativi alle interruzioni dei pod durante l’aggiornamento dei nodi.
Inoltre, non dovrai più aggiornare componenti come:
+ CNI di Amazon VPC
+ Controller del load balancerAWS
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS Driver CSI per EBS
EKS Auto Mode sostituisce questi componenti con funzionalità di servizio.
L’utente è ancora responsabile dell’aggiornamento di:
+ App e carichi di lavoro implementati nel cluster
+ Componenti aggiuntivi e controller autogestiti
+ Componenti aggiuntivi di Amazon EKS
+ Informazioni su come [Aggiornamento di un componente aggiuntivo di Amazon EKS](updating-an-add-on.md)
Informazioni su [Best Practices for Cluster Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Avviare l’aggiornamento del cluster
Per avviare un aggiornamento del cluster, consulta [Aggiornamento del cluster esistente alla nuova versione di Kubernetes](update-cluster.md).
# Attivazione o disattivazione della funzionalità integrata NodePools
La modalità automatica EKS ne ha due integrate NodePools. Puoi abilitarli o disabilitarli NodePools utilizzando la AWS console, la CLI o l'API.
## Riferimento integrato NodePool
+ `system`
+ Questo NodePool ha una `CriticalAddonsOnly` macchia. Molti componenti aggiuntivi EKS, come CoredNS, tollerano questo taint. Utilizza questo pool di nodi di sistema per separare le applicazioni critiche per il cluster.
+ Supporta entrambe le architetture `amd64` e `arm64`.
+ `general-purpose`
+ Ciò NodePool fornisce supporto per l'avvio di nodi per carichi di lavoro generici nel cluster.
+ Utilizza solo l’architettura `amd64`.
Entrambi integrati: NodePools
+ Usa l'EKS predefinito NodeClass
+ Utilizza solo la capacità su richiesta EC2
+ Usa le famiglie di EC2 istanze C, M e R
+ Richiede istanze di quinta generazione o successive EC2
**Nota**
NodePool È necessario abilitare almeno una funzionalità integrata per consentire a EKS di eseguire il provisioning delle impostazioni «predefinite». NodeClass Se disabiliti tutte le funzionalità integrate NodePools, dovrai crearne una personalizzata NodeClass e configurarne una NodePool per utilizzarla. Per ulteriori informazioni su NodeClasses, consulta[Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
## Procedura
### Prerequisiti
+ La versione più recente dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo. Per verificare la versione attuale, usa `aws --version`. Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [configurazione rapida](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) con aws configure nella Guida per l'utente dell'interfaccia a riga di AWS comando.
+ Accedi alla CLI con autorizzazioni IAM sufficienti per creare AWS risorse tra cui politiche IAM, ruoli IAM e cluster EKS.
### Abilita con AWS CLI
Usa il seguente comando per abilitare entrambi i componenti integrati NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
È possibile modificare il comando per abilitare selettivamente il NodePools.
### Disabilita con AWS CLI
Usa il seguente comando per disabilitare entrambi i componenti integrati NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode
Quando si eseguono carichi di lavoro in un cluster EKS con EKS Auto Mode, potresti dover controllare se carichi di lavoro specifici vengono eseguiti su nodi EKS Auto Mode o altri tipi di elaborazione. Questo argomento descrive come utilizzare i selettori di nodi e le regole di affinità per garantire che i carichi di lavoro siano pianificati sull’infrastruttura di elaborazione prevista.
Gli esempi in questo argomento mostrano come utilizzare l’etichetta `eks.amazonaws.com/compute-type` per richiedere o impedire l’implementazione del carico di lavoro sui nodi di EKS Auto Mode. Ciò è particolarmente utile nei cluster a modalità mista in cui è in esecuzione sia EKS Auto Mode che altri tipi di elaborazione, come i provisioner Karpenter autogestiti o i gruppi di nodi gestiti da EKS.
I nodi di EKS Auto Mode hanno impostato il valore dell’etichetta da `eks.amazonaws.com/compute-type` a `auto`. Puoi utilizzare questa etichetta per controllare se un carico di lavoro viene implementato nei nodi gestiti da EKS Auto Mode.
## Richiedono che un carico di lavoro venga implementato ai nodi di EKS Auto Mode
**Nota**
Questo valore `nodeSelector` non è richiesto per EKS Auto Mode. Questo valore `nodeSelector` è rilevante solo se si esegue un cluster in modalità mista, con tipi di nodi non gestiti da EKS Auto Mode. Ad esempio, puoi avere una capacità di elaborazione statica implementata nel cluster con o gruppi di nodi gestiti da EKS e avere una capacità di elaborazione dinamica gestita da EKS Auto Mode.
Puoi aggiungere questo `nodeSelector` alle implementazioni o ad altri carichi di lavoro per richiedere che Kubernetes li pianifichi sui nodi di EKS Auto Mode.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Richiedono che un carico di lavoro non venga implementato ai nodi di EKS Auto Mode
Puoi aggiungere questo `nodeAffinity` alle implementazioni o ad altri carichi di lavoro per richiedere che Kubernetes **non** li pianifichi sui nodi di EKS Auto Mode.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Eseguire componenti aggiuntivi critici su istanze dedicate
Questo argomento illustra come implementare un carico di lavoro con una tolleranza `CriticalAddonsOnly` in modo che la modalità automatica EK lo pianifichi nel pool di nodi `system`.
Il pool di nodi integrato `system` della modalità automatica EKS è progettato per eseguire componenti aggiuntivi critici su istanze dedicate. Questa segregazione garantisce che i componenti essenziali dispongano di risorse dedicate e siano isolati dai carichi di lavoro generali, migliorando la stabilità e le prestazioni complessive del cluster.
Questa guida illustra come implementare componenti aggiuntivi nel pool di nodi `system` utilizzando la tolleranza `CriticalAddonsOnly` e i selettori dei nodi adeguati. Seguendo questa procedura, è possibile garantire che le applicazioni critiche siano pianificate sui nodi `system` dedicati, sfruttando i vantaggi dell’isolamento e dell’allocazione delle risorse offerti dalla struttura specializzata dei pool di nodi della modalità automatica EKS.
La modalità automatica EKS dispone di due pool di nodi integrati: `general-purpose` e `system`. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
Lo scopo del pool di nodi `system` è segregare i componenti aggiuntivi critici su nodi diversi. I nodi con provisioning del pool di nodi `system` hanno un taint Kubernetes `CriticalAddonsOnly`. Kubernetes pianificherà i pod su questi nodi solo se dispongono di una tolleranza corrispondente. Per ulteriori informazioni, consultare [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nella documentazione di Kubernetes.
## Prerequisiti
+ Cluster di modalità automatica EKS con il pool di nodi integrato `system` abilitato. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md)
+ `kubectl` installato e configurato. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Procedura
Rivedere l’esempio yaml riportato di seguito. Tenere presente le configurazioni seguenti:
+ `nodeSelector`: questa configurazione associa il carico di lavoro al pool di nodi integrato `system`. Questo pool di nodi deve essere abilitato con l’API AWS. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
+ `tolerations`: questa tolleranza supera il taint `CriticalAddonsOnly` sui nodi del pool di nodi `system`.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Per aggiornare un carico di lavoro affinché venga eseguito sul pool di nodi `system` è necessario:
1. Aggiornare il carico di lavoro esistenti affinché aggiunga le seguenti configurazioni descritte in precedenza:
+ `nodeSelector`
+ `tolerations`
1. Implementare il carico di lavoro aggiornato nel cluster con `kubectl apply`.
Una volta aggiornato, il carico di lavoro sarà eseguito su nodi dedicati.
# Usa le policy di rete con la modalità automatica di EKS
## Panoramica di
Man mano che i clienti scalano i propri ambienti applicativi utilizzando EKS, l'isolamento del traffico di rete diventa sempre più fondamentale per prevenire l'accesso non autorizzato alle risorse all'interno e all'esterno del cluster. Ciò è particolarmente importante in un ambiente multi-tenant con più carichi di lavoro non correlati che vengono eseguiti fianco a fianco nel cluster. Le policy di rete Kubernetes consentono di migliorare il livello di sicurezza della rete per i carichi di lavoro Kubernetes e le relative integrazioni con endpoint esterni al cluster. EKS Auto Mode supporta diversi tipi di politiche di rete.
### Isolamento di livello 3 e 4
Le policy di rete Kubernetes standard operano ai livelli 3 e 4 del modello di rete OSI e consentono di controllare il flusso di traffico a livello di indirizzo IP o di porta all'interno del cluster Amazon EKS.
#### Casi d’uso
+ Segmenta il traffico di rete tra i carichi di lavoro per garantire che solo le applicazioni correlate possano comunicare tra loro.
+ Isola i tenant a livello di namespace utilizzando policy per imporre la separazione della rete.
### Applicazione basata sul DNS
I clienti in genere implementano carichi di lavoro in EKS che fanno parte di un ambiente distribuito più ampio, alcuni dei quali devono comunicare con sistemi e servizi esterni al cluster (traffico in direzione nord). Questi sistemi e servizi possono essere nel AWS cloud o all'esterno. AWS Le policy basate sul Domain Name System (DNS) consentono di rafforzare il livello di sicurezza adottando un approccio più stabile e prevedibile per impedire l'accesso non autorizzato dai pod a risorse o endpoint esterni al cluster. Questo meccanismo elimina la necessità di tracciare e consentire manualmente l'elenco di indirizzi IP specifici. Proteggendo le risorse con un approccio basato sul DNS, si ha anche una maggiore flessibilità nell'aggiornare l'infrastruttura esterna senza dover allentare il livello di sicurezza o modificare le politiche di rete a causa delle modifiche apportate ai server e agli host upstream. È possibile filtrare il traffico in uscita verso endpoint esterni utilizzando un nome di dominio completo (FQDN) o uno schema corrispondente per un nome di dominio DNS. Ciò offre la maggiore flessibilità di estendere l'accesso a più sottodomini associati a un particolare endpoint esterno al cluster.
#### Casi d’uso
+ Standardizza un approccio basato su DNS per filtrare l'accesso da un ambiente Kubernetes agli endpoint esterni al cluster.
+ Accesso AWS sicuro ai servizi in un ambiente multi-tenant.
+ Gestisci l'accesso alla rete dai pod ai carichi di lavoro on-premise nei tuoi ambienti cloud ibridi.
### Regole amministrative (o con ambito cluster)
In alcuni casi, come negli scenari multi-tenant, i clienti potrebbero avere l'esigenza di applicare uno standard di sicurezza di rete applicabile all'intero cluster. Invece di definire e mantenere ripetutamente una policy distinta per ogni namespace, è possibile utilizzare un'unica policy per gestire centralmente i controlli di accesso alla rete per i diversi carichi di lavoro del cluster, indipendentemente dal relativo namespace. Questi tipi di policy consentono di estendere l'ambito di applicazione delle regole di filtraggio di rete applicate a livello 3, livello 4 e quando si utilizzano regole DNS.
#### Casi d’uso
+ Gestisci centralmente i controlli di accesso alla rete per tutti (o un sottoinsieme di) carichi di lavoro nel tuo cluster EKS.
+ Definisci una posizione di sicurezza di rete predefinita in tutto il cluster.
+ Estendi gli standard di sicurezza organizzativi all'ambito del cluster in un modo più efficiente dal punto di vista operativo.
## Nozioni di base
### Prerequisiti
+ Un cluster Amazon EKS con la modalità automatica di EKS abilitata
+ kubectl configurato per connettersi al cluster
### Fase 1: abilitare il controller della policy di rete
Per utilizzare le politiche di rete con EKS Auto Mode, devi prima abilitare il Network Policy Controller applicando un ConfigMap al tuo cluster.
1. Crea un file denominato `enable-network-policy.yaml` con i seguenti contenuti:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Applica il ConfigMap al tuo cluster:
```
kubectl apply -f enable-network-policy.yaml
```
### Fase 2: Creare e testare le politiche di rete
Il cluster della modalità automatica di EKS è ora configurato per supportare le policy di rete di Kubernetes. Puoi testarlo con la [Demo delle policy di rete con Stars per Amazon EKS](network-policy-stars-demo.md).
### Fase 3: Modifica della configurazione di Network Policy Agent in Node Class (opzionale)
Facoltativamente, è possibile creare una nuova classe di nodi per modificare il comportamento predefinito del Network Policy Agent sui nodi o abilitare la registrazione degli eventi di Network Policy. A tale scopo, seguire queste fasi:
1. Crea o modifica un file YAML di classe del nodo (ad esempio, `nodeclass-network-policy.yaml`) con i seguenti contenuti:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Applica la configurazione di classe del nodo al cluster:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Verifica che la classe del nodo sia stata creata:
```
kubectl get nodeclass network-policy-config
```
1. Aggiorna il pool di nodi per utilizzare questa classe di nodi. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
## Come funziona?
### Politica di rete basata su DNS
![\[Illustrazione del flusso di lavoro quando viene applicata una politica basata su DNS in EKS Auto\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Illustrazione del flusso di lavoro quando una politica basata su DNS viene applicata in EKS Auto\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/apply-dns-policy-2.png)
1. Il team della piattaforma applica una politica basata su DNS al cluster EKS.
1. Il Network Policy Controller è responsabile del monitoraggio della creazione delle politiche all'interno del cluster e della successiva riconciliazione degli endpoint delle politiche. In questo caso d'uso, il network policy controller ordina all'agente del nodo di filtrare le richieste DNS in base ai domini consentiti elencati nella policy creata. I nomi di dominio vengono elencati nell'elenco consentito utilizzando l'FQDN o un nome di dominio che corrisponde a uno schema definito nella configurazione delle risorse Kubernetes.
1. Workload A tenta di risolvere l'IP per un endpoint esterno al cluster. La richiesta DNS passa innanzitutto attraverso un proxy che filtra tali richieste in base all'elenco di autorizzazioni applicato tramite la politica di rete.
1. Una volta che la richiesta DNS passa attraverso l'elenco dei filtri DNS consentiti, viene inoltrata tramite proxy a CoredNS,
1. CoreDNS a sua volta invia la richiesta al Resolver DNS esterno (Amazon Route 53 Resolver) per ottenere l'elenco degli indirizzi IP dietro il nome di dominio.
1. I dati risolti IPs con TTL vengono restituiti nella risposta alla richiesta DNS. Questi IPs vengono quindi scritti in una mappa eBPF che viene utilizzata nella fase successiva per l'applicazione del livello IP.
1. Le sonde eBPF collegate all'interfaccia Pod veth filtreranno quindi il traffico in uscita dal carico di lavoro A all'endpoint esterno del cluster in base alle regole in vigore. Ciò garantisce che i pod possano inviare traffico esterno al cluster solo verso i domini consentiti elencati. IPs La validità di questi si IPs basa sul TTL recuperato dal Resolver DNS esterno (Amazon Route 53 Resolver).
#### Utilizzo della policy di rete dell'applicazione
`ApplicationNetworkPolicy`Combina le funzionalità delle politiche di rete Kubernetes standard con il filtraggio basato su DNS a livello di namespace utilizzando un'unica Custom Resource Definition (CRD). Pertanto, può essere utilizzato per: `ApplicationNetworkPolicy`
1. Definizione delle restrizioni ai livelli 3 e 4 dello stack di rete utilizzando blocchi IP e numeri di porta.
1. Definizione di regole che operano al livello 7 dello stack di rete e consentono di filtrare il traffico in base a. FQDNs
**Importante**
Le regole basate sul DNS definite utilizzando la `ApplicationNetworkPolicy` sono applicabili solo ai carichi di lavoro in esecuzione su istanze EC2 lanciate da EKS Auto Mode. `ApplicationNetworkPolicy`supporta tutti i campi dello standard Kubernetes, con un filtro FQDN aggiuntivo per le regole di `NetworkPolicy` uscita.
**avvertimento**
Non utilizzare lo stesso nome per un `ApplicationNetworkPolicy` e un all'interno dello stesso spazio dei nomi. `NetworkPolicy` Se i nomi entrano in conflitto, gli `PolicyEndpoints` oggetti risultanti potrebbero non riflettere correttamente nessuna delle due politiche. Entrambe le risorse vengono accettate senza errori, il che rende difficile la diagnosi di questo problema.
Per risolvere un conflitto di denominazione, rinomina i `ApplicationNetworkPolicy` o i in `NetworkPolicy` modo che siano univoci all'interno dello spazio dei nomi, quindi verifica che gli oggetti corrispondenti `PolicyEndpoints` siano aggiornati correttamente.
#### Esempio
Nel cluster EKS Auto Mode è presente un carico di lavoro che deve comunicare con un'applicazione locale basata su un sistema di bilanciamento del carico con un nome DNS. È possibile ottenere ciò utilizzando la seguente politica di rete:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
**A livello di rete Kubernetes, ciò consentirebbe l'uscita da qualsiasi pod nello spazio dei nomi «galaxy» etichettato con `role: backend` per connettersi al nome di dominio myapp.mydomain.com sulla porta TCP 8080.** Inoltre, è necessario configurare la connettività di rete per il traffico in uscita dal VPC al data center aziendale.
![\[Illustrazione del carico di lavoro in EKS Auto: comunicazione con le applicazioni in locale\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Politica di rete di amministrazione (o cluster)
![\[Illustrazione dell'ordine di valutazione delle politiche di rete in EKS\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/evaluation-order.png)
#### Utilizzo della politica di rete del cluster
Quando si utilizza a`ClusterNetworkPolicy`, le politiche del livello di amministrazione vengono valutate per prime e non possono essere sostituite. Una volta valutate le politiche di livello amministratore, le politiche standard con ambito dei namespace vengono utilizzate per eseguire le regole di segmentazione della rete applicate. Questa operazione può essere eseguita utilizzando uno dei due o. `ApplicationNetworkPolicy` `NetworkPolicy` Infine, verranno applicate le regole del livello di base che definiscono le restrizioni di rete predefinite per i carichi di lavoro dei cluster. Queste regole del livello di base **possono** essere sostituite dalle policy con ambito dei namespace, se necessario.
#### Esempio
Nel cluster è presente un'applicazione che si desidera isolare dagli altri carichi di lavoro dei tenant. È possibile bloccare in modo esplicito il traffico del cluster proveniente da altri namespace per impedire l'accesso di rete allo spazio dei nomi riservato del carico di lavoro.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Considerazioni
### Comprendi l'ordine di valutazione delle politiche
Le funzionalità relative alle politiche di rete supportate in EKS vengono valutate in un ordine specifico per garantire una gestione del traffico prevedibile e sicura. Pertanto, è importante comprendere il flusso di valutazione per progettare una posizione di sicurezza di rete efficace per il proprio ambiente.
1. **Politiche del livello di amministrazione (valutate per prime)**: tutte le politiche di livello amministratore ClusterNetworkPolicies vengono valutate prima di qualsiasi altra politica. All'interno del livello di amministrazione, le politiche vengono elaborate in ordine di priorità (prima il numero di priorità più basso). Il tipo di azione determina cosa succede dopo.
+ **Nega azione (priorità massima)**: quando una politica di amministrazione con un'azione Rifiuta corrisponde al traffico, tale traffico viene immediatamente bloccato indipendentemente da qualsiasi altra politica. Non vengono elaborate ClusterNetworkPolicy ulteriori NetworkPolicy regole. Ciò garantisce che i controlli di sicurezza a livello di organizzazione non possano essere sostituiti da politiche a livello di namespace.
+ **Consenti azioni**: dopo la valutazione delle regole Deny, le politiche di amministrazione con le azioni Consenti vengono elaborate in ordine di priorità (inizia con il numero di priorità più basso). Quando un'azione Consenti corrisponde, il traffico viene accettato e non viene effettuata alcuna ulteriore valutazione delle politiche. Queste politiche possono concedere l'accesso su più namespace in base a selettori di etichette, fornendo un controllo centralizzato su quali carichi di lavoro possono accedere a risorse specifiche.
+ **Pass action**: le azioni Pass Action nelle policy del livello di amministrazione delegano il processo decisionale ai livelli inferiori. Quando il traffico corrisponde a una regola Pass, la valutazione salta tutte le regole rimanenti del livello di amministratore per quel traffico e passa direttamente al livello. NetworkPolicy Ciò consente agli amministratori di delegare in modo esplicito il controllo di determinati modelli di traffico ai team applicativi. Ad esempio, è possibile utilizzare le regole Pass per delegare la gestione del traffico all'interno del namespace agli amministratori del namespace, mantenendo al contempo controlli rigorosi sull'accesso esterno.
1. **Livello di policy di rete**: se nessuna politica del livello di amministratore corrisponde a Deny o Allow, o se è stata soddisfatta un'azione Pass, vengono successivamente valutate le risorse tradizionali e con ambito namespace. ApplicationNetworkPolicy NetworkPolicy Queste policy forniscono un controllo granulare all'interno dei singoli namespace e sono gestite dai team applicativi. Le politiche con ambito namespace possono essere solo più restrittive delle politiche di amministrazione. Non possono ignorare la decisione di rifiuto di una politica di amministrazione, ma possono limitare ulteriormente il traffico consentito o approvato dalle politiche di amministrazione.
1. **Politiche di amministrazione di livello base**: se nessuna politica di amministrazione o con ambito del namespace corrisponde al traffico, viene valutato il livello di base. ClusterNetworkPolicies Queste forniscono posizioni di sicurezza predefinite che possono essere sostituite da policy con ambito namespace, consentendo agli amministratori di impostare impostazioni predefinite a livello di organizzazione e offrendo al contempo ai team la flessibilità necessaria per personalizzarle in base alle esigenze. Le politiche di base vengono valutate in ordine di priorità (per primo il numero di priorità più basso).
1. **Negazione predefinita (se nessuna policy corrisponde)**: questo deny-by-default comportamento garantisce che siano consentite solo le connessioni esplicitamente consentite, mantenendo un solido livello di sicurezza.
### Applicazione del principio del privilegio minimo
+ **Inizia con politiche restrittive e aggiungi gradualmente le autorizzazioni secondo necessità**. Inizia implementando le deny-by-default politiche a livello di cluster, quindi aggiungi in modo incrementale le regole di autorizzazione man mano che convalidi i requisiti di connettività legittimi. Questo approccio obbliga i team a giustificare esplicitamente ogni connessione esterna, creando un ambiente più sicuro e verificabile.
+ **Verifica e rimuovi regolarmente le regole di policy non utilizzate: le policy** di rete possono accumularsi nel tempo man mano che le applicazioni si evolvono, lasciando dietro di sé regole obsolete che ampliano inutilmente la superficie di attacco. Implementate un processo di revisione regolare per identificare e rimuovere le regole di policy che non sono più necessarie, assicurando che il vostro livello di sicurezza rimanga rigoroso e gestibile.
+ **Se possibile, utilizza nomi di dominio specifici anziché schemi generici. Se** da un lato i modelli wildcard `*.amazonaws.com` offrono maggiore praticità, dall'altro garantiscono l'accesso a un'ampia gamma di servizi. Ove possibile, specifica nomi di dominio esatti, `s3.us-west-2.amazonaws.com` ad esempio per limitare l'accesso solo ai servizi specifici richiesti dalle applicazioni, riducendo il rischio di spostamenti laterali se un carico di lavoro è compromesso.
### Utilizzo di policy basate su DNS in EKS
+ Le regole basate su DNS definite utilizzando `ApplicationNetworkPolicy` sono applicabili solo ai carichi di lavoro in esecuzione su istanze EC2 lanciate in modalità EKS Auto. Se utilizzi un cluster in modalità mista (composto da nodi di lavoro EKS Auto e non EKS Auto), le regole basate sul DNS sono efficaci solo nei nodi di lavoro in modalità EKS Auto (istanze gestite EC2).
### Convalida delle politiche DNS
+ **Utilizzate cluster di staging che rispecchiano la topologia della rete di produzione per i test**: l'ambiente di staging deve replicare l'architettura di rete, le dipendenze esterne e i modelli di connettività di produzione per garantire un test accurato delle politiche. Ciò include configurazioni VPC corrispondenti, comportamento di risoluzione DNS e accesso agli stessi servizi esterni richiesti dai carichi di lavoro di produzione.
+ **Implementa test automatizzati per percorsi di rete critici**: crea test automatizzati che convalidano la connettività ai servizi esterni essenziali come parte della tua pipeline. CI/CD Questi test devono verificare che i flussi di traffico legittimi siano consentiti mentre le connessioni non autorizzate vengono bloccate, in modo da confermare continuamente che le politiche di rete mantengano il corretto livello di sicurezza man mano che l'infrastruttura si evolve.
+ **Monitora il comportamento delle applicazioni dopo le modifiche alle policy**: dopo aver implementato policy di rete nuove o modificate nella produzione, monitorate attentamente i log delle applicazioni, i tassi di errore e le metriche prestazionali per identificare rapidamente eventuali problemi di connettività. Stabilisci procedure di rollback chiare in modo da poter ripristinare rapidamente le modifiche alle policy se causano comportamenti imprevisti delle applicazioni o interruzioni del servizio.
### Interazione con il firewall DNS di Amazon Route 53
Le politiche di amministrazione e di rete di EKS vengono valutate prima a livello di pod quando viene avviato il traffico. Se una policy di rete EKS consente l'uscita verso un dominio specifico, il pod esegue quindi una query DNS che raggiunge il Route 53 Resolver. A questo punto, vengono valutate le regole del firewall DNS Route 53. Se DNS Firewall blocca la query del dominio, la risoluzione DNS fallisce e la connessione non può essere stabilita, anche se la politica di rete EKS lo ha consentito. Ciò crea livelli di sicurezza complementari: le policy di rete basate su EKS DNS forniscono il controllo dell'uscita a livello di pod per i requisiti di accesso specifici delle applicazioni e i limiti di sicurezza multi-tenant, mentre DNS Firewall offre una protezione a livello di VPC contro domini dannosi noti e applica le blocklist a livello di organizzazione.
# Assegnazione di tag alle sottoreti per la modalità automatica EKS
Se utilizzi la funzionalità di bilanciamento del carico di EKS Auto Mode, devi aggiungere AWS tag alle sottoreti VPC.
## Contesto
Questi tag identificano le sottoreti associate al cluster e, soprattutto, se la sottorete è pubblica o privata.
Le sottoreti pubbliche dispongono di un accesso diretto a Internet tramite un gateway Internet. Sono utilizzate per risorse che devono essere accessibili al pubblico, come i bilanciatori del carico.
Le sottoreti private non dispongono di un accesso diretto a Internet e utilizzano gateway NAT per il traffico in uscita. Vengono utilizzati per risorse interne come i nodi EKS che non necessitano di risorse pubbliche. IPs
Per ulteriori informazioni sui gateway NAT e sui gateway Internet, consulta [Connetti il tuo VPC ad altre reti](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) nella Guida per l’utente del cloud privato virtuale (VPC) di Amazon.
## Requisito
Al momento, le sottoreti utilizzate per il bilanciamento del carico tramite la modalità automatica EKS devono avere uno dei seguenti tag.
### Sottoreti pubbliche
Le sottoreti pubbliche sono utilizzate per i bilanciatori del carico connesso a Internet. Queste sottoreti devono avere i tag seguenti:
| Chiave | Valore |
| --- | --- |
| `kubernetes.io/role/elb` | `1` o `` |
### Sottoreti private
Le sottoreti private sono utilizzate per i bilanciatori del carico interni. Queste sottoreti devono avere i tag seguenti:
| Chiave | Valore |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` o `` |
## Procedura
Prima di iniziare, identifica quali sottoreti sono pubbliche (con accesso a gateway Internet) e quali sono private (tramite gateway NAT). Avrai bisogno delle autorizzazioni per modificare le risorse VPC.
### Console di gestione AWS
1. **Apri la console Amazon VPC e accedi alle sottoreti.**
1. Seleziona la sottorete da etichettare.
1. Scegli la scheda **Tag** e seleziona **Aggiungi tag**.
1. Aggiungi il tag appropriato:
+ Per le sottoreti pubbliche: Chiave=`kubernetes.io/role/elb`
+ Per sottoreti private: Chiave=`kubernetes.io/role/internal-elb`
1. Imposta **Valore** su `1` o lascia vuoto.
1. Salva e ripeti per le sottoreti rimanenti.
### AWS CLI
Per le sottoreti pubbliche:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Per le sottoreti private:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Sostituisci `subnet-ID` con l’ID della sottorete corrente.
# Generare report di conformità CIS dai nodi Kubernetes utilizzando kubectl debug
Questo argomento descrive come generare report di conformità CIS (Center for Internet Security) per i nodi Amazon EKS utilizzando il comando `kubectl debug`. Il comando ti consente di creare temporaneamente un container di debug su un nodo di Kubernetes ed eseguire controlli di conformità CIS utilizzando lo strumento `apiclient`. Lo strumento `apiclient` fa parte di Bottlerocket OS, il sistema operativo utilizzato dai nodi della modalità automatica di EKS.
## Prerequisiti
Prima di iniziare, assicurati di disporre di:
+ Accesso a un cluster Amazon EKS con `kubectl` configurato (la versione deve essere almeno v1.32.0; digitare `kubectl version` per verificare).
+ Le autorizzazioni IAM appropriate per il debug dei nodi.
+ Un profilo valido che consente operazioni di debug (ad esempio, `sysadmin`).
Per ulteriori informazioni sull’utilizzo dei profili di debug con `kubectl`, consultare [Debugging a Pod or Node while applying a profile](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) nella documentazione di Kubernetes.
## Procedura
1. Determina l'ID AWS istanza del nodo su cui vuoi eseguire il rapporto. Utilizzare il seguente comando per elencare tutti i nodi nel cluster. L’ID dell’istanza si trova nella colonna del nome e inizia con `i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Esegui il comando seguente, sostituendo `` con l’ID di istanza del nodo su cui si desidera eseguire la query:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
I componenti di questo comando includono:
+ `kubectl debug node/`: crea una sessione di debug sull’ID di istanza EC2 specificato.
+ `-it`: assegna un TTY (shell a riga di comando) e mantiene aperto stdin per un utilizzo interattivo.
+ `--profile=sysadmin`: utilizza il profilo `kubectl` specificato con le autorizzazioni appropriate.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`: utilizza `amazonlinux:2023` come immagine del container per il debug.
+ `bash -c "…"`: esegue i seguenti comandi in una shell bash:
+ `yum install -q -y util-linux-core`: installa in background il pacchetto di utilità richiesto.
+ `nsenter -t 1 -m`: esegue `nsenter` per inserire il namespace del processo host (PID 1).
+ `apiclient report cis --level 1 --format text`: esegue il report di conformità CIS a livello 1 con output di testo.
1. Esaminare l’output del testo del report.
## Interpretazione dell’output
Il comando genera un report basato su testo che mostra lo stato di conformità di vari controlli CIS. L’output include:
+ Controllo CIS individuale IDs
+ Descrizione di ciascun controllo
+ Lo stato Pass, Fail o Skip per ogni controllo
+ Dettagli che spiegano eventuali problemi di conformità
Ecco un esempio di output del report eseguito su un’istanza Bottlerocket:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Per informazioni sul benchmark, consultare [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) dal Center for Internet Security (CIS).
## Risorse correlate
+ [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) nella documentazione del sistema operativo Bottlerocket.
+ [Debug Running Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) nella documentazione di Kubernetes.
+ [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) dal Center for Internet Security (CIS)
# Abilitare la crittografia dei volumi EBS con chiavi KMS gestite dal cliente per la modalità automatica di EKS
Puoi crittografare il volume root temporaneo per le istanze della modalità automatica di EKS con una chiave KMS gestita dal cliente.
La modalità automatica di Amazon EKS utilizza ruoli collegati ai servizi per delegare le autorizzazioni ad altri AWS servizi durante la gestione di volumi EBS crittografati per i cluster Kubernetes. In questo argomento viene descritto come impostare le policy della chiave necessarie quando si specifica una chiave gestita dal cliente per la crittografia Amazon EBS con la modalità automatica di EKS.
Considerazioni:
+ EKS Auto Mode non richiede un'autorizzazione aggiuntiva per utilizzare la chiave AWS gestita predefinita per proteggere i volumi crittografati nel tuo account.
+ Questo argomento tratta la crittografia dei volumi effimeri, i volumi root per le istanze. EC2 Per ulteriori informazioni sulla crittografia dei volumi di dati utilizzati per i carichi di lavoro, consulta [Crea una classe di archiviazione](create-storage-class.md).
## Panoramica di
Le seguenti chiavi AWS KMS possono essere utilizzate per la crittografia dei volumi root di Amazon EBS quando EKS Auto Mode avvia le istanze:
+ **Chiave gestita da AWS **: una chiave di crittografia nell’account che Amazon EBS crea, possiede e gestisce. Questa è la chiave di crittografia di default per un nuovo account.
+ **Chiave gestita dal cliente**: una chiave di crittografia personalizzata che l’utente crea, possiede e gestisce.
**Nota**
La chiave deve essere simmetrica. Amazon EBS non supporta le chiavi gestite dal cliente asimmetriche.
## Fase 1: Configurare la policy della chiave
Le chiavi KMS devono avere una policy della chiave che permetta alla modalità automatica di EKS di avviare istanze con volumi Amazon EBS crittografati con una chiave gestita dal cliente.
Configura la policy della chiave con la seguente struttura:
**Nota**
Questa policy include solo le autorizzazioni per la modalità automatica di EKS. La policy della chiave potrebbe richiedere autorizzazioni aggiuntive se altre identità devono utilizzare la chiave o gestire le concessioni.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Assicurati di sostituirlo `` con l'ID dell'account effettivo. AWS
Durante la configurazione della policy della chiave:
+ Per eseguire le operazioni di crittografia, il `ClusterServiceRole` deve disporre delle autorizzazioni IAM necessarie per usare la chiave KMS.
+ La `kms:GrantIsForAWSResource` condizione garantisce che le sovvenzioni possano essere create solo per i servizi AWS
## Fase 2: Configura NodeClass con la chiave gestita dal cliente
Dopo aver configurato la politica chiave, fai riferimento alla chiave KMS nella configurazione della modalità NodeClass automatica EKS:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Sostituisci i valori di segnaposto con i valori effettivi:
+ ``con la tua regione AWS
+ ``con l'ID AWS del tuo account
+ `` con ID della chiave KMS
Puoi specificare la chiave KMS utilizzando uno dei seguenti formati:
+ ID della chiave KMS: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN della chiave KMS: ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nome alias della chiave: `alias/eks-auto-mode-key`
+ ARN alias della chiave: ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Applica la NodeClass configurazione usando kubectl:
```
kubectl apply -f nodeclass.yaml
```
## Risorse correlate
+ [Creazione di una classe di nodi per Amazon EKS](create-node-class.md)
+ Visualizza ulteriori informazioni nella AWS Key Management Service Developer Guide
+ [Autorizzazioni per AWS i servizi nelle politiche chiave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Modificare una policy della chiave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Sovvenzioni in KMS AWS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Aggiorna i controlli organizzativi per la modalità automatica di EKS
Alcuni controlli organizzativi possono impedire il corretto funzionamento della modalità automatica di EKS. In tal caso, devi aggiornare questi controlli per consentire alla modalità automatica di EKS di disporre delle autorizzazioni necessarie per gestire le istanze EC2 per conto dell’utente.
modalità automatica di EKS utilizza un ruolo di servizio per l’avvio delle istanze EC2 che supportano i nodi della modalità automatica di EKS. Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) creato nell’account che un servizio assume per eseguire operazioni nell’account. [Le policy di controllo del servizio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) si applicano sempre alle azioni eseguite con i ruoli di servizio. Ciò consente a una SCP di inibire le operazioni di Auto Mode. L'evento più comune si verifica quando viene utilizzato un SCP per limitare le Amazon Machine Images (AMIs) che possono essere lanciate. Per consentire il funzionamento di EKS Auto Mode, modifica l'SCP per consentire l'avvio AMIs dagli account EKS Auto Mode.
Puoi anche utilizzare la AMIs funzione [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) per limitare la visibilità di altri account AMIs . Se utilizzi questa funzionalità, devi espandere i criteri dell’immagine per includere anche gli account AMI della modalità automatica di EKS nelle regioni di interesse.
## Esempio: SCP per bloccare tutti AMIs tranne EKS Auto Mode AMIs
La SCP riportata di seguito impedisce di chiamare `ec2:RunInstances` a meno che l’AMI non appartenga all’account AMI della modalità automatica di EKS per us-west-2 o us-east-1.
**Nota**
È importante **non** usare la chiave di contesto `ec2:Owner`. Amazon possiede gli account AMI della modalità automatica di EKS e il valore di questa chiave sarà sempre `amazon`. La creazione di un SCP che consenta l'avvio AMIs se `ec2:Owner` è `amazon` consentirà il lancio di qualsiasi AMI di proprietà di Amazon, non solo quelle per EKS Auto Mode. \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Account AMI della modalità automatica di EKS
AWS gli account che variano in base alla regione ospitano EKS Auto Mode public AMIs.
| | |
| --- |--- |
| AWS Regione | Account |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Associare un indirizzo IP pubblico
Quando viene chiamato `ec2:RunInstances`, il campo `AssociatePublicIpAddress` per l’avvio di un’istanza viene determinato automaticamente dal tipo di sottorete in cui viene avviata l’istanza. È possibile utilizzare un SCP per far sì che questo valore sia impostato esplicitamente su false, indipendentemente dal tipo di sottorete in cui viene avviato. In questo caso il NodeClass campo `spec.advancedNetworking.associatePublicIPAddress` può anche essere impostato su false per soddisfare i requisiti dell'SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS
Puoi controllare l’implementazione dei carichi di lavoro su [Prenotazioni della capacità](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). La modalità automatica di EKS supporta le prenotazioni della capacità on demand EC2 (ODCR) e i blocchi di capacità EC2 per il machine learning.
**Suggerimento**
Per impostazione predefinita, EKS Auto Mode può essere avviato in open ODCRs tramite open-matching, ma non dà loro la priorità. Le istanze avviate tramite open-matching sono etichettate, non. `karpenter.sh/capacity-type: on-demand` `reserved` Per dare priorità all'utilizzo dell'ODCR e etichettare le istanze, configura nella definizione. `karpenter.sh/capacity-type: reserved` `capacityReservationSelectorTerms` NodeClass I Capacity Blocks for ML richiedono sempre `capacityReservationSelectorTerms` e non vengono utilizzati automaticamente.
## Prenotazioni di capacità su richiesta EC2 () ODCRs
Le prenotazioni della capacità on demand di EC2 (ODCR) permettono di prenotare la capacità di elaborazione per le istanze Amazon EC2 in una zona di disponibilità specifica per qualsiasi durata. Quando si utilizza modalità automatica di EKS, potresti voler controllare se i carichi di lavoro di Kubernetes vengono implementati su queste istanze riservate per massimizzare l’utilizzo della capacità pre-acquistata o per garantire che i carichi di lavoro critici abbiano accesso a risorse garantite.
Per impostazione predefinita, EKS Auto Mode si apre automaticamente. ODCRs Tuttavia, configurando `capacityReservationSelectorTerms` su a NodeClass, puoi controllare in modo esplicito l'utilizzo dei ODCRs tuoi carichi di lavoro. I nodi forniti utilizzando configure ODCRs avranno e avranno priorità rispetto a on-demand `karpenter.sh/capacity-type: reserved` e spot. Una volta abilitata questa funzionalità, EKS Auto Mode non utilizzerà più automaticamente open ODCRs: devono essere selezionati esplicitamente da un NodeClass, in modo da consentire un controllo preciso sull'utilizzo della prenotazione della capacità in tutto il cluster.
**avvertimento**
Se si esegue la configurazione `capacityReservationSelectorTerms` all' NodeClass interno di un cluster, EKS Auto Mode non utilizzerà più automaticamente open ODCRs per *nessuno* NodeClass dei componenti del cluster.
### Esempio NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Questo esempio NodeClass illustra due approcci per la selezione ODCRs. Il primo metodo fa riferimento direttamente a una ODCR specifica tramite il relativo ID (`cr-56fac701cc1951b03`). Il secondo metodo utilizza la selezione basata su tag, mirando ODCRs con il tag. `Name: "targeted-odcr"` Facoltativamente, puoi anche filtrare in base all' AWS account proprietario della prenotazione, il che è particolarmente utile negli scenari tra più account o quando lavori con prenotazioni di capacità condivise.
## Blocchi di capacità EC2 per ML
I blocchi di capacità per ML prenotano istanze a calcolo accelerato basate su GPU in una data futura per supportare carichi di lavoro di machine learning (ML) di breve durata. Le istanze eseguite all'interno di un Capacity Block vengono automaticamente posizionate vicine tra loro all'interno di Amazon UltraClusters EC2, per reti a bassa latenza, su scala petabit e non bloccanti.
Per ulteriori informazioni sulle piattaforme e sui tipi di istanze supportati, consulta [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella Guida per l’utente di EC2.
Puoi creare una modalità automatica EKS NodeClass che utilizza un Capacity Block per ML, simile a un ODCR (descritto in precedenza).
Le seguenti definizioni di esempio creano tre risorse:
1. A NodeClass che fa riferimento alla tua prenotazione Capacity Block
1. A NodePool che utilizza NodeClass e applica una macchia
1. Una specifica per Pod che tollera il taint e richiede risorse GPU
### Esempio NodeClass
Questo NodeClass fa riferimento a uno specifico Capacity Block for ML tramite il relativo ID di prenotazione. Puoi ottenere questo ID dalla console EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
### Esempio NodePool
Questo NodePool fa riferimento `gpu` NodeClass e specifica una configurazione importante:
+ Utilizza **solo** la capacità riservata impostando `karpenter.sh/capacity-type: reserved`
+ Richiede famiglie di istanze GPU specifiche adatte ai carichi di lavoro ML
+ Applica un taint `nvidia.com/gpu` per garantire che solo i carichi di lavoro GPU siano pianificati su questi nodi
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
### Pod di esempio
Questo pod di esempio dimostra come configurare un carico di lavoro da eseguire sui nodi del blocco di capacità:
+ Utilizza un **NodeSelector** per indirizzare tipi di GPU specifici (in questo caso, H200) GPUs
+ Include una **tolleranza** per la macchia applicata dal `nvidia.com/gpu` NodePool
+ **Richiede esplicitamente le risorse GPU** che utilizzano il tipo di risorsa `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Per ulteriori informazioni, consulta [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) nella documentazione Kubernetes.
### Risorse correlate
+ [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella Guida per l’utente di Amazon EC2
+ [Find and purchase Capacity Blocks](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) nella Guida per l’utente di Amazon EC2
+ [Gestisci le risorse di calcolo per i AI/ML carichi di lavoro su Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [GPU Resource Optimization and Cost Management](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) nella Guida alle best practice di EKS
# Implementazione dei nodi EKS Auto Mode su Local Zones
EKS Auto Mode offre una gestione semplificata dei cluster con il provisioning automatico dei nodi. AWS Local Zones estendono l' AWS infrastruttura alle aree geografiche più vicine agli utenti finali, riducendo la latenza per le applicazioni sensibili alla latenza. Questa guida illustra il processo di implementazione dei nodi EKS Auto Mode su AWS Local Zones, consentendoti di eseguire applicazioni containerizzate con latenza inferiore per gli utenti in aree geografiche specifiche.
Questa guida dimostra anche come utilizzare i limiti e le tolleranze di Kubernetes per garantire che sui nodi della zona locale vengano eseguiti solo carichi di lavoro specifici, aiutandoti a controllare i costi e ottimizzare l'utilizzo delle risorse.
## Prerequisiti
Prima di iniziare a distribuire i nodi EKS Auto Mode su Local Zones, assicurati di avere i seguenti prerequisiti:
+ [Un cluster EKS Auto Mode esistente](create-auto.md)
+ [Hai effettuato l'accesso alla zona locale del tuo account AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Fase 1: Creare una sottorete di zona locale
Il primo passo per implementare i nodi EKS Auto Mode in una zona locale consiste nella creazione di una sottorete in quella zona locale. Questa sottorete fornisce l'infrastruttura di rete per i nodi e consente loro di comunicare con il resto del VPC. Segui le istruzioni [Create a Local Zone subnet](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (nella AWS Local Zones User Guide) per creare una sottorete nella Local Zone prescelta.
**Suggerimento**
Prendi nota del nome della sottorete della zona locale.
## Fase 2: Creazione NodeClass per la sottorete della zona locale
Dopo aver creato la sottorete Local Zone, è necessario definire una sottorete NodeClass che faccia riferimento a questa sottorete. NodeClass Si tratta di una risorsa personalizzata Kubernetes che specifica gli attributi di infrastruttura per i nodi, incluse le sottoreti, i gruppi di sicurezza e le configurazioni di archiviazione da utilizzare. Nell'esempio seguente, creiamo una NodeClass chiamata «zona locale» che ha come target una sottorete di zona locale in base al suo nome. È inoltre possibile utilizzare l'ID della sottorete. Dovrai adattare questa configurazione per indirizzare la tua sottorete Local Zone.
Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Fase 3: Crea NodePool con NodeClass e Taint
Una volta NodeClass configurato, ora devi crearne uno NodePool che lo NodeClass utilizzi. A NodePool definisce le caratteristiche di calcolo dei nodi, inclusi i tipi di istanza. NodePool utilizza il NodeClass come riferimento per determinare dove avviare le istanze.
Nell'esempio seguente, creiamo un NodePool riferimento alla nostra «zona locale». NodeClass Aggiungiamo anche una macchia ai nodi per garantire che solo i pod con una tolleranza corrispondente possano essere programmati su questi nodi della Zona Locale. Ciò è particolarmente importante per i nodi della zona locale, che in genere hanno costi più elevati e devono essere utilizzati solo da carichi di lavoro che beneficiano specificamente della latenza ridotta.
Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
La contaminazione tra key `aws.amazon.com/local-zone` ed effect `NoSchedule` assicura che i pod senza una tolleranza corrispondente non vengano programmati su questi nodi. Ciò impedisce l'esecuzione accidentale di carichi di lavoro regolari nella zona locale, il che potrebbe comportare costi imprevisti.
## Fase 4: Implementazione dei carichi di lavoro con tolleranza e affinità tra nodi
Per un controllo ottimale sul posizionamento dei carichi di lavoro sui nodi della zona locale, utilizzate entrambi taints/tolerations e l'affinità dei nodi insieme. Questo approccio combinato offre i seguenti vantaggi:
1. **Controllo dei costi**: The taint garantisce che solo i pod con tolleranze esplicite possano utilizzare risorse potenzialmente costose della Zona Locale.
1. **Posizionamento garantito**: l'affinità dei nodi garantisce che le applicazioni sensibili alla latenza vengano eseguite esclusivamente nella zona locale, non sui normali nodi del cluster.
Ecco un esempio di distribuzione configurata per l'esecuzione specifica sui nodi della zona locale:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Questa distribuzione ha due configurazioni di pianificazione chiave:
1. La **tolleranza** consente di programmare i pod sui nodi con la contaminazione. `aws.amazon.com/local-zone`
1. Il requisito di **affinità dei nodi** garantisce che questi pod funzionino solo sui nodi con l'etichetta. `node-type: local-zone`
Insieme, garantiscono che l'applicazione sensibile alla latenza venga eseguita solo sui nodi della zona locale e che le applicazioni normali non consumino le risorse della zona locale a meno che non siano configurate esplicitamente per farlo.
## Passaggio 5: verifica con la console AWS
Dopo aver configurato le NodeClass distribuzioni e le distribuzioni, è necessario verificare che i nodi vengano forniti nella zona locale come previsto e che i carichi di lavoro vengano eseguiti su di essi. NodePool È possibile utilizzare la console di AWS gestione per verificare che le EC2 istanze vengano avviate nella sottorete della zona locale corretta.
Inoltre, puoi controllare l'elenco dei nodi Kubernetes utilizzando `kubectl get nodes -o wide` per confermare che i nodi si uniscano al cluster con le etichette e le sfumature corrette:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Puoi anche verificare che i pod del carico di lavoro siano pianificati sui nodi della zona locale:
```
kubectl get pods -o wide
```
Questo approccio garantisce che su questi nodi vengano pianificati solo i carichi di lavoro che tollerano specificamente la contaminazione della zona locale, aiutandoti a controllare i costi e a utilizzare nel modo più efficiente le risorse della zona locale.
# Configurare le impostazioni di sicurezza avanzate per i nodi
Questo argomento descrive come configurare le impostazioni di sicurezza avanzate per i nodi Amazon EKS Auto Mode utilizzando le `advancedSecurity` specifiche nella tua classe di nodi.
## Prerequisiti
Prima di iniziare, assicurati di disporre dei seguenti elementi:
+ Un cluster della modalità automatica di Amazon EKS. Per ulteriori informazioni, consulta [Creare un cluster con la modalità automatica Amazon EKS](create-auto.md).
+ `kubectl` installato e configurato. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
+ Comprensione della configurazione della classe di nodi. Per ulteriori informazioni, consulta [Creazione di una classe di nodi per Amazon EKS](create-node-class.md).
## Configura le impostazioni di sicurezza avanzate
Per configurare le impostazioni di sicurezza avanzate per i tuoi nodi, imposta i `advancedSecurity` campi nella specifica della tua classe di nodi:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Applica questa configurazione:
```
kubectl apply -f nodeclass.yaml
```
Fai riferimento a questa classe di nodi nella configurazione del tuo pool di nodi. Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
## Descrizioni dei campi
+ `fips`(booleano, opzionale): se impostato su`true`, effettua il provisioning dei nodi utilizzando moduli crittografici AMIs convalidati FIPS 140-2. Questa impostazione seleziona la conformità a FIPS; i clienti sono responsabili della gestione dei propri requisiti di conformità AMIs. [Per ulteriori informazioni, consulta Conformità FIPS.AWS](https://aws.amazon.com/compliance/fips/) Default: `false`.
+ `kernelLockdown`(stringa, opzionale): Controlla la modalità del modulo di sicurezza Kernel Lockdown. Valori accettati:
+ `integrity`: blocca i metodi per sovrascrivere la memoria del kernel o modificare il codice del kernel. Impedisce il caricamento dei moduli del kernel non firmati.
+ `none`: disattiva la protezione dal blocco del kernel.
Per ulteriori informazioni, consultate la documentazione relativa al blocco del [kernel Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Considerazioni
+ Gli standard FIPS AMIs sono disponibili nelle regioni Stati Uniti orientali/occidentali, ( AWS Stati Uniti) e Canada ( AWS GovCloud Centro/Ovest). AWS Per ulteriori informazioni[,AWS consulta](https://aws.amazon.com/compliance/fips/) Conformità FIPS.
+ Durante l'utilizzo`kernelLockdown: "integrity"`, assicurati che i tuoi carichi di lavoro non richiedano il caricamento di moduli del kernel non firmati o la modifica della memoria del kernel.
## Risorse correlate
+ [Creazione di una classe di nodi per Amazon EKS](create-node-class.md)- Guida completa alla configurazione della classe di nodi
+ [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md)- Configurazione del pool di nodi
# 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.
# Osservabilità per la modalità automatica EKS
Usa questo capitolo per conoscere le opzioni di osservabilità per i cluster Amazon EKS Auto Mode.
**Topics**
+ [
# Accedi ai registri dei componenti AWS gestiti per EKS Auto
](auto-managed-component-logs.md)
# Accedi ai registri dei componenti AWS gestiti per EKS Auto
È possibile accedere ai registri dei componenti AWS gestiti da EKS Auto Mode per ottenere una maggiore osservabilità delle operazioni del cluster. EKS Auto Mode supporta i log per le seguenti fonti:
+ Scalabilità automatica del calcolo - Karpenter
+ Archiviazione a blocchi - EBS CSI
+ Bilanciamento del carico - AWS Load Balancer Controller
+ Pod networking - Gestione degli indirizzi IP CNI VPC
I registri possono essere consegnati a una [destinazione di consegna di tua scelta](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Quando create un cluster EKS Auto, avete la possibilità di abilitare la registrazione del piano di controllo (server API, Audit, Authenticator, Controller manager, Scheduler). I registri dei componenti gestiti automaticamente da EKS (come Compute, Block storage, Load balancing e IPAM) richiedono una configurazione separata tramite la consegna dei log.
## Impostazione della consegna dei log
Per configurare la consegna dei log dei componenti AWS gestiti per il tuo cluster EKS Auto Mode, utilizza l'API Amazon CloudWatch Logs. Per istruzioni dettagliate sulla configurazione, consulta [Enabling logging from AWS services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) nella Amazon CloudWatch Logs User Guide. Ogni funzionalità della modalità automatica può essere configurata come fonte di distribuzione individuale di CloudWatch Vend Logs, che consente di selezionare i log a cui si desidera avere accesso.
EKS Auto Mode supporta i seguenti tipi di log:
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### Usare Amazon CloudWatch APIs
La configurazione della registrazione richiede tre passaggi:
1. Crea una fonte di distribuzione per la funzionalità utilizzando l'API CloudWatch PutDeliverySource
1. Crea una destinazione di consegna utilizzando PutDeliveryDestination
1. Crea una consegna per connettere l'origine e la destinazione utilizzando CreateDelivery
È possibile configurare i dettagli della destinazione per i log di Auto Mode utilizzando l' deliveryDestinationConfiguration oggetto nell' CloudWatch PutDeliveryDestination API. Richiede l'ARN di un gruppo di CloudWatch log, di un bucket S3 o del flusso di distribuzione di Kinesis Data Firehose.
È possibile configurare una singola funzionalità di modalità automatica (origine di consegna) per inviare i log a più destinazioni creando più consegne. Puoi anche creare più consegne per configurare più fonti di consegna per inviare i registri alla stessa destinazione di consegna.
### autorizzazioni IAM
A seconda della destinazione selezionata, potrebbe essere necessario configurare le policy o i ruoli IAM per il gruppo di CloudWatch log, il bucket S3 e Kinesis Data Firehose per garantire una corretta consegna dei log. Inoltre, se stai inviando log tra AWS account, dovrai utilizzare l' PutDeliveryDestinationPolicy API per configurare una policy IAM che consenta la consegna alla destinazione. Per ulteriori informazioni, consulta la [documentazione sulle autorizzazioni di CloudWatch Vend Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs).
## Visualizzazione dei registri
Una volta configurata la consegna dei log, i log verranno consegnati alla destinazione specificata. Il metodo di accesso ai log dipende dal tipo di destinazione scelto:
+ **CloudWatch Registri: visualizza i** log nella console Logs, usa CloudWatch i comandi CLI o esegui una AWS query con Logs Insights CloudWatch
+ **Amazon S3**: accedi ai log come oggetti nel tuo bucket S3 tramite la console S3, l'interfaccia a riga di comando o strumenti di analisi come Amazon AWS Athena
+ **Amazon Data Firehose**: i log vengono trasmessi in streaming al target Firehose configurato (ad esempio S3, Service, Redshift, ecc.) OpenSearch
## Prezzi
CloudWatch Le tariffe di Vending Logs si applicano per la consegna e lo stoccaggio dei registri in base alla destinazione di consegna prescelta. CloudWatch Vending Logs consente una consegna affidabile e sicura dei log con AWS autenticazione e autorizzazione integrate a un prezzo ridotto rispetto ai registri standard. CloudWatch Per maggiori dettagli, consulta la [sezione Vending Logs della pagina dei CloudWatch prezzi](https://aws.amazon.com/cloudwatch/pricing/).
### Risorse correlate
+ [Registrazione del piano di controllo Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ [PutDeliverySource API nella guida](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) di riferimento all'API CloudWatch Logs
+ [PutDeliveryDestination API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) nel riferimento all'API CloudWatch Logs
+ [CreateDelivery API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) nel riferimento all'API CloudWatch Logs
# Risoluzione dei problemi della modalità automatica di EKS
Con EKS Auto Mode, AWS ti assumi maggiori responsabilità per le istanze EC2 presenti nel tuo account. AWS EKS si assume la responsabilità del runtime dei container sui nodi, del sistema operativo sui nodi e di determinati controller. Ciò include un controller per l’archiviazione a blocchi, uno per il bilanciamento del carico e uno di elaborazione.
È necessario utilizzare AWS e APIs Kubernetes per risolvere i problemi dei nodi. Puoi:
+ Utilizzare una risorsa `NodeDiagnostic` di Kubernetes per recuperare i log dei nodi utilizzando [Agente di monitoraggio del nodo](#auto-node-monitoring-agent). Per le altri fasi, consulta [Recuperare i log dei nodi per un nodo gestito usando kubectl e S3](auto-get-logs.md).
+ Usa il `get-console-output` comando CLI AWS EC2 per recuperare l'output della console dai nodi. Per le altri fasi, consulta [Ottieni l'output della console da un'istanza gestita da EC2 utilizzando la AWS CLI EC2](#auto-node-console).
+ Usa i *container di debug* di Kubernetes per recuperare i log dei nodi. Per le altri fasi, consulta [Ottieni i log dei nodi utilizzando i *container di debug* e `kubectl` CLI](#auto-node-debug-logs).
**Nota**
modalità automatica di EKS utilizza istanze gestite EC2. Non puoi accedere direttamente alle istanze gestite EC2, anche tramite SSH.
Potresti riscontrare i seguenti problemi che hanno soluzioni specifiche per i componenti della modalità automatica di EKS:
+ Pod bloccati nello stato `Pending`, che non vengono pianificati sui nodi Auto Mode. Per le soluzioni, consulta [Risolvere i problemi relativi alla mancata pianificazione dei Pod sul nodo Auto Mode](#auto-troubleshoot-schedule).
+ Istanze gestite da EC2 che non entrano a far parte del cluster come nodi di Kubernetes. Per le soluzioni, consulta [Risolvere i problemi del nodo che non si unisce al cluster](#auto-troubleshoot-join).
+ Errori e problemi con i `NodePools`, `PersistentVolumes` e `Services` che utilizzano i controller inclusi in modalità automatica di EKS. Per le soluzioni, consulta [Risolvere i problemi relativi ai controller inclusi in Auto Mode](#auto-troubleshoot-controllers).
+ La sicurezza avanzata dei Pod impedisce la condivisione di volumi tra Pod. Per le soluzioni, consulta [Condivisione di volumi tra pod](#auto-troubleshoot-share-pod-volumes).
Puoi utilizzare i seguenti metodi per risolvere i problemi relativi ai componenti della modalità automatica di EKS:
+ [Ottieni l'output della console da un'istanza gestita da EC2 utilizzando la AWS CLI EC2](#auto-node-console)
+ [Ottieni i log dei nodi utilizzando i *container di debug* e `kubectl` CLI](#auto-node-debug-logs)
+ [Visualizza le risorse associate alla modalità automatica EKS nella console AWS](#auto-node-ec2-web)
+ [Visualizza gli errori IAM nel tuo AWS account](#auto-node-iam)
+ [Rilevare i problemi di connettività dei nodi con il `VPC Reachability Analyzer`](#auto-node-reachability)
## Agente di monitoraggio del nodo
modalità automatica di EKS include l’agente di monitoraggio dei nodi di Amazon EKS. Puoi utilizzare questo agente per visualizzare le informazioni di risoluzione dei problemi e di debug relative ai nodi. L’agente di monitoraggio dei nodi pubblica gli `events` di Kubernetes e le `conditions` del nodo. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi](node-health.md).
## Ottieni l'output della console da un'istanza gestita da EC2 utilizzando la AWS CLI EC2
Questa procedura aiuta a risolvere problemi in fase di avvio o a livello di kernel.
Innanzitutto, devi determinare l’ID dell’istanza EC2 dell’istanza associata al carico di lavoro. In secondo luogo, utilizzate la AWS CLI per recuperare l'output della console.
1. Conferma di avere `kubectl` installato e connesso al cluster
1. (Facoltativo) Utilizza il nome di un’implementazione di Kubernetes per elencare i pod associati.
```
kubectl get pods -l app=
```
1. Utilizza il nome del pod di Kubernetes per determinare l’ID dell’istanza EC2 del nodo associato.
```
kubectl get pod -o wide
```
1. Utilizza l’ID dell’istanza EC2 per recuperare l’output della console.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## Ottieni i log dei nodi utilizzando i *container di debug* e `kubectl` CLI
Il modo consigliato per recuperare i log da un nodo della modalità automatica di EKS prevede l’utilizzo della risorsa `NodeDiagnostic`. Per la procedura, consulta [Recuperare i log dei nodi per un nodo gestito usando kubectl e S3](auto-get-logs.md).
Tuttavia, puoi eseguire lo streaming dei log in tempo reale da un’istanza utilizzando il comando `kubectl debug node`. Questo comando avvia un nuovo Pod sul nodo di cui desideri eseguire il debug, che puoi quindi utilizzare in modo interattivo.
1. Avvia un container di debug. Il comando seguente utilizza `i-01234567890123456` per l’ID di istanza del nodo, `-it` alloca a `tty` e allega `stdin` per l’utilizzo interattivo, e utilizza il profilo `sysadmin` del file kubeconfig.
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
Di seguito viene riportato un output di esempio.
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. Dalla shell, puoi ora installare `util-linux-core` che fornisce il comando `nsenter`. Utilizza `nsenter` per inserire il namespace di montaggio di PID 1 (`init`) sull’host ed eseguire il comando `journalctl` per eseguire lo streaming dei log da `kubelet`:
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
Per motivi di sicurezza, l’immagine del container di Amazon Linux non installa molti file binari per impostazione predefinita. Puoi utilizzare il comando `yum whatprovides` per identificare il pacchetto da installare al fine di fornire un determinato file binario.
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## Visualizza le risorse associate alla modalità automatica EKS nella console AWS
È possibile utilizzare la AWS console per visualizzare lo stato delle risorse associate al cluster EKS Auto Mode.
+ [Volumi EBS](https://console.aws.amazon.com/ec2/home#Volumes)
+ Visualizza i volumi della modalità automatica di EKS cercando la chiave del tag `eks:eks-cluster-name`
+ [Sistemi di bilanciamento del carico](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ Visualizza i bilanciatori del carico della modalità automatica di EKS cercando la chiave del tag `eks:eks-cluster-name`
+ [Istanze EC2](https://console.aws.amazon.com/ec2/home#Instances)
+ Visualizza le istanze della modalità automatica di EKS cercando la chiave del tag `eks:eks-cluster-name`
## Visualizza gli errori IAM nel tuo AWS account
1. Vai alla CloudTrail console
1. Seleziona “Cronologia degli eventi” dal riquadro di navigazione a sinistra
1. Applica i filtri dei codici di errore:
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
Cerca gli errori relativi al cluster EKS. Utilizza i messaggi di errore per aggiornare le voci di accesso EKS, il ruolo IAM del cluster o il ruolo IAM del nodo. Potresti dover allegare una nuova policy a questi ruoli con autorizzazioni per la modalità automatica di EKS.
## Risolvere i problemi relativi alla mancata pianificazione dei Pod sul nodo Auto Mode
Se i pod rimangono nello stato `Pending` e non vengono pianificati su un nodo Auto Mode, verifica se il pod o il manifesto di implementazione dispone di un `nodeSelector`. Se è presente un `nodeSelector`, assicurati che utilizzi `eks.amazonaws.com/compute-type: auto` per essere pianificato sui nodi creati dalla modalità automatica di EKS. Per ulteriori informazioni sulle etichette dei nodi utilizzate dalla modalità automatica di EKS, consulta [Controllare se un carico di lavoro viene implementato sui nodi di EKS Auto Mode](associate-workload.md).
## Risolvere i problemi del nodo che non si unisce al cluster
La modalità automatica di EKS configura automaticamente le nuove istanze EC2 con le informazioni corrette per unirsi al cluster, inclusi l’endpoint del cluster e l’autorità di certificazione (CA) del cluster. Tuttavia, queste istanze possono ancora non riuscire a unirsi al cluster EKS sotto forma di nodo. Esegui i seguenti comandi per identificare le istanze che non si sono unite al cluster:
1. Esegui `kubectl get nodeclaim` per verificare le `NodeClaims` che sono `Ready = False`.
```
kubectl get nodeclaim
```
1. Esegui `kubectl describe nodeclaim ` e cerca su **Stato** per trovare eventuali problemi che impediscono al nodo di unirsi al cluster.
```
kubectl describe nodeclaim
```
**Messaggi di errore comuni:**
`Error getting launch template configs`
Potresti ricevere questo errore se stai impostando tag personalizzati nella `NodeClass` con le autorizzazioni del ruolo IAM del cluster predefinite. Per informazioni, consulta [Informazioni su identità e accesso in modalità automatica di EKS](auto-learn-iam.md).
`Error creating fleet`
Potrebbe esserci qualche problema di autorizzazione con la chiamata `RunInstances` dall’API EC2. Verifica AWS CloudTrail la presenza di errori e verifica [Ruolo IAM del cluster della modalità automatica di Amazon EKS](auto-cluster-iam-role.md) le autorizzazioni IAM richieste.
### Rilevare i problemi di connettività dei nodi con il `VPC Reachability Analyzer`
**Nota**
Viene addebitato un costo per ogni analisi eseguita da VPC Reachability Analyzer. Per i dettagli sui prezzi, consulta [Prezzi di Amazon VPC](https://aws.amazon.com/vpc/pricing/).
Un motivo per cui un’istanza non si è unita al cluster è un problema di connettività di rete che impedisce di raggiungere il server API. Per diagnosticare questo problema, puoi utilizzare [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) per eseguire un’analisi della connettività tra un nodo che non riesce a unirsi al cluster e al server API. Avrai bisogno di due informazioni:
+ **ID di istanza** di un nodo che non è in grado di unirsi al cluster
+ Indirizzo IP dell’**endpoint del server dell’API Kubernetes**
Per ottenere l’**ID dell’istanza**, dovrai creare un carico di lavoro sul cluster per far sì che modalità automatica di EKS avvii un’istanza EC2. Questo crea anche un oggetto `NodeClaim` nel cluster che avrà l’ID dell’istanza. Esegui `kubectl get nodeclaim -o yaml` per stampare tutte le `NodeClaims` del cluster. Ciascuna `NodeClaim` contiene l’ID dell’istanza come campo e di nuovo nel providerID:
```
kubectl get nodeclaim -o yaml
```
Di seguito viene riportato un output di esempio.
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
Puoi determinare l’**endpoint del server dell’API Kubernetes** eseguendo `kubectl get endpoint kubernetes -o yaml`. Gli indirizzi si trovano nel campo degli indirizzi:
```
kubectl get endpoints kubernetes -o yaml
```
Di seguito viene riportato un output di esempio.
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
Con queste due informazioni, puoi eseguire l’analisi s. Per prima cosa, accedi a VPC Reachability Analyzer in Console di gestione AWS.
1. Fai clic su “Crea e analizza il percorso”
1. Fornisci un nome per l’analisi (ad esempio “Errore nell’unione del nodo”)
1. Per “Tipo di origine”, seleziona “Istanze”
1. Inserisci l’ID dell’istanza del nodo soggetto a errore come “Origine”
1. Per la “Destinazione del percorso”, seleziona “Indirizzo IP”
1. Inserisci uno degli indirizzi IP per il server API come “Indirizzo di destinazione”
1. Espandi la “Sezione di configurazione aggiuntiva dell’intestazione dei pacchetti”
1. Inserisci una “Porta di destinazione” di 443
1. Seleziona “Protocollo” come TCP se non è già selezionato
1. Fai clic su “Crea e analizza il percorso”
1. L’esecuzione dell’analisi potrebbe richiedere alcuni minuti. Se i risultati dell’analisi mostrano una mancata raggiungibilità, indicheranno dove si trovava l’errore nel percorso di rete in modo da poter risolvere il problema.
## Condivisione di volumi tra pod
I nodi EKS Auto Mode sono SELinux configurati con una modalità di applicazione che fornisce un maggiore isolamento tra i Pod in esecuzione sullo stesso nodo. Quando SELinux è abilitata, alla maggior parte dei pod non privilegiati verrà applicata automaticamente la propria etichetta di sicurezza multicategoria (MCS). Questa etichetta MCS è unica per ogni Pod ed è progettata per garantire che un processo in un Pod non possa manipolare uno in un altro Pod o sull’host. Anche se un Pod etichettato viene eseguito come root e ha accesso al filesystem host, non sarà in grado di manipolare i file, effettuare chiamate di sistema sensibili sull’host, accedere al runtime del container oppure ottenere il materiale delle chiavi segrete di kubelet.
Per questo motivo, potresti riscontrare problemi durante il tentativo di condividere dati tra Pod. Ad esempio, una `PersistentVolumeClaim` con una modalità di accesso di `ReadWriteOnce` non consentirà comunque a più Pod di accedere contemporaneamente al volume.
Per abilitare questa condivisione tra i Pod, puoi usare i Pod `seLinuxOptions` per configurare la stessa etichetta MCS su quei Pod. In questo esempio, assegniamo le tre categorie `c123,c456,c789` al Pod. Ciò non entrerà in conflitto con le categorie assegnate automaticamente ai Pod sul nodo, poiché a esse verranno assegnate solo due categorie.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## Visualizzare gli eventi di Karpenter nei log del piano di controllo
Per i cluster EKS con i log del piano di controllo abilitati, puoi ottenere informazioni sulle azioni e sul processo decisionale di Karpenter interrogando i log. Ciò può essere particolarmente utile per risolvere i problemi della modalità automatica di EKS relativi al provisioning, al dimensionamento e alla terminazione dei nodi. Per visualizzare gli eventi relativi a Karpenter, utilizza la seguente query Logs Insights: CloudWatch
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
Questa query filtra gli [eventi specifici relativi a Karpenter](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) nei log di auditi kube-apiserver. Gli eventi includono vari stati di interruzione, errori di pianificazione, problemi di capacità e problemi relativi ai nodi. Analizzando questi log, puoi comprendere meglio:
+ Perché Karpenter intraprende determinate azioni.
+ Qualsiasi problema che impedisca il corretto provisioning, il dimensionamento o la terminazione dei nodi.
+ Potenziali problemi di capacità o compatibilità con i tipi di istanze.
+ Eventi del ciclo di vita dei nodi come interruzioni, espulsioni o terminazioni.
Per utilizzare questa query:
1. Vai CloudWatch alla console
1. Seleziona “Logs Insights” dal riquadro di navigazione a sinistra
1. Scegli il gruppo di log per i log del piano di controllo del cluster EKS
1. Incolla la query nell’editor di query
1. Regola l’intervallo di tempo in base alle esigenze
1. Eseguire la query
I risultati mostreranno una cronologia degli eventi correlati a Karpenter, aiutandoti a risolvere i problemi e a comprendere il comportamento della modalità automatica di EKS nel cluster. Per esaminare le azioni di Karpenter su un nodo specifico, puoi aggiungere il seguente filtro di riga che specifica l’ID dell’istanza alla suddetta query:
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**Nota**
Per utilizzare questa query, è necessario abilitare la registrazione del piano di controllo sul cluster EKS. Se non hai ancora eseguito questa operazione, consulta [Invia i registri del piano di controllo ai CloudWatch registri](control-plane-logs.md).
## Risolvere i problemi relativi ai controller inclusi in Auto Mode
Se hai un problema con un controller, dovresti cercare:
+ Se le risorse associate a quel controller sono valide e formattate correttamente.
+ Se le risorse AWS IAM e Kubernetes RBAC sono configurate correttamente per il tuo cluster. Per ulteriori informazioni, consulta [Informazioni su identità e accesso in modalità automatica di EKS](auto-learn-iam.md).
## Risorse correlate
Utilizza questi articoli di re:POST per procedure avanzate di AWS risoluzione dei problemi:
+ [Come risolvere i problemi di scalabilità comuni in EKS Auto-Mode?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [Come posso risolvere i problemi di provisioning di nodepool e nodeclass personalizzati nella modalità automatica di Amazon EKS?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [Come posso risolvere i pool di nodi integrati in modalità automatica di EKS con stato sconosciuto?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# Rivedere le note di rilascio della modalità automatica di EKS
Questa pagina documenta gli aggiornamenti alla modalità automatica di Amazon EKS. Puoi controllare periodicamente questa pagina per annunci su funzionalità, correzioni di bug, problemi noti e funzionalità obsolete.
Per ricevere notifiche di tutte le modifiche al file di origine di questa pagina di documentazione specifica, puoi iscriverti al seguente URL con un lettore RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2 febbraio 2026
**Funzionalità: è** stato aggiunto il supporto per disabilitare il traffico V4Egress dai IPv6 pod nei cluster EKS Auto Mode. IPv6 Per ulteriori informazioni, consulta [Disabilita l' IPv4 uscita dai pod nei cluster. IPv6 IPv6](create-node-class.md#enableV4Egress).
## 19 dicembre 2025
**Funzionalità**: è stato aggiunto il supporto per la modalità IP secondaria che fornisce indirizzi IP secondari anziché il prefisso ai nodi Auto. La modalità mantiene un IP secondario come minimo IPTarget e consente di risparmiare risorse IP per i clienti che non hanno bisogno di aggiungere altri prefissi IPs o secondari. Per ulteriori informazioni, consultare [Specifiche della classe di nodi](create-node-class.md#auto-node-class-spec) e [Modalità IP secondaria per Pod](create-node-class.md#secondary-IP-mode).
## 19 novembre 2025
**Funzionalità**: abilitato il pull and unpack parallelo Seekable OCI (SOCI) per le istanze della famiglia G, P e Trn con archiviazione locale. NVMe Il pull and unpack parallelo SOCI viene sempre utilizzato per queste famiglie di istanze con EKS Auto Mode e non sono necessarie modifiche alla configurazione per abilitarlo. [Per ulteriori informazioni su SOCI, consulta il blog di lancio.](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/)
## 19 novembre 2025
**Funzionalità: è** stato aggiunto il supporto per pool di nodi a capacità statica che mantengono un numero fisso di nodi. Per ulteriori informazioni, consulta [Pool di nodi a capacità statica in modalità EKS Auto](auto-static-capacity.md).
## 23 ottobre 2025
**Funzionalità:** gli utenti con cluster nelle regioni degli Stati Uniti possono ora richiedere di utilizzare la compatibilità FIPS AMIs `spec.advancedSecurity.fips` specificando nella loro definizione. NodeClass
## 1° ottobre 2025
**Funzionalità:** EKS Auto Mode ora supporta l'implementazione di nodi su AWS Local Zones. Per ulteriori informazioni, consulta [Implementazione dei nodi EKS Auto Mode su Local Zones](auto-local-zone.md).
## 30 settembre 2025
**Funzionalità:** è stato aggiunto il supporto per InstanceProfile NodeClass `spec.instanceProfile` al quale si esclude a vicenda dal campo. `spec.role`
## 29 settembre 2025
Il DRA non è attualmente supportato da EKS Auto Mode.
## 10 settembre 2025
**Compito:** gli eventi generati dal controller Auto Mode Compute ora utilizzeranno il nome `eks-auto-mode/compute` anziché `karpenter`.
## 24 agosto 2025
**Correzione di bug:** se VPCs si utilizzava un'opzione DHCP impostata con un nome di dominio personalizzato contenente lettere maiuscole, i nodi non riuscivano a unirsi al cluster a causa della generazione di un nome host non valido. Questo problema è stato risolto e i nomi di dominio con lettere maiuscole ora funzionano correttamente.
## 15 agosto 2025
**Correzione di bug:** il Pod Identity Agent ora ascolterà solo l'indirizzo IPv4 Link Local in un cluster IPv4 EKS per evitare problemi in cui il Pod non riesce a raggiungere l'indirizzo. IPv6
## 6 agosto 2025
**Caratteristica:** è stata aggiunta una nuova configurazione NodeClass `spec.advancedNetworking.associatePublicIPAddress` che può essere utilizzata per impedire l'assegnazione di indirizzi IP pubblici ai nodi EKS Auto Mode
## 30 giugno 2025
**Funzionalità:** la modalità automatica NodeClass ora utilizza la chiave KMS personalizzata configurata per crittografare il volume root di sola lettura dell'istanza, oltre al volume di dati. read/write In precedenza, la chiave KMS personalizzata veniva utilizzata solo per crittografare il volume di dati.
## 20 giugno 2025
**Funzionalità:** Supporto per il controllo dell'implementazione dei carichi di lavoro in EC2 On-Demand Capacity Reservations (). ODCRs Ciò aggiunge la chiave opzionale `capacityReservationSelectorTerms` a NodeClass, che consente di controllare in modo esplicito l'utilizzo dei carichi di lavoro. ODCRs Per ulteriori informazioni, consulta [Controlla l’implementazione dei carichi di lavoro in Prenotazioni della capacità con la modalità automatica di EKS](auto-odcr.md).
## 13 giugno 2025
**Funzionalità:** supporto per sottoreti dei pod separate nella `NodeClass`. Vengono aggiunte le chiavi facoltative ``podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms` per impostare le sottoreti e i gruppi di sicurezza per i pod. Per ulteriori informazioni, consulta [Sottoreti e gruppi di sicurezza separati per i pod](create-node-class.md#pod-subnet-selector).
## 30 aprile 2025
**Funzionalità:** supporto per proxy di rete inoltrati nella `NodeClass`. Viene aggiunta la chiave facoltativa `advancedNetworking` per impostare il proxy HTTPS. Per ulteriori informazioni, consulta [Specifiche della classe di nodi](create-node-class.md#auto-node-class-spec).
## 18 aprile 2025
**Funzionalità:** supporto per la risoluzione di domini .local (in genere riservati per Multicast DNS) tramite DNS unicast.
## 11 aprile 2025
**Funzionalità:** aggiunta di `certificateBundles` e `ephemeralStorage.kmsKeyID` a `NodeClass` Per ulteriori informazioni, consulta [Specifiche della classe di nodi](create-node-class.md#auto-node-class-spec).
**Funzionalità:** velocità di estrazione delle immagini migliorata, in particolare per i tipi di istanze con archiviazione locale delle istanze che possono sfruttare la decompressione più rapida delle immagini.
**Correzione di bug:** è stata risolta una condizione di gara che FailedCreatePodSandBox causava un errore durante la chiamata: dial tcp 127.0.0. 1:50051: connect: connection not, a volte si verificava un errore durante la programmazione dei Pod su un nodo immediatamente all'avvio.
## 4 aprile 2025
**Funzionalità:** aumentare `registryPullQPS` da 5 a 25 e `registryBurst` da 10 a 50 per ridurre la limitazione dell’estrazione delle immagini applicata dal client (`Failed to pull image xyz: pull QPS exceeded`)
## 31 marzo 2025
**Correzione di bug**: risoluzione di un problema per cui se un Core DNS Pod è in esecuzione su un nodo in Auto Mode, le query DNS dai Pod sul nodo raggiungevano quel Core DNS Pod anziché il server DNS locale del nodo. Le query DNS dai pod su un nodo in Auto Mode andranno sempre al DNS locale del nodo.
## 21 marzo 2025
**Correzione di bug:** i nodi in Auto Mode ora risolvono `kube-dns.kube-system.svc.cluster.local` correttamente quando non vi è un servizio `kube-dns` installato nel cluster. GitHub [Risolve](https://github.com/aws/containers-roadmap/issues/2546) il problema \$12546.
## 14 marzo 2025
**Funzionalità**: uscita `IPv4` abilitata nei cluster `IPv6`. Il traffico `IPv4` in uscita dai cluster `IPv6` in Auto Mode verrà ora tradotto automaticamente all’indirizzo `v4` del nodo ENI primario.