**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à.
# Ciclo di vita e configurazione del cluster di Amazon EKS
Questa sezione fornisce indicazioni approfondite sulla gestione dell’intero ciclo di vita dei cluster Kubernetes e sui diversi modi per configurarli. Tratta la creazione di cluster, il monitoraggio dell’integrità dei cluster, l’aggiornamento delle versioni di Kubernetes e l’eliminazione dei cluster. Include anche argomenti avanzati su come configurare l'accesso agli endpoint, il supporto di enable/disable Windows, la configurazione di cluster privati, l'implementazione della scalabilità automatica e come migliorare la resilienza con lo spostamento zonale per il reindirizzamento del traffico nelle configurazioni Multi-AZ.
**Topics**
+ [
# Creare un cluster della modalità automatica di Amazon EKS
](create-cluster-auto.md)
+ [
# Crea un cluster Amazon EKS.
](create-cluster.md)
+ [
# Piano di controllo predisposto per Amazon EKS
](eks-provisioned-control-plane.md)
+ [
# Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster
](cluster-insights.md)
+ [
# Aggiornamento del cluster esistente alla nuova versione di Kubernetes
](update-cluster.md)
+ [
# Eliminazione di un cluster
](delete-cluster.md)
+ [
# Endpoint del server API del cluster
](cluster-endpoint.md)
+ [
# Implementazione dei nodi Windows su cluster EKS
](windows-support.md)
+ [
# Disabilitare il supporto Windows
](disable-windows-support.md)
+ [
# Implementazione di cluster privati con accesso limitato a Internet
](private-clusters.md)
+ [
# Dimensionamento dell’elaborazione dei cluster con Karpenter e Cluster Autoscaler
](autoscaling.md)
+ [
# Ulteriori informazioni relative allo spostamento zonale in controller di ripristino delle applicazioni Amazon (ARC)
](zone-shift.md)
+ [
# Abilitazione dello spostamento zonale EKS per evitare zone di disponibilità compromesse
](zone-shift-enable.md)
# Creare un cluster della modalità automatica di Amazon EKS
Questo argomento offre istruzioni dettagliate per creare un cluster della modalità automatica di Amazon EKS usando opzioni di configurazione avanzate. Vengono trattati i prerequisiti, le opzioni di rete e le configurazioni aggiuntive. Il processo comprende l’impostazione dei ruoli IAM, la configurazione delle impostazioni del cluster, la specificazione dei parametri di rete e la selezione dei componenti aggiuntivi. Gli utenti possono creare cluster utilizzando la Console di gestione AWS o la AWS CLI, step-by-step con indicazioni fornite per entrambi i metodi.
Gli utenti che desiderano una procedura di configurazione meno complessa possono fare riferimento alle seguenti istruzioni semplificate per la creazione di cluster:
+ [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)
Questa guida alla configurazione avanzata è destinata agli utenti che necessitano di un controllo più granulare sulla configurazione del cluster della modalità automatica di EKS e che hanno familiarità con i concetti e i requisiti di Amazon EKS. Prima di iniziare la configurazione avanzata, assicurati di aver soddisfatto tutti i prerequisiti e di avere una conoscenza approfondita dei requisiti di rete e IAM per i cluster della modalità automatica di EKS.
La modalità automatica di EKS richiede autorizzazioni IAM aggiuntive. Per ulteriori informazioni, consulta:
+ [Ruoli IAM per cluster della modalità automatica di EKS](automode-get-started-cli.md#auto-mode-create-roles)
+ [Informazioni su identità e accesso in modalità automatica di EKS](auto-learn-iam.md)
**Nota**
Se vuoi creare un cluster senza modalità automatica di EKS, consulta [Crea un cluster Amazon EKS.](create-cluster.md).
In questo argomento viene trattata la configurazione avanzata. Se vuoi iniziare a usare modalità automatica di EKS, consulta [Creare un cluster con la modalità automatica Amazon EKS](create-auto.md).
## Prerequisiti
+ Un VPC esistente e sottoreti che soddisfano i [requisiti di Amazon EKS](network-reqs.md). Prima di implementare un cluster da utilizzare in produzione, ti consigliamo di approfondire le nozioni relative ai requisiti del VPC e delle sottoreti. Se non disponi di un VPC e di sottoreti, puoi crearli utilizzando un modello fornito da [Amazon](creating-a-vpc.md) EKS. AWS CloudFormation
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version`. Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella *Guida per l'utente dell'interfaccia a riga di AWS comando*.
+ Un [IAM principale](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) con le autorizzazioni per creare e modificare risorse EKS e IAM.
## Crea cluster - AWS console
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Seleziona **Aggiungi cluster** e quindi **Crea**.
1. In *Opzioni di configurazione*, seleziona **Configurazione personalizzata**.
+ In questo argomento viene trattata la configurazione personalizzata. Per ulteriori informazioni sulla configurazione rapida, consulta [Crea un cluster di EKS Auto Mode con la Console di gestione AWS](automode-get-started-console.md).
1. Conferma che l’opzione **Usa modalità automatica di EKS** sia abilitata.
+ In questo argomento viene trattata la creazione di cluster con la modalità automatica di EKS. Per ulteriori informazioni sulla creazione di cluster senza modalità automatica di EKS, consulta [Crea un cluster Amazon EKS.](create-cluster.md).
1. Nella pagina **Configura cluster** compila i campi seguenti:
+ **Nome**: un nome per il cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole), trattini e trattini bassi. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster.
+ **Ruolo IAM del cluster**: scegli il ruolo IAM del cluster Amazon EKS che hai creato per consentire al piano di controllo Kubernetes di gestire AWS le risorse per tuo conto. Se non hai mai creato in precedenza un ruolo IAM del cluster per la modalità automatica di EKS, seleziona il pulsante **Crea ruolo consigliato** per creare il ruolo con le autorizzazioni richieste nella console IAM.
+ **Versione Kubernetes** – la versione di Kubernetes da utilizzare per il cluster. È preferibile selezionare la versione più recente, a meno che non occorra una versione precedente.
+ **Policy di aggiornamento**: la policy della versione di Kubernetes che vuoi impostare per il tuo cluster. Se vuoi che il cluster venga eseguito solo su una versione di supporto standard, puoi scegliere **Standard**. Se vuoi che il tuo cluster acceda al supporto esteso alla fine del supporto standard per una versione, puoi scegliere **Esteso**. Se selezioni una versione di Kubernetes che attualmente è in supporto esteso, non puoi selezionare il supporto standard come opzione.
1. Nella sezione **Auto Mode Compute** della pagina di configurazione del cluster, compila i seguenti campi:
+ **Pool di nodi**: stabilisci se vuoi utilizzare i pool di nodi incorporati. Per ulteriori informazioni, consulta [Attivazione o disattivazione della funzionalità integrata NodePools](set-builtin-node-pools.md).
+ **Ruolo IAM del nodo**: se abiliti un pool di nodi integrato, devi selezionare un ruolo IAM del nodo. La modalità automatica di EKS assegnerà tale ruolo ai nuovi nodi. Non puoi modificare questo valore dopo la creazione del cluster. Se non hai mai creato in precedenza un ruolo IAM del nodo per la modalità automatica di EKS, seleziona il pulsante Crea ruolo consigliato per creare il ruolo con le autorizzazioni richieste. Per ulteriori informazioni su questo ruolo, consulta [Informazioni su identità e accesso in modalità automatica di EKS](auto-learn-iam.md).
1. Nella sezione **Accesso al cluster** della pagina Configura cluster, inserisci i seguenti campi:
+ **Accesso amministratore cluster Bootstrap**: il creatore del cluster diventa automaticamente amministratore Kubernetes. Se vuoi disabilitare questa opzione, seleziona **Impedisci l’accesso all’amministratore del cluster**.
+ **Modalità di autenticazione cluster**: modalità automatica di EKS richiede voci di accesso EKS, la modalità di autenticazione API EKS. **Facoltativamente, puoi abilitare la modalità di `ConfigMap` autenticazione selezionando EKS API e. ConfigMap**
1. Inserisci i campi rimanenti nella pagina di configurazione del cluster:
+ **Crittografia dei segreti** (Facoltativo): scegli di abilitare la crittografia dei segreti per i segreti Kubernetes tramite una chiave KMS. Puoi abilitare questa funzionalità anche dopo la creazione del cluster. Assicurati, tuttavia, di acquisire familiarità con le informazioni contenute nella sezione [Crittografia dei segreti Kubernetes con KMS su cluster esistenti](enable-kms.md).
+ **Spostamento zonale ARC**: modalità automatica di EKS non supporta lo spostamento zonale Arc.
+ **Tag**: (facoltativo) aggiunge eventuali tag al cluster. Per ulteriori informazioni, consulta [Organizzazione delle risorse Amazon EKS con tag](eks-using-tags.md).
Quando hai finito con questa pagina, seleziona **Avanti**.
1. Nella pagina **Specifica reti**, seleziona i valori dei campi riportati di seguito:
+ **VPC**: crea il cluster in un VPC esistente conforme ai [requisiti su VPC di Amazon EKS](network-reqs.md#network-requirements-vpc). Prima di scegliere un VPC, ti consigliamo di acquisire familiarità con i requisiti e le considerazioni nella sezione [Visualizzazione di requisiti di rete di Amazon EKS per VPC e sottoreti](network-reqs.md). Dopo la creazione del cluster, non potrai più modificare il VPC da utilizzare. Se non VPCs ne è elencata nessuna, devi prima crearne una. Per ulteriori informazioni, consulta [Creazione di un Amazon VPC per il cluster Amazon EKS.](creating-a-vpc.md).
+ **Sottoreti**: per impostazione predefinita, tutte le sottoreti disponibili nel VPC specificato nel campo precedente sono preselezionate. È necessario selezionarne almeno due.
Le sottoreti scelte devono soddisfare i [requisiti delle sottoreti di Amazon EKS](network-reqs.md#network-requirements-subnets). Prima di selezionare le sottoreti, consigliamo di acquisire familiarità con tutti i [requisiti e le considerazioni su cluster VPC e sottoreti di Amazon EKS](network-reqs.md).
**Gruppi di sicurezza**: (facoltativo) specifica uno o più gruppi di sicurezza da associare alle interfacce di rete create da Amazon EKS.
Indipendentemente dal fatto che tu scelga o meno un gruppo di sicurezza, Amazon EKS ne crea uno nuovo per consentire la comunicazione tra il cluster e il VPC. Amazon EKS associa questo gruppo di sicurezza, e altri gruppi eventualmente scelti dall'utente, alle interfacce di rete create. Per ulteriori informazioni sul gruppo di sicurezza del cluster creato da Amazon EKS, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). Puoi modificare le regole nel gruppo di sicurezza del cluster creato da Amazon EKS.
+ **Scegli la famiglia di indirizzi IP del cluster**: puoi scegliere **IPv4**tra **IPv6**.
Kubernetes assegna indirizzi `IPv4` ai pod e ai servizi, per impostazione predefinita. Prima di utilizzare la famiglia `IPv6`, assicurati di conoscere tutte le considerazioni e i requisiti indicati negli argomenti [Requisiti e considerazioni relativi al VPC](network-reqs.md#network-requirements-vpc), [Considerazioni e requisiti relativi alle sottoreti](network-reqs.md#network-requirements-subnets), [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md) e [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md). Se scegli la famiglia `IPv6`, non puoi specificare un intervallo di indirizzi a cui Kubernetes può assegnare indirizzi di servizio `IPv6` come puoi fare per la famiglia `IPv4`. Kubernetes assegna gli indirizzi del servizio dall’intervallo di indirizzi locale univoco (`fc00::/7`).
+ (Facoltativo) Scegli **Configure Kubernetes Service IP address range** (Configura l’intervallo di indirizzi IP del servizio Kubernetes) e specifica un **intervallo `IPv4` del servizio**.
L’indicazione di un intervallo personalizzato consente di evitare conflitti tra servizi Kubernetes e altre reti con peering o connesse al VPC. Immetti un intervallo in una notazione CIDR. Ad esempio: `10.2.0.0/16`.
Il blocco CIDR deve soddisfare i seguenti requisiti:
+ Essere compreso in uno degli intervalli seguenti: `10.0.0.0/8` `172.16.0.0/12` o `192.168.0.0/16`.
+ Avere una dimensione minima di `/24` e una dimensione massima di `/12`.
+ Non sovrapporsi all'intervallo del VPC per le risorse Amazon EKS.
Puoi specificare questa opzione solo con la famiglia di indirizzi `IPv4` e solo durante la creazione del cluster. Se non specifichi un’opzione, Kubernetes assegna gli indirizzi IP del servizio dai blocchi CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Per **Cluster endpoint access** (Accesso all’endpoint del cluster), seleziona un’opzione. Puoi modificare questa opzione dopo aver creato il cluster. Prima di selezionare un'opzione non predefinita, assicurati di familiarizzare con le opzioni e le relative implicazioni. Per ulteriori informazioni, consulta [Endpoint del server API del cluster](cluster-endpoint.md).
Quando hai finito con questa pagina, seleziona **Avanti**.
1. (Facoltativo) Nella pagina **Configura osservabilità**, scegli le opzioni **Parametri** e **Registrazione del piano di controllo** da attivare. Per impostazione predefinita, i tipi di log sono disattivati.
+ Per ulteriori informazioni sull’opzione relativa alle metriche di Prometheus, consulta [Passaggio 1: attivazione delle metriche Prometheus](prometheus.md#turn-on-prometheus-metrics).
+ Per ulteriori informazioni sulle opzioni **Registrazione del piano di controllo**, consulta [Invia i registri del piano di controllo ai CloudWatch registri](control-plane-logs.md).
+ Quando hai finito con questa pagina, seleziona **Avanti**.
1. Nella pagina **Select add-ons** (Seleziona componenti aggiuntivi), scegli i componenti aggiuntivi da aggiungere al tuo cluster. Puoi scegliere tutti i componenti aggiuntivi **Amazon EKS e i componenti aggiuntivi AWS ** **Marketplace** di cui hai bisogno. Se **i componenti aggiuntivi del AWS Marketplace** che desideri installare non sono elencati, puoi fare clic sulla numerazione delle pagine per visualizzare altri risultati di pagina o cercare i **componenti aggiuntivi di AWS Marketplace** disponibili inserendo il testo nella casella di ricerca. Puoi anche filtrare per **categoria**, **fornitore** o **modello di prezzi** e quindi scegliere i componenti aggiuntivi dai risultati della ricerca. Quando crei un cluster, puoi visualizzare, selezionare e installare tutti i componenti aggiuntivi che supportano EKS Pod Identity, come descritto in dettaglio in [Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS](pod-identities.md).
+ La modalità automatica di EKS automatizza la funzionalità di alcuni componenti aggiuntivi. Se prevedi di implementare i gruppi di nodi gestiti da EKS nel tuo cluster della modalità automatica di EKS, seleziona **Altri componenti aggiuntivi Amazon EKS** ed esamina le opzioni. Potrebbe essere necessaria l’installazione di componenti aggiuntivi come CoredNS e kube-proxy. EKS installerà i componenti aggiuntivi presenti in questa sezione solo su nodi e gruppi di nodi autogestiti.
+ Quando hai finito con questa pagina, seleziona **Avanti**.
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, seleziona la versione da installare. Dopo la creazione del cluster, puoi eseguire in qualsiasi momento l’aggiornamento a una versione successiva.
Per i componenti aggiuntivi che supportano EKS Pod Identities, puoi utilizzare la console per generare automaticamente il ruolo con il nome, la politica AWS gestita e la politica di attendibilità precompilati specificamente per il componente aggiuntivo. È possibile riutilizzare i ruoli esistenti o crearne di nuovi per i componenti aggiuntivi supportati Per i passaggi necessari per usare la console per creare ruoli per i componenti aggiuntivi che supportano EKS Pod Identity, consulta [Crea componente aggiuntivo (console)AWS](creating-an-add-on.md#create_add_on_console). Se un componente aggiuntivo non supporta EKS Pod Identity, viene mostrato un messaggio con le istruzioni per usare la procedura guidata per creare i ruoli IAM per gli account di servizio (IRSA) dopo la creazione del cluster.
Puoi aggiornare la configurazione di ogni componente aggiuntivo dopo la creazione del cluster. Per ulteriori informazioni sulla configurazione dei componenti aggiuntivi, consulta [Aggiornamento di un componente aggiuntivo di Amazon EKS](updating-an-add-on.md). Quando hai finito con questa pagina, seleziona **Avanti**.
1. Nella pagina **Rivedi e crea**, controlla le informazioni che hai inserito o selezionato nelle pagine precedenti. Se devi apportare modifiche, seleziona **Edit** (Modifica). Al termine della configurazione, seleziona **Create** (Crea). Durante il provisioning del cluster, nel campo **Stato** viene visualizzato il messaggio **CREAZIONE**.
**Nota**
Potresti ricevere un messaggio di errore indicante che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l’output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consulta [Capacità insufficiente](troubleshooting.md#ice).
Il provisioning del cluster richiede diversi minuti.
## Crea cluster - AWS CLI
Le seguenti istruzioni sulle CLI riguardano la creazione di risorse IAM e la creazione del cluster.
### 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 IAM del cluster 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
```
### Crea un cluster
1. Crea un cluster con il comando seguente. Prima di eseguire il comando, apporta le modifiche seguenti:
+ Sostituiscilo *region-code* con la AWS regione in cui desideri creare il cluster.
+ Sostituisci *my-cluster* con un nome da assegnare al cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole), trattini e trattini bassi. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster.
+ Sostituisci *1.30* con qualsiasi [versione supportata da Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ *111122223333*Sostituiscilo con l'ID del tuo account
+ Se hai creato ruoli IAM con nomi diversi per i ruoli Cluster e Node, sostituisci ARNs.
+ Sostituisci i valori di `subnetIds` con quelli in tuo possesso. Puoi anche aggiungerne altri IDs. È necessario specificare almeno due sottoreti IDs.
Le sottoreti scelte devono soddisfare i [requisiti delle sottoreti di Amazon EKS](network-reqs.md#network-requirements-subnets). Prima di selezionare le sottoreti, consigliamo di acquisire familiarità con tutti i [requisiti e le considerazioni su cluster VPC e sottoreti di Amazon EKS](network-reqs.md).
+ Se non vuoi specificare un ID del gruppo di sicurezza, rimuovi `,securityGroupIds=sg-` dal comando. Se desideri specificare uno o più gruppi di sicurezza IDs, sostituisci i valori di `securityGroupIds` con i tuoi. Puoi anche aggiungerne altri IDs.
Indipendentemente dal fatto che tu scelga o meno un gruppo di sicurezza, Amazon EKS ne crea uno nuovo per consentire la comunicazione tra il cluster e il VPC. Amazon EKS associa questo gruppo di sicurezza, e altri gruppi eventualmente scelti dall'utente, alle interfacce di rete create. Per ulteriori informazioni sul gruppo di sicurezza del cluster creato da Amazon EKS, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). Puoi modificare le regole nel gruppo di sicurezza del cluster creato da Amazon EKS.
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws: iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws: iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**Nota**
Potresti ricevere un messaggio di errore indicante che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l’output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consulta [Capacità insufficiente](troubleshooting.md#ice).
Di seguito sono riportate le impostazioni facoltative da aggiungere al comando precedente, quando necessario. Puoi abilitare queste opzioni esclusivamente durante la creazione del cluster, non in seguito.
+ Se vuoi specificare il blocco di instradamento interdominio senza classi (CIDR) `IPv4` da cui Kubernetes assegna gli indirizzi IP del servizio, aggiungi `--kubernetes-network-config serviceIpv4Cidr=` al comando seguente.
L’indicazione di un intervallo personalizzato consente di evitare conflitti tra servizi Kubernetes e altre reti con peering o connesse al VPC. Immetti un intervallo in una notazione CIDR. Ad esempio: `10.2.0.0/16`.
Il blocco CIDR deve soddisfare i seguenti requisiti:
+ Essere compreso in uno degli intervalli seguenti: `10.0.0.0/8` `172.16.0.0/12` o `192.168.0.0/16`.
+ Avere una dimensione minima di `/24` e una dimensione massima di `/12`.
+ Non sovrapporsi all'intervallo del VPC per le risorse Amazon EKS.
Puoi specificare questa opzione solo con la famiglia di indirizzi `IPv4` e solo durante la creazione del cluster. Se non specifichi un’opzione, Kubernetes assegna gli indirizzi IP del servizio dai blocchi CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Se stai creando un cluster e vuoi che il cluster assegni gli indirizzi `IPv6` ai pod e ai servizi anziché a indirizzi `IPv4`, aggiungi `--kubernetes-network-config ipFamily=ipv6` al seguente comando.
Kubernetes assegna indirizzi `IPv4` ai pod e ai servizi, per impostazione predefinita. Prima di utilizzare la famiglia `IPv6`, assicurati di conoscere tutte le considerazioni e i requisiti indicati negli argomenti [Requisiti e considerazioni relativi al VPC](network-reqs.md#network-requirements-vpc), [Considerazioni e requisiti relativi alle sottoreti](network-reqs.md#network-requirements-subnets), [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md) e [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md). Se scegli la famiglia `IPv6`, non puoi specificare un intervallo di indirizzi a cui Kubernetes può assegnare indirizzi di servizio `IPv6` come puoi fare per la famiglia `IPv4`. Kubernetes assegna gli indirizzi del servizio dall’intervallo di indirizzi locale univoco (`fc00::/7`).
1. Il provisioning del cluster richiede diversi minuti. È possibile eseguire query sullo stato del cluster con il comando seguente.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## Fasi successive
+ [Connettere kubectl a un cluster EKS creando un file kubeconfig](create-kubeconfig.md)
+ [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md)
+ [Abilitare la crittografia dei segreti per il cluster](enable-kms.md).
+ [Configurare la registrazione per il cluster](control-plane-logs.md).
+ [Aggiungi nodi al cluster](eks-compute.md).
# Crea un cluster Amazon EKS.
**Nota**
Questo argomento tratta la creazione di cluster Amazon EKS senza EKS Auto Mode.
Per istruzioni dettagliate su come creare un cluster della modalità automatica di EKS, consulta [Creare un cluster della modalità automatica di Amazon EKS](create-cluster-auto.md).
Per iniziare a usare modalità automatica di EKS, consulta [Nozioni di base su Amazon EKS: EKS Auto Mode](getting-started-automode.md).
Questo argomento offre una panoramica delle opzioni disponibili e descrivere gli aspetti da considerare quando crei un cluster Amazon EKS. Se devi creare un cluster con la tua infrastruttura on-premises come elaborazione per i nodi, consulta [Creazione di un cluster Amazon EKS con nodi ibridi](hybrid-nodes-cluster-create.md). Se è la prima volta che crei un cluster Amazon EKS, consigliamo di seguire le nostre guide in [Nozioni di base su Amazon EKS](getting-started.md). Le guide consentono di creare un cluster predefinito in modo semplice, senza approfondire tutte le opzioni disponibili.
## Prerequisiti
+ Un VPC esistente e sottoreti che soddisfano i [requisiti di Amazon EKS](network-reqs.md). Prima di implementare un cluster da utilizzare in produzione, ti consigliamo di approfondire le nozioni relative ai requisiti del VPC e delle sottoreti. Se non disponi di un VPC e di sottoreti, puoi crearli utilizzando un modello fornito da [Amazon](creating-a-vpc.md) EKS. AWS CloudFormation
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*.
+ Un [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) con autorizzazioni per `create` e `describe` un cluster Amazon EKS. Per ulteriori informazioni, consultare [Creazione di un cluster Kubernetes locale su un Outpost](security-iam-id-based-policy-examples.md#policy-create-local-cluster) e [Elencare o descrivere tutti i cluster](security-iam-id-based-policy-examples.md#policy-example2).
## Passaggio 1: crea un ruolo IAM del cluster
1. Se disponi già di un ruolo IAM del cluster o intendi creare il cluster con `eksctl`, ignora questo passaggio. Per impostazione predefinita, `eksctl` crea un ruolo per te.
1. Per creare un file JSON della policy di attendibilità IAM, esegui il comando seguente.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Crea il ruolo IAM del cluster Amazon EKS. Se necessario, inserisci il prefisso *eks-cluster-role-trust-policy.json* nel percorso del computer in cui hai eseguito la scrittura del file nella Passaggio precedente. Il comando associa il criterio di attendibilità creato nella Passaggio precedente al ruolo. Per creare un ruolo IAM, l’azione `iam:CreateRole` (autorizzazione) deve essere assegnata al [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che sta creando il ruolo.
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Puoi assegnare la policy gestita da Amazon EKS o creare una policy personalizzata. Per conoscere le autorizzazioni minime che devi utilizzare nella policy personalizzata, consulta [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md).
Allega la policy gestita di Amazon EKS denominata [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) al ruolo. Per allegare una policy IAM a un [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), è necessario assegnare al principale che sta allegando la policy una delle azioni IAM (autorizzazioni) seguenti: `iam:AttachUserPolicy` o `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### Ruolo legato al servizio
Amazon EKS crea automaticamente un ruolo collegato ai servizi denominato `AWSServiceRoleForAmazonEKS`.
Ciò avviene in aggiunta al ruolo IAM del cluster. Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon EKS. Il ruolo consente ad Amazon EKS di gestire i cluster nell’account. Per ulteriori informazioni, consulta [Utilizzo dei ruoli per i cluster Amazon EKS](using-service-linked-roles-eks.md).
L’identità IAM usata per creare il cluster EKS deve disporre dell’autorizzazione per creare il ruolo collegato al servizio. Ciò include l’autorizzazione `iam:CreateServiceLinkedRole`.
Se il ruolo collegato al servizio non esiste già e il ruolo IAM attuale non dispone delle autorizzazioni sufficienti per crearlo, l’operazione di creazione del cluster non andrà a buon fine.
## Fase 2: Creare un cluster
Puoi creare un cluster utilizzando:
+ [`eksctl`](#step2-eksctl)
+ [il Console di gestione AWS](#step2-console)
+ [la AWS CLI](#step2-cli)
### Crea cluster - eksctl
1. È necessaria la versione `0.215.0` o una versione successiva dello strumento da riga di `eksctl` comando installata sul dispositivo o AWS CloudShell. Per l’installazione o l’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.
1. Crea un `IPv4` cluster Amazon EKS con la versione Kubernetes predefinita di Amazon EKS nella tua regione predefinita. AWS Prima di eseguire il comando, apporta le sostituzioni seguenti:
1. Sostituiscilo *region-code* con la AWS regione in cui desideri creare il cluster.
1. Sostituisci *my-cluster* con un nome da assegnare al cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster.
1. Sostituisci *1.35* con qualsiasi [versione supportata da Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Modifica i valori di `vpc-private-subnets` in base alle tue esigenze. Puoi anche aggiungerne altri IDs. È necessario specificare almeno due sottoreti IDs. tuttavia, se preferisci specificare le sottoreti pubbliche, puoi modificare `--vpc-private-subnets` in `--vpc-public-subnets`. Alle sottoreti pubbliche è associata una tabella di routing con un routing a un gateway Internet, al contrario delle sottoreti private. Per questo motivo, ti consigliamo di utilizzare le sottoreti private quando possibile.
Le sottoreti scelte devono soddisfare i [requisiti delle sottoreti di Amazon EKS](network-reqs.md#network-requirements-subnets). Prima di selezionare le sottoreti, consigliamo di acquisire familiarità con tutti i [requisiti e le considerazioni su cluster VPC e sottoreti di Amazon EKS](network-reqs.md).
1. Esegui il comando seguente:
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
Il provisioning del cluster richiede diversi minuti. Durante la creazione del cluster, vengono visualizzate diverse righe di output. L’ultima riga di output è simile alla seguente riga di esempio.
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. Continuare con [Passaggio 3: aggiornamento di kubeconfig](#step3)
#### Impostazioni facoltative
Per visualizzare la maggior parte delle opzioni che è possibile specificare durante la creazione di un cluster con `eksctl`, utilizza il comando `eksctl create cluster --help`. Per visualizzare tutte le opzioni disponibili, puoi utilizzare un file `config`. Per ulteriori informazioni, consulta [Uso dei file config](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) e lo [Schema dei file config](https://eksctl.io/usage/schema/) nella documentazione di `eksctl`. Gli [esempi di file di configurazione](https://github.com/weaveworks/eksctl/tree/master/examples) sono disponibili su GitHub.
Di seguito sono riportate le impostazioni facoltative da aggiungere al comando precedente, quando necessario. Puoi abilitare queste opzioni esclusivamente durante la creazione del cluster, non in seguito. Per specificare queste opzioni, non usare il comando precedente. Crea invece il cluster con un [file di configurazione eksctl](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) e specifica tali impostazioni.
+ Se vuoi specificare uno o più gruppi di sicurezza assegnati da Amazon EKS alle interfacce di rete create, scegli l’opzione [securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup).
Indipendentemente dal fatto che tu scelga o meno un gruppo di sicurezza, Amazon EKS ne crea uno nuovo per consentire la comunicazione tra il cluster e il VPC. Amazon EKS associa questo gruppo di sicurezza, e altri gruppi eventualmente scelti dall'utente, alle interfacce di rete create. Per ulteriori informazioni sul gruppo di sicurezza del cluster creato da Amazon EKS, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). Puoi modificare le regole nel gruppo di sicurezza del cluster creato da Amazon EKS.
+ [Se desideri specificare da quale blocco CIDR (`IPv4`Classless Inter-domain Routing) Kubernetes assegna gli indirizzi IP del servizio, specifica l'opzione CIDR del servizio. IPv4](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR)
L’indicazione di un intervallo personalizzato consente di evitare conflitti tra servizi Kubernetes e altre reti con peering o connesse al VPC. Immetti un intervallo in una notazione CIDR. Ad esempio: `10.2.0.0/16`.
Il blocco CIDR deve soddisfare i seguenti requisiti:
+ Essere compreso in uno degli intervalli seguenti: `10.0.0.0/8` `172.16.0.0/12` o `192.168.0.0/16`.
+ Avere una dimensione minima di `/24` e una dimensione massima di `/12`.
+ Non sovrapporsi all'intervallo del VPC per le risorse Amazon EKS.
Puoi specificare questa opzione solo con la famiglia di indirizzi `IPv4` e solo durante la creazione del cluster. Se non specifichi un’opzione, Kubernetes assegna gli indirizzi IP del servizio dai blocchi CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Se stai creando un cluster e vuoi che il cluster assegni gli indirizzi `IPv6` ai pods e ai servizi anziché a indirizzi `IPv4`, scegli l’opzione [ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily).
Kubernetes assegna indirizzi `IPv4` ai pod e ai servizi, per impostazione predefinita. Prima di utilizzare la famiglia `IPv6`, assicurati di conoscere tutte le considerazioni e i requisiti indicati negli argomenti [Considerazioni e requisiti relativi al VPC](network-reqs.md#network-requirements-vpc), [Considerazioni e requisiti relativi alle sottoreti](network-reqs.md#network-requirements-subnets), [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md) e [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md). Se scegli la famiglia `IPv6`, non puoi specificare un intervallo di indirizzi a cui Kubernetes può assegnare indirizzi di servizio `IPv6` come puoi fare per la famiglia `IPv4`. Kubernetes assegna gli indirizzi del servizio dall’intervallo di indirizzi locale univoco (`fc00::/7`).
### Crea cluster - console AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Seleziona **Aggiungi cluster** e quindi **Crea**.
1. In **Opzioni di configurazione**, seleziona **Configurazione personalizzata**
+ Per informazioni sulla creazione rapida di cluster con la modalità automatica di EKS, consulta [Crea un cluster di EKS Auto Mode con la Console di gestione AWS](automode-get-started-console.md).
1. In **modalità automatica di EKS**, disattiva l’opzione **Usa modalità automatica di EKS**.
+ Per informazioni sulla creazione di cluster della modalità automatica di EKS con configurazione personalizzata, consulta [Creare un cluster della modalità automatica di Amazon EKS](create-cluster-auto.md).
1. Nella pagina **Configura cluster** compila i campi seguenti:
+ **Nome**: un nome per il cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole), trattini e trattini bassi. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster.
+ **Ruolo IAM del cluster**: scegli il ruolo IAM del cluster Amazon EKS che hai creato per consentire al piano di controllo Kubernetes di gestire AWS le risorse per tuo conto.
+ **Versione Kubernetes** – la versione di Kubernetes da utilizzare per il cluster. È preferibile selezionare la versione più recente, a meno che non occorra una versione precedente.
+ **Tipo di supporto**: la policy della versione di Kubernetes che vuoi impostare per il tuo cluster. Se vuoi che il cluster venga eseguito solo su una versione di supporto standard, puoi scegliere **Supporto standard**. Se vuoi che il tuo cluster acceda al supporto esteso alla fine del supporto standard per una versione, puoi scegliere **Supporto esteso**. Se selezioni una versione di Kubernetes che attualmente è in supporto esteso, non puoi selezionare il supporto standard come opzione.
+ **Crittografia dei segreti** (Facoltativo): scegli di abilitare la crittografia dei segreti per i segreti Kubernetes tramite una chiave KMS. Puoi abilitare questa funzionalità anche dopo la creazione del cluster. Assicurati, tuttavia, di acquisire familiarità con le informazioni contenute nella sezione [Crittografia dei segreti Kubernetes con KMS su cluster esistenti](enable-kms.md).
+ **Tag**: (facoltativo) aggiunge eventuali tag al cluster. Per ulteriori informazioni, consulta [Organizzazione delle risorse Amazon EKS con tag](eks-using-tags.md).
+ **Spostamento zonale ARC** - (facoltativo) Puoi usare il controller Route53 Application Recovery per mitigare le zone di disponibilità compromesse. Per ulteriori informazioni, consulta [Ulteriori informazioni relative allo spostamento zonale in controller di ripristino delle applicazioni Amazon (ARC)](zone-shift.md).
1. Nella sezione **Accesso al cluster** della pagina Configura cluster, inserisci i seguenti campi:
+ **Accesso amministratore cluster Bootstrap**: il creatore del cluster diventa automaticamente amministratore Kubernetes. Se vuoi disabilitare questa opzione, seleziona **Impedisci l’accesso all’amministratore del cluster**.
+ **Modalità di autenticazione del cluster**: determina come concedere agli utenti e ai ruoli IAM l'accesso a Kubernetes. APIs Per ulteriori informazioni, consulta [Set Cluster Authentication Mode](grant-k8s-access.md#set-cam).
Quando hai finito con questa pagina, seleziona **Avanti**.
1. Nella pagina **Specifica reti**, seleziona i valori dei campi riportati di seguito:
+ **VPC**: crea il cluster in un VPC esistente conforme ai [requisiti su VPC di Amazon EKS](network-reqs.md#network-requirements-vpc). Prima di scegliere un VPC, ti consigliamo di acquisire familiarità con i requisiti e le considerazioni nella sezione [Visualizzazione di requisiti di rete di Amazon EKS per VPC e sottoreti](network-reqs.md). Dopo la creazione del cluster, non potrai più modificare il VPC da utilizzare. Se non VPCs ne è elencata nessuna, devi prima crearne una. Per ulteriori informazioni, consulta [Creazione di un Amazon VPC per il cluster Amazon EKS.](creating-a-vpc.md).
+ **Sottoreti**: per impostazione predefinita, tutte le sottoreti disponibili nel VPC specificato nel campo precedente sono preselezionate. È necessario selezionarne almeno due.
Le sottoreti scelte devono soddisfare i [requisiti delle sottoreti di Amazon EKS](network-reqs.md#network-requirements-subnets). Prima di selezionare le sottoreti, consigliamo di acquisire familiarità con tutti i [requisiti e le considerazioni su cluster VPC e sottoreti di Amazon EKS](network-reqs.md).
**Gruppi di sicurezza**: (facoltativo) specifica uno o più gruppi di sicurezza da associare alle interfacce di rete create da Amazon EKS.
Indipendentemente dal fatto che tu scelga o meno un gruppo di sicurezza, Amazon EKS ne crea uno nuovo per consentire la comunicazione tra il cluster e il VPC. Amazon EKS associa questo gruppo di sicurezza, e altri gruppi eventualmente scelti dall'utente, alle interfacce di rete create. Per ulteriori informazioni sul gruppo di sicurezza del cluster creato da Amazon EKS, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). Puoi modificare le regole nel gruppo di sicurezza del cluster creato da Amazon EKS.
+ **Scegli la famiglia di indirizzi IP del cluster**: puoi scegliere **IPv4**tra **IPv6**.
Kubernetes assegna indirizzi `IPv4` ai pod e ai servizi, per impostazione predefinita. Prima di utilizzare la famiglia `IPv6`, assicurati di conoscere tutte le considerazioni e i requisiti indicati negli argomenti [Requisiti e considerazioni relativi al VPC](network-reqs.md#network-requirements-vpc), [Considerazioni e requisiti relativi alle sottoreti](network-reqs.md#network-requirements-subnets), [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md) e [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md). Se scegli la famiglia `IPv6`, non puoi specificare un intervallo di indirizzi a cui Kubernetes può assegnare indirizzi di servizio `IPv6` come puoi fare per la famiglia `IPv4`. Kubernetes assegna gli indirizzi del servizio dall’intervallo di indirizzi locale univoco (`fc00::/7`).
+ (Facoltativo) Scegli **Configure Kubernetes Service IP address range** (Configura l’intervallo di indirizzi IP del servizio Kubernetes) e specifica un **intervallo `IPv4` del servizio**.
L’indicazione di un intervallo personalizzato consente di evitare conflitti tra servizi Kubernetes e altre reti con peering o connesse al VPC. Immetti un intervallo in una notazione CIDR. Ad esempio: `10.2.0.0/16`.
Il blocco CIDR deve soddisfare i seguenti requisiti:
+ Essere compreso in uno degli intervalli seguenti: `10.0.0.0/8` `172.16.0.0/12` o `192.168.0.0/16`.
+ Avere una dimensione minima di `/24` e una dimensione massima di `/12`.
+ Non sovrapporsi all'intervallo del VPC per le risorse Amazon EKS.
Puoi specificare questa opzione solo con la famiglia di indirizzi `IPv4` e solo durante la creazione del cluster. Se non specifichi un’opzione, Kubernetes assegna gli indirizzi IP del servizio dai blocchi CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Per **Cluster endpoint access** (Accesso all’endpoint del cluster), seleziona un’opzione. Puoi modificare questa opzione dopo aver creato il cluster. Prima di selezionare un'opzione non predefinita, assicurati di familiarizzare con le opzioni e le relative implicazioni. Per ulteriori informazioni, consulta [Endpoint del server API del cluster](cluster-endpoint.md).
Quando hai finito con questa pagina, seleziona **Avanti**.
1. (Facoltativo) Nella pagina **Configura osservabilità**, scegli le opzioni **Parametri** e **Registrazione del piano di controllo** da attivare. Per impostazione predefinita, i tipi di log sono disattivati.
+ Per ulteriori informazioni sull’opzione relativa alle metriche di Prometheus, consulta [Passaggio 1: attivazione delle metriche Prometheus](prometheus.md#turn-on-prometheus-metrics).
+ Per ulteriori informazioni sulle opzioni **Registrazione del piano di controllo**, consulta [Invia i registri del piano di controllo ai CloudWatch registri](control-plane-logs.md).
Quando hai finito con questa pagina, seleziona **Avanti**.
1. Nella pagina **Select add-ons** (Seleziona componenti aggiuntivi), scegli i componenti aggiuntivi da aggiungere al tuo cluster. Certi componenti aggiuntivi sono preselezionati. Puoi scegliere tutti i componenti aggiuntivi **Amazon EKS e i componenti aggiuntivi AWS ** **Marketplace** di cui hai bisogno. Se **i componenti aggiuntivi del AWS Marketplace** che desideri installare non sono elencati, puoi fare clic sulla numerazione delle pagine per visualizzare altri risultati di pagina o cercare i **componenti aggiuntivi di AWS Marketplace** disponibili inserendo il testo nella casella di ricerca. Puoi anche filtrare per **categoria**, **fornitore** o **modello di prezzi** e quindi scegliere i componenti aggiuntivi dai risultati della ricerca. Quando crei un cluster, puoi visualizzare, selezionare e installare tutti i componenti aggiuntivi che supportano EKS Pod Identity, come descritto in dettaglio in [Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS](pod-identities.md).
Quando hai finito con questa pagina, seleziona **Avanti**.
Alcuni componenti aggiuntivi, come Amazon VPC CNI, CoreDNS e kube-proxy, sono installati per impostazione predefinita. Disabilitare uno dei componenti aggiuntivi predefiniti potrebbe influire sulla tua capacità di eseguire le applicazioni Kubernetes.
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, seleziona la versione da installare. Dopo la creazione del cluster, puoi eseguire in qualsiasi momento l’aggiornamento a una versione successiva.
Per i componenti aggiuntivi che supportano EKS Pod Identities, puoi utilizzare la console per generare automaticamente il ruolo con il nome, la politica AWS gestita e la politica di attendibilità precompilati specificamente per il componente aggiuntivo. È possibile riutilizzare i ruoli esistenti o crearne di nuovi per i componenti aggiuntivi supportati Per i passaggi necessari per usare la console per creare ruoli per i componenti aggiuntivi che supportano EKS Pod Identity, consulta [Crea componente aggiuntivo (console)AWS](creating-an-add-on.md#create_add_on_console). Se un componente aggiuntivo non supporta EKS Pod Identity, viene mostrato un messaggio con le istruzioni per usare la procedura guidata per creare i ruoli IAM per gli account di servizio (IRSA) dopo la creazione del cluster.
Puoi aggiornare la configurazione di ogni componente aggiuntivo dopo la creazione del cluster. Per ulteriori informazioni sulla configurazione dei componenti aggiuntivi, consulta [Aggiornamento di un componente aggiuntivo di Amazon EKS](updating-an-add-on.md). Quando hai finito con questa pagina, seleziona **Avanti**.
1. Nella pagina **Rivedi e crea**, controlla le informazioni che hai inserito o selezionato nelle pagine precedenti. Se devi apportare modifiche, seleziona **Edit** (Modifica). Al termine della configurazione, seleziona **Create** (Crea). Durante il provisioning del cluster, nel campo **Stato** viene visualizzato il messaggio **CREAZIONE**.
**Nota**
Potresti ricevere un messaggio di errore indicante che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l’output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consulta [Capacità insufficiente](troubleshooting.md#ice).
Il provisioning del cluster richiede diversi minuti.
1. Continua con [Passaggio 3: aggiornamento di kubeconfig](#step3)
### Crea cluster - AWS CLI
1. Crea un cluster con il comando seguente. Prima di eseguire il comando, apporta le modifiche seguenti:
+ Sostituisci *region-code* con la AWS regione in cui desideri creare il cluster.
+ Sostituisci *my-cluster* con un nome da assegnare al cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole), trattini e trattini bassi. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster.
+ Sostituisci *1.35* con qualsiasi [versione supportata da Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Sostituisci *111122223333* con il tuo ID account e *myAmazonEKSClusterRole* con il nome del ruolo IAM del cluster.
+ Sostituisci i valori di `subnetIds` con quelli in tuo possesso. Puoi anche aggiungerne altri IDs. È necessario specificare almeno due sottoreti IDs.
Le sottoreti scelte devono soddisfare i [requisiti delle sottoreti di Amazon EKS](network-reqs.md#network-requirements-subnets). Prima di selezionare le sottoreti, consigliamo di acquisire familiarità con tutti i [requisiti e le considerazioni su cluster VPC e sottoreti di Amazon EKS](network-reqs.md).
+ Se non vuoi specificare un ID del gruppo di sicurezza, rimuovi `,securityGroupIds=sg-` dal comando. Se desideri specificare uno o più gruppi di sicurezza IDs, sostituisci i valori di `securityGroupIds` con i tuoi. Puoi anche aggiungerne altri IDs.
Indipendentemente dal fatto che tu scelga o meno un gruppo di sicurezza, Amazon EKS ne crea uno nuovo per consentire la comunicazione tra il cluster e il VPC. Amazon EKS associa questo gruppo di sicurezza, e altri gruppi eventualmente scelti dall'utente, alle interfacce di rete create. Per ulteriori informazioni sul gruppo di sicurezza del cluster creato da Amazon EKS, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). Puoi modificare le regole nel gruppo di sicurezza del cluster creato da Amazon EKS.
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws: iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**Nota**
Potresti ricevere un messaggio di errore indicante che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l’output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consulta [Capacità insufficiente](troubleshooting.md#ice).
Di seguito sono riportate le impostazioni facoltative da aggiungere al comando precedente, quando necessario. Puoi abilitare queste opzioni esclusivamente durante la creazione del cluster, non in seguito.
+ Durante la creazione del cluster, EKS installa più componenti aggiuntivi di rete per impostazione predefinita. Sono inclusi Amazon VPC CNI, CoreDNS e kube-proxy.
Se vuoi disabilitare l’installazione di questi componenti aggiuntivi di rete predefiniti, usa il parametro seguente. Questo può essere usato per alternative CNIs, come Cilium. Per ulteriori informazioni, consulta la [Documentazione di riferimento delle API di EKS](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html).
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ Se vuoi specificare il blocco di instradamento interdominio senza classi (CIDR) `IPv4` da cui Kubernetes assegna gli indirizzi IP del servizio, aggiungi `--kubernetes-network-config serviceIpv4Cidr=` al comando seguente.
L’indicazione di un intervallo personalizzato consente di evitare conflitti tra servizi Kubernetes e altre reti con peering o connesse al VPC. Immetti un intervallo in una notazione CIDR. Ad esempio: `10.2.0.0/16`.
Il blocco CIDR deve soddisfare i seguenti requisiti:
+ Essere compreso in uno degli intervalli seguenti: `10.0.0.0/8` `172.16.0.0/12` o `192.168.0.0/16`.
+ Avere una dimensione minima di `/24` e una dimensione massima di `/12`.
+ Non sovrapporsi all'intervallo del VPC per le risorse Amazon EKS.
Puoi specificare questa opzione solo con la famiglia di indirizzi `IPv4` e solo durante la creazione del cluster. Se non specifichi un’opzione, Kubernetes assegna gli indirizzi IP del servizio dai blocchi CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Se stai creando un cluster e vuoi che il cluster assegni gli indirizzi `IPv6` ai pod e ai servizi anziché a indirizzi `IPv4`, aggiungi `--kubernetes-network-config ipFamily=ipv6` al seguente comando.
Kubernetes assegna indirizzi `IPv4` ai pod e ai servizi, per impostazione predefinita. Prima di utilizzare la famiglia `IPv6`, assicurati di conoscere tutte le considerazioni e i requisiti indicati negli argomenti [Requisiti e considerazioni relativi al VPC](network-reqs.md#network-requirements-vpc), [Considerazioni e requisiti relativi alle sottoreti](network-reqs.md#network-requirements-subnets), [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md) e [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md). Se scegli la famiglia `IPv6`, non puoi specificare un intervallo di indirizzi a cui Kubernetes può assegnare indirizzi di servizio `IPv6` come puoi fare per la famiglia `IPv4`. Kubernetes assegna gli indirizzi del servizio dall’intervallo di indirizzi locale univoco (`fc00::/7`).
1. Il provisioning del cluster richiede diversi minuti. È possibile eseguire query sullo stato del cluster con il comando seguente.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
Non passare alla fase successiva finché l’output restituito non è `ACTIVE`.
1. Continua con [Passaggio 3: aggiornamento di kubeconfig](#step3)
## Passaggio 3: aggiornamento di kubeconfig
1. Se hai creato il cluster utilizzando `eksctl`, puoi ignorare questo passaggio, poiché è già stato completato da `eksctl`. Abilita `kubectl` per consentire la comunicazione con il cluster aggiungendo un nuovo contesto al file `config` `kubectl`. Per ulteriori informazioni su come creare e aggiornare il file, consulta [Connettere kubectl a un cluster EKS creando un file kubeconfig](create-kubeconfig.md).
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Di seguito viene riportato un output di esempio:
```
Added new context arn:aws: eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. Conferma la comunicazione con il cluster eseguendo il comando seguente.
```
kubectl get svc
```
Di seguito viene riportato un output di esempio.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## Passaggio 4: configurazione del cluster
1. (Consigliato) Per utilizzare alcuni componenti aggiuntivi di Amazon EKS o per consentire a singoli carichi di lavoro Kubernetes di disporre di autorizzazioni IAM ( AWS Identity and Access Management) specifiche, crea un provider [IAM OpenID](enable-iam-roles-for-service-accounts.md) Connect (OIDC) per il tuo cluster. È necessario creare un provider OIDC IAM per il cluster una sola volta. Per ulteriori informazioni sui componenti aggiuntivi di Amazon EKS, consulta [Componenti aggiuntivi Amazon EKS](eks-add-ons.md). Per ulteriori informazioni sull'assegnazione di autorizzazioni IAM specifiche ai carichi di lavoro, consulta [Ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md).
1. (Consigliato) Configura il cluster per il componente aggiuntivo CNI di Amazon VPC per Kubernetes prima di implementare i nodi Amazon EC2 nel cluster. Per impostazione predefinita, il plugin è stato installato con il cluster. Quando aggiungi i nodi Amazon EC2 al cluster, il plugin viene implementato automaticamente su ogni nodo Amazon EC2 aggiunto. Il componente aggiuntivo richiede di collegare una delle policy IAM seguenti a un ruolo IAM. Se il cluster usa la famiglia `IPv4`, usa la policy IAM gestita [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html). Se il tuo cluster usa la famiglia `IPv6`, utilizza una [policy IAM creata da te](cni-iam-role.md#cni-iam-role-create-ipv6-policy).
Il ruolo IAM a cui si collega la policy può essere il ruolo IAM del nodo o un ruolo dedicato utilizzato solo per il plugin. Consigliamo di allegare la policy a quest'ultimo ruolo. Per ulteriori informazioni sulla creazione del ruolo, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md) o il [ruolo IAM del nodo Amazon EKS](create-node-role.md).
1. Se hai distribuito il cluster utilizzando, puoi saltare questo passaggio. Console di gestione AWS Per impostazione predefinita, Console di gestione AWS implementa il plug-in Amazon VPC CNI per i componenti aggiuntivi Kubernetes, CoredNS e Amazon EKS. `kube-proxy`
Se distribuisci il cluster utilizzando una delle due opzioni `eksctl` o la AWS CLI, vengono implementati il plug-in Amazon VPC CNI per Kubernetes, CoredNS e componenti aggiuntivi autogestiti. `kube-proxy` Puoi eseguire la migrazione dei componenti aggiuntivi CNI di Amazon VPC per Kubernetes, CoreDNS e dei componenti autogestiti `kube-proxy` implementati con il cluster verso i componenti aggiuntivi di Amazon EKS. Per ulteriori informazioni, consulta [Componenti aggiuntivi Amazon EKS](eks-add-ons.md).
1. (Facoltativo) Se non l’hai già fatto, puoi abilitare le metriche Prometheus per il cluster. Per ulteriori informazioni, consulta [Creare uno scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) nella *Guida per l'utente di Amazon Managed Service for Prometheus*.
1. Se hai intenzione di implementare nel tuo cluster carichi di lavoro che utilizzano volumi Amazon EBS, devi installare il [Amazon EBS CSI](ebs-csi.md) nel cluster prima di implementare i carichi di lavoro.
## Fasi successive
+ L'utente o il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che ha creato il cluster è l'unico principale in grado di accedere al cluster. [Concedi autorizzazioni ad altri principali IAM](grant-k8s-access.md) in modo che possano accedere al tuo cluster.
+ Se il principale IAM che ha creato il cluster dispone solo delle autorizzazioni IAM minime a cui si fa riferimento nei prerequisiti, potresti voler aggiungere ulteriori autorizzazioni Amazon EKS per quel principale IAM. Per ulteriori informazioni su come concedere le autorizzazioni Amazon EKS ali principali IAM, consulta [Identity and Access Management per Amazon EKS](security-iam.md).
+ Se desideri che il principale IAM che ha creato il cluster o qualsiasi altro principale visualizzi le risorse Kubernetes nella console Amazon EKS, concedi le [autorizzazioni necessarie](view-kubernetes-resources.md#view-kubernetes-resources-permissions) alle entità.
+ Se desideri che i nodi e i principali IAM accedano al cluster dall'interno della VPC, attiva l'endpoint privato per il cluster. L'endpoint pubblico è abilitato per impostazione predefinita. Puoi disabilitare l’endpoint pubblico dopo aver abilitato l’endpoint privato, se lo desideri. Per ulteriori informazioni, consulta [Endpoint del server API del cluster](cluster-endpoint.md).
+ [Abilitare la crittografia dei segreti per il cluster](enable-kms.md).
+ [Configurare la registrazione per il cluster](control-plane-logs.md).
+ [Aggiungi nodi al cluster](eks-compute.md).
# Piano di controllo predisposto per Amazon EKS
## Panoramica di
Amazon EKS Provisioned Control Plane è una funzionalità che consente agli amministratori dei cluster di scegliere tra una serie di livelli di scalabilità e designare il livello prescelto per prestazioni molto elevate e prevedibili dal piano di controllo del cluster. Ciò consente agli amministratori del cluster di garantire che il piano di controllo sia sempre dotato della capacità specificata.
Amazon EKS offre due modalità operative per il piano di controllo del cluster. Per impostazione predefinita, i cluster Amazon EKS utilizzano la **modalità Standard**, in cui il piano di controllo si ridimensiona automaticamente verso l'alto e verso il basso in base alle richieste del carico di lavoro. La modalità Standard alloca dinamicamente una capacità del piano di controllo sufficiente a soddisfare le esigenze di carico di lavoro ed è la soluzione consigliata per la maggior parte dei casi d'uso. **Tuttavia, per carichi di lavoro specializzati che non possono tollerare alcuna variabilità delle prestazioni dovuta alla scalabilità del piano di controllo o che richiedono quantità molto elevate di capacità del piano di controllo, è possibile utilizzare facoltativamente la modalità Provisioned.** La modalità Provisioned consente di preallocare la capacità del piano di controllo che è sempre pronta a gestire requisiti di carico di lavoro impegnativi.
**Nota**
La modalità Provisioned è una modalità operativa del piano di controllo aggiuntiva rispetto alla modalità Standard predefinita. L'introduzione della modalità Provisioned non modifica il comportamento della modalità Standard.
Con EKS Provisioned Control Plane, gli amministratori del cluster possono predisporre in anticipo la capacità desiderata del piano di controllo, fornendo prestazioni prevedibili e elevate dal piano di controllo del cluster, sempre disponibile. EKS Provisioned Control Plane consente inoltre agli amministratori del cluster di fornire la stessa capacità del piano di controllo in tutti gli ambienti, dallo staging ai siti di produzione e di disaster recovery. Questo è importante per garantire che le prestazioni del piano di controllo ottenute in tutti gli ambienti siano coerenti e prevedibili. Infine, EKS Provisioned Control Plane consente di accedere a livelli molto elevati di prestazioni del piano di controllo, consentendo l'esecuzione di carichi di lavoro di intelligenza artificiale estremamente scalabili, elaborazione ad alte prestazioni e carichi di lavoro di elaborazione dati su larga scala su Kubernetes.
Per impostazione predefinita, tutti i cluster Amazon EKS nuovi e esistenti funzionano in modalità Standard. Per i cluster che richiedono prestazioni elevate e prevedibili dal piano di controllo, puoi scegliere di utilizzare la funzione EKS Provisioned Control Plane. Ti verrà fatturata la tariffa oraria per il particolare livello di scalabilità del Control Plane, oltre alle tariffe orarie EKS per il supporto standard o esteso. Per ulteriori informazioni sui prezzi, consulta i [prezzi di Amazon EKS](https://aws.amazon.com/eks/pricing/).
![\[Modalità del piano di controllo di Amazon EKS\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/control-plane-modes.png)
## Casi d’uso
EKS Provisioned Control Plane è progettato per affrontare scenari specifici in cui prestazioni elevate e prevedibili del piano di controllo sono fondamentali per le operazioni. La comprensione di questi casi d'uso può aiutarvi a determinare se EKS Provisioned Control Plane è la soluzione giusta per i vostri carichi di lavoro.
Carichi di **lavoro critici per le prestazioni: per i carichi** di lavoro che richiedono una latenza minima e le massime prestazioni dal piano di controllo Kubernetes, EKS Provisioned Control Plane offre una capacità che elimina la variabilità delle prestazioni con la scalabilità del piano di controllo.
Carichi di **lavoro estremamente scalabili: se esegui carichi** di lavoro altamente scalabili come l'addestramento e l'inferenza basati sull'intelligenza artificiale, l'elaborazione ad alte prestazioni o l'elaborazione di dati su larga scala che richiedono un gran numero di nodi in esecuzione nel cluster, Provisioned Control Plane fornisce la capacità del piano di controllo necessaria per supportare questi carichi di lavoro impegnativi.
**Eventi previsti ad alta richiesta**: quando si prevede un improvviso aumento delle richieste di control plane a causa di un evento imminente, come vendite o promozioni di e-commerce, lanci di prodotti, periodi di shopping natalizio o importanti eventi sportivi o di intrattenimento, Provisioned Control Plane consente di scalare in anticipo la capacità del piano di controllo. Questo approccio proattivo assicura che il piano di controllo sia pronto a gestire l'aumento del carico senza attendere che la scalabilità automatica risponda alla domanda.
**Coerenza dell'ambiente**: Provisioned Control Plane consente di abbinare la capacità e le prestazioni del piano di controllo negli ambienti di staging e produzione, aiutando a identificare potenziali problemi prima dell'implementazione in produzione. Mantenendo lo stesso livello del piano di controllo in tutti gli ambienti, è possibile garantire che i risultati dei test riflettano accuratamente il comportamento di produzione, riducendo il rischio di sorprese legate alle prestazioni durante l'implementazione.
**Disaster recovery e business continuity**: per gli scenari di disaster recovery, Provisioned Control Plane consente di effettuare il provisioning di ambienti di failover con lo stesso livello di capacità dell'ambiente primario. Ciò garantisce interruzioni minime e un ripristino rapido durante gli eventi di failover, poiché il cluster di disaster recovery avrà caratteristiche prestazionali del piano di controllo identiche a quelle del cluster di produzione dal momento in cui viene attivato.
## Control Plane Scaling Tiers
EKS Provisioned Control Plane offre livelli di scalabilità denominati utilizzando le taglie delle t-shirt (XL, 2XL, 4XL e 8XL). Ogni livello definisce la propria capacità attraverso tre attributi chiave di Kubernetes che determinano le caratteristiche prestazionali del piano di controllo del cluster. La comprensione di questi attributi consente di selezionare il livello appropriato per i requisiti del carico di lavoro.
La **concorrenza delle richieste API** misura il numero di richieste che il server API del piano di controllo Kubernetes può elaborare contemporaneamente, il che è fondamentale per carichi di lavoro con throughput elevato.
La **frequenza di pianificazione dei pod indica la velocità con cui lo scheduler** Kubernetes predefinito può pianificare i pod sui nodi, misurata in pod al secondo.
La **dimensione del database del cluster** indica lo spazio di archiviazione allocato a etcd, il database che contiene lo stato/i metadati del cluster.
Quando si effettua il provisioning del piano di controllo del cluster su un determinato livello di scalabilità utilizzando Provisioned Control Plane, EKS garantisce che il piano di controllo del cluster mantenga i limiti corrispondenti a tale livello. I limiti dei livelli di scalabilità del piano di controllo variano in base alla versione di Kubernetes, come illustrato nelle tabelle seguenti.
### EKS v1.28 e v1.29
| Livello di scalabilità del piano di controllo fornito | Concorrenza delle richieste API (postazioni) | Velocità di pianificazione dei pod (pods/sec) | Dimensioni del database del cluster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8 XL | 13600 | 100 | 16 |
### EKS v1.30 e versioni successive
| Provisioned Control Plane Scaling Tier | Concorrenza delle richieste API (postazioni) | Velocità di pianificazione dei pod (pods/sec) | Dimensioni del database del cluster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2XL | 3400 | 283 | 16 |
| 4 XL | 6800 | 400 | 16 |
| 8 XL | 13600 | 400 | 16 |
### Monitoraggio del piano di controllo, scalabilità dell'utilizzo dei livelli
Amazon EKS fornisce diverse metriche per aiutarti a monitorare l'utilizzo dei livelli del piano di controllo. Queste metriche sono pubblicate come [ CloudWatch metriche Amazon](cloudwatch.md) e sono accessibili tramite la CloudWatch console EKS. [Inoltre, queste metriche possono essere recuperate dall'endpoint Prometheus del cluster EKS (vedi qui).](prometheus.md)
| | **Metrica Prometheus** | **CloudWatch Parametro** |
| --- | --- | --- |
| **Concorrenza delle richieste API** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **Frequenza di pianificazione del pod** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total, scheduler\$1schedule\$1attempts\$1scheduled, scheduler\$1schedule\$1attempts\$1unschedulable |
| **Dimensioni del database del cluster** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
Puoi visualizzare l'utilizzo del piano di controllo nella console Amazon EKS. Dalla pagina di panoramica del cluster, scegli **Monitor cluster** per accedere alla dashboard di osservabilità, quindi seleziona la scheda **Control plane monitoring** per visualizzare l'utilizzo del piano di controllo nella sezione **Control plane** scaling.
![\[Monitora il cluster EKS\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/monitor-cluster.png)
![\[Monitoraggio del piano di controllo EKS\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/control-plane-monitoring.png)
### Comprensione della capacità di Tier rispetto alle prestazioni effettive
Quando selezioni un livello di scalabilità Provisioned Control Plane, gli attributi del livello rappresentano le configurazioni sottostanti che Amazon EKS applica al tuo piano di controllo. Tuttavia, le prestazioni effettive ottenute dipendono dai modelli di carico di lavoro specifici, dalle configurazioni e dall'aderenza alle best practice di Kubernetes. Ad esempio, mentre un livello 4XL configura API Priority and Fairness (APF) con 6.800 postazioni di richieste simultanee, la velocità effettiva delle richieste ottenuta dal piano di controllo dipende dai tipi di operazioni eseguite. [Ad esempio, Kubernetes penalizza le richieste di elenco più di quelle get, e quindi il numero effettivo di richieste di elenco elaborate contemporaneamente dal piano di controllo è inferiore alle richieste get (vedi qui).](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness) Allo stesso modo, sebbene lo scheduler predefinito QPS sia impostato su 400 per un livello 4XL, la velocità di pianificazione effettiva dei pod dipende da fattori come la disponibilità e l'integrità dei nodi per la pianificazione. Per ottenere prestazioni ottimali, assicurati che le tue applicazioni seguano le best practice di Kubernetes (vedi [qui](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)) e siano configurate correttamente per le caratteristiche del tuo carico di lavoro.
## Considerazioni
+ **Capacità del piano di controllo standard**: la modalità del piano di controllo standard di EKS offre il miglior rapporto prezzo/prestazioni ed è l'opzione consigliata per la maggior parte dei casi d'uso. Tuttavia, per carichi di lavoro specializzati che non possono tollerare alcuna variabilità delle prestazioni dovuta alla scalabilità del piano di controllo o che richiedono quantità molto elevate di capacità del piano di controllo, è possibile prendere in considerazione l'utilizzo della modalità Provisioned.
+ [È **richiesto il consenso esplicito**: i cluster esistenti non passeranno automaticamente dal piano di controllo Standard a un livello EKS Provisioned Control Plane più costoso.](https://aws.amazon.com/eks/pricing/) È necessario attivare esplicitamente uno dei nuovi livelli di scalabilità EKS Provisioned Control Plane.
+ **Restrizione all'uscita: la** modalità piano di controllo standard supporta fino a 8 GB di dimensioni del database cluster (etcd). Se la dimensione del database del cluster supera gli 8 GB durante l'utilizzo della modalità Provisioned, non è possibile tornare alla modalità Standard finché non si riducono le dimensioni del database al di sotto di 8 GB. Ad esempio, se si utilizzano 14 GB di storage del database in modalità Provisioned, è necessario innanzitutto ridurre l'utilizzo del database a meno di 8 GB prima di tornare alla modalità Standard.
+ **Nessuna scalabilità automatica dei livelli**: EKS Provisioned Control Plane non esegue automaticamente la scalabilità tra i livelli. Una volta selezionato un livello di scalabilità, il piano di controllo del cluster rimane fissato a quel livello, garantendo prestazioni coerenti e prevedibili. Tuttavia, avete la flessibilità necessaria per implementare la vostra soluzione di scalabilità automatica monitorando le metriche di utilizzo dei livelli e utilizzando l'EKS Provisioned Control Plane APIs per scalare verso l'alto o verso il basso quando queste metriche superano le soglie definite, offrendovi il pieno controllo sulla strategia di scalabilità e sull'ottimizzazione dei costi.
+ **Visualizzazione del livello corrente**: puoi utilizzare la console Amazon EKS, l'interfaccia a riga di comando di Amazon Web Services o l'API per visualizzare l'attuale livello di scalabilità del piano di controllo. Nella CLI, puoi eseguire il `describe-cluster` comando: `aws eks describe-cluster --name cluster-name`
+ **Tempo di transizione dei livelli**: puoi utilizzare la console Amazon EKS, Amazon EKS APIs o la CLI per uscire o passare da un livello di scalabilità all'altro. Amazon EKS ha introdotto un nuovo tipo di aggiornamento del cluster chiamato`ScalingTierConfigUpdate`, che puoi ispezionare per monitorare l'avanzamento della transizione. Dopo aver eseguito un comando di cambio di livello, puoi elencare gli aggiornamenti sul cluster per visualizzare un nuovo aggiornamento di tipo `ScalingTierConfigUpdate` con stato`Updating`. Lo stato cambia `Successful` al termine dell'aggiornamento o in `Failed` caso di errore. Il campo di errore nell'aggiornamento indica il motivo dell'errore. Non ci sono restrizioni sulla frequenza con cui è possibile passare da un livello all'altro. Il completamento della modifica del livello del piano di controllo richiede diversi minuti. Non vi sono tempi di inattività del server API durante questo processo, poiché EKS attiva nuovi server API prima di terminare quelli vecchi.
+ **Selezione del livello ottimale**: per determinare il livello di scalabilità Provisioned Control Plane ottimale per il cluster, è possibile eseguire test di carico effettuando il provisioning del cluster sul livello più alto (8XL). Quindi esegui un test di carico per simulare la domanda di picco sul piano di controllo del cluster. Osservate le metriche di utilizzo del livello di control plane al picco di carico e utilizzate queste osservazioni come fattore guida per selezionare il livello appropriato per la modalità Provisioned.
+ **Prezzi Provisioned Control Plane**: ti verrà addebitata la tariffa oraria per il livello di scalabilità Provisioned Control Plane in cui si trova il cluster. Questo si aggiunge alle tariffe orarie di supporto standard o esteso. Per ulteriori informazioni, consulta la [pagina](https://aws.amazon.com/eks/pricing/) dei prezzi di Amazon EKS.
+ **Livello di scalabilità più ampio**: se intendi eseguire il cluster su un livello di scalabilità superiore a 8XL, contatta il team dell'account di Amazon Web Services per ulteriori informazioni sui prezzi.
+ **Supporto per versioni e regioni di Kubernetes**: EKS Provisioned Control Plane è supportato in tutte le regioni commerciali di Amazon Web Services GovCloud e in Cina. Provisioned Control Plane funziona su EKS v1.28 e versioni successive.
# Guida introduttiva all'Amazon EKS Provisioned Control Plane
Questa guida illustra i passaggi per configurare e utilizzare EKS Provisioned Control Plane utilizzando AWS Console di gestione AWS CLI e.
## Prerequisiti
Prima di iniziare, assicurati di disporre dei seguenti elementi:
+ ** AWS CLI**: uno strumento da riga di comando per lavorare con AWS servizi, incluso Amazon EKS. Per ulteriori informazioni, consulta la *Guida per l'utente all'[installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) nell'interfaccia a riga di AWS comando*. Dopo aver installato la AWS CLI, ti consigliamo di configurarla anche. Per ulteriori informazioni, consulta [Configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella *Guida per l'utente dell'interfaccia a riga di AWS comando*. Nota che la AWS CLI v2 è necessaria per utilizzare l'opzione **update-kubeconfig** mostrata in questa pagina.
+ **Autorizzazioni IAM richieste**: il responsabile della sicurezza IAM che stai utilizzando deve disporre delle autorizzazioni per lavorare con i ruoli IAM di Amazon EKS, i ruoli collegati ai servizi AWS CloudFormation, un VPC e le risorse correlate. *Per ulteriori informazioni, consulta [Azioni](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) e [utilizzo dei ruoli collegati ai servizi nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) per l'utente IAM.* È necessario che tutti i passaggi di questa guida siano completati dallo stesso utente. Esegui il comando seguente per controllare l’utente corrente:
```
aws sts get-caller-identity
```
**Nota**
Ti consigliamo di completare la procedura descritta in questo argomento in una shell Bash. In alternativa, puoi apportare alcune modifiche alla tua shell per alcuni comandi di script, come i caratteri di continuazione della riga, e per il modo in cui le variabili vengono impostate e utilizzate. Inoltre, le regole di escape e di utilizzo delle virgolette per la shell (interprete di comandi) potrebbero essere diverse. Per ulteriori informazioni, consulta [Uso delle virgolette con le stringhe nella AWS CLI nella Guida](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) per l'utente dell'interfaccia a *riga di AWS comando*.
## Piano di controllo predisposto EKS - AWS CLI
### Crea cluster con EKS Provisioned Control Plane Scaling Tier
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
Risposta:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Visualizza il livello Control Plane Scaling del cluster
```
aws eks describe-cluster --name prod-cluster
```
Risposta:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Aggiorna il cluster per utilizzare EKS Provisioned Control Plane
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
Risposta:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### Visualizza l'aggiornamento di Control Plane Scaling
```
aws eks list-updates --name example
```
Risposta:
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### Uscire da Provisioned Control Plane a Standard Control Plane
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
Risposta:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## Piano di controllo predisposto EKS - Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli **Crea cluster**.
1. In *Opzioni di configurazione*, seleziona **Configurazione personalizzata**.
1. Scorri verso il basso fino al **livello di scalabilità del piano di controllo**. Seleziona **Usa un livello di scalabilità** per abilitare Provisioned Control Plane.
1. Seleziona il livello di scalabilità del piano di controllo che desideri fornire per il cluster tra varie opzioni di scaling tier come XL, 2XL, 4XL e 8XL.
1. Seleziona altre opzioni di configurazione del cluster in base alle esigenze. Nel passaggio finale seleziona **Crea cluster**. Nota che il completamento della creazione del cluster potrebbe richiedere alcuni minuti.
# Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster
Gli approfondimenti sui cluster di Amazon EKS rilevano i problemi e forniscono consigli per risolverli e gestire il cluster. Ogni cluster Amazon EKS è soggetto a controlli automatici e ricorrenti basati su un elenco di approfondimenti curato da Amazon EKS. Questi *controlli sugli approfondimenti* sono completamente gestiti da Amazon EKS e offrono consigli su come affrontare eventuali esiti.
## Tipi di approfondimenti del cluster
+ **Approfondimenti sulla configurazione**: identificano le configurazioni errate nella configurazione di nodi ibridi EKS che potrebbero compromettere la funzionalità del cluster o dei carichi di lavoro.
+ **Approfondimenti sugli aggiornamenti**: identificano i problemi che potrebbero influire sulla capacità di aggiornamento a nuove versioni di Kubernetes.
## Considerazioni
+ **Frequenza**: Amazon EKS aggiorna le informazioni sul cluster ogni 24 ore oppure è possibile aggiornarle manualmente per visualizzare lo stato più recente. Ad esempio, puoi aggiornare manualmente le informazioni sul cluster dopo aver risolto un problema per vedere se il problema è stato risolto.
+ **Autorizzazioni**: Amazon EKS crea automaticamente una voce di accesso al cluster per le informazioni sui cluster in ogni cluster EKS. Questa voce concede l’autorizzazione a EKS per visualizzare le informazioni relative al cluster. Amazon EKS utilizza queste informazioni per generare approfondimenti. Per ulteriori informazioni, consulta [Amazon EKSCluster InsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy).
## Casi d’uso
Gli approfondimenti sui cluster in Amazon EKS forniscono controlli automatizzati per aiutare a mantenere l’integrità, l’affidabilità e la configurazione ottimale dei cluster Kubernetes. Di seguito sono riportati i principali casi d’uso degli approfondimenti sui cluster, tra cui la preparazione all’aggiornamento e la risoluzione dei problemi di configurazione.
### Approfondimenti sugli aggiornamenti
Gli approfondimenti sugli aggiornamenti sono un tipo specifico di controlli approfonditi all’interno degli approfondimenti del cluster. Questi controlli restituiscono approfondimenti riguardanti la preparazione all’aggiornamento della versione di Kubernetes. Amazon EKS esegue controlli approfonditi sugli aggiornamenti su ogni cluster EKS.
**Importante**
Amazon EKS ha temporaneamente eseguito il rollback di una funzionalità che richiedeva l’utilizzo di un flag `--force` per aggiornare il cluster in caso di determinati problemi di approfondimenti sul cluster. Per ulteriori informazioni, consulta [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570) su GitHub.
Per ulteriori informazioni sull’aggiornamento del cluster, consulta [Fase 3: aggiornamento del piano di controllo del cluster](update-cluster.md#update-cluster-control-plane).
Prima di aggiornare la versione di Kubernetes del cluster, puoi utilizzare la scheda **Approfondimenti sugli aggiornamenti** della dashboard di osservabilità nella [console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). Se il cluster ha identificato problemi, consultali e apporta le correzioni appropriate. I problemi includono collegamenti alla documentazione di Amazon EKS e Kubernetes. Dopo aver risolto il problema, aggiornare gli aggiornamenti sui cluster su richiesta per recuperare gli approfondimenti più recenti. Se tutti i problemi sono stati risolti, [aggiorna il cluster](update-cluster.md).
Amazon EKS restituisce approfondimenti riguardanti la preparazione all’aggiornamento della versione di Kubernetes. Gli approfondimenti sugli aggiornamenti identificano possibili problemi che possono influire sugli aggiornamenti del cluster di Kubernetes. Questo riduce l’impegno richiesto agli amministratori nella preparazione degli aggiornamenti e aumenta l’affidabilità delle applicazioni sulle versioni più recenti di Kubernetes. I cluster vengono scansionati automaticamente da Amazon EKS in base a un elenco di possibili aggiornamenti di versione di Kubernetes che influiscono sui problemi. Amazon EKS aggiorna frequentemente l’elenco dei controlli sugli approfondimenti in base alle revisioni delle modifiche apportate in ogni versione di Kubernetes.
Gli approfondimenti sugli aggiornamenti offerti da Amazon EKS velocizzano il processo di test e verifica per le nuove versioni. Inoltre, consentono agli amministratori dei cluster e agli sviluppatori di applicazioni di avvalersi delle funzionalità di Kubernetes più recenti, evidenziando eventuali problemi e offrendo consigli per porvi rimedio.
### Approfondimenti sulla configurazione
Gli approfondimenti sui cluster di EKS analizzano automaticamente i cluster di Amazon EKS con nodi ibridi per identificare problemi di configurazione che compromettono la comunicazione tra piano di controllo e webhook di Kubernetes, comandi kubectl come exec e logs, e altro ancora. Gli approfondimenti sulla configurazione evidenziano i problemi e forniscono consigli per la correzione, accelerando i tempi per una configurazione di nodi ibridi perfettamente funzionante.
## Inizia a usare
Per visualizzare l’elenco dei controlli sugli approfondimenti eseguiti e gli eventuali problemi rilevanti identificati da Amazon EKS, puoi usare Console di gestione AWS, AWS CLI, AWS SDK e l’operazione dell’API `ListInsights` di Amazon EKS. Per iniziare, consulta [Visualizzazione degli approfondimenti sui cluster](view-cluster-insights.md).
# Visualizzazione degli approfondimenti sui cluster
Amazon EKS fornisce due tipi di approfondimenti: **Approfondimenti sulla configurazione** e **Approfondimenti sugli aggiornamenti**. **Gli approfondimenti sulla configurazione** identificano le configurazioni errate nella configurazione di nodi ibridi EKS che potrebbero compromettere la funzionalità del cluster o dei carichi di lavoro. **Gli approfondimenti sugli aggiornamenti** identificano i problemi che potrebbero influire sulla capacità di aggiornamento a nuove versioni di Kubernetes.
Per visualizzare l'elenco dei controlli approfonditi eseguiti e gli eventuali problemi rilevanti identificati da Amazon EKS, puoi chiamare il look in the Console di gestione AWS, la AWS CLI e il funzionamento AWS SDKs dell'`ListInsights`API Amazon EKS.
## Visualizzare approfondimenti sulla configurazione (console)
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dall'elenco dei cluster, scegli il nome del cluster Amazon EKS per il quale desideri visualizzare gli approfondimenti.
1. Scegli **Monitora cluster**.
1. Scegli la scheda **Integrità del cluster**.
1. Nella tabella **Approfondimenti sulla configurazione**, vedrai le seguenti colonne:
+ **Nome**: il controllo eseguito da Amazon EKS sul cluster.
+ **Stato di approfondimento**: un approfondimento con stato `Error` indica una configurazione errata che potrebbe influire sulla funzionalità del cluster. Un approfondimento con uno stato `Warning` indica che la configurazione non corrisponde all’approccio documentato, ma che la funzionalità del cluster potrebbe funzionare se configurata intenzionalmente. Un approfondimento con lo stato `Passing` indica che Amazon EKS non ha riscontrato alcun problema associato a questo controllo sull’approfondimento nel cluster.
+ **Versione**: la versione applicabile.
+ **Ora dell’ultimo aggiornamento**: l’ora in cui lo stato dell’approfondimento è stato aggiornato l’ultima volta per questo cluster.
+ **Descrizione**: informazioni tratte dal controllo sull'approfondimento, che include l'avviso e le azioni consigliate per la correzione.
## Visualizzare gli approfondimenti sugli aggiornamenti (console)
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dall'elenco dei cluster, scegli il nome del cluster Amazon EKS per il quale desideri visualizzare gli approfondimenti.
1. Scegli **Monitora cluster**.
1. Scegli la scheda **Approfondimenti sugli aggiornamenti**.
1. Per visualizzare i dati più recenti, scegli il pulsante **Aggiorna approfondimenti** e attendi il completamento dell’operazione di aggiornamento.
1. Nella tabella **Approfondimenti sugli aggiornamenti**, vedrai le seguenti colonne:
+ **Nome**: il controllo eseguito da Amazon EKS sul cluster.
+ **Stato dell’approfondimento**: un approfondimento che presenta lo stato “Errore” in genere indica che la versione di Kubernetes interessata è N\$11 rispetto alla versione corrente del cluster, mentre lo stato “Avviso” indica che l’approfondimento si applica a una versione di Kubernetes futura N\$12 o superiore. Un approfondimento con lo stato "Ammesso" indica che Amazon EKS non ha riscontrato alcun problema associato a questo controllo sull'approfondimento nel cluster. Lo stato dell'approfondimento "Sconosciuto" significa che Amazon EKS non è in grado di determinare se il cluster è interessato da questo controllo sull'approfondimento.
+ **Versione**: la versione di Kubernetes che l’approfondimento ha verificato per individuare possibili problemi.
+ **Ora dell’ultimo aggiornamento**: l’ora in cui lo stato dell’approfondimento è stato aggiornato l’ultima volta per questo cluster.
+ **Ora dell’ultima transizione**: l’ora in cui lo stato di questo approfondimento è cambiato l’ultima volta.
+ **Descrizione**: informazioni tratte dal controllo sull'approfondimento, che include l'avviso e le azioni consigliate per la correzione.
## Visualizza informazioni dettagliate sul cluster (AWS CLI)
1. Utilizza gli approfondimenti per un cluster specificato per visualizzare i dati più recenti. Apporta le seguenti modifiche al comando, se necessario, quindi esegui il comando modificato:
+ Sostituiscilo *region-code* con il codice della tua AWS regione.
+ Sostituisci *my-cluster* con il nome del cluster.
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. Esegui il comando seguente per tenere traccia dello stato di un aggiornamento di approfondimenti. Sostituisci *my-cluster* con il nome del cluster.
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
Di seguito viene riportato un output di esempio.
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. Elenca gli approfondimenti per un cluster specificato. Apporta le seguenti modifiche al comando, se necessario, quindi esegui il comando modificato:
+ Sostituiscilo *region-code* con il codice AWS della tua regione.
+ Sostituisci *my-cluster* con il nome del cluster.
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
Di seguito viene riportato un output di esempio.
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. Esegui il comando seguente per visualizzare le informazioni dettagliate relative a un approfondimento. Apporta le seguenti modifiche al comando, se necessario, quindi esegui il comando modificato:
+ Sostituiscilo *region-code* con il codice AWS della tua regione.
+ *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222*Sostituiscilo con un ID di approfondimento recuperato dall'elenco degli approfondimenti del cluster.
+ Sostituisci *my-cluster* con il nome del cluster.
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
Di seguito viene riportato un output di esempio.
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# Aggiornamento del cluster esistente alla nuova versione di Kubernetes
**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.
Quando è disponibile una nuova versione di Kubernetes in Amazon EKS, è possibile aggiornare il cluster Amazon EKS alla versione più recente.
**Importante**
Una volta aggiornato un cluster, non è possibile effettuare il downgrade a una versione precedente. Prima di eseguire l’aggiornamento a una nuova versione di Kubernetes, consigliamo di esaminare le informazioni contenute in [Comprensione del ciclo di vita della versione di Kubernetes su EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) e nei passaggi di aggiornamento in questo argomento.
Le nuove versioni di Kubernetes hanno introdotto modifiche significative. Pertanto ti consigliamo di verificare il comportamento delle applicazioni rispetto alla nuova versione di Kubernetes prima di eseguire l'aggiornamento sui cluster di produzione. È possibile eseguire questa operazione mediante la creazione di un flusso di lavoro di integrazione continua per testare il comportamento totale dell'applicazione prima di passare a una nuova versione di Kubernetes.
Il processo di aggiornamento consiste nell'avvio, da parte di Amazon EKS, di nuovi nodi del server API con la versione aggiornata di Kubernetes per sostituire quelli esistenti. Amazon EKS esegue i controlli dell’integrità dell’infrastruttura standard e dello stato di preparazione per il traffico di rete su questi nuovi nodi per verificare che funzionino come previsto. Tuttavia, una volta avviato l’aggiornamento del cluster, non è possibile metterlo in pausa o interromperlo. Se uno di questi controlli non va a buon fine, Amazon EKS ripristina l'implementazione dell'infrastruttura e il cluster rimane nella versione precedente di Kubernetes. Le applicazioni in esecuzione non sono interessate e il cluster non è mai lasciato in uno stato non deterministico o irrecuperabile. Amazon EKS esegue regolarmente il backup di tutti i cluster gestiti e, se necessario, dispone di meccanismi per il recupero dei cluster. Stiamo valutando e migliorando costantemente i nostri processi di gestione dell’infrastruttura di Kubernetes.
Per aggiornare il cluster, Amazon EKS richiede fino a cinque indirizzi IP disponibili dalle sottoreti specificate al momento della creazione del cluster. Amazon EKS crea nuove interfacce di rete elastiche (interfacce di rete) per il cluster in una delle sottoreti specificate, che può essere diversa rispetto a quella in cui si trovano le interfacce di rete esistenti. Assicurati quindi che le regole del gruppo di sicurezza consentano la [comunicazione necessaria con il cluster](sec-group-reqs.md) per una delle sottoreti specificate al momento della creazione del cluster. Se nessuna delle sottoreti che hai specificato durante la creazione del cluster non esiste, se non hai abbastanza indirizzi IP disponibili o se non disponi di regole del gruppo di sicurezza per la comunicazione con il cluster, l’aggiornamento potrebbe non riuscire.
Per garantire che l’endpoint del server API per il tuo cluster sia sempre accessibile, Amazon EKS fornisce un’elevata disponibilità del piano di controllo Kubernetes ed esegue aggiornamenti continui delle istanze del server API durante le operazioni di aggiornamento. Per tenere conto della modifica degli indirizzi IP delle istanze del server API che supportano l’endpoint del server API Kubernetes, devi assicurarti che i client del tuo server API gestiscano le riconnessioni in modo efficace. Le versioni recenti di `kubectl` e le [librerie](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) di client Kubernetes sono ufficialmente supportati, esegui questo processo di riconnessione in modo trasparente.
**Nota**
Per ulteriori informazioni sui componenti di un aggiornamento del cluster, consulta [Best practice per gli aggiornamenti dei cluster](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) nella Guida alle best practice EKS. Questa risorsa consente di pianificare un aggiornamento e comprendere la strategia di aggiornamento di un cluster.
## Considerazioni per la modalità automatica di Amazon EKS
+ La funzionalità di elaborazione della modalità automatica di Amazon EKS controlla la versione di Kubernetes dei nodi. Dopo aver aggiornato il piano di controllo, modalità automatica EKS inizierà ad aggiornare in modo incrementale i nodi gestiti. Modalità automatica EKS rispetta i budget relativi alle interruzioni dei pod.
+ Non è necessario aggiornare manualmente le funzionalità di modalità automatica di Amazon EKS, incluse le funzionalità di scalabilità automatica di calcolo, archiviazione a blocchi e bilanciamento del carico.
## Riepilogo
Il riepilogo approfondito del processo di aggiornamento del cluster Amazon EKS è il seguente:
1. Assicurati che il cluster sia in uno stato che supporti un aggiornamento. Ciò include il controllo di Kubernetes APIs utilizzato dalle risorse distribuite nel cluster, per garantire che il cluster sia privo di problemi di salute. È necessario utilizzare gli approfondimenti sull’aggiornamento di Amazon EKS per valutare la preparazione all’aggiornamento del cluster.
1. Aggiorna il piano di controllo alla versione secondaria successiva (ad esempio, dalla 1.34 alla 1.35).
1. Aggiorna i nodi nel piano dati in modo che corrispondano a quelli del piano di controllo.
1. Aggiorna tutte le applicazioni aggiuntive eseguite sul cluster (ad esempio, `cluster-autoscaler`).
1. Esegui l’aggiornamento dei componenti aggiuntivi forniti da Amazon EKS, come quelli inclusi per impostazione predefinita:
+ [Versione consigliata di Amazon VPC CNI](managing-vpc-cni.md)
+ [Versione consigliata di CoredNS](managing-coredns.md)
+ [Versione suggerita `kube-proxy`](managing-kube-proxy.md)
1. Aggiorna tutti i client che comunicano con il cluster (ad esempio, `kubectl`).
## Passaggio 1: preparazione per l’aggiornamento
Confrontare la versione Kubernetes del piano di controllo cluster con la versione Kubernetes dei nodi.
+ Ottieni la versione di Kubernetes del piano di controllo del cluster.
```
kubectl version
```
+ Ottieni la versione di Kubernetes dei tuoi nodi. Questo comando restituisce tutti i nodi gestiti e autogestiti Amazon EC2, Fargate e ibridi. Ciascun pod Fargate è presente nell’elenco assieme al rispettivo nodo.
```
kubectl get nodes
```
Prima di aggiornare il piano di controllo a una nuova versione di Kubernetes, assicurarsi che la versione secondaria di Kubernetes dei nodi gestiti e dei nodi Fargate nel cluster sia la stessa versione del piano di controllo. Ad esempio, se il piano di controllo è in versione running `1.29` e uno dei nodi è in esecuzione`1.28`, è necessario aggiornare i nodi alla versione `1.29` prima di aggiornare il control plane alla 1.30. Prima di aggiornare il piano di controllo, si consiglia inoltre di aggiornare i nodi autogestiti e i nodi ibridi alla stessa versione del piano di controllo. Per ulteriori informazioni, consultare [Aggiornamento del gruppo di nodi gestito per il cluster](update-managed-node-group.md), [Aggiornamento dei nodi autogestiti per il tuo cluster](update-workers.md) e [Aggiornamento dei nodi ibridi per il tuo cluster](hybrid-nodes-upgrade.md). Se hai nodi Fargate con una versione secondaria inferiore rispetto alla versione del piano di controllo, devi prima eliminare il pod rappresentato dal nodo. a aggiornare il piano di controllo (control-plane). Tutti i pod rimanenti saranno aggiornati alla nuova versione dopo averli nuovamente implementati.
## Passaggio 2: esaminare le considerazioni sull’aggiornamento
Gli approfondimento sull’aggiornamento di Amazon EKS esegue automaticamente la scansione dei cluster e li mette a confronto con un elenco di potenziali problemi di aggiornamento della versione di Kubernetes, come l’utilizzo di API Kubernetes obsoleti. Amazon EKS aggiorna periodicamente l’elenco dei controlli approfonditi da eseguire in base alle valutazioni delle modifiche nel progetto Kubernetes. Amazon EKS aggiorna anche l’elenco dei controlli approfonditi man mano che sono introdotte modifiche nel servizio Amazon EKS insieme a nuove versioni. Per ulteriori informazioni, consulta [Prepararsi agli aggiornamenti delle versioni di Kubernetes e risolvere i problemi di configurazione errata con gli approfondimenti sui cluster](cluster-insights.md).
Esamina la [Guida alla migrazione delle API obsolete](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) nei documenti di Kubernetes.
### Esaminare gli approfondimenti sull’aggiornamento
Utilizza approfondimenti sull’aggiornamento di Amazon EKS per identificare i problemi. Per ulteriori informazioni, consulta [Visualizzare gli approfondimenti sugli aggiornamenti (console)](view-cluster-insights.md#view-upgrade-insights-console).
### Considerazioni dettagliate
+ Poiché Amazon EKS viene eseguito in un piano di controllo ad alta disponibilità, è possibile aggiornare solo una versione secondaria alla volta. Per ulteriori informazioni su questo requisito, consulta [Kubernetes Version and Version Skew Support Policy](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver) (Policy per la versione Kubernetes e il supporto Skew della versione). Supponiamo che la versione corrente del cluster sia `1.28` e che desideri aggiornarlo alla versione `1.30`. Devi prima aggiornare la versione `1.28` del cluster alla versione `1.29`, quindi aggiornare la versione `1.29` del cluster alla versione `1.30`.
+ Esamina la discrepanza di versione tra Kubernetes `kube-apiserver` e `kubelet` sui nodi.
+ A partire dalla versione `1.28` di Kubernetes, `kubelet` può essere fino a tre versioni minori precedenti rispetto a `kube-apiserver`. Consulta la sezione [Kubernetes upstream version skew policy](https://kubernetes.io/releases/version-skew-policy/#kubelet).
+ Se `kubelet` sui nodi gestiti e Fargate è nella versione di Kubernetes `1.25` o più recente, è possibile aggiornare il cluster fino a tre versioni successive senza aggiornare la versione di `kubelet`. Ad esempio, se `kubelet` è nella versione `1.25`, è possibile aggiornare la versione del cluster Amazon EKS dalla `1.25` alla `1.26`, `1.27` e `1.28` mentre `kubelet` rimane sulla versione `1.25`.
+ Come best practice prima di iniziare un aggiornamento, assicurati che `kubelet` sui nodi sia alla stessa versione di Kubernetes del tuo piano di controllo.
+ Se il cluster è configurato con una versione del plugin CNI di Amazon VPC per Kubernetes precedente a `1.8.0`, consigliamo di aggiornare il plugin all’ultima versione prima di aggiornare il cluster. Per aggiornare il plug-in, consulta [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md).
+ Puoi eseguire un backup del tuo cluster Amazon EKS, per consentirti di ripristinare lo stato del cluster Amazon EKS e lo storage persistente in caso di errori durante il processo di aggiornamento. Per informazioni, consultare [Backup dei cluster EKS con AWS Backup](integration-backup.md).
## Fase 3: aggiornamento del piano di controllo del cluster
**Importante**
Amazon EKS ha temporaneamente eseguito il rollback di una funzionalità che richiedeva l’utilizzo di un flag `--force` per aggiornare il cluster in caso di determinati problemi di approfondimenti sul cluster. Per ulteriori informazioni, consulta la sezione [Ripristino temporaneo dell'applicazione degli approfondimenti sull'aggiornamento della versione del cluster su](https://github.com/aws/containers-roadmap/issues/2570). GitHub
Amazon EKS aggiorna un approfondimento sul cluster 24 ore dopo “l’ultimo aggiornamento”. È possibile confrontare l’ora in cui hai risolto un problema con “l’ora dell’ultimo aggiornamento” dell’approfondimento sul cluster.
Inoltre, l’aggiornamento dello stato degli approfondimenti può richiedere fino a 30 giorni dopo la risoluzione dell’utilizzo di API obsolete. Gli approfondimenti sull’aggiornamento cercano sempre l’utilizzo di API obsolete in una finestra di 30 giorni consecutivi.
È possibile inviare la richiesta di aggiornamento della versione del tuo piano di controllo EKS utilizzando:
+ [eksctl](#step3-eksctl)
+ [la console AWS](#step3-console)
+ [la AWS CLI](#step3-cli)
### Aggiornare il cluster: eksctl
Questa procedura richiede `eksctl` versione `0.215.0` o successiva. È possibile verificare la versione con il comando seguente:
```
eksctl version
```
Per istruzioni sull'installazione e sull'aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.
Aggiorna la versione di Kubernetes del tuo piano di controllo di Amazon EKS. Sostituisci `` con il nome del cluster. Sostituisci `` con il numero di versione supportato da Amazon EKS a cui aggiornare il tuo cluster. Per l’elenco completo delle versioni supportate, consulta [Versioni supportate da Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
eksctl upgrade cluster --name --version --approve
```
Il processo di aggiornamento può richiedere alcuni minuti per il completamento.
Continua su [Fase 4: aggiornamento dei componenti del cluster](#step4).
### Aggiorna cluster - console AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli **Aggiorna ora** per un cluster che desideri aggiornare.
1. Seleziona la versione a cui aggiornare il cluster e scegli **Aggiorna**.
1. Il processo di aggiornamento può richiedere alcuni minuti per il completamento. Continua su [Fase 4: aggiornamento dei componenti del cluster](#step4).
### Aggiorna cluster - AWS CLI
1. Verifica che la AWS CLI sia installata e che tu abbia effettuato l'accesso. Per ulteriori informazioni, consulta [Installazione o aggiornamento alla versione più recente della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Aggiorna il tuo cluster Amazon EKS con il seguente AWS comando CLI. Sostituisci `` e `` del cluster che desideri aggiornare. Sostituisci `` con il numero di versione supportato da Amazon EKS a cui aggiornare il tuo cluster. Per l’elenco completo delle versioni supportate, consulta [Versioni supportate da Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
Di seguito viene riportato un output di esempio.
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. Il processo di aggiornamento può richiedere alcuni minuti per il completamento. É possibile monitorare lo stato di aggiornamento del cluster attraverso il seguente comando. Oltre a utilizzare gli stessi `` e ``, utilizza `` restituito dal comando precedente.
```
aws eks describe-update --name \
--region --update-id
```
Quando viene visualizzato lo stato `Successful`, l'aggiornamento è completo.
1. Continua su [Fase 4: aggiornamento dei componenti del cluster](#step4).
## Fase 4: aggiornamento dei componenti del cluster
1. Dopo che l'aggiornamento del cluster è completo, aggiornare i nodi di lavoro alla stessa versione secondaria di Kubernetes del cluster aggiornato. Per ulteriori informazioni, consultare [Aggiornamento dei nodi autogestiti per il tuo cluster](update-workers.md), [Aggiornamento del gruppo di nodi gestito per il cluster](update-managed-node-group.md) e [Aggiornamento dei nodi ibridi per il tuo cluster](hybrid-nodes-upgrade.md). Tutti i nuovi pod avviati in Fargate hanno una versione di `kubelet` che corrisponde alla versione del cluster. I pod Fargate esistenti non sono modificati.
1. (Facoltativo) Se è stato implementato Kubernetes Cluster Autoscaler nel cluster prima di aggiornarlo, aggiornare Cluster Autoscaler alla versione più recente che corrisponde alla versione principale e secondaria di Kubernetes per cui è stato eseguito l'aggiornamento.
1. Apri la pagina delle [versioni](https://github.com/kubernetes/autoscaler/releases) di Cluster Autoscaler in un browser Web e trova la versione più recente di Cluster Autoscaler corrispondente alla versione principale e secondaria di Kubernetes del cluster. Ad esempio, se la versione Kubernetes del cluster è `1.30`, cerca la versione più recente di Cluster Autoscaler che inizia con `1.30`. Registra il numero di versione semantica (`1.30.n`, ad esempio) per tale versione da utilizzare nella fase successiva.
1. Impostare il tag image di Cluster Autoscaler sulla versione registrata nella fase precedente mediante il comando seguente. Se necessario, sostituire `X.XX.X` con il valore in proprio possesso.
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (Solo cluster con nodi GPU) Se il tuo cluster ha gruppi di nodi con supporto GPU (ad esempio,`p3.2xlarge`), devi aggiornare il [plug-in del dispositivo NVIDIA per](https://github.com/NVIDIA/k8s-device-plugin) Kubernetes sul tuo cluster. DaemonSet Sostituiscilo `` con la versione di [s-device-pluginNVIDIA/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) desiderata prima di eseguire il comando seguente.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Aggiorna il plugin CNI di Amazon VPC per Kubernetes, CoredNS e componenti aggiuntivi `kube-proxy`. È preferibile aggiornare i componenti aggiuntivi alle versioni minime elencate nei [Token dell'account di servizio](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions).
+ Se stai utilizzando i componenti aggiuntivi di Amazon EKS, nella console Amazon EKS seleziona **Clusters** (Cluster), quindi seleziona il nome del cluster aggiornato nel riquadro di navigazione a sinistra. Le notifiche vengono visualizzate nella console Ti viene segnalato che è disponibile una nuova versione per ogni componente aggiuntivo per cui è disponibile un aggiornamento. Per aggiornare un componente aggiuntivo, seleziona la scheda **Add-ons** (Componenti aggiuntivi). In una delle caselle relative al componente aggiuntivo che dispone di un aggiornamento disponibile, selezionare **Aggiorna ora**, selezionare una versione disponibile e quindi selezionare **Aggiorna**.
+ In alternativa, puoi utilizzare la AWS CLI `eksctl` o aggiornare i componenti aggiuntivi. Per ulteriori informazioni, consulta [Aggiornamento di un componente aggiuntivo di Amazon EKS](updating-an-add-on.md).
1. Se necessario, aggiorna la tua versione di `kubectl`. Utilizza la versione secondaria `kubectl` immediatamente precedente a quella del piano di controllo del cluster Amazon EKS.
## Effettuare il downgrade della versione di Kubernetes di un cluster Amazon EKS
Non è possibile effettuare il downgrade di Kubernetes di un cluster Amazon EKS. Invece, crea un nuovo cluster su una versione precedente di Amazon EKS e migra i carichi di lavoro.
# Eliminazione di un cluster
Terminato l’utilizzo del cluster Amazon EKS, è necessario eliminare le risorse a esso associate per non dover sostenere costi superflui.
È possibile eliminare un cluster con `eksctl` Console di gestione AWS, o la AWS CLI.
## Considerazioni
+ Se viene visualizzato un errore in seguito alla rimozione del creatore del cluster, consultare [questo articolo](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error) per la risoluzione.
+ Le risorse del Servizio gestito da Amazon per Prometheus non rientrano nel ciclo di vita del cluster e devono essere gestite indipendentemente dal cluster. Quando si elimina il cluster, assicurarsi di eliminare anche tutti gli scraper applicabili per bloccare i relativi costi. Per ulteriori informazioni, consultare [Find and delete scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) nella *Guida per l’utente del Servizio gestito da Amazon per Prometheus*.
+ Per rimuovere un cluster connesso, consultare [Annullare la registrazione di un cluster Kubernetes dalla console Amazon EKS](deregister-connected-cluster.md)
+ Prima di poter eliminare un cluster, assicurati che la protezione da eliminazione sia disabilitata per il cluster.
### Considerazioni per la modalità automatica EKS
+ Eventuali nodi della modalità automatica EKS saranno eliminati, comprese le istanze gestite EC2.
+ Tutti i bilanciatori del carico saranno eliminati.
Per ulteriori informazioni, consulta [Disabilita modalità automatica di EKS](auto-disable.md).
## Prerequisiti
Di seguito sono riportati i passaggi da eseguire prima di poter eliminare un cluster. Questi passaggi si applicano indipendentemente dal metodo utilizzato per eliminare il cluster.
1. Elenca tutti i servizi in esecuzione nel cluster.
```
kubectl get svc --all-namespaces
```
1. Elimina i servizi che hanno un valore `EXTERNAL-IP` associato. Questi servizi sono anticipati da un Elastic Load Balancing, (load balancer) ed è necessario eliminarli in Kubernetes per consentire al sistema e alle risorse associate di essere rilasciate correttamente. Sostituisci *service-name* con il nome di ogni servizio elencato come descritto.
```
kubectl delete svc service-name
```
1. Elimina anche tutte le risorse in ingresso. Se non elimini le risorse in ingresso, l'application load balancer rimane attivo anche se hai eliminato il cluster. *ingress-name*Sostituiscilo con il nome delle tue risorse in ingresso.
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## Eliminare un cluster (eksctl)
Questa procedura richiede `eksctl` versione `0.215.0` o successiva. È possibile verificare la versione con il comando seguente:
```
eksctl version
```
Per istruzioni sull’installazione o sull’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.
1. Segui i passaggi [preliminari](#prerequisite-steps). Dopo averlo fatto, elimina il cluster e i nodi associati con il seguente comando, sostituendolo *prod* con il nome del cluster.
```
eksctl delete cluster --name prod
```
Output:
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## Elimina cluster (AWS console)
1. Segui i [passaggi preliminari](#prerequisite-steps). Dopo averlo fatto, elimina tutti i gruppi di nodi e i profili Fargate.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, scegli **Clusters** (Cluster) Amazon EKS, quindi nell'elenco a schede dei cluster scegli il nome del cluster da eliminare.
1. Seleziona la scheda **Compute** (Calcolo), quindi scegli un gruppo di nodi da eliminare. Scegli **Delete** (Elimina), immetti il nome del gruppo di nodi, quindi seleziona **Delete** (Elimina). Eliminare tutti i gruppi di nodi del cluster.
**Nota**
L'elenco presenta solo [gruppi di nodi gestiti](managed-node-groups.md).
1. Scegli un **profilo Fargate** da eliminare, seleziona **Delete** (Elimina), immetti il nome del profilo e infine scegli **Delete** (Elimina). Eliminare tutti i profili di Fargate nel cluster.
1. Elimina tutti gli stack di [nodi AWS CloudFormation autogestiti](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Apri la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Scegli lo stack del nodo da eliminare, quindi scegli **Elimina**.
1. Nella finestra di dialogo di conferma **Delete stack** (Elimina stack) scegliere **Delete stack**.(Elimina stack). Eliminare tutte le pile di nodi autogestiti nel cluster.
1. Eliminare il cluster.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Seleziona il cluster da eliminare e scegli **Delete** (Elimina).
1. Nella schermata di conferma dell'eliminazione del cluster, scegliere **Elimina**.
1. (Facoltativo) Eliminare lo stack VPC. AWS CloudFormation
1. Apri la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).
1. Selezionare lo stack del VPC da eliminare, quindi scegliere **Delete** (Elimina).
1. Nella finestra di dialogo di conferma **Delete stack** (Elimina stack) scegliere **Delete stack**.(Elimina stack).
## Elimina cluster (AWS CLI)
1. Segui i passaggi [preliminari](#prerequisite-steps). Dopo averlo fatto, elimina tutti i gruppi di nodi e i profili Fargate.
1. Elencare i gruppi di nodi nel cluster con il comando seguente.
```
aws eks list-nodegroups --cluster-name my-cluster
```
**Nota**
L'elenco presenta solo [gruppi di nodi gestiti](managed-node-groups.md).
1. Eliminare ogni gruppo di nodi con il comando seguente. Eliminare tutti i gruppi di nodi del cluster.
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. Elenca i proqfili Fargate nel cluster con il comando seguente.
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. Eliminare ogni profilo di Fargate con il comando seguente. Eliminare tutti i profili di Fargate nel cluster.
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. Elimina tutti gli stack di [nodi AWS CloudFormation autogestiti](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Elenca gli AWS CloudFormation stack disponibili con il seguente comando. Trovare il nome del modello del nodo nell'output risultante.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Elimina lo stack di ogni nodo con il seguente comando, sostituendo *node-stack* con il nome del tuo stack. Eliminare tutte le pile di nodi autogestiti nel cluster.
```
aws cloudformation delete-stack --stack-name node-stack
```
1. Elimina il cluster con il seguente comando, sostituendo *my-cluster* con il nome del tuo cluster.
```
aws eks delete-cluster --name my-cluster
```
1. (Facoltativo) Eliminare lo stack VPC. AWS CloudFormation
1. Elenca gli AWS CloudFormation stack disponibili con il seguente comando. Trovare il nome del modello di VPC nell'output risultante.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Elimina lo stack VPC con il seguente comando, sostituendo *my-vpc-stack* con il nome dello stack VPC.
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# Proteggi i cluster EKS dall’eliminazione accidentale
L’eliminazione accidentale di un cluster EKS può compromettere le operazioni del cluster Kubernetes.
Ora è possibile proteggere i cluster EKS dall’eliminazione accidentale. Se la protezione dall’eliminazione è abilitata su un cluster, prima di poterlo eliminare è necessario disabilitare tale protezione.
Lo scopo della protezione dall’eliminazione è prevenire gli incidenti. È necessario limitare attentamente gli utenti autorizzati a eliminare i cluster.
Se si cerca di eliminare un cluster attivo con la protezione dall’eliminazione attivata, si riceverà un’eccezione `InvalidRequestException`.
**Importante**
Se abiliti la protezione da eliminazione su un cluster, devi disporre **sia** delle UpdateClusterConfig autorizzazioni che di DeleteCluster IAM per rimuovere prima la protezione da eliminazione e infine eliminare il cluster.
**Nota**
Se lo stato del cluster è Creazione, Non riuscito o Eliminazione, è possibile eliminarlo anche se è attivata la protezione dall’eliminazione.
## Per abilitare la protezione dall’eliminazione per un cluster esistente
È possibile eseguire questo comando solo su un cluster con stato attivo.
```
aws eks update-cluster-config --name --region --deletion-protection
```
## Per disabilitare la protezione dall’eliminazione per un cluster esistente
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# Endpoint del server API del cluster
Questo argomento consente di abilitare l’accesso privato per l’endpoint del server API Kubernetes del cluster Amazon EKS e limitare, o disabilitare completamente, l’accesso pubblico in modo che non sia accessibile da Internet.
Quando si crea un nuovo cluster, Amazon EKS crea un endpoint per il server API Kubernetes gestito utilizzato per comunicare con il cluster (usando strumenti di gestione Kubernetes, ad esempio `kubectl`). [Per impostazione predefinita, questo endpoint del server API è pubblico su Internet e l'accesso al server API è protetto utilizzando una combinazione di AWS Identity and Access Management (IAM) e RBAC (Role Based Access Control) nativo di Kubernetes.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) Questo endpoint è noto come *l’endpoint pubblico del cluster*. Esiste anche un *endpoint privato del cluster*. Per maggiori informazioni sull’endpoint privato del cluster, consulta la sezione [Endpoint privato del cluster](#cluster-endpoint-private) seguente.
## formato dell’endpoint del cluster `IPv6`
EKS crea un endpoint dual-stack unico nel seguente formato per i nuovi cluster `IPv6` creati dopo ottobre 2024. Un *IPv6 cluster* è un cluster selezionato `IPv6` nell'impostazione della famiglia IP () del cluster. `ipFamily`
**Example**
public/private Endpoint del cluster EKS: `eks-cluster.region.api.aws`
public/private Endpoint del cluster EKS: `eks-cluster.region.api.aws`
public/private Endpoint del cluster EKS: `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**Nota**
L’endpoint del cluster dual-stack è stato introdotto nell’ottobre 2024. Per ulteriori informazioni sui cluster `IPv6`, consulta [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md). I cluster creati prima di ottobre 2024 usano invece il seguente formato di endpoint.
## formato dell’endpoint del cluster `IPv4`
EKS crea un endpoint unico nel seguente formato per ogni cluster che seleziona `IPv4` nell’impostazione della famiglia IP (ipFamily) del cluster:
**Example**
Endpoint del cluster public/private EKS `eks-cluster.region.eks.amazonaws.com`
Endpoint del cluster public/private EKS `eks-cluster.region.eks.amazonaws.com`
Endpoint del cluster public/private EKS `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**Nota**
Prima di ottobre 2024, anche i cluster `IPv6` usavano questo formato di endpoint. Per questi cluster, sia l’endpoint pubblico che l’endpoint privato dispongono solo di indirizzi `IPv4` risolti da questo endpoint.
## Endpoint privato del cluster
Puoi abilitare l’accesso privato al server API Kubernetes in modo che tutte le comunicazioni tra i nodi di lavoro e il server API rimangano all’interno del VPC. È possibile limitare gli indirizzi IP che possono accedere al server API da Internet o disabilitare completamente l’accesso a Internet al server API.
**Nota**
Poiché questo endpoint è destinato al server API Kubernetes e non a un AWS PrivateLink endpoint tradizionale per la comunicazione con un' AWS API, non viene visualizzato come endpoint nella console Amazon VPC.
Quando si abilita l’accesso privato all’endpoint per il cluster, Amazon EKS crea una zona ospitata privata Route 53 per conto dell’utente e la associa al VPC del cluster. Questa zona ospitata privata è gestita da Amazon EKS e non viene visualizzata nelle risorse Route 53 dell’account. Affinché la zona ospitata privata instradi correttamente il traffico verso il tuo server API, il VPC deve avere `enableDnsHostnames` e `enableDnsSupport` impostati su `true` e le opzioni DHCP impostate per il VPC devono includere `AmazonProvidedDNS` nell'elenco dei server dei nomi di dominio. Per ulteriori informazioni, consultare [Visualizzazione e aggiornamento del supporto DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) nella *Guida per l'utente di Amazon VPC*.
È possibile definire i requisiti di accesso all'endpoint del server API quando si crea un nuovo cluster e aggiornare l'accesso endpoint del server API per un cluster in qualsiasi momento.
## Modifica dell'accesso all'endpoint del cluster
Utilizza le procedure in questa sezione per modificare l'accesso all'endpoint per un cluster esistente. La tabella seguente mostra le combinazioni di accesso all'endpoint del server API supportate e il comportamento associato.
| Accesso pubblico all'endpoint | Accesso privato all'endpoint | Comportamento |
| --- | --- | --- |
| Abilitato | Disabilitato | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/cluster-endpoint.html) |
| Abilitato | Abilitato | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/cluster-endpoint.html) |
| Disabilitato | Abilitato | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/cluster-endpoint.html) |
**Controlli di accesso agli endpoint**
Tieni presente che ciascuno dei seguenti metodi per controllare l'accesso agli endpoint influisce solo sul rispettivo endpoint.
*Gruppo di sicurezza del cluster*
Il gruppo di sicurezza del cluster controlla due tipi di connessioni: connessioni all'*API Kubelet* e all'endpoint privato. Le connessioni all'`kubelet`API vengono utilizzate nei comandi`kubectl attach`,, `kubectl cp` `kubectl exec``kubectl logs`, e. `kubectl port-forward` Il gruppo di sicurezza del cluster non influisce sull'endpoint pubblico.
*Accesso pubblico CIDRs*
L'*accesso pubblico CIDRs* controlla l'accesso all'endpoint pubblico tramite un elenco di blocchi CIDR. Tieni presente che l'accesso pubblico CIDRs non influisce sull'endpoint privato. L'accesso pubblico CIDRs si comporta in modo diverso nei `IPv6` cluster e nei `IPv4` cluster a seconda della data di creazione, descritta di seguito:
**Blocchi CIDR nell’endpoint pubblico (cluster `IPv6`)**
Puoi aggiungere blocchi `IPv6` e `IPv4` CIDR all’endpoint pubblico di un cluster `IPv6`, in quanto l’endpoint pubblico è dual-stack. Questo vale solo per i nuovi cluster con `ipFamily` impostato su `IPv6` creati a ottobre 2024 o successivamente. Puoi identificare questi cluster in base al nuovo nome di dominio dell’endpoint `api.aws`.
**Blocchi CIDR nell’endpoint pubblico (cluster `IPv4`)**
Puoi aggiungere blocchi CIDR `IPv4` all’endpoint pubblico di un cluster `IPv4`. Non puoi aggiungere blocchi CIDR `IPv6` all’endpoint pubblico di un cluster `IPv4`. Se provi a farlo, EKS restituirà il seguente messaggio di errore: `The following CIDRs are invalid in publicAccessCidrs`
**Blocchi CIDR nell’endpoint pubblico (cluster `IPv6` creato prima di ottobre 2024)**
Puoi aggiungere blocchi CIDR `IPv4` all’endpoint pubblico dei cluster `IPv6` precedenti creati prima di ottobre 2024. Puoi identificare questi cluster in base all’endpoint `eks.amazonaws.com`. Non puoi aggiungere blocchi CIDR `IPv6` all’endpoint pubblico dei cluster `IPv6` precedenti creati prima di ottobre 2024. Se provi a farlo, EKS restituirà il seguente messaggio di errore: `The following CIDRs are invalid in publicAccessCidrs`
## Accesso a un server API solo privato
Se è stato disabilitato l’accesso pubblico all’endpoint del server API Kubernetes del cluster, è possibile accedere al server di API solo dal VPC o da una [rete connessa](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Di seguito sono elencati alcuni possibili modi per accedere all'endpoint del server API Kubernetes:
**Rete connessa**
È possibile connettere la rete al VPC con un [gateway di transito AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) o un'altra opzione di [connettività](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html) e quindi utilizzare un computer nella rete connessa. Il gruppo di sicurezza del piano di controllo di Amazon EKS deve contenere le regole per consentire il traffico in ingresso sulla porta 443 dalla rete connessa.
**Host Amazon EC2 Bastion**
Puoi avviare un' EC2 istanza Amazon in una sottorete pubblica nel VPC del cluster e quindi accedere tramite SSH a quell'istanza per eseguire i comandi. `kubectl` Per ulteriori informazioni, consultare [Bastion host Linux in AWS](https://aws.amazon.com/quickstart/architecture/linux-bastion/). Il gruppo di sicurezza del piano di controllo di Amazon EKS deve contenere le regole per consentire il traffico in ingresso sulla porta 443 dal bastion host. Per ulteriori informazioni, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md).
Quando esegui la configurazione `kubectl` per il tuo host bastion, assicurati di utilizzare AWS le credenziali già mappate alla configurazione RBAC del cluster oppure aggiungi il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che verrà utilizzato dal tuo bastion alla configurazione RBAC prima di rimuovere l'accesso pubblico agli endpoint. Per ulteriori informazioni, consultare [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md) e [Accesso negato o non autorizzato (`kubectl`)](troubleshooting.md#unauthorized).
** AWS Cloud9 IDE**
AWS Cloud9 è un ambiente di sviluppo integrato (IDE) basato su cloud che consente di scrivere, eseguire ed eseguire il debug del codice con un semplice browser. Puoi creare un IDE AWS Cloud9 nel VPC del cluster e utilizzare l'IDE per comunicare con il cluster. Per ulteriori informazioni, consulta [Creazione di un ambiente in AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html). È necessario assicurarsi che il gruppo di sicurezza del piano di controllo Amazon EKS contenga regole per consentire il traffico in ingresso sulla porta 443 dal gruppo di sicurezza IDE. Per ulteriori informazioni, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md).
Quando esegui la configurazione `kubectl` per il tuo AWS IDE Cloud9, assicurati di AWS utilizzare credenziali già mappate alla configurazione RBAC del cluster o aggiungi il principale IAM che l'IDE utilizzerà alla configurazione RBAC prima di rimuovere l'accesso pubblico agli endpoint. Per ulteriori informazioni, consultare [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md) e [Accesso negato o non autorizzato (`kubectl`)](troubleshooting.md#unauthorized).
[📝 Modifica questa pagina su GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# Configurare l’accesso di rete all’endpoint del server API del cluster
È possibile modificare l'accesso agli endpoint del server API del cluster utilizzando Console di gestione AWS o la AWS CLI nelle sezioni seguenti.
## Configura l'accesso agli endpoint - console AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegliere il nome del cluster per visualizzare le informazioni sul cluster.
1. Scegli la scheda **Networking** e scegli **Gestisci accesso all’endpoint**.
1. Per **Accesso privato**, scegli se attivare o disattivare l’acceso privato per l’endpoint del server API Kubernetes del cluster. Se abiliti l’accesso privato, le richieste API Kubernetes che provengono dal VPC del cluster utilizzano l’endpoint VPC privato. Per disabilitare l’accesso pubblico è necessario abilitare l’accesso privato.
1. Per **Accesso pubblico**, scegli se attivare o disattivare l’acceso pubblico per l’endpoint del server API Kubernetes del cluster. Se disabiliti l’accesso pubblico, il server API Kubernetes del cluster può ricevere solo richieste dal VPC del cluster.
1. (Facoltativo) Se abilitati l’**Accesso pubblico**, puoi specificare quali indirizzi Internet possono comunicare con l’endpoint pubblico. Seleziona **Impostazioni avanzate**. Immettere un blocco CIDR, ad esempio *203.0.113.5/32*. L’intervallo non può includere [indirizzi riservati](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Puoi immettere intervalli aggiuntivi selezionando **Aggiungi origine**. Puoi specificare un numero massimo di intervalli CIDR. Per ulteriori informazioni, consulta [Visualizzazione e gestione di quote di servizio di Amazon EKS e Fargate](service-quotas.md). Se non si specificano gli intervalli, l’endpoint del server API pubblico riceve richieste da tutti gli indirizzi IP sia per `IPv4` (`0.0.0.0/0`) che in aggiunta `IPv6` (`::/0`) per il cluster `IPv6` a doppio stack. Se limitati l’accesso all’endpoint pubblico utilizzando gli intervalli CIDR, ti consigliamo di abilitare anche l’accesso agli endpoint privati in modo che i nodi e Fargate Pods (se utilizzati) possano comunicare con il cluster. Senza l’endpoint privato abilitato, le origini CIDR dell’endpoint di accesso pubblico devono includere le origini di uscita dal VPC. Ad esempio, se si dispone di un nodo in una sottorete privata che comunica su Internet tramite un gateway NAT, sarà necessario aggiungere l’indirizzo IP in uscita del gateway NAT come parte di un blocco CIDR nella whitelist nell’endpoint pubblico.
1. Scegliere **Update (Aggiorna)** per terminare.
## Configurazione dell'accesso agli endpoint - AWS CLI
Completa i seguenti passaggi utilizzando la versione AWS CLI `1.27.160` o successiva. È possibile verificare la versione corrente con `aws --version`. Per installare o aggiornare la AWS CLI, vedi [Installazione della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Aggiorna l'accesso agli endpoint del server API del cluster con il seguente comando AWS CLI. Sostituire il nome del cluster e i valori di accesso dell’endpoint desiderati. Se si imposta `endpointPublicAccess=true`, è possibile (facoltativamente) immettere un singolo blocco CIDR o un elenco separato da virgole di blocchi CIDR per `publicAccessCidrs`. I blocchi non possono includere [indirizzi riservati](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Se si specificano blocchi CIDR, l’endpoint del server API pubblico riceverà solo le richieste dai blocchi elencati. Puoi specificare un numero massimo di intervalli CIDR. Per ulteriori informazioni, consulta [Visualizzazione e gestione di quote di servizio di Amazon EKS e Fargate](service-quotas.md). Se limiti l’accesso all’endpoint pubblico utilizzando i blocchi CIDR, è consigliabile abilitare anche l’accesso agli endpoint privati in modo che i nodi e i Pods Fargate (se utilizzati) possano comunicare con il cluster. Senza l’endpoint privato abilitato, le origini CIDR dell’endpoint di accesso pubblico devono includere le origini di uscita dal VPC. Ad esempio, se si dispone di un nodo in una sottorete privata che comunica su Internet tramite un gateway NAT, sarà necessario aggiungere l’indirizzo IP in uscita del gateway NAT come parte di un blocco CIDR nella whitelist nell’endpoint pubblico. Se non specifichi intervalli CIDR, l’endpoint del server API pubblico riceve richieste da tutti (0.0.0.0/0) gli indirizzi IP e in aggiunta `IPv6` (`::/0`) per il cluster `IPv6` a doppio stack.
**Nota**
Il comando seguente consente l’accesso privato e l’accesso pubblico da un singolo indirizzo IP per l’endpoint del server API. Sostituire *203.0.113.5/32* con un singolo blocco CIDR o un elenco separato da virgole di blocchi CIDR a cui si desidera limitare l'accesso alla rete.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
Di seguito viene riportato un output di esempio:
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. Monitorare lo stato di aggiornamento dell’accesso all’endpoint con il comando seguente, utilizzando il nome del cluster, e aggiornare l’ID restituito dal comando precedente. L’aggiornamento è completo quando lo stato è illustrato come `Successful`.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
Di seguito viene riportato un output di esempio.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [Modifica questa pagina su GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# Implementazione dei nodi Windows su cluster EKS
Informazioni su come abilitare e gestire il supporto Windows per i cluster Amazon EKS per l’esecuzione di container Windows insieme a container Linux.
## Considerazioni
Prima di implementare i nodi di Windows, tenere conto delle seguenti considerazioni.
+ La modalità automatica EKS non supporta i nodi Windows
+ Puoi utilizzare la rete host sui nodi Windows utilizzando i Pod `HostProcess` . Per ulteriori informazioni, consulta [Creare un Windows HostProcessPod nella documentazione](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) di Kubernetes.
+ I cluster Amazon EKS devono contenere uno o più nodi Linux o Fargate per eseguire i pod del sistema core che funzionano solo su Linux, come CoreDNS.
+ I log degli eventi `kubelet` e `kube-proxy` sono reindirizzati al log degli eventi `EKS Windows` e sono impostati su un limite di 200 MB.
+ Non è possibile utilizzare [Assegna gruppi di sicurezza a singoli pod](security-groups-for-pods.md) con i pod in esecuzione su nodi Windows.
+ Non è possibile utilizzare [reti personalizzate](cni-custom-network.md) con nodi Windows.
+ Non è possibile utilizzare `IPv6` con nodi Windows.
+ I nodi di Windows supportano un'interfaccia di rete elastica per nodo. Per impostazione predefinita, il numero di pod che è possibile eseguire per ogni nodo Windows è uguale al numero di indirizzi IP (meno uno) disponibili per interfaccia di rete elastica relativa al tipo di istanza del nodo. Per ulteriori informazioni, [consulta Indirizzi IP per interfaccia di rete per tipo di istanza](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) nella *Amazon EC2 User Guide*.
+ In un cluster Amazon EKS, un singolo servizio con un bilanciatore del carico può supportare fino a 1024 pod back-end. Ogni pod ha il proprio indirizzo IP univoco. Il limite precedente di 64 pod non è più valido, dopo un [aggiornamento di Windows Server](https://github.com/microsoft/Windows-Containers/issues/93) a partire da [Build del sistema operativo 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4).
+ I container Windows non sono supportati per i pod Amazon EKS su Fargate.
+ Non è possibile utilizzare Amazon EKS Hybrid Nodes con Windows come sistema operativo per l’host.
+ Non è possibile recuperare i log dal pod `vpc-resource-controller`. In precedenza era possibile quando si implementava il controller sul piano dati.
+ Esiste un periodo di raffreddamento prima che un indirizzo `IPv4` venga assegnato a un nuovo pod. In questo modo, si impedisce che il traffico vada verso un pod precedente con lo stesso indirizzo `IPv4` a causa della mancata validità delle regole `kube-proxy`.
+ L'origine del controller è gestita su GitHub. Per contribuire o segnalare problemi al controller, visita il [progetto](https://github.com/aws/amazon-vpc-resource-controller-k8s) su GitHub.
+ Quando specifichi un ID AMI personalizzato per i gruppi di nodi gestiti da Windows, aggiungilo `eks:kube-proxy-windows` alla mappa di configurazione di AWS IAM Authenticator. Per ulteriori informazioni, consulta [Limiti e condizioni quando si specifica un ID AMI](launch-templates.md#mng-ami-id-conditions).
+ Se la conservazione IPv4 degli indirizzi disponibili è fondamentale per la sottorete, consultate la [EKS Best Practices Guide - Windows Networking IP Address Management per una guida](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management).
+ Considerazioni relative a voci di accesso EKS
+ Le voci di accesso da utilizzare con i nodi Windows richiedono il tipo di `EC2_WINDOWS`. Per ulteriori informazioni, consulta [Creare voci di accesso](creating-access-entries.md).
Per creare una voce di accesso per un nodo Windows:
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/ --type EC2_Windows
```
## Prerequisiti
+ Un cluster esistente.
+ Il tuo cluster deve avere almeno un nodo Linux (ne consigliamo almeno due) o un pod Fargate per eseguire CoreDNS. Se si abilita il supporto Windows legacy, è necessario utilizzare un nodo Linux (non è possibile utilizzare un pod Fargate) per eseguire CoreDNS.
+ Un [ruolo IAM del cluster Amazon EKS](cluster-iam-role.md) esistente.
## Abilitazione del supporto Windows
1. Se non disponi di nodi Amazon Linux nel cluster e utilizzi gruppi di sicurezza per i pod, vai al passaggio successivo. Altrimenti, conferma che la policy gestita di `AmazonEKSVPCResourceController` è collegata al tuo [ruolo del cluster](cluster-iam-role.md). Sostituisci *eksClusterRole* con il nome del ruolo del cluster.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
Di seguito viene riportato un output di esempio:
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
Se la policy è collegata, come nell'output precedente, salta il passaggio successivo.
1. Collega la policy gestita di **[Amazon EKSVPCResource Controller](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html)** al tuo [ruolo IAM del cluster Amazon EKS](cluster-iam-role.md). Sostituisci *eksClusterRole* con il nome del ruolo del cluster.
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController
```
1. Aggiorna il VPC CNI ConfigMap per abilitare Windows IPAM. Nota, se il VPC CNI è installato sul tuo cluster utilizzando un grafico Helm o come componente aggiuntivo Amazon EKS, potresti non essere in grado di modificare direttamente il. ConfigMap Per informazioni sulla configurazione dei componenti aggiuntivi Amazon EKS, consulta [Determina i campi che puoi personalizzare per i componenti aggiuntivi Amazon EKS](kubernetes-field-management.md).
1. Crea un file denominato *vpc-resource-controller-configmap.yaml* con i seguenti contenuti.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. Applica la `ConfigMap` al cluster.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. Se il cluster ha la modalità di autenticazione impostata per abilitare configmap `aws-auth`:
+ Verifica che `aws-auth` `ConfigMap` contenga una mappatura per il ruolo di istanza del nodo Windows per includere il gruppo di autorizzazioni `eks:kube-proxy-windows` RBAC. Puoi eseguire la verifica eseguendo il comando seguente.
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
Di seguito viene riportato un output di esempio.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws: iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
Dovresti vedere `eks:kube-proxy-windows` elencato nei gruppi. Se il gruppo non è specificato, devi aggiornare `ConfigMap` o crearla per includere il gruppo richiesto. Per ulteriori informazioni su `aws-auth` `ConfigMap`, consulta [Applica la `aws-auth` `ConfigMap` al cluster](auth-configmap.md#aws-auth-configmap).
1. Se il cluster ha la modalità di autenticazione impostata per disabilitare configmap `aws-auth`, è possibile utilizzare le voci di accesso EKS. La creazione di un nuovo ruolo del nodo da utilizzare con le istanze Windows ed EKS creerà automaticamente una voce di accesso di tipo `EC2_WINDOWS`.
## Implementazione di pods Windows
Quando si implementano i pod nel cluster, è necessario specificare il sistema operativo utilizzato se si esegue una combinazione di tipi di nodi.
Per i pod Linux, utilizzare il seguente testo del selettore dei nodi nei manifesti.
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Per i pod Windows, utilizzare il seguente testo del selettore dei nodi nei manifesti.
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
È possibile implementare [un'applicazione di esempio](sample-deployment.md) per vedere i selettori dei nodi in uso.
## Supporto di maggiore densità di pod sui nodi di Windows
Su Amazon EKS a ciascun pod è assegnato un indirizzo `IPv4` dal tuo VPC. Per questo motivo, il numero di pod che è possibile distribuire su un nodo è vincolato agli indirizzi IP disponibili, anche se ci sono risorse sufficienti per eseguire più pod sul nodo. Poiché un nodo di Windows supporta una sola interfaccia di rete elastica, per impostazione predefinita, il numero massimo di indirizzi IP disponibili su un nodo di Windows è pari a:
```
Number of private IPv4 addresses for each interface on the node - 1
```
Un indirizzo IP è utilizzato come indirizzo IP principale dell’interfaccia di rete, quindi non può essere assegnato ai pod.
È possibile abilitare una maggiore densità di pod sui nodi Windows abilitando la delega del prefisso IP. Questa funzionalità consente di assegnare un prefisso`/28` `IPv4` all'interfaccia di rete principale, anziché assegnare indirizzi `IPv4` secondari. L'assegnazione di un prefisso IP aumenta il numero massimo di indirizzi `IPv4` disponibili sul nodo:
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
Con questo numero di indirizzi IP disponibili di gran lunga maggiore, gli indirizzi IP disponibili non dovrebbero limitare la capacità di scalare il numero di pod sui tuoi nodi. Per ulteriori informazioni, consulta [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md).
# Disabilitare il supporto Windows
1. Se il cluster contiene nodi Amazon Linux e si utilizzano [gruppi di sicurezza per i pod](security-groups-for-pods.md), saltare questo passaggio.
Rimuovi la policy IAM gestita `AmazonVPCResourceController` dal [ruolo del cluster](cluster-iam-role.md). Sostituire *eksClusterRole* con il nome del ruolo del cluster.
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. Disabilita Windows IPAM nella ConfigMap per `amazon-vpc-cni`.
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# Implementazione di cluster privati con accesso limitato a Internet
Questo argomento descrive come distribuire un cluster Amazon EKS distribuito sul AWS cloud, ma che non dispone di accesso a Internet in uscita. Se hai un cluster locale su AWS Outposts, consulta[Crea nodi Amazon Linux su AWS Outposts](eks-outposts-self-managed-nodes.md), invece di questo argomento.
Se non si ha dimestichezza con la rete Amazon EKS, consulta [Demistificare le reti cluster per i nodi nodo worker Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Se il cluster non dispone di accesso a Internet in uscita, deve soddisfare i seguenti requisiti:
## Requisiti dell’architettura del cluster
+ Il tuo cluster deve estrarre immagini da un registro di container che si trova nel tuo VPC. Puoi creare un Amazon Elastic Container Registry nel VPC e copiare al suo interno le immagini dei container per i nodi da cui estrarre. Per ulteriori informazioni, consulta [Copia di un'immagine di container da un repository a un altro](copy-image-to-repository.md).
+ Il tuo cluster deve avere l'accesso privato all'endpoint abilitato. Ciò è obbligatorio per la registrazione dei nodi con l'endpoint del cluster. L'accesso pubblico all'endpoint è facoltativo. Per ulteriori informazioni, consulta [Endpoint del server API del cluster](cluster-endpoint.md).
## Requisiti dei nodi
+ Prima di essere lanciati, i nodi Linux e Windows autogestiti devono includere i seguenti argomenti di bootstrap. Questi argomenti ignorano l’introspezione Amazon EKS e non richiedono l’accesso all’API Amazon EKS dal VPC.
1. Determina l’endpoint del cluster con il comando seguente. Sostituisci *my-cluster* con il nome del cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
Di seguito viene riportato un output di esempio.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Determina il valore dell’autorità di certificazione del cluster con il seguente comando. Sostituisci *my-cluster* con il nome del cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
L'output è una stringa molto lunga.
1. Sostituisci i valori di `apiServerEndpoint` e `certificateAuthority` nell' NodeConfig oggetto con i valori restituiti nell'output dei comandi precedenti. Per ulteriori informazioni sulla specificazione degli argomenti di bootstrap all'avvio di nodi Amazon Linux 2023 autogestiti, consulta e. [Crea nodi Amazon Linux autogestiti](launch-workers.md) [Crea nodi Microsoft Windows autogestiti](launch-windows-workers.md)
+ Per i nodi Linux:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
[Per ulteriori argomenti, consulta lo script bootstrap su.](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) GitHub
+ Per i nodi Windows:
**Nota**
Se utilizzi il servizio personalizzato CIDR, devi specificarlo utilizzando il parametro `-ServiceCIDR`. In caso contrario, la risoluzione DNS per i pod nel cluster avrà esito negativo.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Per ulteriori argomenti, consulta.[Parametri di configurazione dello script di bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ `aws-auth` `ConfigMap` del tuo cluster deve essere creata all’interno del tuo VPC. Per ulteriori informazioni sulla creazione e l'aggiunta di voci a `aws-auth` `ConfigMap`, digita `eksctl create iamidentitymapping --help` nel terminale. Se `ConfigMap` non esiste sul server, `eksctl` la creerà quando usi il comando per aggiungere una mappatura dell’identità.
## Requisiti del pod
+ **Pod Identity:** i pod configurati con EKS Pod Identity acquisiscono le credenziali dall’API EKS Auth. Se non è presente un accesso a Internet in uscita, è necessario creare e utilizzare un endpoint VPC per l’API EKS Auth: `com.amazonaws.region-code.eks-auth`. Per ulteriori informazioni sugli endpoint VCP EKS ed EKS Auth, consulta [Accesso ad Amazon EKS tramite AWS PrivateLink](vpc-interface-endpoints.md).
+ **IRSA** - I pod configurati con [ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md) acquisiscono le credenziali da una chiamata API AWS Security Token Service (AWS STS). Se non è disponibile un accesso a Internet in uscita, è necessario creare e utilizzare un endpoint VPC AWS STS nel VPC. La maggior parte AWS `v1` SDKs utilizza l'endpoint AWS STS globale di default (`sts.amazonaws.com`), che non utilizza l'endpoint VPC AWS STS. Per utilizzare l'endpoint VPC AWS STS, potrebbe essere necessario configurare l'SDK per utilizzare l'endpoint AWS STS regionale (). `sts.region-code.amazonaws.com` Per ulteriori informazioni, consulta [Configurare l’endpoint del Servizio di token di sicurezza AWS per un account di servizio](configure-sts-endpoint.md).
+ Le sottoreti VPC del cluster devono disporre di un endpoint di interfaccia VPC per tutti i AWS servizi a cui i Pod devono accedere. Per ulteriori informazioni, consulta [Accedere a un AWS servizio utilizzando un endpoint VPC di interfaccia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Nella tabella seguente sono elencati alcuni servizi ed endpoint di uso comune. Per un elenco completo degli endpoint, consulta [Servizi AWS che si integrano con AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) nella [Guida di AWS PrivateLink ](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Ti consigliamo di [abilitare i nomi DNS privati](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) per gli endpoint VPC, in modo che i carichi di lavoro possano continuare a utilizzare gli endpoint del AWS servizio pubblico senza problemi.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/private-clusters.html)
+ Qualsiasi nodo autogestito deve essere implementato in sottoreti con gli endpoint di interfaccia VPC richiesti. Se crei un gruppo di nodi gestiti, il gruppo di sicurezza dell'endpoint di interfaccia VPC deve consentire il CIDR per le sottoreti oppure dovrai aggiungere il gruppo di sicurezza del nodo creato al gruppo di sicurezza dell'endpoint di interfaccia VPC.
+ **Storage EFS**: se i tuoi pod utilizzano volumi Amazon EFS, prima di distribuire [Store, un file system elastico con Amazon EFS, devi modificare il file](efs-csi.md) [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) del driver per impostare le immagini del contenitore in modo che utilizzino la stessa regione del cluster Amazon EKS. AWS
+ Route53 non supporta. AWS PrivateLink Non è possibile gestire i record DNS di Route53 da un cluster Amazon EKS privato. Ciò ha un impatto su [external-dns](https://github.com/kubernetes-sigs/external-dns)di Kubernetes.
+ Se utilizzi l’AMI ottimizzata EKS, devi abilitare l’endpoint `ec2` nella tabella precedente. In alternativa, esiste la possibilità di impostare manualmente il nome DNS del nodo. L'AMI ottimizzata utilizza l'AMI EC2 APIs per impostare automaticamente il nome DNS del nodo.
+ Puoi utilizzare [AWS Load Balancer Controller](aws-load-balancer-controller.md) per distribuire AWS Application Load Balancer (ALB) e Network Load Balancer nel tuo cluster privato. Quando lo implementi, devi usare [i flag della riga di comando](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) per impostare`enable-shield`, `enable-waf` e `enable-wafv2` su fasle. Il [rilevamento dei certificati](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) con i nomi host degli oggetti in entrata non è supportato. Questo perché il controller deve raggiungere AWS Certificate Manager, che non dispone di un endpoint di interfaccia VPC.
Il controller supporta bilanciatori di carico di rete destinazioni IP, necessari per l'utilizzo con Fargate. Per ulteriori informazioni, consultare [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md) e [Creazione di un Network Load Balancer](network-load-balancing.md#network-load-balancer).
+ [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) è supportato. Quando si implementano i pod di Cluster Autoscaler, assicurarsi che la riga di comando includa `--aws-use-static-instance-list=true`. Per ulteriori informazioni, consulta [Use Static Instance List on](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list). GitHub Il VPC del nodo di lavoro deve includere anche l'endpoint VPC STS e l'endpoint AWS VPC con scalabilità automatica.
+ Alcuni prodotti software container utilizzano chiamate API che accedono al AWS Marketplace Metering Service per monitorare l'utilizzo. I cluster privati non consentono queste chiamate, pertanto questi tipi di container non possono essere utilizzati nei cluster privati.
# Dimensionamento dell’elaborazione dei cluster con Karpenter e Cluster Autoscaler
Il dimensionamento automatico è una funzione che dimensiona automaticamente in verticale e in orizzontale le risorse per soddisfare le esigenze in continua evoluzione. Questa è una delle principali funzioni Kubernetes, la cui esecuzione manuale richiederebbe altrimenti diverse risorse umane.
## EKS Auto Mode
EKS Auto Mode di Amazon dimensiona automaticamente le risorse di calcolo del cluster. Se un pod non può adattarsi ai nodi esistenti, EKS Auto Mode ne crea uno nuovo. EKS Auto Mode consolida anche i carichi di lavoro ed elimina i nodi. EKS Auto Mode si basa su Karpenter.
Per ulteriori informazioni, consultare:
+ [Automate cluster infrastructure with EKS Auto Mode](automode.md)
+ [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md)
+ [Implementazione di un esempio di carico di lavoro di decompressione in un cluster con modalità automatica di Amazon EKS](automode-workload.md)
## Ulteriori soluzioni
Amazon EKS supporta due ulteriori prodotti con dimensionamento automatico:
**Karpenter**
Karpenter è un Cluster Autoscaler Kubernetes flessibile e ad alte prestazioni che aiuta a migliorare la disponibilità delle applicazioni e l'efficienza del cluster. Karpenter avvia risorse di calcolo di dimensioni corrette, ad esempio le istanze di Amazon EC2, in risposta alla modifica del carico dell’applicazione in meno di un minuto. Integrando Kubernetes con AWS, Karpenter è in grado di effettuare il provisioning di risorse di calcolo just-in-time che soddisfano con precisione i requisiti del carico di lavoro. Karpenter effettua automaticamente il provisioning di nuove risorse di calcolo in base ai requisiti specifici dei carichi di lavoro del cluster. Questi includono requisiti di calcolo, archiviazione, accelerazione e pianificazione. Amazon EKS supporta i cluster che utilizzano Karpenter, anche se Karpenter funziona con qualsiasi cluster di Kubernetes conforme. Per ulteriori informazioni, consulta la [documentazione di Karpenter](https://karpenter.sh/docs/).
Karpenter è un software open source che i clienti AWS sono tenuti a installare, configurare e gestire nei propri cluster Kubernetes. AWS fornisce supporto tecnico quando Karpenter viene eseguito senza modifiche usando una versione compatibile nei cluster Amazon EKS. È fondamentale che i clienti mantengano la disponibilità e la sicurezza del controller Karpenter, nonché adeguate procedure di test quando lo aggiornano o aggiornano il cluster Kubernetes in cui è in esecuzione, proprio come qualsiasi altro software gestito dal cliente. Non esiste un accordo sul livello di servizio (SLA) AWS per Karpenter e i clienti sono responsabili di garantire che le istanze EC2 avviate da Karpenter soddisfino i loro requisiti aziendali.
**Cluster Autoscaler**
Il Cluster Autoscaler Kubernetes regola automaticamente il numero di nodi nel cluster quando i pod non riescono o vengono riprogrammati su altri nodi. Il Cluster Autoscaler utilizza i gruppi con scalabilità automatica. Per ulteriori informazioni consultare [Cluster Autoscaler su AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
# Ulteriori informazioni relative allo spostamento zonale in controller di ripristino delle applicazioni Amazon (ARC)
Kubernetes dispone di funzionalità native che consentono di rendere le applicazioni più resistenti a eventi come il deterioramento dello stato di integrità o il deterioramento di una zona di disponibilità (AZ). Quando esegui i carichi di lavoro in un cluster Amazon EKS, è possibile migliorare ulteriormente la tolleranza ai guasti e il ripristino delle applicazioni dell’ambiente applicativo utilizzando lo [spostamento zonale](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) o [lo spostamento zonale automatico](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html) del controller di ripristino delle applicazioni Amazon (ARC). Lo spostamento zonale ARC è progettato per essere una misura temporanea che consente di spostare il traffico di una risorsa lontano da una AZ interessata fino alla scadenza dello spostamento zonale o all’annullamento dello stesso. È possibile estendere lo spostamento zonale, se necessario.
Puoi avviare uno spostamento di zona per un cluster EKS oppure puoi consentire AWS di spostare il traffico per te abilitando lo spostamento automatico di zona. Questa modifica aggiorna il flusso del traffico di east-to-west rete nel cluster in modo da prendere in considerazione solo gli endpoint di rete per i Pod in esecuzione sui nodi di lavoro in condizioni di integrità. AZs Inoltre, qualsiasi ALB o NLB che gestisca il traffico in ingresso per le applicazioni del cluster EKS indirizzerà automaticamente il traffico verso gli obiettivi integri. AZs Per i clienti che cercano gli obiettivi di disponibilità più elevati, nel caso in cui una zona AZ sia compromessa, può essere importante consentire di indirizzare tutto il traffico lontano dalla AZ compromessa fino a quando non si ripristina. Per questo, puoi anche [https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html).
## Comprensione del flusso di traffico di rete est-ovest tra i pod
Il diagramma seguente illustra due esempi di carichi di lavoro, Ordini e Prodotti. Lo scopo di questo esempio è mostrare come comunicano carichi di lavoro e Pod diversi. AZs
![\[Illustrazione del traffico di rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[Illustrazione del traffico di rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. Affinché gli Ordini comunichino con i Prodotti, gli Ordini devono prima risolvere il nome DNS del servizio di destinazione. Ordini comunica con CoredNS per recuperare l’indirizzo IP virtuale (IP cluster) per quel servizio. Dopo che Ordini ha risolto il nome del servizio Prodotti, invia il traffico a quell’indirizzo IP di destinazione.
1. Il kube-proxy viene eseguito su ogni nodo del cluster e controlla continuamente i servizi. [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) Quando viene creato un servizio, un servizio EndpointSlice viene creato e gestito in background dal controller. EndpointSlice Ciascuno EndpointSlice ha un elenco o una tabella di endpoint che contiene un sottoinsieme di indirizzi Pod, insieme ai nodi su cui sono in esecuzione. Il kube-proxy imposta le regole di routing per ciascuno di questi endpoint di pod utilizzando `iptables` sui nodi. Il kube-proxy è anche responsabile di una forma base di bilanciamento del carico, che consiste nel reindirizzare il traffico destinato all’indirizzo IP del cluster di un servizio per inviarlo invece direttamente all’indirizzo IP di un pod. Il kube-proxy esegue questa operazione riscrivendo l’indirizzo IP di destinazione sulla connessione in uscita.
1. I pacchetti di rete vengono quindi inviati al Products Pod in AZ 2 utilizzando i ENIs rispettivi nodi, come mostrato nel diagramma precedente.
### Comprensione dello spostamento zonale ARC in Amazon EKS
Se il tuo ambiente presenta un deterioramento di AZ, è possibile avviare uno spostamento zonale per l’ambiente del cluster EKS. In alternativa, puoi consentire di gestire AWS al posto tuo il traffico variabile con lo spostamento automatico zonale. Con lo spostamento automatico zonale, AWS monitora lo stato generale della zona a zona e risponde a un potenziale deterioramento della zona Z spostando automaticamente il traffico dall'area AZ compromessa nell'ambiente del cluster.
Dopo che il cluster Amazon EKS ha abilitato lo spostamento zonale con ARC, puoi avviare uno spostamento zonale o abilitare lo spostamento automatico di zona utilizzando la console ARC, la AWS CLI o lo spostamento zonale e lo spostamento automatico zonale. APIs Durante uno spostamento zonale EKS, è eseguito automaticamente quanto segue:
+ Tutti i nodi della zona AZ interessata sono isolati. Ciò impedisce al sistema di pianificazione Kubernetes di pianificare nuovi pod su nodi in una zona AZ non integra.
+ Se utilizzi i [gruppi di nodi gestiti](managed-node-groups.md), il [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) viene sospeso e il gruppo Auto Scaling viene aggiornato per garantire che i nuovi nodi del piano dati EKS vengano lanciati solo in condizioni ottimali. AZs
+ I nodi all’interno di AZ non integra non sono terminati e i pod non sono espulsi dai nodi. In questo modo, quando uno spostamento zonale scade o è annullato, il traffico può essere restituito in tutta sicurezza ad AZ per sfruttarne la piena capacità.
+ Il EndpointSlice controller trova tutti gli endpoint Pod nella zona AZ compromessa e li rimuove dai relativi. EndpointSlices Ciò garantisce che solo gli endpoint Pod integri AZs siano destinati a ricevere il traffico di rete. Quando uno spostamento di zona viene annullato o scade, il EndpointSlice controller lo aggiorna EndpointSlices per includere gli endpoint nella AZ ripristinata.
I seguenti diagrammi forniscono una panoramica di alto livello su come uno spostamento zonale EKS garantisce che solo gli endpoint dei pod integri siano presi di mira nell’ambiente del cluster.
![\[Illustrazione del traffico di rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[Illustrazione del traffico di rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## Requisiti per lo spostamento zonale EKS
Affinché lo spostamento zonale funzioni correttamente con EKS, è necessario configurare in anticipo l’ambiente del cluster in modo che sia resiliente a una compromissione di AZ. Di seguito è riportato un elenco di opzioni di configurazione che aiutano a garantire la resilienza.
+ Effettua il provisioning dei nodi di lavoro del cluster su più nodi AZs
+ Consulta a una capacità di elaborazione sufficiente per consentire la rimozione di una singola AZ
+ Pre-scala i tuoi pod, incluso CoredNS, in ogni AZ
+ Distribuisci più repliche Pod su tutti AZs, per assicurarti che anche quando ti allontani da una singola AZ, avrai comunque una capacità sufficiente
+ Effettua la co-locazione di pod interdipendenti o correlati nella stessa AZ
+ Verifica che il tuo ambiente cluster funzioni come previsto senza una AZ avviando manualmente uno spostamento zonale dalla zona AZ. In alternativa, è possibile abilitare lo spostamento zonale automatico e fare affidamento sulle esecuzioni pratiche di spostamento automatico. I test con spostamenti zonali manuali o pratici non sono necessari affinché lo spostamento zonale funzioni in EKS, ma sono fortemente consigliati.
### Esegui il provisioning dei nodi workerEKS in più zone di disponibilità
AWS Le regioni hanno più sedi separate con data center fisici, note come zone di disponibilità (AZs). AZs sono progettate per essere isolate fisicamente l'una dall'altra per evitare impatti simultanei che potrebbero interessare un'intera regione. Quando si effettua il provisioning di un cluster EKS, si consiglia di distribuire i nodi di lavoro su più nodi AZs in una regione. Ciò contribuisce a rendere l'ambiente del cluster più resiliente ai danni di una singola AZ e consente di mantenere un'elevata disponibilità per le applicazioni eseguite nell'altra. AZs Quando iniziate un cambiamento di zona rispetto alla zona di zona interessata, la rete interna al cluster dell'ambiente EKS si aggiorna automaticamente per utilizzarla solo in condizioni ottimali AZs, per contribuire a mantenere un'elevata disponibilità del cluster.
La garanzia di disporre di una configurazione multi-AZ per l’ambiente EKS migliora l’affidabilità complessiva del sistema. Tuttavia, gli ambienti multi-AZ influenzano il modo in cui i dati delle applicazioni sono trasferiti ed elaborati, il che a sua volta ha un impatto sui costi di rete dell’ambiente. In particolare, il traffico in uscita frequente tra le zone (traffico distribuito tra le zone AZs) può avere un impatto importante sui costi relativi alla rete. È possibile applicare diverse strategie per controllare la quantità di traffico tra le zone tra i pod nel cluster EKS e ridurre i costi associati. Per ulteriori informazioni su come ottimizzare i costi di rete durante l’esecuzione di ambienti EKS ad alta disponibilità, consulta [https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/).
Il diagramma seguente illustra un ambiente EKS ad alta disponibilità con tre ambienti integri. AZs
![\[Illustrazione della rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-ha-before-failure.png)
Il diagramma seguente illustra come un ambiente EKS con tre elementi AZs sia resiliente a una compromissione AZ e rimanga altamente disponibile perché ne rimangono due integri. AZs
![\[Illustrazione della rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-ha-after-failure.png)
### Consulta a una capacità di elaborazione sufficiente per resistere alla rimozione di una singola zona di disponibilità
Per ottimizzare l’utilizzo delle risorse e i costi per l’infrastruttura di elaborazione nel piano dati EKS, è consigliabile allineare la capacità di elaborazione ai requisiti del carico di lavoro. Tuttavia, **se tutti i nodi worker sono a piena capacità**, è necessario aggiungere nuovi nodi worker al piano dati EKS prima di poter pianificare nuovi pod. Quando si eseguono carichi di lavoro critici, in genere è buona norma impiegare una capacità ridondante online per gestire scenari quali aumenti improvvisi del carico e problemi di integrità dei nodi. Se prevedi di utilizzare lo spostamento zonale, intendi rimuovere un’intera AZ di capacità in caso di compromissione. Ciò significa che è necessario regolare la capacità di elaborazione ridondante in modo che sia sufficiente a gestire il carico anche con uno dei sistemi offline. AZs
Quando si ridimensionano le risorse di elaborazione, il processo di aggiunta di nuovi nodi al piano dati EKS richiede del tempo. Ciò può avere implicazioni sulle prestazioni e sulla disponibilità in tempo reale delle applicazioni, soprattutto in caso di una compromissione zonale. Il tuo ambiente EKS dovrebbe essere in grado di assorbire il peso della perdita di una AZ senza compromettere l’esperienza degli utenti finali o dei clienti. Ciò significa ridurre al minimo o eliminare il ritardo tra il momento in cui è necessario un nuovo pod e quello in cui è effettivamente pianificato su un nodo worker.
Inoltre, in caso di problemi a livello di zona, dovreste mirare a mitigare il rischio di incorrere in un limite di capacità di elaborazione che impedirebbe l'aggiunta di nuovi nodi necessari al piano dati EKS quando sono integri. AZs
Per ridurre il rischio di questi potenziali impatti negativi, consigliamo di fornire una capacità di elaborazione eccessiva in alcuni nodi di lavoro di ciascuno di essi. AZs In questo modo, Kubernetes Scheduler dispone di una capacità preesistente per il posizionamento di nuovi Pod, il che è particolarmente importante quando si perde uno di essi nell'ambiente. AZs
### Esegui e distribuisci più repliche di pod tra le zone di disponibilità
Kubernetes ti consente di pre-scalare i carichi di lavoro eseguendo più istanze (repliche di pod) di una singola applicazione. L’esecuzione di più repliche di pod per un’applicazione elimina i singoli punti di guasto e aumenta le prestazioni complessive riducendo il carico di sovraccarico su una singola replica. Tuttavia, per garantire un’elevata disponibilità e una migliore tolleranza ai guasti per le applicazioni, si consiglia di eseguire più repliche dell’applicazione e di distribuirle su diversi domini di guasto, noti anche come domini di topologia. I domini di guasto in questo scenario sono le zone di disponibilità. Utilizzando i [vincoli di diffusione della topologia](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/), è possibile configurare le applicazioni in modo che abbiano una stabilità statica pre-esistente. Quindi, in caso di problemi di AZ, il tuo ambiente avrà un numero sufficiente di repliche in buone condizioni per gestire immediatamente eventuali picchi o picchi AZs di traffico.
Il diagramma seguente illustra un ambiente EKS con flusso di traffico quando tutto è east-to-west in buone condizioni. AZs
![\[Illustrazione della rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-spread-constraints.png)
Il diagramma seguente illustra un ambiente EKS con un flusso di east-to-west traffico in cui una singola AZ ha avuto un errore ed è stato avviato un cambiamento di zona.
![\[Illustrazione della rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-spread-constraints-2.png)
Il seguente frammento di codice è un esempio di come configurare il carico di lavoro con più repliche in Kubernetes.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
Soprattutto, è necessario eseguire più repliche del software del server DNS (CoreDNS/Kube-DNS) e applicare vincoli di diffusione della topologia simili, se non sono configurati per impostazione predefinita. In questo modo è possibile garantire che, in caso di un solo problema della zona di disponibilità, siano presenti abbastanza pod DNS integri per continuare AZs a gestire le richieste di rilevamento del servizio per gli altri Pod comunicanti del cluster. Il componente aggiuntivo [CoreDNS EKS](managing-coredns.md) dispone di impostazioni predefinite per i CoredNS Pods che assicurano che, se sono presenti AZs più nodi disponibili, siano distribuiti nelle zone di disponibilità del cluster. Se si desidera, è possibile sostituire queste impostazioni predefinite con le proprie configurazioni personalizzate.
Quando installi [CoreDNS con Helm](https://github.com/coredns/helm/tree/master), è possibile aggiornare `replicaCount` nel [file values.yaml](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml) per assicurarti di avere un numero sufficiente di repliche in ciascuna AZ. Inoltre, per garantire che queste repliche siano distribuite tra i diversi ambienti del cluster, assicuratevi di aggiornare la proprietà AZs nello stesso file. `topologySpreadConstraints` `values.yaml` Il seguente frammento di codice illustra come configurare CoreDNS per eseguire tale operazione.
**values.yaml CoredNS Helm**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
In caso di compromissione di AZ, è possibile assorbire l’aumento del carico sui pod CoreDNS, utilizzando un sistema di scalabilità automatica per CoreDNS. Il numero di istanze DNS necessarie dipende dal numero di carichi di lavoro in esecuzione nel cluster. CoreDNS è legato alla CPU, il che gli consente di scalare in base alla CPU utilizzando l’[Horizontal Pod Autoscaler (HPA)](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa). Di seguito è riportato un esempio che è possibile modificare in base alle esigenze.
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
In alternativa, EKS può gestire la scalabilità automatica dell’implementazione CoreDNS nella versione del componente aggiuntivo EKS di CoreDNS. Questo autoscaler di CoreDNS monitora continuamente lo stato del cluster, incluso il numero di nodi e core CPU. Sulla base di tali informazioni, il controller regola dinamicamente il numero di repliche dell’implementazione CoreDNS in un cluster EKS.
Per abilitare la [configurazione di scalabilità automatica nel componente aggiuntivo CoredNS EKS](coredns-autoscaling.md), utilizzare la seguente impostazione di configurazione:
```
{
"autoScaling": {
"enabled": true
}
}
```
Puoi anche usare [NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) o l'[autoscaler proporzionale del cluster](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) per scalare CoredNS. Per ulteriori informazioni, consulta [Scalare CoredNS orizzontalmente](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally).
### Co-locare i pod interdipendenti nella stessa zona di disponibilità
In genere, le applicazioni hanno carichi di lavoro distinti che devono comunicare tra loro per completare correttamente un processo. end-to-end Se queste applicazioni distinte sono distribuite su più aree AZs e non sono collocate nella stessa zona di zona, una singola area di disponibilità può influire sul processo. end-to-end ****Ad esempio, se **l'applicazione A** ha più repliche in AZ 1 e AZ 2, ma **l'applicazione B** ha tutte le repliche in AZ 3, la perdita di AZ 3 influirà sui end-to-end processi tra i due carichi di lavoro, l'applicazione A e l'applicazione B.**** Se combini i vincoli di diffusione della topologia con l'affinità dei pod, puoi migliorare la resilienza dell'applicazione distribuendo i Pod su tutti. AZs Inoltre, ciò configura una relazione tra determinati pod per garantire che siano co-locati.
Con [le regole di affinità dei pod](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), è possibile definire le relazioni tra i carichi di lavoro per influenzare il comportamento del sistema di pianificazione Kubernetes in modo che collochi i pod sullo stesso nodo worker o nella stessa AZ. Inoltre, è possibile configurare la rigidità dei vincoli di pianificazione.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
Il diagramma seguente mostra diversi pod che sono stati co-locati sullo stesso nodo utilizzando le regole di affinità dei pod.
![\[Illustrazione della rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### Verifica che il tuo ambiente cluster sia in grado di gestire la perdita di una AZ
Dopo aver completato i requisiti descritti nelle sezioni precedenti, il passaggio successivo consiste nel verificare di disporre di una capacità di elaborazione e carico di lavoro sufficiente per gestire la perdita di una AZ. Per eseguire tale operazione è possibile avviare manualmente uno spostamento zonale in EKS. In alternativa, è possibile abilitare lo spostamento zonale automatico e configurare le sessioni pratiche, che consentono anche di verificare che le applicazioni funzionino come previsto con una AZ in meno nell’ambiente cluster.
## Domande frequenti
**Qual è il vantaggio di utilizzare questa funzionalità?**
Utilizzando lo spostamento zonale ARC o lo spostamento zonale automatico nel cluster EKS, è possibile mantenere meglio la disponibilità delle applicazioni Kubernetes automatizzando il processo di ripristino rapido che consiste nello spostamento del traffico di rete interno al cluster da una zona AZ compromessa. Con ARC, è possibile evitare passaggi lunghi e complicati, che possono portare a un periodo di recupero prolungato in caso di eventi AZ compromessi.
**Come funziona questa funzionalità con altri servizi? AWS **
EKS si integra con ARC, che fornisce l'interfaccia principale in cui eseguire le operazioni di ripristino. AWS Per garantire che il traffico all’interno del cluster sia indirizzato in modo appropriato lontano da una zona di disponibilità compromessa, EKS apporta modifiche all’elenco degli endpoint di rete per i pod in esecuzione sul piano dati Kubernetes. Se utilizzi Elastic Load Balancing per instradare il traffico esterno verso il cluster, è possibile registrare i bilanciatori del carico con ARC e avviare uno spostamento zonale su di essi per impedire che il traffico fluisca verso la zona AZ deteriorata. Zonal shift funziona anche con i gruppi di Amazon EC2 Auto Scaling creati da gruppi di nodi gestiti da EKS. Per evitare che una AZ compromessa sia utilizzata per nuovi pod Kubernetes o avvii di nodi, EKS rimuove la AZ compromessa dai gruppi Auto Scaling.
**In che modo questa funzionalità è diversa dalle protezioni Kubernetes predefinite?**
Tale funzionalità funziona in combinazione con diverse protezioni integrate di Kubernetes che aiutano la resilienza delle applicazioni dei clienti. È possibile configurare le sonde readiness e liveness di pod che decidono quando un Pod deve ricevere traffico. Quando queste sonde si guastano, Kubernetes rimuove questi pod come obiettivi di un servizio e il traffico non è più inviato al pod. Sebbene ciò sia utile, non è semplice per i clienti configurare tali controlli dell’integrità in modo da garantire che abbiano esito negativo in caso di deterioramento di una AZ. La funzione di spostamento zonale ARC fornisce una rete di sicurezza aggiuntiva che ti aiuta a isolare completamente una AZ deteriorata quando le protezioni native di Kubernetes non erano sufficienti. Lo spostamento zonale offre anche un modo semplice per testare la prontezza operativa e la resilienza dell’architettura.
**Posso AWS avviare un cambiamento di zona per mio conto?**
Sì, se desideri un modo completamente automatizzato di utilizzare lo spostamento zonale ARC, puoi abilitare lo spostamento zonale automatico ARC. Con l'autoshift zonale, puoi contare sul AWS monitoraggio dello stato del tuo cluster EKS e sull' AZs avvio automatico di uno spostamento di zona quando viene rilevata una compromissione della zona A Z.
**Cosa succede se utilizzo questa funzionalità e i miei nodi worker e i miei carichi di lavoro non sono predimensionati?**
Se non si esegue una pre-scalabilità e si affida al provisioning di nodi o pod aggiuntivi durante uno spostamento zonale, si rischia un ripristino ritardato. Il processo di aggiunta di nuovi nodi al piano dati di Kubernetes richiede del tempo, il che può influire sulle prestazioni e sulla disponibilità in tempo reale delle applicazioni, soprattutto in caso di compromissione zonale. Inoltre, in caso di compromissione zonale, è possibile che si verifichi un potenziale limite di capacità di elaborazione che potrebbe impedire l'aggiunta dei nuovi nodi necessari a quelli integri. AZs
Se i carichi di lavoro non sono prescalati e distribuiti su tutto il cluster, un AZs problema zonale potrebbe influire sulla disponibilità di un'applicazione che viene eseguita solo sui nodi di lavoro nelle zone di lavoro interessate. Per mitigare il rischio di un’interruzione completa della disponibilità dell’applicazione, EKS dispone di un sistema a prova di guasto per l’invio del traffico agli endpoint di pod in una zona compromessa se il carico di lavoro ha tutti i suoi endpoint in una AZ non integra. Tuttavia, ti consigliamo vivamente di pre-scalare e distribuire le applicazioni su tutte AZs per mantenere la disponibilità in caso di problemi zonali.
**Come funziona se sto eseguendo un’applicazione stateful?**
Se stai eseguendo un’applicazione stateful, devi valutarne la tolleranza ai guasti, in base al tuo caso d’uso e all’architettura. Se disponi di un' active/standby architettura o di un pattern, potrebbero esserci casi in cui l'attivo si trova in una zona AZ compromessa. A livello di applicazione, se lo standby non è attivato, è possibile che si verifichino problemi con l’applicazione. Potresti inoltre riscontrare problemi quando i nuovi Kubernetes Pod vengono lanciati in modalità integra AZs, poiché non saranno in grado di collegarsi ai volumi persistenti limitati alla zona AZ compromessa.
**Questa funzionalità funziona con Karpenter?**
Il supporto di Karpenter non è attualmente disponibile con uno spostamento zonale ARC e uno spostamento zonale automatico in EKS. Se una AZ è compromessa, puoi modificare la NodePool configurazione di Karpenter pertinente rimuovendo quella non integra in modo che i nuovi nodi di lavoro vengano avviati solo nell'altra. AZs
**Questa funzionalità funziona con EKS Fargate?**
Questa funzionalità non funziona con EKS Fargate. Per impostazione predefinita, quando EKS Fargate riconosce un evento sanitario zonale, i Pods preferiranno essere eseguiti nell'altra. AZs
**Il piano di controllo Kubernetes gestito da EKS ne risentirà?**
No, per impostazione predefinita Amazon EKS esegue e ridimensiona il piano di controllo Kubernetes su più piani AZs per garantire un'elevata disponibilità. Lo spostamento zonale ARC e lo spostamento zonale automatico agiscono solo sul piano dati Kubernetes.
**Ci sono dei costi associati a questa nuova funzionalità?**
È possibile utilizzare uno spostamento zonale ARC e uno spostamento zonale automatico nel cluster EKS senza costi aggiuntivi. Tuttavia, continuerai a pagare per le istanze assegnate e consigliamo vivamente di pre-scalare il tuo piano dati Kubernetes prima di utilizzare questa funzionalità. È necessario considerare un equilibrio tra costi e disponibilità delle applicazioni.
## Risorse aggiuntive
+ [Come funziona uno spostamento zonale](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [Best practice per spostamenti zonali in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [Risorse e scenari supportati per lo spostamento zonale e lo spostamento zonale automatico](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Funzionamento di carichi di lavoro resilienti su Amazon EKS](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [Elimina il ritardo di scalabilità dei nodi Kubernetes con la priorità dei pod e l’eccesso di provisioning](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [Scala i pod CoreDNS per un traffico DNS elevato](coredns-autoscaling.md)
# Abilitazione dello spostamento zonale EKS per evitare zone di disponibilità compromesse
Amazon Application Recovery Controller (ARC) ti aiuta a gestire e coordinare il ripristino per le tue applicazioni nelle zone di disponibilità (AZs) e funziona con molti servizi, tra cui Amazon EKS. Con il supporto EKS per lo spostamento zonale ARC, è possibile spostare il traffico di rete interno al cluster da una AZ compromessa. Puoi anche AWS autorizzare il monitoraggio dello stato della tua rete AZs e spostare temporaneamente il traffico di rete da una zona non sicura per tuo conto.
**Come utilizzare uno spostamento zonale EKS:**
1. Abilita il tuo cluster EKS con Amazon Application Recovery Controller (ARC). Questa operazione viene eseguita a livello di cluster utilizzando la console Amazon EKS, la AWS CLI o CloudFormation eksctl.
1. Una volta abilitato, puoi gestire i turni zonali o gli spostamenti automatici zonali utilizzando la console ARC, la AWS CLI o lo spostamento zonale e lo spostamento automatico zonale. APIs
Tieni presente che dopo aver registrato un cluster EKS con ARC, devi comunque configurare ARC. Per esempio, è possibile utilizzare la console ARC per configurare lo spostamento zonale automatico.
Per informazioni più dettagliate su come funziona lo spostamento zonale EKS e su come progettare i carichi di lavoro per gestire le zone di disponibilità compromesse, consulta [Ulteriori informazioni relative allo spostamento zonale in controller di ripristino delle applicazioni Amazon (ARC)](zone-shift.md).
## Considerazioni
+ La modalità automatica EKS non supporta Amazon Application Recovery Controller, lo spostamento zonale e lo spostamento zonale automatico.
+ Consigliamo di attendere almeno 60 secondi tra le operazioni di spostamento zonale per garantire la corretta elaborazione di ciascuna richiesta.
Quando si tenta di eseguire spostamenti zonali in rapida successione (entro 60 secondi l’uno dall’altro), il servizio Amazon EKS potrebbe non elaborare correttamente tutte le richieste di spostamento. Ciò è dovuto all’attuale meccanismo di polling che aggiorna lo stato zonale del cluster. Se è necessario eseguire più spostamenti zonali, assicuratevi che vi sia un periodo di tempo adeguato tra le operazioni affinché il sistema elabori ogni modifica.
## What is Amazon Application Recovery Controller?
Amazon Application Recovery Controller (ARC) ti aiuta a prepararti e a portare a termine ripristini più rapidi per le applicazioni in esecuzione su AWS. Lo spostamento zonale consente di riprendersi rapidamente dai problemi relativi alla zona di disponibilità (AZ), spostando temporaneamente il traffico di una risorsa supportata da una zona di disponibilità a un livello ottimale nella regione. AZs AWS
[Ulteriori informazioni su Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## Che cos’è uno spostamento zonale?
Lo spostamento zonale è una funzionalità di ARC che consente di spostare il traffico per una risorsa come un cluster EKS o un Elastic Load Balancer lontano da una zona di disponibilità in AWS una regione per mitigare rapidamente un problema e ripristinare rapidamente l'applicazione. È possibile scegliere di spostare il traffico, per esempio, perché una cattiva implementazione causa problemi di latenza o perché la zona di disponibilità è compromessa. Uno spostamento zonale non richiede passaggi di configurazione avanzati.
[Ulteriori informazioni sullo spostamento zonale ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## Cos’è lo spostamento automatico zonale automatico?
L'autoshift zonale è una funzionalità di ARC che puoi abilitare per autorizzare lo spostamento del traffico da una zona di zona AWS alle risorse supportate, per tuo conto, a un traffico funzionante nella regione. AZs AWS AWS avvia uno spostamento automatico quando la telemetria interna indica che in una zona AZ in una regione si è verificata una compromissione che potrebbe avere un impatto sui clienti. La telemetria interna incorpora metriche provenienti da più fonti, tra cui la rete e i servizi AWS Amazon ed Elastic Load EC2 Balancing.
AWS interrompe gli spostamenti automatici quando gli indicatori indicano che non esiste più un problema o un problema potenziale.
[Ulteriori informazioni sullo spostamento zonale automatico ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## Cosa fa EKS durante uno spostamento automatico?
EKS aggiorna le configurazioni di rete per evitare di indirizzare il traffico verso persone con problemi. AZs Inoltre, se utilizzi Managed Node Groups, EKS lancerà nuovi nodi nell'area integra solo AZs durante un cambio di zona. Quando lo spostamento scade o viene annullato, le configurazioni di rete saranno ripristinate per includere l’AZ che in precedenza era stato rilevato come non integra.
[Ulteriori informazioni sullo spostamento zonale EKS](zone-shift.md)
## Registra il cluster EKS con Amazon Application Recovery Controller (ARC) (AWS console)
1. Trova il nome e la regione del cluster EKS che desideri registrare con ARC.
1. Vai alla [Console EKS](https://console.aws.amazon.com/eks) in quella regione e seleziona il tuo cluster.
1. Nella pagina delle **Informazioni sul cluster**, seleziona la scheda **Panoramica**.
1. Sotto l’intestazione **Spostamento zonale**, seleziona il pulsante **Gestisci**.
1. Seleziona **abilita** o **disabilita** per lo *spostamento zonale EKS*.
Ora il tuo cluster EKS è registrato con ARC.
Se desideri AWS rilevare ed evitare zone di disponibilità ridotta, devi configurare l'autoshift zonale ARC. Ad esempio, è possibile eseguire questa operazione nella console ARC.
## Fasi successive
+ Scopri come [abilitare lo spostamento zonale automatico](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html).
+ Scopri come [avviare](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) manualmente uno spostamento zonale.