**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à. # Implementazione di Amazon EKS on-premises con AWS Outposts Puoi utilizzare Amazon EKS per eseguire applicazioni Kubernetes on-premises su AWS Outposts. Puoi implementare Amazon EKS su Outposts nei seguenti modi: + **Cluster estesi**: esegui il piano di controllo (control-plane) di Kubernetes in una Regione AWS e i nodi sull’Outpost. + **Cluster locali**: esegui il piano di controllo (control-plane) di Kubernetes e i nodi sull’Outpost. Per entrambe le opzioni di implementazione, il piano di controllo (control-plane) di Kubernetes è completamente gestito da AWS. Puoi utilizzare le stesse API, gli stessi strumenti e le stesse console di Amazon EKS che utilizzi nel cloud per creare ed eseguire Amazon EKS su Outposts. Il diagramma seguente illustra queste opzioni di implementazione. ![\[Opzioni di implementazione dell'Outpost\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/outposts-deployment-options.png) ## Quando utilizzare ciascuna opzione di implementazione Sia i cluster locali sia quelli estesi sono opzioni di implementazione generiche e possono essere utilizzati per una vasta gamma di applicazioni. Con i cluster locali puoi eseguire l'intero cluster Amazon EKS in locale su Outposts. Questa opzione consente di ridurre il rischio di tempi di inattività delle applicazioni che possono derivare da disconnessioni temporanee del cloud dalla rete. Queste disconnessioni di rete possono essere causate da interruzioni della fibra o da eventi meteorologici. Poiché l'intero cluster Amazon EKS viene eseguito in locale su Outposts, le applicazioni rimangono disponibili. Durante le disconnessioni del cloud dalla rete è possibile eseguire operazioni del cluster. Per ulteriori informazioni, consulta [Preparazione di cluster Amazon EKS locali su AWS Outposts per le disconnessioni di rete](eks-outposts-network-disconnects.md). Se ti preoccupa la qualità della connessione di rete dai tuoi Outpost alla Regione AWS principale e hai bisogno di una disponibilità elevata durante le disconnessioni di rete, ti consigliamo di utilizzare l’opzione di implementazione del cluster locale. I cluster estesi consentono di risparmiare capacità sul tuo Outpost perché il piano di controllo (control-plane) di Kubernetes viene eseguito nella Regione AWS principale. Questa opzione può essere più adatta se sei in grado di investire in una connettività di rete affidabile e ridondante dal tuo Outpost alla Regione AWS. La qualità della connessione di rete è fondamentale per questa opzione. Il modo in cui Kubernetes gestisce le disconnessioni di rete tra il piano di controllo (control-plane) Kubernetes e i nodi potrebbe comportare tempi di inattività delle applicazioni. Per ulteriori informazioni sul funzionamento di Kubernetes, consulta [Scheduling, Preemption, and Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/) nella documentazione di Kubernetes. ## Confronto tra le opzioni di implementazione La tabella seguente riporta le differenze tra le due opzioni. | Funzionalità | Cluster esteso | Cluster locale | | --- | --- | --- | | Posizione del piano di controllo Kubernetes | Regione AWS | Outpost | | Account del piano di controllo (control-plane) di Kubernetes | Account AWS | Il tuo account | | Disponibilità regionale | Consulta [Service endpoints](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region) | Stati Uniti orientali (Ohio), Stati Uniti orientali (Virginia settentrionale), Stati Uniti occidentali (California settentrionale), Stati Uniti occidentali (Oregon), Asia Pacifico (Seoul), Asia Pacifico (Singapore), Asia Pacifico (Sydney), Asia Pacifico (Tokyo), Canada (Centrale), Europa (Francoforte), Europa (Irlanda), Europa (Londra), Medio Oriente (Bahrein) e Sud America (San Paolo) | | Versioni secondarie di Kubernetes | eks/latest/userguide/kubernetes-versions.html [Versioni di Amazon EKS supportate, type=“documentation”]. | eks/latest/userguide/kubernetes-versions.html [Versioni di Amazon EKS supportate, type=“documentation”]. | | Versioni della piattaforma | Consulta [Versioni della piattaforma di EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) | Consulta la sezione [Scopri le versioni della piattaforma Kubernetes e Amazon EKS per Outposts AWS](eks-outposts-platform-versions.md) | | Fattori di forma dell'Outpost | Rack dell'Outpost | Rack dell'Outpost | | Interfacce utente | Console di gestione AWS, AWS CLI, API Amazon EKS, `eksctl`, AWS CloudFormation e Terraform | Console di gestione AWS, AWS CLI, API Amazon EKS, `eksctl`, AWS CloudFormation e Terraform | | Policy gestite | [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) e [AWS politica gestita: Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) e [AWS politica gestita: Amazon EKSLocal OutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | | VPC e sottoreti del cluster | Consulta la sezione [Visualizzazione di requisiti di rete di Amazon EKS per VPC e sottoreti](network-reqs.md) | Consulta la sezione [Creazione di VPC e sottoreti per i cluster Amazon EKS su AWS Outposts](eks-outposts-vpc-subnet-requirements.md) | | Accesso all'endpoint del cluster | Pubblico o privato o entrambi | Solo privati | | Autenticazione del server API Kubernetes | AWS Identity and Access Management (IAM) e OIDC | IAM e certificati `x.509` | | Tipi di nodo | Solo autogestito | Solo autogestito | | Tipi di elaborazione dei nodi | Amazon EC2 on demand | Amazon EC2 on demand | | Tipi di archiviazione dei nodi | `gp2` di Amazon EBS e SSD NVMe locali | `gp2` di Amazon EBS e SSD NVMe locali | | AMI ottimizzate per Amazon EKS | Amazon Linux, Windows e Bottlerocket | Solo Amazon Linux | | Versioni IP | Solo `IPv4` | Solo `IPv4` | | Componenti aggiuntivi | Componenti aggiuntivi Amazon EKS o autogestiti | Solo componenti aggiuntivi autogestiti | | Interfaccia di rete del container predefinita | Plug-in CNI di Amazon VPC per Kubernetes | Plug-in CNI di Amazon VPC per Kubernetes | | Registri del piano di controllo Kubernetes | Amazon CloudWatch Logs | Amazon CloudWatch Logs | | Sistema di bilanciamento del carico | Utilizza [AWS Load Balancer Controller](aws-load-balancer-controller.md) per eseguire il provisioning solo di Application Load Balancer (nessun Network Load Balancer) | Utilizza [AWS Load Balancer Controller](aws-load-balancer-controller.md) per eseguire il provisioning solo di Application Load Balancer (nessun Network Load Balancer) | | Crittografia a busta dei segreti | Consulta la sezione [Crittografia dei segreti Kubernetes con KMS su cluster esistenti](enable-kms.md) | Non supportato | | Ruoli IAM per gli account di servizio | Consulta la sezione [Ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md) | Non supportato | | Risoluzione dei problemi | Consulta la sezione [Risoluzione dei problemi con i cluster e i nodi Amazon EKS](troubleshooting.md) | Consulta la sezione [Risolvi i problemi relativi ai cluster Amazon EKS locali su Outposts AWS](eks-outposts-troubleshooting.md) | **Topics** # Creazione di cluster Amazon EKS locali su AWS Outposts per un’elevata disponibilità I cluster locali consentono di eseguire l’intero cluster Amazon EKS in locale su AWS Outposts. Ciò consente di ridurre il rischio di tempi di inattività delle applicazioni che possono derivare da disconnessioni temporanee del cloud dalla rete. Queste disconnessioni di rete possono essere causate da interruzioni della fibra o da eventi meteorologici. Poiché l’intero cluster Kubernetes viene eseguito localmente su Outposts, le applicazioni rimangono disponibili. Durante le disconnessioni del cloud dalla rete è possibile eseguire operazioni del cluster. Per ulteriori informazioni, consulta [Preparazione di cluster Amazon EKS locali su AWS Outposts per le disconnessioni di rete](eks-outposts-network-disconnects.md). Il diagramma seguente mostra un'implementazione di un cluster locale. ![\[Cluster locale su Outpost\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/outposts-local-cluster.png) I cluster locali sono generalmente disponibili per l'uso con i rack di Outposts. ## Regioni AWS supportate Puoi creare cluster locali nelle seguenti Regioni AWS: Stati Uniti orientali (Ohio), Stati Uniti orientali (Virginia settentrionale), Stati Uniti occidentali (California settentrionale), Stati Uniti occidentali (Oregon), Asia Pacifico (Seoul), Asia Pacifico (Singapore), Asia Pacifico (Sydney), Asia Pacifico (Tokyo), Canada (Centrale), Europa (Francoforte), Europa (Irlanda), Europa (Londra), Medio Oriente (Bahrein) e Sud America (San Paolo). Per informazioni dettagliate sulle funzionalità supportate, consulta la sezione [Confronto tra le opzioni di implementazione](eks-outposts.md#outposts-overview-comparing-deployment-options). **Topics** # Implementa un cluster Amazon EKS su Outposts AWS Questo argomento offre una panoramica degli elementi da prendere in considerazione quando si esegue un cluster locale su un Outpost. L'argomento fornisce anche istruzioni su come implementare un cluster locale su un Outpost. **Importante** Queste considerazioni non sono trattate nella documentazione correlata di Amazon EKS. Se altri argomenti della documentazione di Amazon EKS sono in conflitto con le considerazioni qui riportate, segui le considerazioni qui. Queste considerazioni sono soggette a modifiche e potrebbero cambiare frequentemente. Pertanto, ti consigliamo di rivedere regolarmente questo argomento. Molte considerazioni sono diverse da quelle relative alla creazione di un cluster sul cloud. AWS + I cluster locali supportano solo i rack dell'Outpost. Un singolo cluster locale può essere eseguito su più dell'Outpost fisici che comprendono un unico Outpost logico. Un singolo cluster locale non può essere eseguito su più Outpost logici. Ogni Outpost logico ha un singolo ARN dell'Outpost. + I cluster locali eseguono e gestiscono il piano di controllo (control-plane) di Kubernetes nel tuo account sull’Outpost. Non puoi eseguire carichi di lavoro sulle istanze del piano di controllo (control-plane) di Kubernetes né modificare i relativi componenti. Questi nodi sono gestiti dal servizio Amazon EKS. Le modifiche al piano di controllo (control-plane) di Kubernetes non persistono tra un’operazione di gestione automatica di Amazon EKS e l’altra, come l’applicazione di patch. + I cluster locali supportano i componenti aggiuntivi autogestiti e i gruppi di nodi Amazon Linux autogestiti. I componenti aggiuntivi: [plug-in per la Container Network Interface (CNI) di Amazon VPC per Kubernetes](managing-vpc-cni.md), [kube-proxy](managing-kube-proxy.md) e [CoreDNS](managing-coredns.md) vengono installati automaticamente nei cluster locali. + I cluster locali richiedono l'utilizzo di Amazon EBS su Outposts. Il tuo Outpost deve avere a disposizione Amazon EBS per l’archiviazione del piano di controllo (control-plane) di Kubernetes. Gli Outpost supportano solo i volumi `gp2` di Amazon EBS. + I `PersistentVolumes` Kubernetes sostenuti da Amazon EBS sono supportati tramite il driver CSI per Amazon EBS. + Le istanze del piano di controllo (control-plane) dei cluster locali sono configurate in una [topologia in stack ad alta disponibilità](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/). Due delle tre istanze del piano di controllo (control-plane) devono essere sempre integre per mantenere il quorum. Se il quorum viene perso, contatta l' AWS assistenza, poiché saranno necessarie alcune azioni sul lato del servizio per abilitare le nuove istanze gestite. **Prerequisiti** + [Familiarità con le opzioni di [distribuzione di Outposts](eks-outposts.md#outposts-overview-comparing-deployment-options)[, Select Instance Types e Placement Groups per i cluster Amazon EKS AWS su Outposts in base a considerazioni sulla capacità](eks-outposts-capacity-considerations.md) e requisiti e considerazioni VPC.](eks-outposts-vpc-subnet-requirements.md) + Un Outpost esistente. Per ulteriori informazioni, consulta [What is AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html). + Lo strumento a riga di comando `kubectl` è installato sul computer 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 | 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 (utente o ruolo) con autorizzazioni `create` e `describe` per 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). Quando viene creato un cluster Amazon EKS locale, il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che crea il cluster viene aggiunto in modo permanente. Il principale viene aggiunto specificamente alla tabella di autorizzazione RBAC Kubernetes come amministratore. Questa entità dispone di autorizzazioni `system:masters`. L’identità di questa entità non è visibile nella configurazione del cluster, per cui è fondamentale prendere nota dell’entità che ha creato il cluster, in modo da non eliminarla. Inizialmente, solo il principale che ha creato il server può effettuare chiamate al server API Kubernetes utilizzando `kubectl`. Se utilizzi la console per creare il cluster, assicurati che le stesse credenziali IAM siano presenti nella catena di credenziali AWS SDK quando `kubectl` esegui i comandi sul cluster. Dopo aver creato il cluster, è possibile concedere l'accesso ad altri principali IAM al cluster. ## Creazione di un cluster locale Amazon EKS. Puoi creare un cluster locale con i seguenti strumenti descritti in questa pagina: + [`eksctl`](#eksctl_create_cluster_outpost) + [Console di gestione AWS](#console_create_cluster_outpost) Puoi anche usare la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html), l'[API Amazon EKS [AWS SDKs](https://aws.amazon.com/developer/tools/)](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html)o [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest) per creare cluster su Outposts. ### `eksctl` **Per creare un cluster con `eksctl` ** 1. Installa la versione `0.215.0` o successiva dello strumento da riga di `eksctl` comando sul tuo 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. Copia i seguenti contenuti sul tuo dispositivo. Sostituisci i valori seguenti, quindi esegui il comando modificato per creare il file `outpost-control-plane.yaml`: + Sostituiscilo *region-code* con la [AWS regione supportata](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions) 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) 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. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster. + Sostituisci *vpc-ExampleID1* e *subnet-ExampleID1* con il IDs VPC e la sottorete esistenti. Il VPC e la sottorete devono soddisfare i requisiti in Crea [un VPC e sottoreti per i cluster Amazon](eks-outposts-vpc-subnet-requirements.md) EKS su Outposts. AWS + Sostituiscilo con *uniqueid* l'ID del tuo Outpost. + Sostituisci *m5.large* con un tipo di istanza disponibile sul tuo Outpost. Prima di scegliere un tipo di istanza, consulta la sezione [Selezione dei tipi di istanze e dei gruppi di posizionamento per i cluster Amazon EKS su AWS Outposts in base alle considerazioni sulla capacità](eks-outposts-capacity-considerations.md). Vengono implementate tre istanze del piano di controllo. Questo numero non può essere modificato. ``` cat >outpost-control-plane.yaml < **Per creare il cluster con la Console di gestione AWS ** 1. Hai bisogno di un VPC e una sottorete esistenti che soddisfano i requisiti di Amazon EKS. Per ulteriori informazioni, consulta [Creazione di VPC e sottoreti per i cluster Amazon EKS su AWS Outposts](eks-outposts-vpc-subnet-requirements.md). 1. Se disponi già di un ruolo IAM del cluster locale o intendi creare il cluster con `eksctl`, puoi ignorare 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": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Crea il ruolo IAM del cluster Amazon EKS. Per creare un ruolo IAM, è necessario assegnare l'azione `iam:CreateRole` (autorizzazione) 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 myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json" ``` 1. Allega la policy gestita di Amazon EKS denominata [Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) 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/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole ``` 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Nella parte superiore dello schermo della console, assicurati di aver selezionato una [AWS regione supportata](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions). 1. Seleziona **Aggiungi cluster** e quindi **Crea**. 1. Nella pagina **Configure cluster** (Configura cluster), inserisci o seleziona i valori per i campi seguenti: + **Posizione del piano di controllo Kubernetes: scegli Outposts**. AWS + **Outpost ID** (ID Outpost): scegli l'ID dell'Outpost su cui vuoi creare il tuo piano di controllo. + **Instance type** (Tipo di istanza): seleziona un tipo di istanza. Vengono visualizzati solo i tipi di istanza disponibili nel tuo Outpost. Nell'elenco a discesa, ogni tipo di istanza descrive per quanti nodi è consigliato il tipo di istanza. Prima di scegliere un tipo di istanza, consulta la sezione [Selezione dei tipi di istanze e dei gruppi di posizionamento per i cluster Amazon EKS su AWS Outposts in base alle considerazioni sulla capacità](eks-outposts-capacity-considerations.md). Tutte le repliche vengono implementate utilizzando lo stesso tipo di istanza. Non è possibile modificare il tipo di istanza dopo la creazione del cluster. Vengono implementate tre istanze del piano di controllo. Questo numero non può essere modificato. + **Nome**: un nome per il cluster. Deve essere univoca nel tuo account. AWS 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. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster. + **Versione Kubernetes**: scegli la versione di Kubernetes da utilizzare per il cluster. È preferibile selezionare la versione più recente, a meno che non occorra utilizzare una versione precedente. + Ruolo del **servizio cluster: scegli il ruolo** IAM del cluster Amazon EKS creato in un passaggio precedente per consentire al piano di controllo Kubernetes di gestire le risorse. AWS + **Accesso di amministratore del cluster Kubernetes**: se desideri che il principale IAM (ruolo o utente) che crea il cluster disponga dell’accesso di amministratore agli oggetti Kubernetes sul cluster, accetta l’impostazione predefinita (Consenti). Amazon EKS crea una voce di accesso per il principale IAM e concede le autorizzazioni di amministratore del cluster per la voce di accesso. Per ulteriori informazioni sulle voci di accesso, consulta la sezione [Concedere agli utenti IAM l’accesso a Kubernetes con le voci di accesso EKS](access-entries.md). Se desideri che un principale IAM diverso da quello che crea il cluster disponga dell’accesso di amministratore agli oggetti del cluster Kubernetes, scegli l’opzione Non consentire. Dopo la creazione del cluster, qualsiasi principale IAM che disponga delle autorizzazioni IAM per creare voci di accesso può aggiungerne una per tutti i principali IAM che necessitano dell’accesso agli oggetti del cluster Kubernetes. Per ulteriori informazioni sulle autorizzazioni IAM richieste, consulta [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) nella Documentazione di riferimento per l'autorizzazione ai servizi. Se scegli l’opzione Non consentire e non crei alcuna voce di accesso, nessun principale IAM avrà accesso agli oggetti Kubernetes sul cluster. + **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**: scegli un VPC esistente. Il VPC deve disporre di un numero sufficiente di indirizzi IP da mettere a disposizione per il cluster, i nodi e le altre risorse Kubernetes da creare. Il VPC deve soddisfare i requisiti elencati in [VPC requirements and considerations](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements). + **Sottoreti**: per impostazione predefinita, tutte le sottoreti disponibili nel VPC specificato nel campo precedente sono preselezionate. Le sottoreti scelte devono soddisfare i requisiti elencati in [Subnet requirements and considerations](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). + **Gruppi di sicurezza**: (facoltativo) specifica uno o più gruppi di sicurezza da associare alle interfacce di rete create da Amazon EKS. Amazon EKS crea automaticamente un gruppo di sicurezza che consente 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 vuoi aggiungere i tuoi gruppi di sicurezza, non potrai modificare i gruppi scelti dopo la creazione del cluster. Per consentire agli host on-premises di comunicare con l'endpoint del cluster, è necessario consentire il traffico in entrata dal gruppo di sicurezza del cluster. Per i cluster che non dispongono di una connessione internet in ingresso e in uscita (noti anche come cluster privati), è necessario effettuare una delle seguenti operazioni: + Aggiungi il gruppo di sicurezza associato agli endpoint VPC richiesti. Per ulteriori informazioni sugli endpoint richiesti, consulta la sezione Accesso tramite [sottorete [Utilizzo di endpoint VPC dell'interfaccia](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints)](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services) ai servizi. AWS + Modifica il gruppo di sicurezza creato da Amazon EKS per consentire il traffico proveniente dal gruppo di sicurezza associato agli endpoint VPC. Quando hai finito con questa pagina, seleziona **Avanti**. 1. Nella pagina **Configura osservabilità**, puoi scegliere facoltativamente le opzioni **Parametri** e **Registrazione del piano di controllo** che desideri 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 **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**. Il provisioning del cluster richiede diversi minuti. ## Visualizzazione del cluster locale Amazon EKS 1. Dopo avere creato il cluster, puoi visualizzare le istanze del piano di controllo Amazon EC2 che sono state create. ``` aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane ``` Di seguito viene riportato un output di esempio: ``` "Name": "my-cluster-control-plane-id1" "Name": "my-cluster-control-plane-id2" "Name": "my-cluster-control-plane-id3" ``` Ogni istanza è contaminata dal taint `node-role.eks-local.amazonaws.com/control-plane` per evitare che i carichi di lavoro vengano pianificati sulle istanze del piano di controllo. Per ulteriori informazioni sui taint, consulta [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nella documentazione di Kubernetes. Amazon EKS monitora continuamente lo stato dei cluster locali. Eseguiamo operazioni di gestione automatiche, come applicazioni di patch di sicurezza e riparazioni di istanze non integre. Quando i cluster locali vengono disconnessi dal cloud, eseguiamo una serie di operazioni per garantire che il cluster venga ripristinato a uno stato di integrità al momento della riconnessione. 1. Se hai creato il cluster utilizzando `eksctl`, puoi ignorare questo passaggio. `eksctl` lo completerà automaticamente per tuo conto. Abilita `kubectl` per consentire la comunicazione con il cluster aggiungendo un nuovo contesto al file `config` `kubectl`. Per istruzioni 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. Per connetterti al server API Kubernetes del cluster locale, devi disporre dell’accesso al gateway locale per la sottorete o connetterti dall’interno del VPC. Per ulteriori informazioni sulla connessione di un rack Outpost alla rete locale, vedi [Come funzionano i gateway locali per i rack nella Guida per](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html) l'utente di Outposts AWS . Se utilizzi l’instradamento VPC diretto e la sottorete dell’Outpost ha un instradamento al gateway locale, gli indirizzi IP privati delle istanze del piano di controllo (control-plane) di Kubernetes vengono trasmessi automaticamente sulla rete locale. L’endpoint del server API Kubernetes del server locale è ospitato in Amazon Route 53 (Route 53). L'endpoint del servizio API può essere risolto dai server DNS pubblici negli indirizzi IP privati dei server dell'API Kubernetes. Le istanze del piano di controllo (control-plane) di Kubernetes dei cluster locali sono configurate con interfacce di rete elastiche statiche con indirizzi IP privati fissi che non cambiano durante il ciclo di vita del cluster. Le macchine che interagiscono con il server API Kubernetes potrebbero non avere connettività a Route 53 durante le disconnessioni di rete. In tal caso, si consiglia di configurare `/etc/hosts` con gli indirizzi IP privati statici per continuare le operazioni. Ti consigliamo inoltre di configurare i server DNS locali e di collegarli al tuo Outpost. Per ulteriori informazioni, consulta la [documentazione di AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns). Esegui il comando riportato per confermare che è stata stabilita la comunicazione con il cluster. ``` 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 ``` 1. (Facoltativo) Verifica l'autenticazione del cluster locale quando si trova in uno stato disconnesso dal cloud. AWS Per istruzioni, consulta [Preparazione di cluster Amazon EKS locali su AWS Outposts per le disconnessioni di rete](eks-outposts-network-disconnects.md). ### Risorse interne Amazon EKS crea le seguenti risorse sul tuo cluster. Le risorse sono destinate all'uso interno di Amazon EKS. Per garantire il corretto funzionamento del cluster, non modificare o alterare queste risorse. + I seguenti [pod mirror](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod): + `aws-iam-authenticator-node-hostname ` + `eks-certificates-controller-node-hostname ` + `etcd-node-hostname ` + `kube-apiserver-node-hostname ` + `kube-controller-manager-node-hostname ` + `kube-scheduler-node-hostname ` + I seguenti componenti aggiuntivi autogestiti: + `kube-system/coredns` + `kube-system/` `kube-proxy` (non viene creato finché non aggiungi il primo nodo) + `kube-system/aws-node` (non viene creato finché non si aggiunge il primo nodo). I cluster locali utilizzano il plug-in per la CNI di Amazon VPC per Kubernetes per le reti di cluster. Non modificare la configurazione per le istanze del piano di controllo (pod denominati `aws-node-controlplane-*`). Ci sono variabili di configurazione che consentono di modificare il valore predefinito quando il plugin crea nuove interfacce di rete. Per ulteriori informazioni, consulta la [documentazione](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) su GitHub. + I seguenti servizi: + `default/kubernetes` + `kube-system/kube-dns` + Una `PodSecurityPolicy` denominata `eks.system` + Una `ClusterRole` denominata `eks:system:podsecuritypolicy` + Una `ClusterRoleBinding` denominata `eks:system` + Oltre al [gruppo di sicurezza del cluster](sec-group-reqs.md), Amazon EKS crea un gruppo di sicurezza denominato nel tuo AWS account`eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid `. Questo gruppo di sicurezza consente al traffico di fluire liberamente tra i componenti Kubernetes in esecuzione sulle istanze del piano di controllo (control-plane). Fasi successive consigliate: + [Concedi al responsabile IAM che ha creato il cluster le autorizzazioni necessarie per visualizzare le risorse Kubernetes nel Console di gestione AWS](view-kubernetes-resources.md#view-kubernetes-resources-permissions) + [Concedere alle entità IAM l'accesso al cluster](grant-k8s-access.md). Per consentire alle entità di visualizzare le risorse Kubernetes nella console Amazon EKS, concedi le relative [autorizzazioni richieste](view-kubernetes-resources.md#view-kubernetes-resources-permissions). + [Configurare la registrazione per il cluster](control-plane-logs.md) + Acquisisci familiarità con ciò che accade durante le [disconnessioni dalla rete](eks-outposts-network-disconnects.md). + [Aggiungere nodi al cluster](eks-outposts-self-managed-nodes.md) + Prendi in considerazione la possibilità di impostare un piano di backup per `etcd`. Amazon EKS non supporta il backup e il ripristino automatici di `etcd` per i cluster locali. Per ulteriori informazioni, consulta [Backing up an etcd cluster](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) nella documentazione di Kubernetes. Le due opzioni principali sono l'utilizzo di `etcdctl` per automatizzare l'acquisizione di snapshot o l'utilizzo del backup del volume di archiviazione di Amazon EBS. # Scopri le versioni della piattaforma Kubernetes e Amazon EKS per Outposts AWS Le versioni della piattaforma cluster locale rappresentano le funzionalità del cluster Amazon EKS su AWS Outposts. Le versioni includono i componenti che vengono eseguiti sul piano di controllo (control-plane) Kubernetes, i cui flag del server API Kubernetes sono abilitati. Includono anche la versione corrente della patch di Kubernetes. Ogni versione secondaria Kubernetes dispone di una o più versioni della piattaforma associate. Le versioni della piattaforma per le diverse versioni secondarie di Kubernetes sono indipendenti. Le versioni della piattaforma per i cluster locali e i cluster Amazon EKS nel cloud sono indipendenti. Quando è disponibile una nuova versione secondaria di Kubernetes per i cluster locali, ad esempio `1.31`, la versione della piattaforma iniziale per tale versione secondaria di Kubernetes inizia da `eks-local-outposts.1`. Tuttavia, Amazon EKS rilascia periodicamente nuove versioni della piattaforma per abilitare nuove impostazioni del piano di controllo Kubernetes e fornire soluzioni per problemi relativi alla sicurezza. Quando nuove versioni della piattaforma del cluster locale diventano disponibili per una versione secondaria: + Il numero di versione della piattaforma viene incrementato (`eks-local-outposts.n+1`). + Amazon EKS aggiorna automaticamente tutti i cluster locali esistenti alla versione della piattaforma più recente per la versione secondaria di Kubernetes corrispondente. Gli aggiornamenti automatici delle versioni della piattaforma esistenti vengono implementati in modo incrementale. Il processo di rollout consiste nella sostituzione delle istanze gestite del piano di controllo (control-plane) Kubernetes in esecuzione su Outpost, una alla volta, fino a quando tutte le 3 non vengono sostituite da istanze nuove. + Il processo di sostituzione delle istanze del piano di controllo (control-plane) Kubernetes verrà arrestato in caso di rischio di interruzione del servizio. Amazon EKS cercherà di sostituire un’istanza del piano di controllo (control-plane) Kubernetes solo nel caso in cui le altre 2 siano integre e soddisfino tutte le condizioni di disponibilità come nodo del cluster. + Il completamento del rollout di una versione della piattaforma richiede in genere meno di 30 minuti. Se un cluster rimane attivo `UPDATING` per un periodo di tempo prolungato, consulta [Risolvi i problemi relativi ai cluster Amazon EKS locali su Outposts AWS](eks-outposts-troubleshooting.md) e chiedi aiuto a AWS Support. Non terminare mai manualmente le istanze del piano di controllo Kubernetes a meno che non venga richiesto da Support. AWS + Amazon EKS potrebbe pubblicare un nuovo nodo AMI con una versione patch corrispondente. Tutte le versioni delle patch sono compatibili tra il piano di controllo e il nodo Kubernetes per una singola versione secondaria di Kubernetes. AMIs Le nuove versioni della piattaforma non introducono modifiche in conflitto né causano interruzioni del servizio. I cluster locali vengono sempre creati con la versione della piattaforma disponibile più recente (`eks-local-outposts.n`) per la versione Kubernetes specificata. Le versioni della piattaforma correnti e recenti sono descritte nelle tabelle qui di seguito. Per ricevere notifiche di tutte le modifiche al file di origine di questa pagina di documentazione specifica, è possibile iscriversi al seguente URL con un lettore RSS: ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom ``` ## Versione `1.31` di Kubernetes I seguenti controller di ammissione sono abilitati per tutte le versioni della piattaforma `1.31`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` e `ValidatingAdmissionWebhook`. | Versione di Kubernetes | Versione della piattaforma Amazon EKS | Note di rilascio | Data di rilascio | | --- | --- | --- | --- | | `1.31.14` | `eks-local-outposts.8` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.31.14` AWS IAM `v0.7.8` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.4`. Versione Bottlerocket aggiornata a `v1.52.0`. | 23 dicembre 2025 | | `1.31.12` | `eks-local-outposts.5` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.31.10` AWS IAM `v0.7.4` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.2`. Versione Bottlerocket aggiornata a `v1.47.0`. | 3 ottobre 2025 | | `1.31.9` | `eks-local-outposts.4` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.31.9` AWS IAM `v0.7.2` Authenticator aggiornato a. Plugin Amazon VPC CNI per Kubernetes aggiornato alla versione Bottlerocket aggiornata a. `v1.20.0` `v1.43.0` | 9 agosto 2025 | | `1.31.7` | `eks-local-outposts.3` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.31.9` AWS IAM `v0.7.1` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.19.5`. Versione Bottlerocket aggiornata a `v1.40.0`. | 19 giugno 2025 | | `1.31.6` | `eks-local-outposts.2` | Nuova versione della piattaforma con correzioni di sicurezza e miglioramenti. Versione Bottlerocket aggiornata a `v1.36.0`. | 24 aprile 2025 | | `1.31.6` | `eks-local-outposts.1` | Rilascio iniziale di Kubernetes versione `v1.31` per cluster Amazon EKS locali su Outposts. | 9 aprile 2025 | ## Versione `1.30` di Kubernetes I seguenti controller di ammissione sono abilitati per tutte le versioni della piattaforma `1.30`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` e `ValidatingAdmissionWebhook`. | Versione di Kubernetes | Versione della piattaforma Amazon EKS | Note di rilascio | Data di rilascio | | --- | --- | --- | --- | | `1.30.14` | `eks-local-outposts.10` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. AWS IAM Authenticator aggiornato a. `v0.7.8` Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.4`. Versione Bottlerocket aggiornata a `v1.52.0`. | 23 dicembre 2025 | | `1.30.14` | `eks-local-outposts.7` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.30.14` AWS IAM `v0.7.4` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.2`. Versione Bottlerocket aggiornata a `v1.47.0`. | 3 ottobre 2025 | | `1.30.13` | `eks-local-outposts.6` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.30.13` AWS IAM `v0.7.2` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.0`. Versione Bottlerocket aggiornata a `v1.43.0`. | 09 agosto 2025 | | `1.30.11` | `eks-local-outposts.5` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.30.11` AWS IAM `v0.7.1` Authenticator aggiornato a. Plugin Amazon VPC CNI per Kubernetes aggiornato alla versione Bottlerocket aggiornata a. `v1.19.5` `v1.40.0` | 19 giugno 2025 | | `1.30.10` | `eks-local-outposts.4` | Nuova versione della piattaforma con correzioni di sicurezza e miglioramenti. Versione Bottlerocket aggiornata a `v1.36.0`. | 24 aprile 2025 | | `1.30.10` | `eks-local-outposts.3` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.30.10` AWS IAM `v0.6.29` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.19.2`. CoredNS aggiornato a. `v1.11.4` AWS Cloud Controller Manager aggiornato a. `v1.30.8` Versione Bottlerocket aggiornata a `v1.34.0`. | 27 marzo 2025 | | `1.30.7` | `eks-local-outposts.2` | Nuova versione della piattaforma con correzioni e miglioramenti alla sicurezza. kube-proxy aggiornato a. `v1.30.7` AWS IAM `v0.6.28` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.19.0`. Versione di Bottlerocket aggiornata a `v1.29.0`. | 10 gennaio 2025 | | `1.30.5` | `eks-local-outposts.1` | Rilascio iniziale di Kubernetes versione `v1.30` per cluster Amazon EKS locali su Outposts. | 13 novembre 2024 | ## Versione `1.29` di Kubernetes I seguenti controller di ammissione sono abilitati per tutte le versioni della piattaforma `1.29`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` e `ValidatingAdmissionWebhook`. | Versione di Kubernetes | Versione della piattaforma Amazon EKS | Note di rilascio | Data di rilascio | | --- | --- | --- | --- | | `1.29.15` | `eks-local-outposts.13` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. AWS IAM Authenticator aggiornato a. `v0.7.8` Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.4`. Versione Bottlerocket aggiornata a `v1.52.0`. | 23 dicembre 2025 | | `v1.29.15` | `eks-local-outposts.10` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. AWS IAM Authenticator aggiornato a. `v0.7.4` Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.2`. Versione Bottlerocket aggiornata a `v1.47.0`. | 3 ottobre 2025 | | `v1.29.15` | `eks-local-outposts.9` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. AWS IAM Authenticator aggiornato a. `v0.7.2` Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.20.0`. Versione Bottlerocket aggiornata a `v1.43.0`. | 9 agosto 2025 | | `v1.29.15` | `eks-local-outposts.8` | Nuova versione della piattaforma con correzioni e miglioramenti di sicurezza. kube-proxy aggiornato a. `v1.29.15` AWS IAM `v0.7.1` Authenticator aggiornato a. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.19.5`. Versione Bottlerocket aggiornata a `v1.40.0`. | 19 giugno 2025 | | `v1.29.14` | `eks-local-outposts.7` | Nuova versione della piattaforma con correzioni di sicurezza e miglioramenti. Versione Bottlerocket aggiornata a `v1.36.0`. | 24 marzo 2025 | | `v1.29.14` | `eks-local-outposts.6` | Nuova versione della piattaforma con correzioni di sicurezza e miglioramenti. kube-proxy aggiornato a `v1.29.14`. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.19.2`. CoredNS aggiornato a. `v1.11.4` AWS Cloud Controller Manager aggiornato a. `v1.29.8` Versione Bottlerocket aggiornata a `v1.34.0`. | 27 marzo 2025 | | `v1.29.11` | `eks-local-outposts.5` | Nuova versione della piattaforma con correzioni di sicurezza e miglioramenti. kube-proxy aggiornato a `v1.29.11`. Plug-in CNI di Amazon VPC per Kubernetes aggiornato a `v1.19.0`. Immagine CoreDNS aggiornata a `v1.11.3`. Versione di Bottlerocket aggiornata a `v1.29.0`. | 10 gennaio 2025 | | `1.29.9` | `eks-local-outposts.4` | Nuova versione della piattaforma con correzioni e miglioramenti alla sicurezza. kube-proxy aggiornato a. `v1.29.9` AWS IAM `v0.6.26` Authenticator aggiornato a. Versione di Bottlerocket aggiornata a `v1.26.0`. | 8 novembre 2024 | | `1.29.6` | `eks-local-outposts.3` | Nuova versione della piattaforma con correzioni di sicurezza e miglioramenti. Versione di Bottlerocket aggiornata a `v1.22.0`. | 22 ottobre 2024 | | `1.29.6` | `eks-local-outposts.2` | Nuova versione della piattaforma con correzioni di sicurezza e miglioramenti. Versione di Bottlerocket aggiornata a `v1.21.0`. | 27 agosto 2024 | | `1.29.6` | `eks-local-outposts.1` | Rilascio iniziale di Kubernetes versione `v1.29` per cluster Amazon EKS locali su Outposts. | 20 agosto 2024 | # Creazione di VPC e sottoreti per i cluster Amazon EKS su AWS Outposts Durante la creazione di un cluster locale, in genere si specificano un VPC e almeno una sottorete privata in esecuzione su Outposts. Questo argomento offre una panoramica dei requisiti e delle considerazioni relativi al VPC e alle sottoreti utilizzate con il cluster locale. ## Considerazioni e requisiti relativi al VPC Durante la creazione di un cluster locale, il VPC specificato deve soddisfare i requisiti e le considerazioni seguenti: + Assicurarsi che il VPC disponga di un numero sufficiente di indirizzi IP per il cluster locale, i nodi e le altre risorse Kubernetes da creare. Se il VPC da utilizzare non dispone di un numero sufficiente di indirizzi IP, aumentane il numero. Tale operazione può essere effettuata [associando i blocchi di instradamento interdominio senza classi (CIDR) secondari](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) al VPC. L'associazione di blocchi di CIDR privati (RFC 1918) e pubblici (non RFC 1918) può avvenire prima o dopo la creazione del cluster. Il riconoscimento del blocco CIDR associato a un VPC da parte del cluster può richiedere fino a cinque ore. + Il VPC non può avere prefissi IP o intervalli CIDR IPv6 assegnati. A causa di queste limitazioni, le informazioni riportate alla pagina [Assign more IP addresses to Amazon EKS nodes with prefixes](cni-increase-ip-addresses.md) e [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md) non sono applicabili al VPC. + Il VPC ha un nome host DNS e una risoluzione DNS abilitati. Senza queste funzionalità la creazione del cluster locale ha esito negativo, quindi dovrai abilitare le funzionalità e creare nuovamente il cluster. Per ulteriori informazioni, consulta [Attributi DNS nel VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) nella Guida per l'utente di Amazon VPC. + Per accedere al cluster locale tramite la rete locale, il VPC deve essere associato alla tabella di instradamento del gateway locale dell'Outpost. Per ulteriori informazioni, consultare la pagina [VPC associations](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations) della Guida per l’utente di AWS Outposts. ## Considerazioni e requisiti relativi alle sottoreti Durante la creazione del cluster, è necessario specificare almeno una sottorete privata. Se si specificano più sottoreti, le istanze del piano di controllo (control-plane) Kubernetes sono distribuite uniformemente tra le sottoreti. Se viene specificata più di una sottorete, le sottoreti devono essere presenti sullo stesso Outpost. Tuttavia, per comunicare tra loro le sottoreti devono avere gli instradamenti corretti e le autorizzazioni del gruppo di sicurezza. Quando crei un cluster locale, le sottoreti specificate devono soddisfare i requisiti seguenti: + Le sottoreti si trovano tutte sullo stesso Outpost logico. + Le sottoreti devono avere complessivamente almeno tre indirizzi IP disponibili per le istanze del piano di controllo (control-plane) Kubernetes. Se sono specificate tre sottoreti, ogni sottorete deve avere almeno un indirizzo IP disponibile. Se sono specificate due sottoreti, ogni sottorete deve avere almeno due indirizzi IP disponibili. Se è specificata una sottorete, la sottorete deve avere almeno tre indirizzi IP disponibili. + Le sottoreti hanno un istradamento al [gateway locale](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) del rack dell’Outpost per accedere al server API Kubernetes sulla rete locale. Se le sottoreti non dispongono di un instradamento per il gateway locale del rack dell’Outpost, è necessario comunicare con il server API Kubernetes dall’interno del VPC. + Le sottoreti devono utilizzare la denominazione basata sull'indirizzo IP. La [denominazione basata sulle risorse](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn) di Amazon EC2 non è supportata da Amazon EKS. ## Accesso della sottorete ai servizi AWS Le sottoreti private del cluster locale su Outposts devono essere in grado di comunicare con i servizi AWS Regionali. Ciò è possibile utilizzando un [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) per l'accesso a Internet in uscita o, se si desidera mantenere privato tutto il traffico all'interno del VPC, tramite gli [endpoint VPC di interfaccia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). ### Utilizzo di un gateway NAT Le sottoreti private del cluster locale su Outposts devono avere una tabella di routing associata con un instradamento a un gateway NAT in una sottorete pubblica che si trova nella zona di disponibilità parent dell’Outpost. La sottorete pubblica deve disporre di una route a un [gateway Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). Il gateway NAT consente l'accesso a Internet in uscita e impedisce le connessioni in entrata non richieste da Internet alle istanze sull'Outpost. ### Utilizzo di endpoint VPC dell'interfaccia Se le sottoreti private del cluster locale su Outposts non dispongono di una connessione Internet in uscita o se si desidera mantenere tutto il traffico privato all’interno del VPC, è necessario creare i seguenti endpoint VPC ed [endpoint gateway](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) in una sottorete Regionale prima di creare il cluster. | Endpoint | Endpoint type (Tipo di endpoint) | | --- | --- | | `com.amazonaws.region-code.ssm` | Interfaccia | | `com.amazonaws.region-code.ssmmessages` | Interfaccia | | `com.amazonaws.region-code.ec2messages` | Interfaccia | | `com.amazonaws.region-code.ec2` | Interfaccia | | `com.amazonaws.region-code.secretsmanager` | Interfaccia | | `com.amazonaws.region-code.logs` | Interfaccia | | `com.amazonaws.region-code.sts` | Interfaccia | | `com.amazonaws.region-code.ecr.api` | Interfaccia | | `com.amazonaws.region-code.ecr.dkr` | Interfaccia | | `com.amazonaws.region-code.s3` | Gateway | Gli endpoint devono soddisfare i seguenti requisiti: + Creato in una sottorete privata situata nella zona di disponibilità parent dell’Outpost + Abilitazione dei nomi DNS privati + Disponi di un gruppo di sicurezza collegato che consente il traffico HTTPS in ingresso dall'intervallo CIDR della sottorete privata dell'Outpost. La creazione di endpoint comporta dei costi. Per ulteriori informazioni, consulta [Prezzi di AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/). Se i pod hanno bisogno di accedere ad altri servizi AWS, sarà necessario creare degli endpoint aggiuntivi. Per un elenco completo degli endpoint, consultare la pagina [AWS services that integrate with AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html). ## Crea un VPC È possibile creare un VPC che soddisfi i requisiti precedenti utilizzando uno dei seguenti modelli AWS CloudFormation: + **[Modello 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml)**: questo modello crea un VPC con una sottorete privata nell’Outpost e una sottorete pubblica nella Regione AWS. La sottorete privata ha un instradamento verso Internet tramite un gateway NAT che si trova nella sottorete pubblica nella Regione AWS. Questo modello può essere utilizzato per creare un cluster locale in una sottorete con accesso a Internet in uscita. + **[Modello 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml)**: questo modello crea un VPC con una sottorete privata sull’Outpost e il set minimo di endpoint VPC necessari per creare un cluster locale in una sottorete che non dispone di accesso a Internet in ingresso o in uscita (nota anche come sottorete privata). # Preparazione di cluster Amazon EKS locali su AWS Outposts per le disconnessioni di rete Se la tua rete locale ha perso la connettività con il cloud AWS, puoi continuare a utilizzare il cluster Amazon EKS locale su un Outpost. Questo argomento illustra come preparare il cluster locale per le disconnessioni di rete e le considerazioni correlate. + I cluster locali consentono la stabilità e la continua operatività durante le disconnessioni di rete temporanee e non pianificate. AWS Outposts rimane un’offerta completamente connessa che funge da estensione del cloud AWS nel tuo data center. In caso di disconnessioni dalla rete tra l’Outpost e il cloud AWS, ti consigliamo di provare a ripristinare la connessione. Per le relative istruzioni, consulta [AWS Outposts rack network troubleshooting checklist](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) nella *Guida per l’utente di AWS Outposts*. Per informazioni su come risolvere i problemi con i cluster locali, consulta [Risolvi i problemi relativi ai cluster Amazon EKS locali su Outposts AWS](eks-outposts-troubleshooting.md). + Gli Outpost emettono un parametro `ConnectedStatus` che puoi utilizzare per monitorare lo stato di connettività del tuo Outpost. Per ulteriori informazioni, consulta [Outposts Metrics](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) nella *Guida per l’utente di AWS Outposts*. + I cluster locali utilizzano IAM come meccanismo di autenticazione predefinito tramite [AWS Identity and Access Management authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator). IAM non è disponibile durante le disconnessioni di rete. Pertanto, i cluster locali supportano un meccanismo di autenticazione alternativo basato sui certificati `x.509` che puoi utilizzare per connetterti al cluster durante le disconnessioni dalla rete. Per informazioni su come ottenere e utilizzare un certificato `x.509` per il tuo cluster, consulta [Autenticazione al cluster locale durante una disconnessione dalla rete](#outposts-network-disconnects-authentication). + Se non riesci ad accedere a Route 53 durante le disconnessioni dalla rete, prendi in considerazione l’utilizzo dei server DNS locali nel tuo ambiente on-premises. Le istanze del piano di controllo (control-plane) di Kubernetes utilizzano indirizzi IP statici. Puoi configurare gli host che utilizzi per connetterti al cluster con il nome host e gli indirizzi IP dell'endpoint anziché utilizzare i server DNS locali. Per ulteriori informazioni, consulta [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) nella *Guida per l’utente di AWS Outposts*. + Se prevedi un aumento del traffico delle applicazioni durante le disconnessioni dalla rete, puoi allocare capacità di elaborazione di riserva nel tuo cluster quando sei connesso al cloud. Le istanze Amazon EC2 sono incluse nel prezzo di AWS Outposts. Pertanto, l’esecuzione di istanze di riserva non influisce sui costi di utilizzo di AWS. + Durante le disconnessioni dalla rete, per consentire le operazioni di creazione, aggiornamento e dimensionamento dei carichi di lavoro, le immagini di container dell'applicazione devono essere accessibili sulla rete locale e il cluster deve disporre di una capacità sufficiente. I cluster locali non ospitano un registro dei container per tuo conto. Se i pod in precedenza sono stati eseguiti su tali nodi, le immagini di container vengono memorizzate nella cache dei nodi. Se in genere estrai le immagini dei container dell'applicazione da Amazon ECR nel cloud, prendi in considerazione l'esecuzione di una cache o di un registro locale. Una cache o un registro locale è utile se hai bisogno di creare, aggiornare e dimensionare le risorse del carico di lavoro durante le disconnessioni dalla rete. + I cluster locali utilizzano Amazon EBS come classe di archiviazione predefinita per i volumi persistenti e il driver Amazon EBS CSI per gestire il ciclo di vita dei volumi persistenti di Amazon EBS. Durante le disconnessioni di rete, i pod supportati da Amazon EBS non possono essere creati, aggiornati o dimensionati. Questo perché queste operazioni richiedono chiamate all'API Amazon EBS nel cloud. Se stai implementando carichi di lavoro stateful su cluster locali e hai bisogno di creare, aggiornare o dimensionare le operazioni durante le disconnessioni dalla rete, prendi in considerazione l’utilizzo di un meccanismo di archiviazione alternativo. + Gli snapshot di Amazon EBS non possono essere creati o eliminati se AWS Outposts non può accedere alle API pertinenti nella Regione AWS (ad esempio le API per Amazon EBS o Amazon S3). + Quando integri ALB (ingresso) con Gestione certificati AWS (ACM), i certificati vengono inviati e archiviati nella memoria dell’istanza AWS Outposts ALB Compute. Il terminale TLS corrente continuerà a funzionare in caso di disconnessione dalla Regione AWS. La modifica delle operazioni in questo contesto non riuscirà (ad esempio nuove definizioni di ingresso, nuove operazioni dell'API su certificati ACM, dimensionamento del calcolo ALB o rotazione dei certificati). Per ulteriori informazioni, consulta [Troubleshooting managed certificate renewal](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html) nella *Guida per l’utente di Gestione certificati AWS*. + I registri del piano di controllo (control-plane) di Amazon EKS vengono memorizzati nella cache locale sulle istanze del piano di controllo (control-plane) di Kubernetes durante le disconnessioni dalla rete. Dopo la riconnessione, i log vengono inviati a CloudWatch Logs nella Regione AWS principale. Per monitorare il cluster in locale utilizzando l’endpoint dei parametri del server API Kubernetes o Fluent Bit per i log, puoi utilizzare [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/) e le soluzioni partner di Amazon EKS. + Se stai utilizzando AWS Load Balancer Controller su Outposts per il traffico delle applicazioni, i pod esistenti anticipati da AWS Load Balancer Controller continueranno a ricevere traffico durante le disconnessioni di rete. I nuovi pod creati durante le disconnessioni dalla rete non ricevono traffico fino a quando l’Outpost non ristabilisce la connessione con il cloud AWS. Puoi impostare il numero di repliche per le tue applicazioni mentre effettui la connessione al cloud AWS in base alle tue esigenze di dimensionamento durante le disconnessioni di rete. + Il plug-in della CNI di Amazon VPC per Kubernetes utilizza per impostazione predefinita la [modalità IP secondaria](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview). È configurato con `WARM_ENI_TARGET`=`1`, che consente al plug-in di mantenere disponibile “un’interfaccia di rete completamente elastica” degli indirizzi IP disponibili. Puoi modificare i valori `WARM_ENI_TARGET`, `WARM_IP_TARGET` e `MINIMUM_IP_TARGET` in base alle tue esigenze di scalabilità durante uno stato di disconnessione. Per ulteriori informazioni, consulta il file [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) per il plug-in su GitHub. Per un elenco del numero massimo di pod supportati da ciascun tipo di istanza, consulta il file [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) su GitHub. ## Autenticazione al cluster locale durante una disconnessione dalla rete AWS Identity and Access Management (IAM) non è disponibile durante le disconnessioni di rete. Non puoi autenticarti nel cluster locale utilizzando le credenziali IAM durante una disconnessione. Tuttavia, durante la disconnessione, potrai connetterti al cluster tramite la rete locale utilizzando i certificati `x509`. È necessario scaricare e archiviare un certificato `X509` client da utilizzare durante le disconnessioni. In questo argomento viene illustrato come creare e utilizzare il certificato per autenticarsi nel cluster quando è disconnesso. 1. Creare una richiesta di firma del certificato. 1. Genera una richiesta di firma del certificato. ``` openssl req -new -newkey rsa:4096 -nodes -days 365 \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Crea una richiesta di firma del certificato in Kubernetes. ``` BASE64_CSR=$(cat admin.csr | base64 -w 0) cat << EOF > admin-csr.yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: signerName: kubernetes.io/kube-apiserver-client request: ${BASE64_CSR} usages: - client auth EOF ``` 1. Crea una richiesta di firma del certificato utilizzando `kubectl`. ``` kubectl create -f admin-csr.yaml ``` 1. Controlla lo stato della richiesta di firma del certificato. ``` kubectl get csr admin-csr ``` Di seguito viene riportato un output di esempio: ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Pending ``` Kubernetes ha creato la richiesta di firma del certificato. 1. Approva la richiesta di firma del certificato. ``` kubectl certificate approve admin-csr ``` 1. Controlla nuovamente lo stato della richiesta di firma del certificato per l'approvazione. ``` kubectl get csr admin-csr ``` Di seguito viene riportato un output di esempio: ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Approved ``` 1. Recupera e verifica il certificato. 1. Recupera il certificato. ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. Verifica il certificato. ``` cat admin.crt ``` 1. Crea un'associazione di ruoli del cluster per un utente `admin`. ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. Genera un kubeconfig con ambito utente per uno stato disconnesso. Puoi generare un file `kubeconfig` utilizzando il certificati `admin` scaricati. Sostituisci *my-cluster* e *apiserver-endpoint* nei comandi seguenti. ``` aws eks describe-cluster --name my-cluster \ --query "cluster.certificateAuthority" \ --output text | base64 --decode > ca.crt ``` ``` kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server apiserver-endpoint --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin ``` ``` kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster ``` 1. Visualizza il file `kubeconfig`. ``` kubectl get nodes --kubeconfig admin.kubeconfig ``` 1. Se disponi di servizi già in produzione sul tuo Outpost, salta questo passaggio. Se Amazon EKS è l’unico servizio in esecuzione sul tuo Outpost e quest’ultimo non è attualmente in produzione, puoi simulare una disconnessione di rete. Prima di entrare in produzione con il cluster locale, puoi simulare una disconnessione per assicurarti di riuscire ad accedere al cluster quando è in uno stato disconnesso. 1. Applica le regole del firewall sui dispositivi di rete che connettono il tuo Outpost alla Regione AWS. Questo disconnette il link del servizio dell'Outpost. Non puoi creare nuove istanze. Le istanze attualmente in esecuzione perdono la connettività con la Regione AWS e internet. 1. Puoi testare la connessione al cluster locale durante una disconnessione tramite il certificato `x509`. Assicurati di modificare la `kubeconfig` con il `admin.kubeconfig` che hai creato in una fase precedente. Sostituisci *my-cluster* con il nome del cluster locale. ``` kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig ``` Se riscontri problemi con i cluster locali mentre sono disconnessi, ti consigliamo di inviare una richiesta di supporto. # Selezione dei tipi di istanze e dei gruppi di posizionamento per i cluster Amazon EKS su AWS Outposts in base alle considerazioni sulla capacità Questo argomento fornisce assistenza per la selezione del tipo di istanza del piano di controllo (control-plane) di Kubernetes e (facoltativamente) per l’uso di gruppi di posizionamento per soddisfare requisiti di alta disponibilità per il tuo cluster Amazon EKS locale su un Outpost. Prima di selezionare un tipo di istanza (`m5`, `c5` o `r5`) da utilizzare per il piano di controllo (control-plane) di Kubernetes del cluster locale su Outposts, devi verificare i tipi di istanza disponibili nella configurazione dell’Outpost. Dopo aver identificato i tipi di istanza disponibili, devi selezionare la dimensione dell'istanza (`large`, `xlarge` o `2xlarge`) in base al numero di nodi richiesti dai carichi di lavoro. La tabella seguente fornisce consigli per la selezione della dimensione dell'istanza. **Nota** Le dimensioni delle istanze devono essere assegnate ai tuoi Outposts. Assicurati di disporre di una capacità sufficiente per tre istanze della dimensione disponibile negli Outposts per tutta la durata del cluster locale. Per un elenco dei tipi di istanza Amazon EC2 disponibili, consulta le sezioni relative al calcolo e all’archiviazione in [Funzionalità dei rack AWS Outposts](https://aws.amazon.com/outposts/rack/features/). | Numero di nodi | Dimensione dell'istanza del piano di controllo (control-plane) Kubernetes | | --- | --- | | 1-20 | `large` | | 21-100 | `xlarge` | | 101-250 | `2xlarge` | | 251-500 | `4xlarge` | L’archiviazione per il piano di controllo (control-plane) di Kubernetes richiede 246 GB di spazio di archiviazione Amazon EBS per cluster locale per soddisfare gli IOPS richiesti per `etcd`. Quando viene creato il cluster, i volumi Amazon EBS vengono allocati automaticamente per tuo conto. ## Collocamento del piano di controllo (control-plane) Se non specifichi un gruppo di posizionamento con la proprietà `OutpostConfig.ControlPlanePlacement.GroupName`, le istanze Amazon EC2 fornite per il tuo piano di controllo (control-plane) di Kubernetes non ricevono alcuna specifica applicazione del collocamento dell’hardware nella capacità sottostante disponibile sul tuo Outpost. Puoi utilizzare gruppi di collocamento per soddisfare i requisiti di alta disponibilità del tuo cluster Amazon EKS locale su un Outpost. Specificando un gruppo di posizionamento durante la creazione del cluster, influisci sul collocamento delle istanze del piano di controllo (control-plane) di Kubernetes. Le istanze sono distribuite su un hardware sottostante indipendente (rack o host), riducendo al minimo l'impatto di istanze correlate in caso di guasti hardware. Il tipo di spread che puoi configurare dipende dal numero di rack Outpost esistenti nella tua implementazione. + **Implementazioni con uno o due rack fisici in un unico Outpost logico**: occorrono almeno tre host configurati con il tipo di istanza scelto per le tue istanze del piano di controllo (control plane) di Kubernetes. Un gruppo di posizionamento degli *spread* che utilizza lo *spread a livello di host* garantisce che tutte le istanze del piano di controllo (control-plane) di Kubernetes vengano eseguite su host distinti all’interno dei rack sottostanti disponibili nella tua implementazione Outpost. + **Implementazioni con tre o più rack fisici in un unico Outpost logico**: occorrono almeno tre host configurati con il tipo di istanza scelto per le tue istanze del piano di controllo (control plane) di Kubernetes. Un gruppo di posizionamento degli *spread* che utilizza lo *spread a livello di rack* garantisce che tutte le istanze del piano di controllo (control-plane) di Kubernetes vengano eseguite su rack distinti nella tua implementazione Outpost. In alternativa, puoi utilizzare il gruppo di collocamento *spread a livello di host* come descritto nell'opzione precedente. Sei responsabile della creazione del gruppo di collocamento desiderato. Specifichi il gruppo di collocamento quando richiami l'API `CreateCluster`. Per ulteriori informazioni, sui gruppi di posizionamento e per le istruzioni per crearli, consulta [Placement Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) nella Guida per l’utente di Amazon EC2. + Quando viene specificato un gruppo di collocamento, deve essere disponibile una capacità slot sull'Outpost per creare correttamente un cluster Amazon EKS locale. La capacità varia a seconda se utilizzi il tipo di spread host o rack. Se la capacità è insufficiente, il cluster rimane nello stato `Creating`. Puoi controllare `Insufficient Capacity Error` nel campo di integrità della risposta dell’API [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Devi liberare capacità per l'avanzamento del processo di creazione. + Durante gli aggiornamenti della piattaforma e della versione del cluster locale Amazon EKS, le istanze del piano di controllo (control-plane) di Kubernetes dal tuo cluster vengono sostituite da nuove istanze utilizzando una strategia di aggiornamento in sequenza. Durante questo processo di sostituzione, ogni istanza del piano di controllo (control plane) termina, liberando il rispettivo slot. Al suo posto viene fornita una nuova istanza aggiornata. L'istanza aggiornata potrebbe essere collocata nello slot che è stato rilasciato. Se lo slot viene utilizzato da un'altra istanza non correlata e la capacità rimanente non soddisfa i requisiti di topologia spread richiesti, il cluster rimane nello stato `Updating`. Puoi controllare il rispettivo `Insufficient Capacity Error` nel campo di integrità della risposta dell’API [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Devi liberare la capacità per l'avanzamento del processo di aggiornamento e la ridefinizione dei livelli di alta disponibilità precedenti. + In ogni Regione AWS puoi creare un massimo di 500 gruppi di posizionamento per account. Per ulteriori informazioni, consulta [General rules and limitations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general) nella Guida per l’utente di Amazon EC2. # Risolvi i problemi relativi ai cluster Amazon EKS locali su Outposts AWS Questo argomento illustra alcuni errori comuni che si potrebbero verificare durante l'utilizzo dei cluster locali e il modo in cui risolverli. I cluster locali siano simili ai cluster Amazon EKS sul cloud, ma esistono delle differenze nel modo in cui sono gestiti da Amazon EKS. **Importante** Non terminare mai alcuna istanza del `Kubernetes` piano di controllo del cluster locale EKS gestita in esecuzione su Outpost a meno che non venga esplicitamente richiesto da Support. AWS La terminazione di queste istanze comporta un rischio per la disponibilità dei servizi del cluster locale, inclusa la perdita del cluster locale nel caso in cui più istanze vengano terminate contemporaneamente. Le istanze del `Kubernetes` piano di controllo del cluster locale EKS sono identificate dal tag sulla console dell'istanza. `eks-local:controlplane-name` EC2 ## Funzionamento dell'API I cluster locali vengono creati tramite l'API Amazon EKS, ma vengono eseguiti in modo asincrono. Ciò significa che le richieste all'API Amazon EKS vengono restituite immediatamente per i cluster locali. Tuttavia, queste richieste potrebbero avere esito positivo, anticipare l’errore a causa di errori di convalida degli input oppure fallire e riportare errori di convalida descrittivi. Questo funzionamento è simile a quello dell’API Kubernetes. I cluster locali non effettuano la transizione a uno stato `FAILED`. Amazon EKS prova a riconciliare lo stato del cluster con lo stato desiderato richiesto dall'utente in modo continuo. Di conseguenza, un cluster locale può rimanere a lungo nello stato `CREATING`, fino a quando il problema di base non viene risolto. ## Descrizione del campo di integrità del cluster I problemi relativi ai cluster locali possono essere scoperti utilizzando il comando [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) Amazon EKS AWS CLI. I problemi relativi ai cluster locali vengono evidenziati dal campo `cluster.health` della risposta del comando `describe-cluster`. Il messaggio contenuto in questo campo include un codice di errore, un messaggio descrittivo e una risorsa correlata. IDs Queste informazioni sono disponibili solo tramite l'API e la AWS CLI di Amazon EKS. Nell'esempio seguente, sostituiscilo *my-cluster* con il nome del tuo cluster locale. ``` aws eks describe-cluster --name my-cluster --query 'cluster.health' ``` Di seguito viene riportato un output di esempio. ``` { "issues": [ { "code": "ConfigurationConflict", "message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.", "resourceIds": [ "my-cluster-arn" ] } ] } ``` Se il problema non è risolvibile, potrebbe essere necessario eliminare il cluster locale e crearne uno nuovo. Ad esempio, ciò potrebbe verificarsi nel caso in cui si provi ad allocare un cluster con un tipo di istanza che non è disponibile sul tuo Outpost. La tabella seguente include gli errori più comuni relativi allo stato di integrità. | Scenario di errore | Codice | Messaggio | ResourceIds | | --- | --- | --- | --- | | Non è stato possibile trovare le sottoreti fornite. | `ResourceNotFound` | `The subnet ID subnet-id does not exist` | Tutte le sottoreti fornite IDs | | Le sottoreti fornite non appartengono allo stesso VPC. | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | Tutte le sottoreti fornite IDs | | Alcune delle sottoreti fornite non appartengono all’Outpost specificato. | `ConfigurationConflict` | `Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn ` | ID della sottorete problematico | | Alcune delle sottoreti fornite non appartengono ad alcun Outpost. | `ConfigurationConflict` | `Subnet subnet-id is not part of any Outpost` | ID della sottorete problematico | | Alcune sottoreti fornite non dispongono di indirizzi liberi sufficienti per creare interfacce di rete elastiche per le istanze del piano di controllo (control-plane). | `ResourceLimitExceeded` | `The specified subnet does not have enough free addresses to satisfy the request.` | ID della sottorete problematico | | Il tipo di istanza del piano di controllo (control-plane) specificato non è supportato sul tuo Outpost. | `ConfigurationConflict` | `The instance type type is not supported in Outpost outpost-arn ` | ARN del cluster | | Hai terminato un' EC2 istanza Amazon del piano di controllo o l'operazione `run-instance` è stata completata, ma lo stato ha rilevato modifiche a. `Terminated` Ciò può verificarsi per un periodo di tempo dopo la riconnessione di Outpost e gli errori interni di Amazon EBS causano il fallimento di un flusso di lavoro EC2 interno di Amazon. | `InternalFailure` | `EC2 instance state "Terminated" is unexpected` | ARN del cluster | | Capacità insufficiente nell'Outpost. Ciò può verificarsi anche quando viene creato un cluster se un Outpost è disconnesso dalla regione. AWS | `ResourceLimitExceeded` | `There is not enough capacity on the Outpost to launch or start the instance.` | ARN del cluster | | Il tuo account supera la quota del gruppo di sicurezza | `ResourceLimitExceeded` | Messaggio di errore restituito dall' EC2 API Amazon | ID del VPC di destinazione | | Il tuo account supera la quota dell'interfaccia di rete elastica | `ResourceLimitExceeded` | Messaggio di errore restituito dall' EC2 API Amazon | ID della sottorete di destinazione | | Le istanze del piano di controllo non erano raggiungibili tramite Systems Manager AWS . Per la risoluzione, consulta la sezione [Le istanze del piano di controllo non sono raggiungibili tramite Systems Manager AWS](#outposts-troubleshooting-control-plane-instances-ssm). | `ClusterUnreachable` | Le istanze del piano di controllo di Amazon EKS non sono raggiungibili tramite SSM. Verifica la configurazione SSM e di rete e fai riferimento alla documentazione per la risoluzione dei problemi di EKS su Outposts. | EC2 Istanza Amazon IDs | | Si è verificato un errore durante la raccolta dei dettagli per un gruppo di sicurezza gestito o un'interfaccia di rete elastica. | Basato sul codice di errore EC2 del client Amazon. | Messaggio di errore restituito dall' EC2 API Amazon | Tutti i gruppi di sicurezza gestiti IDs | | Si è verificato un errore durante l'autorizzazione o la revoca delle regole di ingresso dei gruppi di sicurezza. Questo vale per i gruppi di sicurezza sia del cluster sia del piano di controllo. | Basato sul codice di errore EC2 del client Amazon. | Messaggio di errore restituito dall' EC2 API Amazon | ID gruppo di sicurezza problematico | | Si è verificato un errore durante l'eliminazione di un'interfaccia di rete elastica per un'istanza del piano di controllo | Basato sul codice di errore EC2 del client Amazon. | Messaggio di errore restituito dall' EC2 API Amazon | ID dell'interfaccia di rete elastica problematica | La tabella seguente elenca gli errori di altri AWS servizi presentati nel campo relativo allo stato della `describe-cluster` risposta. | Codice EC2 di errore Amazon | Codice del problema di integrità del cluster | Description | | --- | --- | --- | | `AuthFailure` | `AccessDenied` | Questo problema può verificarsi per una serie di motivi. Di solito si verificano se un tag utilizzato dal servizio per definire la policy dei ruoli collegati al servizio viene rimosso accidentalmente dal piano di controllo. In tal caso, Amazon EKS non può più gestire e monitorare queste AWS risorse. | | `UnauthorizedOperation` | `AccessDenied` | Questo problema può verificarsi per una serie di motivi. Di solito si verificano se un tag utilizzato dal servizio per definire la policy dei ruoli collegati al servizio viene rimosso accidentalmente dal piano di controllo. In tal caso, Amazon EKS non può più gestire e monitorare queste AWS risorse. | | `InvalidSubnetID.NotFound` | `ResourceNotFound` | Questo errore si verifica quando non viene trovato l’ID di sottorete per le regole di ingresso di un gruppo di sicurezza. | | `InvalidPermission.NotFound` | `ResourceNotFound` | Questo errore si verifica quando le autorizzazioni per le regole di ingresso di un gruppo di sicurezza non sono corrette. | | `InvalidGroup.NotFound` | `ResourceNotFound` | Questo errore si verifica quando non viene trovato il gruppo delle regole di ingresso di un gruppo di sicurezza. | | `InvalidNetworkInterfaceID.NotFound` | `ResourceNotFound` | Questo errore si verifica quando non viene trovato l’ID dell’interfaccia di rete per le regole di ingresso di un gruppo di sicurezza. | | `InsufficientFreeAddressesInSubnet` | `ResourceLimitExceeded` | Questo errore si verifica quando viene superata la quota di risorse della sottorete. | | `InsufficientCapacityOnOutpost` | `ResourceLimitExceeded` | Questo errore si verifica quando viene superata la quota di capacità dell'outpost. | | `NetworkInterfaceLimitExceeded` | `ResourceLimitExceeded` | Questo errore si verifica quando viene superata la quota dell'interfaccia di rete elastica. | | `SecurityGroupLimitExceeded` | `ResourceLimitExceeded` | Questo errore si verifica quando viene superata la quota del gruppo di sicurezza. | | `VcpuLimitExceeded` | `ResourceLimitExceeded` | Ciò si verifica quando si crea un' EC2 istanza Amazon in un nuovo account. L'errore potrebbe essere simile al seguente: "`You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."` | | `InvalidParameterValue` | `ConfigurationConflict` | Amazon EC2 restituisce questo codice di errore se il tipo di istanza specificato non è supportato su Outpost. | | Tutti gli altri errori | `InternalFailure` | Nessuno | ## Impossibile creare o modificare i cluster I cluster locali richiedono autorizzazioni e policy diverse rispetto ai cluster Amazon EKS ospitati nel cloud. Quando un cluster non riesce a creare e produce un `InvalidPermissions` errore, ricontrolla che al ruolo del cluster che stai utilizzando sia associata la policy EKSLocal OutpostClusterPolicy gestita da [Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). Tutte le altre chiamate API richiedono lo stesso set di autorizzazioni dei cluster Amazon EKS sul cloud. ## Il cluster è bloccato nello stato `CREATING` La quantità di tempo necessaria per creare un cluster locale varia a seconda di diversi fattori. Questi fattori includono la configurazione della rete, dell’Outpost e del cluster. In generale, viene creato un cluster locale che passa allo stato `ACTIVE` entro 15-20 minuti. Se un cluster locale rimane nello stato `CREATING`, puoi richiamare `describe-cluster` per informazioni sulla causa nel campo di output `cluster.health`. I problemi più comuni sono i seguenti: + Il cluster non può connettersi all'istanza del piano di controllo dalla AWS regione in cui si trova Systems Manager. Puoi eseguire una verifica chiamando `aws ssm start-session --target instance-id ` da un host bastione nella regione. Se il comando non funziona, controlla se Systems Manager è in esecuzione sull’istanza del piano di controllo (control-plane). Oppure, un'altra soluzione alternativa consiste nell'eliminare il cluster e quindi ricrearlo. + Le istanze del piano di controllo (control-plane) non vengono create a causa delle autorizzazioni della chiave KMS per i volumi EBS. Con le chiavi KMS gestite dall’utente per i volumi EBS crittografati, le istanze del piano di controllo (control-plane) termineranno se la chiave non è accessibile. Se le istanze vengono terminate, passa a una chiave KMS AWS gestita o assicurati che la politica delle chiavi gestite dagli utenti conceda le autorizzazioni necessarie per il ruolo del cluster. + Le istanze del piano di controllo di Systems Manager potrebbero non avere accesso a Internet. Verifica se la sottorete fornita durante la creazione del cluster dispone di un gateway NAT e un VPC con un gateway Internet. Usa VPC Reachability Analyzer per verificare se l'istanza del control plane può raggiungere il gateway Internet. Per ulteriori informazioni, consulta la sezione [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) (Nozioni di base su VPC Reachability Analyzer). + L'ARN del ruolo fornito è privo di alcune policy. Verifica se la [policy AWS gestita: Amazon EKSLocal OutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) è stata rimossa dal ruolo. Ciò può verificarsi anche se uno AWS CloudFormation stack non è configurato correttamente. + Tutte le sottoreti fornite devono essere associate allo stesso Outpost ed essere in grado di raggiungersi tra loro. Quando vengono specificate più sottoreti durante la creazione del cluster, Amazon EKS prova a distribuire le istanze del piano di controllo su più sottoreti. + I gruppi di sicurezza gestiti da Amazon EKS vengono applicati all'interfaccia di rete elastica. Tuttavia, altri elementi di configurazione, come le regole del firewall NACL, potrebbero essere in conflitto con le regole per l'interfaccia di rete elastica. **La configurazione del DNS del VPC e della sottorete non è configurata correttamente o è assente** Consulta [Creare un VPC e sottoreti per i cluster Amazon EKS](eks-outposts-vpc-subnet-requirements.md) su Outposts. AWS ## Il cluster è bloccato nello stato `UPDATING` Amazon EKS aggiorna automaticamente tutti i cluster locali esistenti alla versione della piattaforma più recente per la versione secondaria di Kubernetes corrispondente. Per ulteriori informazioni sulle versioni della piattaforma, consulta [Scopri le versioni della piattaforma Kubernetes e Amazon EKS per Outposts AWS](eks-outposts-platform-versions.md). Durante l’implementazione automatica di una versione della piattaforma, lo stato di un cluster cambia in `UPDATING`. Il processo di aggiornamento consiste nella sostituzione di tutte le istanze del piano di controllo (control-plane) Kubernetes con nuove istanze contenenti le patch di sicurezza e le correzioni di bug più recenti rilasciate per la rispettiva versione secondaria di Kubernetes. In generale, il processo di aggiornamento della piattaforma di un cluster locale viene completato in meno di 30 minuti e il cluster torna allo stato `ACTIVE`. Se un cluster locale rimane nello stato `UPDATING` per un periodo di tempo prolungato, puoi chiamare `describe-cluster` per controllare le informazioni sulla causa nel campo di output `cluster.health`. Amazon EKS garantisce che almeno due istanze del piano di controllo (control-plane) Kubernetes su tre siano nodi del cluster integri e operativi, al fine di mantenere la disponibilità del cluster locale e prevenire l’interruzione del servizio. Se un cluster locale è bloccato in uno stato `UPDATING`, di solito è perché c’è qualche problema di infrastruttura o di configurazione che impedisce di garantire la disponibilità minima delle due istanze nel caso in cui il processo continui. Pertanto, il processo di aggiornamento arresta l’avanzamento per proteggere l’interruzione del servizio del cluster locale. È importante risolvere i problemi di un cluster locale bloccato nello stato `UPDATING` e risolvere la causa principale in modo che il processo di aggiornamento possa essere completato e ripristinare il cluster locale nello stato `ACTIVE` con l’elevata disponibilità di tre istanze del piano di controllo (control-plane) Kubernetes. Non terminare alcuna `Kubernetes` istanza di cluster locale EKS gestita su Outposts a meno che non venga esplicitamente richiesto da Support. AWS Ciò è particolarmente importante per i cluster locali bloccati nello stato `UPDATING`, perché esiste un’alta probabilità che altri nodi del piano di controllo (control-plane) non siano completamente integri e la terminazione dell’istanza sbagliata potrebbe causare l’interruzione del servizio e il rischio di perdita dei dati del cluster locale. I problemi più comuni sono i seguenti: + Una o più istanze del piano di controllo (control-plane) non sono in grado di connettersi a System Manager a causa di una modifica della configurazione di rete avvenuta dopo la prima creazione del cluster locale. Puoi eseguire una verifica chiamando `aws ssm start-session --target instance-id ` da un host bastione nella regione. Se il comando non funziona, controlla se Systems Manager è in esecuzione sull’istanza del piano di controllo (control-plane). + Impossibile creare nuove istanze del piano di controllo (control-plane) a causa delle autorizzazioni chiave KMS per i volumi EBS. Con le chiavi KMS gestite dall’utente per i volumi EBS crittografati, le istanze del piano di controllo (control-plane) termineranno se la chiave non è accessibile. Se le istanze vengono terminate, passa a una chiave KMS gestita o assicurati che la politica delle chiavi AWS gestite dagli utenti conceda le autorizzazioni necessarie per il ruolo del cluster. + Le istanze del piano di controllo (control-plane) di Systems Manager potrebbero aver perso l’accesso a internet. Verifica se la sottorete fornita durante la creazione del cluster dispone di un gateway NAT e un VPC con un gateway Internet. Usa VPC Reachability Analyzer per verificare se l'istanza del control plane può raggiungere il gateway Internet. Per ulteriori informazioni, consulta la sezione [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) (Nozioni di base su VPC Reachability Analyzer). Se le reti private non dispongono di una connessione internet in uscita, assicurati che tutti gli endpoint VPC e gli endpoint gateway richiesti siano ancora presenti nella sottorete regionale del cluster (consulta [Accesso della sottorete ai servizi AWS](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)). + L'ARN del ruolo fornito è privo di alcune policy. Verifica se la [policy AWS gestita: Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) non EKSLocal OutpostClusterPolicy è stata rimossa dal ruolo. + Una delle nuove istanze del piano di controllo (control-plane) Kubernetes potrebbe aver subito un errore di bootstrap imprevisto. Invia un ticket al [centro di Supporto AWS](https://console.aws.amazon.com/support/home) per ulteriori indicazioni sulla risoluzione dei problemi e sulla raccolta dei log in questo caso eccezionale. ## Impossibile unire i nodi a un cluster + Problemi relativi alle AMI: + Stai usando un'AMI incompatibile. È supportato solo Amazon Linux 2 AMIs ottimizzato per Amazon EKS (`amazon-linux-2`,`amazon-linux-2-gpu`,`amazon-linux-2-arm64`). Se tenti di unire AL2 023 nodi a EKS LocalClusters su AWS Outposts, i nodi non riescono a unirsi al cluster. Per ulteriori informazioni, consulta [Creare nodi Amazon Linux su AWS Outposts](eks-outposts-self-managed-nodes.md). + Se hai usato un AWS CloudFormation modello per creare i tuoi nodi, assicurati che non usasse un'AMI non supportata. + Manca l' AWS IAM Authenticator`ConfigMap`: se manca, devi crearlo. Per ulteriori informazioni, consulta [Applica la `aws-auth` `ConfigMap` al cluster](auth-configmap.md#aws-auth-configmap). + È stato utilizzato un gruppo di sicurezza non corretto: assicurati di utilizzare `eks-cluster-sg-cluster-name-uniqueid ` per il gruppo di sicurezza dei nodi worker. Il gruppo di sicurezza selezionato viene modificato AWS CloudFormation per consentire un nuovo gruppo di sicurezza ogni volta che viene utilizzato lo stack. + A seguito dei passaggi del VPC di collegamento privato imprevisto: vengono passati dati CA (`--b64-cluster-ca`) o API Endpoint (`--apiserver-endpoint`) errati. ## Raccolta di registri Quando un Outpost viene disconnesso dalla AWS regione a cui è associato, è probabile che il cluster Kubernetes continui a funzionare normalmente. Tuttavia, se il cluster non funziona correttamente, segui la procedura di risoluzione dei problemi in [Preparare i cluster Amazon EKS locali su AWS Outposts per](eks-outposts-network-disconnects.md) le disconnessioni di rete. Se riscontri altri problemi, contatta l' AWS assistenza. AWS Support può aiutarti a scaricare ed eseguire uno strumento di raccolta dei log. In questo modo, puoi raccogliere i log dalle istanze del piano di controllo del cluster Kubernetes e inviarli all'assistenza AWS Support per ulteriori indagini. ## Le istanze del piano di controllo non sono raggiungibili tramite Systems Manager AWS Quando le istanze del piano di controllo di Amazon EKS non sono raggiungibili tramite AWS Systems Manager (Systems Manager), Amazon EKS visualizza il seguente errore per il cluster. ``` Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation. ``` Per risolvere questo problema, assicurati che il tuo VPC e le sottoreti soddisfino i requisiti in Creare [un VPC e sottoreti per i cluster Amazon EKS su AWS Outposts e](eks-outposts-vpc-subnet-requirements.md) di aver completato i passaggi descritti nella Configurazione di Session Manager nella Systems Manager [User](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) Guide. AWS # Crea nodi Amazon Linux su AWS Outposts **Importante** Amazon EKS Local Clusters on Outposts supporta solo nodi creati dai seguenti Amazon Linux 2023 ottimizzati per Amazon EKS: AMIs Amazon Linux 2023 standard (`amazon-linux-2023/x86_64/standard`) Nvidia Amazon Linux 2023 accelerato () `amazon-linux-2023/x86_64/nvidia` Neurone accelerato Amazon Linux 2023 () `amazon-linux-2023/x86_64/neuron` AWS ha terminato il supporto per EKS AL2 ottimizzato e AL2 accelerato AMIs, a partire dal 26 novembre 2025. Sebbene tu possa continuare a utilizzare EKS AL2 AMIs dopo la data end-of-support (EOS) (26 novembre 2025), EKS non rilascerà più nuove versioni o aggiornamenti di Kubernetes AL2 AMIs, incluse versioni minori, patch e correzioni di bug dopo questa data. [Consulta questo articolo per ulteriori informazioni sulla deprecazione.](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) AL2 In questo argomento viene descritto come avviare gruppi con scalabilità automatica di nodi Amazon Linux su un Outpost che si registrano con il cluster Amazon EKS. Il cluster può essere sul AWS Cloud o su un Outpost. + Un Outpost esistente. Per ulteriori informazioni, consulta [What is AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html). + Un cluster Amazon EKS esistente. Per distribuire un cluster sul AWS cloud, consulta. [Crea un cluster Amazon EKS.](create-cluster.md) Per implementare un cluster su un Outpost, consulta la sezione [Creazione di cluster Amazon EKS locali su AWS Outposts per un’elevata disponibilità](eks-outposts-local-cluster-overview.md). + Supponiamo di creare i nodi in un cluster sul AWS Cloud e di disporre di sottoreti nella AWS regione in cui sono abilitati Outposts AWS , Wavelength AWS o Local Zones. AWS Quindi, le sottoreti non devono essere state passate al momento della creazione del cluster. Se stai creando i nodi in un cluster su un Outpost, durante la creazione del cluster devi avere passato una sottorete Outpost. + (Consigliato per i cluster sul AWS cloud) Il plug-in CNI Amazon VPC per Kubernetes è configurato con il proprio ruolo IAM a cui è associata la politica IAM necessaria. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md). I cluster locali non supportano i ruoli IAM per gli account di servizio. Puoi creare un gruppo di nodi Amazon Linux autogestito con `eksctl` o Console di gestione AWS (con un AWS CloudFormation modello). Puoi anche utilizzare Terraform. Puoi creare un gruppo di nodi autogestito per il cluster locale con i seguenti strumenti descritti in questa pagina: + [`eksctl`](#eksctl_create_nodes_outpost) + [Console di gestione AWS](#console_create_nodes_outpost) **Importante** Il gruppo di nodi autogestito include EC2 istanze Amazon nel tuo account. Queste istanze non vengono aggiornate in automatico quando l’utente o Amazon EKS aggiorna la versione del piano di controllo (control-plane) per tuo conto. Nella console, un gruppo di nodi autogestito non riceve alcuna indicazione di aggiornamento. È possibile visualizzare la versione di `kubelet` installata su un nodo selezionando il nodo nella finestra di dialogo **Nodi** nella scheda **Panoramica** del cluster per determinare quali nodi devono essere aggiornati. È necessario aggiornare manualmente i nodi. Per ulteriori informazioni, consulta [Aggiornamento dei nodi autogestiti per il tuo cluster](update-workers.md). I certificati utilizzati da kubelet sui nodi autogestiti vengono emessi con una scadenza di un anno. Per impostazione predefinita, la rotazione dei certificati **non** è abilitata (vedi: https://kubernetes. io/docs/reference/config-api/kubelet-config.v1beta1/\$1 kubelet-config-k 8 s-io-v 1beta1-KubeletConfiguration), questo significa che se hai un nodo autogestito attivo per più di un anno, non sarà più in grado di autenticarsi nell'API Kubernetes. Come best practice, consigliamo ai clienti di aggiornare regolarmente i propri gruppi di nodi autogestiti per ricevere CVEs patch di sicurezza dalle più recenti AMI ottimizzate per Amazon EKS. L’aggiornamento delle AMI utilizzate nei gruppi di nodi autogestiti attiva anche la ricreazione dei nodi e assicura che non si verifichino problemi dovuti a certificati kubelet scaduti. In alternativa, puoi anche abilitare la rotazione dei certificati client (vedi: https://kubernetes). io/docs/tasks/tls/certificate-rotation/) durante la creazione dei gruppi di nodi autogestiti per assicurarsi che i certificati kubelet vengano rinnovati man mano che il certificato corrente si avvicina alla scadenza. ## `eksctl` **Per avviare nodi Linux autogestiti utilizzando `eksctl`** 1. Installa la versione `0.215.0` o successiva dello strumento da riga di `eksctl` comando installato sul tuo 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. Se il tuo cluster è sul AWS cloud e la policy IAM gestita da **Amazoneks\$1CNI\$1Policy** è collegata al ruolo IAM del [nodo Amazon EKS, ti consigliamo di assegnarlo a un ruolo IAM da associare invece all'account](create-node-role.md) del servizio Kubernetes. `aws-node` Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md). Se il cluster è sull'Outpost, la policy deve essere collegata al ruolo del tuo nodo. 1. Il comando seguente crea un gruppo di nodi in un cluster esistente. Il cluster deve essere stato creato utilizzando `eksctl`. Sostituisci *al-nodes* con un nome per il gruppo di nodi. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura. Sostituisci *my-cluster* con il nome del 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 della regione e dell'account in cui stai creando il cluster. AWS AWS Se il cluster si trova su un Outpost, sostituisci *id* con l'ID di una sottorete dell'Outpost. Se il cluster esiste nel AWS cloud, sostituiscilo *id* con l'ID di una sottorete che non hai specificato al momento della creazione del cluster. Sostituisci i valori di esempio con i tuoi valori. Per impostazione predefinita, i nodi vengono creati con la stessa versione Kubernetes del piano di controllo. Sostituisci *instance-type* con un tipo di istanza disponibile sul tuo Outpost. Sostituiscilo *my-key* con il nome della tua coppia di EC2 chiavi Amazon o della tua chiave pubblica. Questa chiave viene utilizzata per eseguire il SSH nei nodi dopo il loro avvio. Se non disponi già di una coppia di EC2 chiavi Amazon, puoi crearne una in Console di gestione AWS. Per ulteriori informazioni, consulta le [coppie di EC2 chiavi Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Amazon EC2 User Guide*. Crea il tuo gruppo di nodi con il comando seguente. ``` eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \ --nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \ --node-volume-type gp2 --subnet-ids subnet-id \ --node-ami-family AmazonLinux2023 ``` Se il tuo cluster è distribuito sul AWS cloud: + Il gruppo di nodi implementato può assegnare gli indirizzi `IPv4` ai pod da un altro intervallo CIDR rispetto a quello dell’istanza. Per ulteriori informazioni, consulta [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md). + Il gruppo di nodi che implementi non richiede l’accesso a internet in uscita. Per ulteriori informazioni, consulta [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md). Per un elenco completo di tutte le impostazioni predefinite e le opzioni disponibili, consulta [AWS Outposts Support](https://eksctl.io/usage/outposts/) nella documentazione di `eksctl`. + Se i nodi non riescono a unirsi al cluster, consulta [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) la sezione [Risoluzione dei problemi con i cluster e i nodi Amazon EKS e Risoluzione dei problemi dei cluster](troubleshooting.md) [Amazon EKS locali su Outposts](eks-outposts-troubleshooting.md). [Impossibile unire i nodi a un cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) AWS + Di seguito viene riportato un output di esempio. Durante la creazione dei nodi vengono generate diverse righe. Una delle ultime righe di output è simile alla seguente riga di esempio. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Facoltativo) implementare [un’applicazione di esempio](sample-deployment.md) per testare il cluster e i nodi Linux. ## Console di gestione AWS **Fase 1: avvia i nodi Linux autogestiti utilizzando la Console di gestione AWS ** 1. Scarica l'ultima versione del modello. AWS CloudFormation ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml ``` 1. Apri la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/). 1. Scegli **Crea stack** e quindi seleziona **Con nuove risorse (standard)**. 1. In **Specifica modello**, seleziona **Carica un file di modello** e **Scegli file**. Seleziona il file `amazon-eks-nodegroup.yaml` scaricato in un passaggio precedente, quindi seleziona **Next** (Successivo). 1. Nella pagina **Specifica i dettagli dello stack**, immetti i parametri seguenti e scegli **Successivo**: + **Nome dello stack**: scegli un nome per lo stack. AWS CloudFormation Ad esempio, è possibile chiamarlo *al-nodes*. 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 della AWS regione e AWS dell'account in cui stai creando il cluster. + **ApiServerEndpoint**: Inserisci l'endpoint del server API Kubernetes, visibile nella console EKS o tramite API. DescribeCluster + **ClusterName**: Inserisci il nome del tuo cluster. Se questo nome non corrisponde al nome del cluster, i nodi non possono unirsi al cluster. + **ClusterId**: Inserisci l'id assegnato al cluster dal servizio EKS. Visibile tramite DescribeCluster API. Se questo ID non corrisponde al tuo ID del cluster, i tuoi nodi non possono unirsi al cluster. + **CertificateAuthority**: Inserisci la stringa codificata in base64 dell'autorità di certificazione Kubernetes. Visibile nella console EKS o tramite API. DescribeCluster + **ServiceCidr**: Accedi al CIDR di Kubernetes Services. Visibile nella console EKS o tramite API. DescribeCluster + **ClusterControlPlaneSecurityGroup**: scegli il **SecurityGroups**valore dall' AWS CloudFormation output che hai generato quando hai creato il tuo [VPC](creating-a-vpc.md). Nella procedura seguente viene illustrata un’operazione per recuperare il gruppo applicabile. 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Scegli il nome del cluster. 1. Scegli la scheda **Reti**. 1. Utilizza il valore dei **gruppi di sicurezza aggiuntivi** come riferimento quando selezioni dall'**ClusterControlPlaneSecurityGroup**elenco a discesa. + **NodeGroupName**: inserisci un nome per il tuo gruppo di nodi. Questo nome può essere utilizzato in seguito per identificare il gruppo di nodi con dimensionamento automatico creato per i tuoi nodi. + **NodeAutoScalingGroupMinSize**: Inserisci il numero minimo di nodi su cui il gruppo Auto Scaling del nodo può scalare. + **NodeAutoScalingGroupDesiredCapacity**: Inserisci il numero di nodi desiderato su cui scalare quando viene creato lo stack. + **NodeAutoScalingGroupMaxSize**: Inserisci il numero massimo di nodi su cui il gruppo Auto Scaling del nodo può scalare orizzontalmente. + **NodeInstanceType**: scegli un tipo di istanza per i tuoi nodi. Se il cluster è in esecuzione sul AWS cloud, per ulteriori informazioni, consulta[Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md). Se il cluster è in esecuzione su un Outpost, puoi selezionare solo un tipo di istanza disponibile sul tuo Outpost. + **NodeImageIdSSMParam**: precompilato con il parametro Amazon EC2 Systems Manager di una recente AMI ottimizzata per Amazon EKS per una versione variabile di Kubernetes. Se si desidera utilizzare una diversa versione secondaria di Kubernetes supportata da Amazon EKS, è possibile sostituire *1.XX* con una [versione supportata](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) differente. Si consiglia di specificare la stessa versione Kubernetes del cluster. Per utilizzare un'AMI accelerata ottimizzata per Amazon EKS, aggiorna il *NodeImageIdSSMParam* valore al parametro SSM desiderato. [Scopri come recuperare l'AMI EKS IDs da SSM qui.](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html) **Nota** I nodi Amazon EKS AMIs sono basati su Amazon Linux. Tieni traccia degli eventi di sicurezza o di privacy per Amazon Linux in [Amazon Linux security center](https://alas.aws.amazon.com/) scegliendo la scheda per la versione desiderata. Puoi anche abbonarti al feed RSS applicabile. Gli eventi di sicurezza e privacy includono una panoramica del problema, quali sono i pacchetti interessati e come aggiornare le istanze per risolvere il problema. + **NodeImageId**: (Facoltativo) Se utilizzi un'AMI personalizzata (anziché un'AMI ottimizzata per Amazon EKS), inserisci un ID AMI del nodo per la tua AWS regione. Se specifichi un valore qui, questo sostituisce tutti i valori nel **NodeImageIdSSMParam**campo. + **NodeVolumeSize**: Specificate la dimensione del volume root per i nodi, in GiB. + **NodeVolumeType**: Specificate un tipo di volume root per i nodi. + **KeyName**: inserisci il nome di una coppia di chiavi Amazon EC2 SSH che puoi usare per connetterti tramite SSH ai tuoi nodi dopo il loro avvio. Se non disponi già di una coppia di EC2 chiavi Amazon, puoi crearne una in Console di gestione AWS. Per ulteriori informazioni, consulta le [coppie di EC2 chiavi Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Amazon EC2 User Guide*. **Nota** Se non fornisci una key pair qui, la creazione dello AWS CloudFormation stack fallisce. + **Disabilita IMDSv1**: per impostazione predefinita, ogni nodo supporta Instance Metadata Service versione 1 (IMDSv1) e. IMDSv2 È possibile disabilitare IMDSv1. Per impedire l'utilizzo di nodi e Pod futuri nel gruppo di nodi IMDSv1, imposta **Disable** su IMDSv1 **true**. Per ulteriori informazioni su IMDS, consulta [Configurazione del servizio di metadati dell’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Per ulteriori informazioni sulle relative limitazioni dell’accesso ai nodi, consulta [Limita l’accesso al profilo dell’istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). + **VpcId**: inserisci l'ID per il [VPC](creating-a-vpc.md) che hai creato. Prima di scegliere un VPC, consulta [VPC requirements and considerations](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements). + **Subnets**: (Sottoreti) se il cluster è su un Outpost, scegli almeno una sottorete privata nel VPC. Prima di scegliere le sottoreti, consulta [Considerazioni e requisiti relativi alla sottorete](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). È possibile visualizzare le sottoreti private aprendo ogni collegamento relativo alla sottorete dalla scheda **Reti** del cluster. 1. Seleziona le opzioni desiderate nella pagina **Configura opzioni dello stack**, quindi scegli **Next** (Avanti). 1. Seleziona la casella di controllo a sinistra di **Riconosco che AWS CloudFormation potrebbe creare risorse IAM**. , quindi scegli **Create stack**. 1. Al termine della creazione dello stack, selezionalo nella console e scegli **Output**. 1. Registra il **NodeInstanceRole**per il gruppo di nodi che è stato creato. Ciò sarà utile quando configurerai i nodi di Amazon EKS. **Fase 2: abilitazione dell’aggiunta di nodi al cluster** 1. Verifica se disponi già di una `ConfigMap` per `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Se ti viene mostrata una `ConfigMap` per `aws-auth`, aggiornala se necessario. 1. Apri `ConfigMap` per la modifica. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Aggiungi una nuova voce `mapRoles`, se necessario. Impostate il `rolearn` **NodeInstanceRole**valore sul valore registrato nella procedura precedente. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. Salva il file ed esci dall’editor di testo. 1. Se hai ricevuto un messaggio di errore che indica "`Error from server (NotFound): configmaps "aws-auth" not found`", applica lo `ConfigMap` di stock. 1. Scarica la mappa di configurazione. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. Nel `aws-auth-cm.yaml` file, impostate `rolearn` il **NodeInstanceRole**valore sul valore registrato nella procedura precedente. Per eseguire questa operazione, utilizza un editor di testo o sostituisci *my-node-instance-role* tramite il comando seguente: ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Applica la configurazione. L’esecuzione di questo comando potrebbe richiedere alcuni minuti. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. Guarda lo stato dei nodi e attendi che raggiungano lo stato `Ready`. ``` kubectl get nodes --watch ``` Inserisci `Ctrl`\$1`C` per tornare a un prompt dello shell (interprete di comandi). **Nota** Se ricevi qualsiasi altro errore di tipo di risorsa o autorizzazione, consulta la sezione [Accesso negato o non autorizzato (`kubectl`)](troubleshooting.md#unauthorized) nell’argomento relativo alla risoluzione dei problemi. Se i nodi non riescono a unirsi al cluster, consulta [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) la sezione [Risoluzione dei problemi con i cluster e i nodi Amazon EKS e Risoluzione dei problemi dei cluster](troubleshooting.md) [Amazon EKS locali su Outposts](eks-outposts-troubleshooting.md). [Impossibile unire i nodi a un cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) AWS 1. Installa il driver CSI per Amazon EBS. [Per ulteriori informazioni, consulta Installazione su.](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) GitHub Nella sezione **Set up driver permission** (Configura autorizzazione del driver), assicurati di seguire le istruzioni per l'opzione **Using IAM instance profile** (Utilizzo del profilo dell'istanza IAM). È necessario utilizzare la classe di archiviazione `gp2`. La classe di archiviazione `gp3` non è supportata. Per creare una classe di archiviazione `gp2` nel cluster, completa i seguenti passaggi. 1. Per creare il file `gp2-storage-class.yaml`, emetti il seguente comando: ``` cat >gp2-storage-class.yaml <