**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à.

# Che cosa è Amazon EKS?
<a name="what-is-eks"></a>

**Suggerimento**  
 [Registrati](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) ai prossimi workshop Amazon EKS.

## Amazon EKS: gestione semplificata di Kubernetes
<a name="_amazon_eks_simplified_kubernetes_management"></a>

Amazon Elastic Kubernetes Service (EKS) fornisce un servizio Kubernetes completamente gestito che elimina la complessità del funzionamento dei cluster Kubernetes. Con EKS è possibile:
+ Implementare le applicazioni più velocemente con meno spese operative
+ Scalare senza problemi per soddisfare le mutevoli esigenze dei carichi di lavoro
+ Migliora la sicurezza attraverso AWS l'integrazione e gli aggiornamenti automatici
+ Scegliere tra la modalità automatica EKS standard o completamente automatizzata

Amazon Elastic Kubernetes Service (Amazon EKS) è la piattaforma principale per l’esecuzione di cluster [Kubernetes](https://kubernetes.io/docs/concepts/overview/), sia nel cloud Amazon Web Services (AWS) che nei tuoi data center ([EKS Anywhere](https://anywhere.eks.amazonaws.com/) e [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md)).

Amazon EKS semplifica la creazione, la protezione e la manutenzione dei cluster Kubernetes. Fornire risorse sufficienti per soddisfare i picchi di domanda può essere più conveniente rispetto alla manutenzione dei propri data center. Due degli approcci principali all’utilizzo di Amazon EKS sono i seguenti:
+  **Standard EKS**: AWS gestisce il [piano di controllo di Kubernetes](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) quando si crea un cluster con EKS. I componenti che gestiscono i nodi, pianificano i carichi di lavoro, si integrano con il AWS cloud e archiviano e ridimensionano le informazioni del piano di controllo per mantenere i cluster attivi e funzionanti, vengono gestiti automaticamente.
+  **Modalità automatica EKS**: utilizzando la funzione [Modalità automatica EKS](automode.md), EKS estende il proprio controllo anche alla gestione dei [nodi](https://kubernetes.io/docs/concepts/overview/components/#node-components) (piano dati Kubernetes). Semplifica la gestione di Kubernetes effettuando automaticamente il provisioning dell'infrastruttura, selezionando le istanze di calcolo ottimali, scalando dinamicamente le risorse, ottimizzando continuamente i costi, applicando patch ai sistemi operativi e integrandosi con i servizi di sicurezza. AWS 

Il diagramma seguente illustra come Amazon EKS integra i tuoi cluster Kubernetes con il AWS cloud, a seconda del metodo di creazione del cluster scelto:

![\[Modalità automatica o standard EKS Amazon\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/whatis.png)


Amazon EKS ti aiuta a rimuovere gli attriti e ad accelerare i tempi di produzione, migliorare le prestazioni, la disponibilità e la resilienza e migliorare la sicurezza del sistema. Per ulteriori informazioni, consulta [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/).

## Creazione e scalabilità con Kubernetes: Amazon EKS Capabilities
<a name="_building_and_scaling_with_kubernetes_amazon_eks_capabilities"></a>

Amazon EKS non solo ti aiuta a creare e gestire cluster, ma ti aiuta a creare e scalare sistemi applicativi con Kubernetes. [Amazon EKS Capabilities](capabilities.md) sono servizi cluster completamente gestiti che estendono le funzionalità del cluster con strumenti nativi Kubernetes a mani libere, tra cui:
+  **Argo CD: Argo CD** fornisce una distribuzione continua dichiarativa e GitOps basata su dichiarazioni per i carichi di lavoro, le risorse e l'infrastruttura cloud. AWS 
+  ** AWS Controller for Kubernetes (ACK): ACK consente la creazione nativa di Kubernetes e** la gestione del ciclo di vita delle risorse, unificando l'orchestrazione dei carichi di lavoro e i flussi di lavoro. AWS Infrastructure-as-code
+  **kro (Kube Resource Orchestrator): kro estende le funzionalità native di Kubernetes per semplificare la creazione, l'orchestrazione** e la composizione di risorse personalizzate, offrendoti gli strumenti per creare i tuoi elementi costitutivi cloud personalizzati.

EKS Capabilities sono risorse cloud che riducono al minimo l'onere operativo di installazione, manutenzione e scalabilità di questi componenti fondamentali della piattaforma nei cluster, consentendoti di concentrarti sulla creazione di software anziché sulle operazioni della piattaforma cluster.

Per ulteriori informazioni, consulta [Funzionalità EKS](capabilities.md).

## Funzionalità di Amazon EKS
<a name="eks-features"></a>

Amazon EKS offre le seguenti funzionalità di alto livello:

 **Interfacce di gestione**   
EKS offre diverse interfacce per il provisioning, la gestione e la manutenzione dei cluster, tra cui Console di gestione AWS Amazon EKS API/SDKs, CDK, AWS CLI, eksctl CLI e Terraform. AWS CloudFormation Per ulteriori informazioni, consultare [Nozioni di base su Amazon EKS](getting-started.md) e [Ciclo di vita e configurazione del cluster di Amazon EKS](clusters.md).

 **Accedere agli strumenti di controllo**   
EKS si affida alle funzionalità di Kubernetes e AWS Identity and Access Management (AWS IAM) per [gestire l'accesso da utenti](cluster-auth.md) e carichi di lavoro. Per ulteriori informazioni, consultare [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md) e [Concessione ai carichi di lavoro Kubernetes dell’accesso a AWS utilizzando gli account di servizio Kubernetes](service-accounts.md).

 **Risorse di calcolo**   
Per quanto riguarda [le risorse di calcolo](eks-compute.md), EKS consente l'intera gamma di tipi di EC2 istanze Amazon e AWS innovazioni come Nitro e Graviton con Amazon EKS per ottimizzare l'elaborazione per i tuoi carichi di lavoro. Per ulteriori informazioni, consulta [Gestire le risorse di elaborazione utilizzando i nodi](eks-compute.md).

 **Storage**   
Modalità automatica EKS crea automaticamente classi di archiviazione utilizzando [volumi EBS](create-storage-class.md), Utilizzando i driver dell’interfaccia di archiviazione in container (CSI), è anche possibile utilizzare Amazon S3, Amazon EFS, Amazon FSx e Amazon File Cache per le tue esigenze di archiviazione delle applicazioni. Per ulteriori informazioni, consulta [Utilizzo dell’archiviazione di dati delle applicazioni per il tuo cluster](storage.md).

 **Sicurezza**   
Il modello di responsabilità condivisa è impiegato in relazione alla [Sicurezza in Amazon EKS](security.md). Per ulteriori informazioni, consulta [Best practice di sicurezza](security-best-practices.md), [Sicurezza dell’infrastruttura](infrastructure-security.md) e [Sicurezza Kubernetes](security-k8s.md).

 **Strumenti di monitoraggio**   
Utilizza la [dashboard di osservabilità](observability-dashboard.md) per monitorare i cluster Amazon EKS. [[Gli strumenti di monitoraggio includono [Prometheus [CloudWatch](cloudwatch.md)](prometheus.md), Cloudtrail e ADOT Operator.](opentelemetry.md)](logging-using-cloudtrail.md) Per ulteriori informazioni su dashboard, server di metriche e altri strumenti, consulta [Costi del cluster EKS](cost-monitoring.md) e [Server delle metriche Kubernetes](metrics-server.md).

 **Funzionalità del cluster**   
EKS offre funzionalità di cluster gestite per l'implementazione continua, la gestione delle risorse cloud e la composizione delle risorse basate su innovazioni open source. EKS installa Kubernetes APIs nei cluster, ma i controller e gli altri componenti vengono eseguiti in EKS e sono completamente gestiti, fornendo patch, scalabilità e monitoraggio automatizzati. Per ulteriori informazioni, consulta [Funzionalità EKS](capabilities.md).

 **Compatibilità e supporto Kubernetes**   
Amazon EKS è certificato conforme a Kubernetes, quindi è possibile implementare applicazioni compatibili con Kubernetes senza rifattorizzare e utilizzare strumenti e plugin della community Kubernetes. EKS offre [supporto standard](kubernetes-versions-standard.md) e [supporto esteso](kubernetes-versions-extended.md) per Kubernetes. Per ulteriori informazioni, consulta [Comprendere il ciclo di vita delle versioni di Kubernetes su EKS](kubernetes-versions.md).

## Servizi correlati
<a name="eks-related-services"></a>

 **Servizi da utilizzare con Amazon EKS** 

Puoi utilizzare altri AWS servizi con i cluster che distribuisci con Amazon EKS:

 **Amazon EC2**   
[Ottieni capacità di elaborazione scalabile su richiesta con Amazon. EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)

 **Amazon EBS**   
Collegare risorse di archiviazione a blocchi scalabili e ad alte prestazioni con [Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html).

 **Amazon ECR**   
Archiviare le immagini dei container in modo sicuro con [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html).

 **Amazon CloudWatch**   
Monitora AWS risorse e applicazioni in tempo reale con [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).

 **Amazon Prometheus**   
Tenere traccia delle metriche per le applicazioni all’interno di container con [Servizio gestito da Amazon per Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html).

 **Elastic Load Balancing**   
Distribuire il traffico in ingresso tra più destinazioni con [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html).

 **Amazon GuardDuty**   
Rileva le minacce ai cluster EKS con [Amazon GuardDuty](integration-guardduty.md).

 ** AWS Hub di resilienza**   
[Valutare la resilienza dei cluster EKS con AWS Resilience Hub](integration-resilience-hub.md).

## Prezzi di Amazon EKS
<a name="eks-pricing"></a>

Amazon EKS prevede prezzi per cluster basati sul supporto della versione del cluster Kubernetes, prezzi per modalità automatica Amazon EKS e prezzi per vCPU per Amazon EKS Hybrid Nodes.

Quando usi Amazon EKS, paghi separatamente per le AWS risorse utilizzate per eseguire le tue applicazioni sui nodi di lavoro Kubernetes. Ad esempio, se utilizzi nodi di lavoro Kubernetes come EC2 istanze Amazon con volumi e indirizzi IPv4 pubblici Amazon EBS, ti verrà addebitata la capacità dell'istanza tramite Amazon, la capacità di volume tramite EC2 Amazon EBS e l'indirizzo IPv4 tramite Amazon VPC.

Visita le rispettive pagine dei prezzi dei AWS servizi che utilizzi con le tue applicazioni Kubernetes per informazioni dettagliate sui prezzi.
+ Per i prezzi di cluster Amazon EKS, Amazon EKS Auto Mode, Amazon EKS Capabilities e Amazon EKS Hybrid Nodes, consulta i [prezzi di Amazon EKS](https://aws.amazon.com/eks/pricing/).
+ Per i EC2 prezzi di Amazon, consulta i prezzi di [Amazon EC2 On-Demand e i prezzi](https://aws.amazon.com/ec2/pricing/on-demand/) [Amazon EC2 Spot](https://aws.amazon.com/ec2/spot/pricing/).
+ [Per i prezzi di AWS Fargate, consulta i prezzi di Fargate AWS .](https://aws.amazon.com/fargate/pricing)
+ Puoi utilizzare i tuoi savings plans per le risorse di calcolo utilizzate nei cluster Amazon EKS. Per ulteriori informazioni, consulta [Prezzi con Savings Plans](https://aws.amazon.com/savingsplans/pricing/).

# Casi d’uso comuni in Amazon EKS
<a name="common-use-cases"></a>

Amazon EKS offre solidi servizi Kubernetes gestiti su AWS, progettati per ottimizzare le applicazioni containerizzate. Di seguito sono riportati alcuni dei casi d’uso più comuni di Amazon EKS per aiutarti a sfruttarne i punti di forza per esigenze specifiche.

 **Implementazione di applicazioni ad alta disponibilità**   
Utilizzando [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/), puoi assicurarti che le applicazioni siano altamente disponibili in più [zone di disponibilità](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).

 **Creazione di architetture di microservizi**   
Utilizzare le funzionalità di rilevamento servizi di Kubernetes con [AWS Cloud Map](https://aws.amazon.com/cloud-map/) o [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) per creare sistemi resilienti.

 **Automazione dei processi di rilascio del software**   
Gestisci le pipeline di integrazione continua e distribuzione continua (CI/CD) che semplificano il processo di creazione, test e implementazione automatizzati delle applicazioni. Per una distribuzione continua dichiarativa, consulta [Continuous Deployment with Argo CD](argocd.md).

 **Esecuzione di applicazioni serverless**   
Utilizzare [AWS Fargate](https://aws.amazon.com/fargate/) con Amazon EKS per eseguire applicazioni serverless. In questo modo, potrai concentrarti esclusivamente sullo sviluppo delle applicazioni mentre Amazon EKS e Fargate gestiscono l’infrastruttura sottostante.

 **Esecuzione di carichi di lavoro di machine learning**   
Amazon EKS è compatibile con i framework di machine learning più diffusi, come [TensorFlow](https://www.tensorflow.org/), [MXNet](https://mxnet.apache.org/) e [PyTorch](https://pytorch.org/). Con il supporto GPU, è possibile gestire efficacemente anche attività di machine learning complesse.

 **Implementazione coerente in locale e nel cloud**   
Per semplificare l’esecuzione di Kubernetes in ambienti on-premises, è possibile utilizzare gli stessi cluster, funzionalità e strumenti di Amazon EKS per eseguire nodi autogestiti su [AWS Outposts](eks-outposts.md) o utilizzare [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md) con la propria infrastruttura. Per ambienti autonomi e isolati, è possibile utilizzare [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) per automatizzare la gestione del ciclo di vita dei cluster di Kubernetes sulla propria infrastruttura.

 **Esecuzione di carichi di lavoro di elaborazione in batch e big data a costi contenuti**   
Utilizzare le [istanze spot](https://aws.amazon.com/ec2/spot/) per eseguire carichi di lavoro di elaborazione in batch e big data, come [Apache Hadoop](https://aws.amazon.com/emr/details/hadoop/what-is-hadoop/) e [Spark](https://aws.amazon.com/big-data/what-is-spark/), a un costo ridotto. In questo modo puoi sfruttare la EC2 capacità inutilizzata di Amazon a prezzi scontati.

 **Gestione delle AWS risorse da Kubernetes**   
Usa [AWS Controllers for Kubernetes (ACK)](ack.md) per creare e gestire AWS risorse direttamente dal tuo cluster Kubernetes utilizzando Kubernetes nativo. APIs

 **Creazione di astrazioni ingegneristiche della piattaforma**   
[Crea Kubernetes personalizzati APIs che compongono più risorse in astrazioni di livello superiore usando kro (Kube Resource Orchestrator).](kro.md)

 **Proteggere le applicazioni e garantire la conformità**   
Implementa pratiche di sicurezza solide e mantieni la conformità con Amazon EKS, che si integra con servizi di AWS sicurezza come [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM), [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) (Amazon VPC) [AWS e Key Management](https://aws.amazon.com/kms/) Service AWS (KMS). Ciò garantisce la privacy e la protezione dei dati secondo gli standard del settore.

# Architettura di Amazon EKS
<a name="eks-architecture"></a>

Amazon EKS segue l’architettura generale dei cluster di Kubernetes. Per ulteriori informazioni, consultare la pagina [Kubernetes Components](https://kubernetes.io/docs/concepts/overview/components/) nella documentazione Kubernetes. Le seguenti sezioni riassumono alcuni dettagli aggiuntivi sull'architettura di Amazon EKS.

## Piano di controllo
<a name="control-plane"></a>

Amazon EKS garantisce che ogni cluster abbia un proprio piano di controllo Kubernetes specifico. Questo design mantiene l'infrastruttura di ciascun cluster separata, senza sovrapposizioni tra cluster o account. AWS La configurazione include:

 **Componenti distribuiti**   
Il piano di controllo posiziona almeno due istanze del server API e tre istanze [etcd](https://etcd.io/) in tre zone di AWS disponibilità all'interno di una regione. AWS 

 **Prestazioni ottimali**   
Amazon EKS monitora e regola attivamente le istanze del piano di controllo per mantenere le massime prestazioni.

 **Resilienza**   
Se un'istanza del piano di controllo fallisce, Amazon EKS la sostituisce rapidamente, utilizzando una zona di disponibilità diversa, se necessario.

 **Tempo di attività costante**   
Eseguendo i cluster su più zone di disponibilità, si consegue l'affidabilità dell'[Accordo sul livello di servizio (SLA) sulla disponibilità degli endpoint dei server API](https://aws.amazon.com/eks/sla).

Amazon EKS utilizza Amazon Virtual Private Cloud (Amazon VPC) per limitare il traffico tra i componenti del piano di controllo all'interno di un singolo cluster. I componenti del cluster non possono visualizzare o ricevere comunicazioni da altri cluster o AWS account, tranne quando autorizzati dalle politiche di controllo degli accessi basato sui ruoli (RBAC) di Kubernetes.

## Calcolo
<a name="nodes"></a>

Oltre al piano di controllo, un cluster Amazon EKS dispone di un set di macchine di lavoro chiamate nodi. La selezione del tipo di nodo del cluster Amazon EKS appropriato è fondamentale per soddisfare i propri requisiti specifici e ottimizzare l'utilizzo delle risorse. Amazon EKS offre i seguenti tipi di nodi primari:

 **Modalità automatica EKS**   
 [EKS Auto Mode estende la](automode.md) AWS gestione oltre il piano di controllo per includere il piano dati, automatizzando la gestione dell'infrastruttura del cluster. Integra le funzionalità di base di Kubernetes come componenti integrati, tra cui scalabilità automatica del calcolo, rete, bilanciamento del carico, DNS, archiviazione e supporto della GPU. EKS Auto Mode gestisce dinamicamente i nodi in base alle richieste del carico di lavoro, utilizzando funzionalità di sicurezza immutabili AMIs e avanzate. Automatizza aggiornamenti e upgrade rispettando i budget per le interruzioni dei pod e include componenti gestiti che altrimenti richiederebbero la gestione di componenti aggiuntivi. Questa opzione è ideale per gli utenti che desiderano sfruttare l' AWS esperienza per day-to-day le operazioni, ridurre al minimo il sovraccarico operativo e concentrarsi sullo sviluppo di applicazioni piuttosto che sulla gestione dell'infrastruttura.

 ** AWS Fargate**   
 [Fargate](fargate.md) è un motore di elaborazione serverless per container che elimina la necessità di gestire le istanze sottostanti. Fargate consente di specificare le esigenze di risorse dell'applicazione e di effettuare AWS automaticamente il provisioning, la scalabilità e la manutenzione dell'infrastruttura. Questa opzione è ideale per gli utenti che danno priorità ease-of-use e vogliono concentrarsi sullo sviluppo e l'implementazione delle applicazioni piuttosto che sulla gestione dell'infrastruttura.

 **Karpenter**   
 [Karpenter](https://karpenter.sh/) è un cluster autoscaler Kubernetes flessibile e ad alte prestazioni che aiuta a migliorare la disponibilità delle applicazioni e l’efficienza del cluster. Karpenter avvia risorse di calcolo dimensionate in modo ottimale in risposta alla modifica del carico dell’applicazione. Questa opzione può fornire risorse di just-in-time elaborazione che soddisfino i requisiti del carico di lavoro.

 **Gruppi di nodi gestiti**   
 I [gruppi di nodi gestiti](managed-node-groups.md) sono una combinazione di automazione e personalizzazione per la gestione di una raccolta di EC2 istanze Amazon all'interno di un cluster Amazon EKS. AWS si occupa di attività come l'applicazione di patch, l'aggiornamento e il ridimensionamento dei nodi, semplificando gli aspetti operativi. Parallelamente, sono supportati gli argomenti `kubelet` personalizzati, che offrono la possibilità di creare policy avanzate per la gestione della CPU e della memoria. Inoltre, migliorano la sicurezza tramite i ruoli AWS Identity and Access Management (IAM) per gli account di servizio, riducendo al contempo la necessità di autorizzazioni separate per cluster.

 **Nodi autogestiti**   
 [I nodi autogestiti](worker.md) offrono il controllo completo sulle EC2 istanze Amazon all'interno di un cluster Amazon EKS. L'utente è responsabile della gestione, del dimensionamento e della manutenzione dei nodi, disponendo del controllo totale sull'infrastruttura sottostante. Questa opzione è consigliata per gli utenti che necessitano di controllo e personalizzazione granulari dei propri nodi e sono pronti a investire tempo nella gestione e nella manutenzione della propria infrastruttura.

 **Amazon EKS Hybrid Nodes**   
Con [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md) è possibile utilizzare l’infrastruttura on-premises ed edge come nodi nei cluster Amazon EKS. Amazon EKS Hybrid Nodes unifica la gestione di Kubernetes tra gli ambienti e affida la gestione del piano di controllo Kubernetes alle applicazioni locali e periferiche. AWS 

## Funzionalità EKS
<a name="eks-capabilities"></a>

Amazon EKS offre funzionalità di cluster completamente gestite, installando e gestendo Kubernetes APIs (con Kubernetes Custom Resource Definitions) nel cluster e gestendo controller e altri componenti in AWS un'infrastruttura di proprietà, separata dal cluster. EKS fornisce patch, scalabilità e monitoraggio automatizzati di queste funzionalità, gestendone completamente il ciclo di vita per ridurre il carico di lavoro dei servizi in cluster per l'orchestrazione dei carichi di lavoro, la gestione delle risorse e altro ancora. AWS 

EKS offre i seguenti tipi di funzionalità:

 ** AWS Controller per Kubernetes (ACK)**   
 [AWS Controllers for Kubernetes (ACK)](ack.md) ti consente di gestire le AWS risorse utilizzando Kubernetes APIs, consentendoti di definire bucket S3, database RDS, ruoli IAM e altre risorse come risorse personalizzate Kubernetes. AWS Puoi gestire AWS le risorse insieme ai carichi di lavoro Kubernetes utilizzando gli stessi strumenti e flussi di lavoro, con supporto per oltre 50 AWS servizi tra cui S3, RDS, DynamoDB e Lambda.

 **CD Argo**   
 [Argo CD](argocd.md) GitOps implementa una distribuzione continua basata sui carichi di lavoro delle applicazioni, sulle AWS risorse e sulla configurazione del cluster, utilizzando i repository Git come fonte di verità. Argo CD sincronizza automaticamente i cluster con i repository Git e rileva eventuali deviazioni, riconciliandosi continuamente per garantire che le applicazioni e le risorse distribuite corrispondano allo stato desiderato nel controllo delle versioni. È possibile utilizzare Argo CD per gestire le applicazioni su un determinato cluster o distribuire e gestire applicazioni su più cluster da una singola risorsa Argo CD, con la distribuzione automatica dai repository Git ogni volta che vengono apportate modifiche.

 **kro (Kube Resource Orchestrator)**   
 [kro (Kube Resource Orchestrator)](kro.md) ti consente di creare Kubernetes personalizzati APIs che compongono più risorse in astrazioni di livello superiore, permettendo ai team della piattaforma di definire modelli riutilizzabili per combinazioni di risorse comuni. Ciò consente ai team della piattaforma di fornire funzionalità self-service con barriere appropriate, permettendo agli sviluppatori di fornire infrastrutture complesse utilizzando infrastrutture semplici e appositamente progettate, mantenendo al contempo gli standard organizzativi e le migliori pratiche. APIs 

# Concetti di Kubernetes
<a name="kubernetes-concepts"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) è un servizio gestito da AWS basato sul progetto open source [Kubernetes](https://kubernetes.io/). Sebbene ci siano cose che devi sapere su come il servizio Amazon EKS si integra con il cloud AWS (in particolare quando crei per la prima volta un cluster Amazon EKS), una volta che è attivo e funzionante, puoi utilizzare il cluster Amazon EKS più o meno allo stesso modo di qualsiasi altro cluster Kubernetes. Quindi, per iniziare a gestire i cluster Kubernetes e distribuire carichi di lavoro, è necessaria almeno una conoscenza di base dei concetti di Kubernetes.

Questa pagina divide i concetti di Kubernetes in tre sezioni: [Perché Kubernetes?](#why-kubernetes), [Cluster](#concepts-clusters) e [Carichi di lavoro](#workloads). La prima sezione descrive il valore dell’esecuzione di un servizio Kubernetes, in particolare come servizio gestito quale Amazon EKS. La sezione Carichi di lavoro illustra come le applicazioni Kubernetes vengono create, archiviate, eseguite e gestite. La sezione Cluster illustra i diversi componenti che formano i cluster Kubernetes e quali sono le tue responsabilità per la creazione e la manutenzione di questi cluster.

**Topics**
+ [Perché Kubernetes?](#why-kubernetes)
+ [Cluster](#concepts-clusters)
+ [Carichi di lavoro](#workloads)
+ [Passaggi successivi](#next-steps)

Durante la lettura di questo contenuto, i link ti condurranno a ulteriori descrizioni dei concetti di Kubernetes nella documentazione di Amazon EKS e Kubernetes, nel caso in cui desideri approfondire uno degli argomenti trattati qui. Per dettagli su come Amazon EKS implementa il piano di controllo e le funzionalità di calcolo di Kubernetes, consulta [Architettura di Amazon EKS](eks-architecture.md).

## Perché Kubernetes?
<a name="why-kubernetes"></a>

Kubernetes è stato progettato per migliorare la disponibilità e la scalabilità durante l’esecuzione di applicazioni containerizzate mission-critical e di qualità produttiva. Anziché limitarsi a eseguire Kubernetes su una singola macchina (sebbene ciò sia possibile), Kubernetes raggiunge questi obiettivi consentendoti di eseguire applicazioni su set di computer che possono espandersi o contrarsi per soddisfare la domanda. Kubernetes include funzionalità che rendono più semplice:
+ Distribuire applicazioni su più macchine (utilizzando container distribuiti nei pod)
+ Monitorare lo stato dei container e riavviare quelli che hanno subito un errore
+ Aumentare e ridurre i container in base al carico
+ Aggiornare i container con le nuove versioni
+ Allocare le risorse tra i container
+ Bilanciare il traffico tra le macchine

L’automazione di questi tipi di attività complesse da parte di Kubernetes consente agli sviluppatori di applicazioni di concentrarsi sulla creazione e sul miglioramento dei carichi di lavoro delle applicazioni, anziché preoccuparsi dell’infrastruttura. In genere, lo sviluppatore crea file di configurazione, formattati come file YAML, che descrivono lo stato desiderato dell’applicazione. Ciò potrebbe includere i container da eseguire, i limiti delle risorse, il numero di repliche dei pod, l’allocazione della CPU/memoria, le regole di affinità e molto altro.

### Attributi di Kubernetes
<a name="attributes-of-kubernetes"></a>

Per raggiungere gli obiettivi, Kubernetes ha i seguenti attributi:
+  **Containerizzato**: Kubernetes è uno strumento di orchestrazione dei container. Per utilizzare Kubernetes, devi prima avere le tue applicazioni containerizzate. A seconda del tipo di applicazione, potrebbe trattarsi di un insieme di *microservizi,* di processi in batch o in altre forme. Quindi, le tue applicazioni possono trarre vantaggio da un flusso di lavoro di Kubernetes che comprende un enorme ecosistema di strumenti, in cui i container possono essere archiviati come [immagini in un registro di container](https://kubernetes.io/docs/concepts/containers/images/#multi-architecture-images-with-image-indexes), distribuiti in un cluster [Kubernetes](https://kubernetes.io/docs/concepts/architecture/) ed eseguiti su un [nodo](https://kubernetes.io/docs/concepts/architecture/nodes/) disponibile. Puoi creare e testare singoli container sul tuo computer locale con Docker o un altro [runtime di container](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) prima di distribuirli nel cluster Kubernetes.
+  **Scalabile**: se la domanda per le tue applicazioni supera la capacità delle istanze in esecuzione delle stesse, Kubernetes è in grado di aumentare verticalmente. Se necessario, Kubernetes è in grado di stabilire se le applicazioni richiedono più CPU o memoria e rispondere o espandendo automaticamente la capacità disponibile o utilizzando una maggiore capacità esistente. La scalabilità può essere eseguita a livello di pod, se è disponibile una quantità di calcolo sufficiente per eseguire solo più istanze dell’applicazione ([scalabilità automatica del pod in orizzontale](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)), o a livello di nodo, se è necessario attivare più nodi per gestire l’aumento della capacità ([Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) o [Karpenter](https://karpenter.sh/)). Poiché la capacità non è più necessaria, questi servizi possono eliminare i pod non necessari e chiudere i nodi non necessari.
+  **Disponibile**: se un’applicazione o un nodo non sono integri o non sono disponibili, Kubernetes può spostare i carichi di lavoro in esecuzione su un altro nodo disponibile. Puoi forzare il problema semplicemente eliminando un’istanza in esecuzione di un carico di lavoro o di un nodo che esegue i tuoi carichi di lavoro. In conclusione, i carichi di lavoro possono essere trasferiti in altre posizioni se non possono più essere eseguiti dove si trovano.
+  **Dichiarativo**: Kubernetes utilizza la riconciliazione attiva per verificare costantemente che lo stato dichiarato per il cluster corrisponda allo stato effettivo. Applicando [oggetti Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/) a un cluster, in genere tramite file di configurazione in formato YAML, puoi, ad esempio, chiedere di avviare i carichi di lavoro che desideri eseguire sul cluster. Successivamente, puoi modificare le configurazioni per eseguire operazioni quali utilizzare una versione successiva di un container o allocare più memoria. Kubernetes farà ciò che deve fare per stabilire lo stato desiderato. Ciò può includere l’attivazione o la disattivazione dei nodi, l’arresto e il riavvio dei carichi di lavoro o l’estrazione di container aggiornati.
+  **Componibile**: poiché un’applicazione è in genere composta da più componenti, è necessario essere in grado di gestire insieme un insieme di questi componenti (spesso rappresentati da più container). Sebbene Docker Compose offra un modo per farlo direttamente con Docker, il comando [Kompose](http://kompose.io/) di Kubernetes può aiutarti a farlo con Kubernetes. Consultare [Translate a Docker Compose File to Kubernetes Resources](https://kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes/) per un esempio di come eseguire questa operazione.
+  **Estensibile**: a differenza del software proprietario, il progetto open source Kubernetes è progettato per consentirti di estendere Kubernetes in qualsiasi modo desideri per soddisfare le tue esigenze. Le API e i file di configurazione sono aperti a modifiche dirette. I terzi sono incoraggiati a scrivere i propri [comandi](https://kubernetes.io/docs/concepts/architecture/controller/) per estendere sia l’infrastruttura che le funzionalità di Kubernetes per gli utenti finali. I [webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) consentono di configurare le regole del cluster per applicare le policy e adattarsi alle condizioni mutevoli. Per altre idee su come estendere i cluster Kubernetes, consultare [Extending Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/).
+  **Portatile**: molte organizzazioni hanno standardizzato le proprie operazioni su Kubernetes perché consente loro di gestire tutte le esigenze applicative nello stesso modo. Gli sviluppatori possono utilizzare le stesse pipeline per creare e archiviare applicazioni containerizzate. Queste applicazioni possono quindi essere distribuite su cluster Kubernetes che vengono eseguiti on-premises, nel cloud, sui terminali dei punti vendita nei ristoranti o su dispositivi IOT distribuiti tra i siti remoti dell’azienda. La sua natura open source consente alle persone di sviluppare queste speciali distribuzioni Kubernetes, insieme agli strumenti necessari per gestirle.

### Gestione di Kubernetes
<a name="managing-kubernetes"></a>

Il codice sorgente di Kubernetes è disponibile gratuitamente, quindi è possibile installare e gestire Kubernetes da soli con le proprie apparecchiature. Tuttavia, la gestione automatica di Kubernetes richiede una profonda esperienza operativa e richiede tempo e impegno per la manutenzione. Per questi motivi, la maggior parte delle persone che implementano carichi di lavoro di produzione sceglie un provider cloud (come Amazon EKS) o un provider on-premises (come Amazon EKS Anywhere) con la propria distribuzione Kubernetes testata e il supporto di esperti Kubernetes. Ciò consente di alleggerire gran parte del carico di lavoro indifferenziato necessario per la manutenzione dei cluster, tra cui:
+  **Hardware**: se non disponi di hardware disponibile per eseguire Kubernetes in base alle tue esigenze, un provider di servizi cloud come AWS Amazon EKS può farti risparmiare sui costi iniziali. Con Amazon EKS, ciò significa che puoi utilizzare le migliori risorse cloud offerte da AWS, tra cui istanze di computer (Amazon Elastic Compute Cloud), il tuo ambiente privato (Amazon VPC), la gestione centralizzata di identità e permessi (IAM) e lo storage (Amazon EBS). AWS gestisce i computer, le reti, i data center e tutti gli altri componenti fisici necessari per eseguire Kubernetes. Allo stesso modo, non è necessario pianificare il data center per gestire la capacità massima nei giorni con una maggiore richiesta. Per Amazon EKS Anywhere o altri cluster Kubernetes on-premises, sei responsabile della gestione dell’infrastruttura utilizzata nelle implementazioni Kubernetes, ma puoi comunque contare sull’aiuto di AWS per mantenere Kubernetes aggiornato.
+  **Gestione del piano di controllo**: Amazon EKS gestisce la sicurezza e la disponibilità del piano di controllo Kubernetes ospitato da AWS, responsabile della pianificazione dei container, della gestione della disponibilità delle applicazioni e di altre attività chiave, così che tu possa concentrarti sui carichi di lavoro delle applicazioni. In caso di guasto del cluster, AWS dovrebbe avere a disposizione i mezzi per ripristinarlo in uno stato di esecuzione. Per Amazon EKS Anywhere, il piano di controllo verrebbe gestito dall’utente stesso.
+  **Upgrade testati**: quando aggiorni i tuoi cluster, puoi fare affidamento su Amazon EKS o Amazon EKS Anywhere per fornire versioni testate delle distribuzioni Kubernetes.
+  **Componenti aggiuntivi**: esistono centinaia di progetti creati per estendere e utilizzare Kubernetes che puoi aggiungere all’infrastruttura del cluster o utilizzare per facilitare l’esecuzione dei tuoi carichi di lavoro. Invece di creare e gestire per proprio conto questi componenti aggiuntivi, AWS fornisce [Componenti aggiuntivi Amazon EKS](eks-add-ons.md) che puoi utilizzare coi cluster. Amazon EKS Anywhere fornisce [pacchetti curati](https://anywhere.eks.amazonaws.com/docs/packages/) che includono build di molti progetti open source popolari. Quindi non è necessario creare il software o gestire patch di sicurezza, correzioni di bug o aggiornamenti critici per proprio conto. Allo stesso modo, se le impostazioni predefinite soddisfano le tue esigenze, è normale che sia necessaria una configurazione minima di tali componenti aggiuntivi. Consultare [Estendere i cluster](#extend-clusters) per i dettagli sull’estensione del cluster con componenti aggiuntivi.

### Kubernetes in azione
<a name="kubernetes-in-action"></a>

Il diagramma seguente mostra le attività chiave che potresti svolgere in qualità di amministratore o sviluppatore di applicazioni Kubernetes per creare e utilizzare un cluster Kubernetes. Nel processo, illustra come i componenti di Kubernetes interagiscono tra loro, utilizzando il cloud AWS come esempio del provider cloud sottostante.

![\[Un cluster Kubernetes in azione.\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/k8sinaction.png)


Un amministratore Kubernetes crea il cluster Kubernetes utilizzando uno strumento specifico per il tipo di provider su cui verrà creato il cluster. Questo esempio utilizza il cloud AWS come provider, che offre il servizio Kubernetes gestito chiamato Amazon EKS. Il servizio gestito alloca automaticamente le risorse necessarie per creare il cluster, inclusa la creazione di due nuovi cloud privati virtuali (Amazon VPC) per il cluster, la configurazione della rete e la mappatura delle autorizzazioni Kubernetes direttamente nei nuovi VPC per la gestione delle risorse cloud. Il servizio gestito verifica inoltre che i servizi del piano di controllo abbiano luoghi in cui essere eseguiti e alloca zero o più istanze Amazon EC2 come nodi Kubernetes per l’esecuzione di carichi di lavoro. AWS gestisce un Amazon VPC per il piano di controllo, mentre l’altro Amazon VPC contiene i nodi cliente che eseguono i carichi di lavoro.

Molte delle attività future dell’amministratore di Kubernetes vengono eseguite utilizzando strumenti Kubernetes come `kubectl`. Questo strumento invia le richieste di servizi direttamente al piano di controllo del cluster. I modi in cui le query e le modifiche vengono apportate al cluster sono quindi molto simili a quelli in cui verrebbero eseguite in qualsiasi cluster Kubernetes.

Uno sviluppatore di applicazioni che desidera distribuire carichi di lavoro in questo cluster può eseguire diverse attività. Lo sviluppatore deve creare l’applicazione in una o più immagini di container, quindi inviare tali immagini a un registro di contenitori accessibile al cluster Kubernetes. A tale scopo, AWS offre Amazon Elastic Container Registry (Amazon ECR).

Per eseguire l’applicazione, lo sviluppatore può creare file di configurazione in formato YAML che indicano al cluster come eseguire l’applicazione, compresi quali container estrarre dal registro e come avvolgerli nei pod. Il piano di controllo (scheduler) pianifica i container su uno o più nodi e il runtime del container su ciascun nodo recupera ed esegue effettivamente i container necessari. Lo sviluppatore può anche configurare un Application Load Balancer per bilanciare il traffico verso i container disponibili in esecuzione su ciascun nodo ed esporre l’applicazione al mondo esterno in modo che sia disponibile su una rete pubblica. Fatto ciò, qualcuno che desidera utilizzare l’applicazione può connettersi al suo endpoint per accedervi.

Le sezioni seguenti illustrano i dettagli di ciascuna di queste funzionalità, dal punto di vista dei cluster e dei carichi di lavoro Kubernetes.

## Cluster
<a name="concepts-clusters"></a>

Se il tuo compito è avviare e gestire i cluster Kubernetes, devi sapere come vengono creati, migliorati, gestiti ed eliminati. Devi anche sapere quali sono i componenti che formano un cluster e cosa fare per mantenerli.

Gli strumenti per la gestione dei cluster si occupano della sovrapposizione tra i servizi Kubernetes e il provider hardware sottostante. Per questo motivo, l’automazione di queste attività tende ad essere eseguita dal provider Kubernetes (come Amazon EKS o Amazon EKS Anywhere) utilizzando strumenti specifici per il provider. Ad esempio, per avviare un cluster Amazon EKS si può utilizzare `eksctl create cluster`, mentre per Amazon EKS Anywhere è possibile utilizzare `eksctl anywhere create cluster`. Nota che, sebbene questi comandi creino un cluster Kubernetes, sono specifici del provider e non fanno parte del progetto Kubernetes stesso.

### Strumenti per la creazione e la gestione dei cluster
<a name="cluster-creation-and-management-tools"></a>

Il progetto Kubernetes offre strumenti per creare manualmente un cluster Kubernetes. Quindi, se vuoi installare Kubernetes su una singola macchina o eseguire il piano di controllo su una macchina e aggiungere nodi manualmente, puoi utilizzare strumenti CLI come [kind](https://kind.sigs.k8s.io/), [minikube](https://kubernetes.io/docs/tutorials/hello-minikube/) o [kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) elencati in [Install Tools](https://kubernetes.io/docs/tasks/tools/) di Kubernetes. Per semplificare e automatizzare l’intero ciclo di vita della creazione e della gestione dei cluster, è molto più semplice utilizzare gli strumenti supportati da un provider Kubernetes affermato, come Amazon EKS o Amazon EKS Anywhere.

Nel cloud AWS, puoi creare cluster [Amazon EKS](https://docs.aws.amazon.com/eks/) utilizzando strumenti CLI, come [eksctl](https://eksctl.io/), o strumenti più dichiarativi, come Terraform (consultare [Amazon EKS Blueprints for Terraform](https://github.com/aws-ia/terraform-aws-eks-blueprints)). Puoi creare un cluster da Console di gestione AWS. Consultare [Amazon EKS features](https://aws.amazon.com/eks/features/) per un elenco di ciò che si ottiene con Amazon EKS. Le responsabilità di Kubernetes che Amazon EKS si assume per te includono:
+  **Piano di controllo gestito**: AWS assicura che il cluster Amazon EKS sia disponibile e scalabile perché gestisce il piano di controllo per te e lo rende disponibile in tutte le zone di disponibilità AWS.
+  **Gestione dei nodi**: invece di aggiungere i nodi manualmente, puoi fare in modo che Amazon EKS crei i nodi in automatico a seconda delle necessità, utilizzando Gruppi di nodi gestiti (vedere [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md)) o [Karpenter](https://karpenter.sh/). I gruppi di nodi gestiti presentano integrazioni con [Cluster Autoscaling](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes. Utilizzando gli strumenti di gestione dei nodi, è possibile trarre vantaggio dai risparmi sui costi, come le [istanze spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) e il consolidamento e la disponibilità dei nodi, utilizzando le funzionalità di [pianificazione](https://karpenter.sh/docs/concepts/scheduling/) per impostare la modalità di distribuzione dei carichi di lavoro e la selezione dei nodi.
+  **Rete di cluster**: utilizzando i modelli CloudFormation, `eksctl` configura la rete tra i componenti del piano di controllo e del piano dati (nodo) nel cluster Kubernetes. Inoltre, configura gli endpoint attraverso i quali possono avvenire le comunicazioni interne ed esterne. Per i dettagli, consultare [De-mystifying cluster networking for Amazon EKS worker nodes](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Le comunicazioni tra i pod in Amazon EKS vengono effettuate utilizzando Pod Identity di Amazon EKS (consultare [Informazioni su come EKS Pod Identity consente ai pod di accedere ai servizi AWS](pod-identities.md)), che fornisce un mezzo per consentire ai pod di attingere ai metodi cloud AWS per la gestione delle credenziali e delle autorizzazioni.
+  **Componenti aggiuntivi**: con Amazon EKS non c’è bisogno di creare e aggiungere componenti software comunemente usati per supportare i cluster Kubernetes. Ad esempio, quando crei un cluster Amazon EKS da Console di gestione AWS, questo aggiunge automaticamente i componenti aggiuntivi Amazon EKS kube-proxy ([Gestisci `kube-proxy` nei cluster Amazon EKS](managing-kube-proxy.md)), il plug-in Amazon VPC CNI per Kubernetes ([Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md)) e CoreDNS ([Gestisci CoredNS per DNS nei cluster Amazon EKS](managing-coredns.md)). Consultare [Componenti aggiuntivi Amazon EKS](eks-add-ons.md) per ulteriori elementi aggiuntivi, incluso un elenco di quali sono disponibili.

Per eseguire i cluster su computer e reti on-premises, Amazon offre [Amazon EKS Anywhere](https://anywhere.eks.amazonaws.com/). Invece del cloud AWS come provider, puoi scegliere di eseguire Amazon EKS Anywhere su piattaforme [VMware vSphere](https://anywhere.eks.amazonaws.com/docs/getting-started/vsphere/), [bare metal](https://anywhere.eks.amazonaws.com/docs/getting-started/baremetal/) ([provider Tinkerbell](https://tinkerbell.org)), [Snow](https://anywhere.eks.amazonaws.com/docs/getting-started/snow/), [CloudStack](https://anywhere.eks.amazonaws.com/docs/getting-started/cloudstack/) o [Nutanix](https://anywhere.eks.amazonaws.com/docs/getting-started/nutanix/) utilizzando le tue apparecchiature.

Amazon EKS Anywhere si basa sullo stesso software [Amazon EKS Distro](https://distro.eks.amazonaws.com/) utilizzato da Amazon EKS. Tuttavia, Amazon EKS Anywhere si affida a diverse implementazioni dell’interfaccia [API del cluster Kubernetes](https://cluster-api.sigs.k8s.io/) (CAPI) per gestire l’intero ciclo di vita delle macchine in un cluster Amazon EKS Anywhere (come [CAPV](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere) per vSphere e [CAPC](https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack) per CloudStack). Poiché l’intero cluster è in esecuzione sulle tue apparecchiature, ti assumi la responsabilità aggiuntiva della gestione del piano di controllo e del backup dei relativi dati (consulta `etcd` più avanti in questo documento).

### Componenti del cluster
<a name="cluster-components"></a>

I componenti del cluster Kubernetes sono suddivisi in due aree principali: piano di controllo e nodi worker. [I componenti del piano di controllo](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) gestiscono il cluster e forniscono l’accesso alle relative API. I nodi worker (a volte denominati semplicemente nodi) forniscono i luoghi in cui vengono eseguiti i carichi di lavoro effettivi. [I componenti del nodo](https://kubernetes.io/docs/concepts/overview/components/#node-components) sono costituiti da servizi eseguiti su ciascun nodo per comunicare con il piano di controllo ed eseguire i container. Il set di nodi worker per il cluster è denominato *Piano dati*.

#### Piano di controllo
<a name="concepts-control-plane"></a>

Il piano di controllo è costituito da un insieme di servizi che gestiscono il cluster. Questi servizi possono essere eseguiti tutti su un singolo computer o possono essere distribuiti su più computer. Internamente, queste sono denominate Istanze del piano di controllo (CPI). Il modo in cui vengono eseguite le CPI dipende dalla dimensione del cluster e dai requisiti di elevata disponibilità. Con l’aumento della domanda nel cluster, un servizio del piano di controllo può scalare per fornire più istanze di quel servizio, utilizzando le richieste come bilanciatore del carico tra le istanze.

Le attività eseguite dai componenti del piano di controllo Kubernetes includono:
+  **Comunicazione con i componenti del cluster (server API)**: il server API ([kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)) espone l’API Kubernetes in modo che le richieste al cluster possano essere effettuate sia dall’interno che dall’esterno del cluster. In altre parole, le richieste di aggiunta o modifica degli oggetti di un cluster (pod, servizi, nodi e così via) possono provenire da comandi esterni, come le richieste di esecuzione da parte di `kubectl` di eseguire un pod. Allo stesso modo, è possibile effettuare richieste dal server API ai componenti all’interno del cluster, ad esempio una richiesta al servizio `kubelet` per lo stato di un pod.
+  **Archivia dati sul cluster (archivio di valori delle chiavi `etcd`)**: il servizio `etcd` svolge il ruolo fondamentale di tenere traccia dello stato attuale del cluster. Se il servizio `etcd` diventasse inaccessibile, non sarebbe possibile aggiornare lo stato del cluster o eseguire query su di esso, anche se i carichi di lavoro continuerebbero a funzionare per un po’. Per questo motivo, i cluster critici in genere dispongono di più istanze di bilanciatore del carico del servizio `etcd` in esecuzione contemporaneamente ed effettuano backup periodici dell’archivio di valori delle chiavi `etcd` in caso di perdita o danneggiamento dei dati. Tieni presente che, in Amazon EKS, tutto questo viene gestito automaticamente per impostazione predefinita. Amazon EKS Anywhere fornisce istruzioni per [etcd backup and restore](https://anywhere.eks.amazonaws.com/docs/clustermgmt/etcd-backup-restore/). Consulta [etcd Data Model](https://etcd.io/docs/v3.5/learning/data_model/) per scoprire come `etcd` gestisce i dati.
+  **Programma i pod ai nodi (Scheduler)**: le richieste di avvio o arresto di un pod in Kubernetes vengono indirizzate a [Kubernetes Scheduler](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/) ([kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)). Poiché un cluster può avere più nodi in grado di eseguire il pod, spetta allo Scheduler scegliere su quale nodo (o nodi, nel caso delle repliche) eseguire il pod. Se la capacità disponibile non è sufficiente per eseguire il pod richiesto su un nodo esistente, la richiesta avrà esito negativo, a meno che non siano state prese altre disposizioni. Tali disposizioni potrebbero includere l’abilitazione di servizi come Gruppi di nodi gestiti ([Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md)) o [Karpenter](https://karpenter.sh/) in grado di avviare automaticamente nuovi nodi per gestire i carichi di lavoro.
+  **Mantieni i componenti nello stato desiderato (Gestore di controller)**: il Gestore controller di Kubernetes viene eseguito come processo daemon ([kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)) per monitorare lo stato del cluster e apportare modifiche al cluster per ristabilire gli stati previsti. In particolare, esistono diversi controller che controllano diversi oggetti Kubernetes, tra cui `statefulset-controller`, `endpoint-controller`, `cronjob-controller`, `node-controller` e altri.
+  **Gestisci le risorse cloud (Gestore di controller cloud)**: le interazioni tra Kubernetes e il provider cloud che esegue le richieste per le risorse del data center sottostanti vengono gestite dal [Gestore di controller cloud](https://kubernetes.io/docs/concepts/architecture/cloud-controller/) ([cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)). I controller gestiti da Gestore di controller cloud possono includere un controller di percorso (per configurare i percorsi di rete cloud), un controller di servizio (per l’utilizzo dei servizi di bilanciatore del carico nel cloud) e un controller del ciclo di vita dei nodi (per mantenere i nodi sincronizzati con Kubernetes per tutto il loro ciclo di vita).

#### Nodi di lavoro (piano dati)
<a name="worker-nodes-data-plane"></a>

Per un cluster Kubernetes a nodo singolo, i carichi di lavoro vengono eseguiti sulla stessa macchina del piano di controllo. Tuttavia, una configurazione più standard prevede uno o più sistemi informatici separati ([nodi](https://kubernetes.io/docs/concepts/architecture/nodes/)) dedicati all’esecuzione dei carichi di lavoro Kubernetes.

Quando crei per la prima volta un cluster Kubernetes, alcuni strumenti per la creazione di cluster ti consentono di configurare un certo numero di nodi da aggiungere al cluster (identificando i sistemi informatici esistenti o chiedendo al provider di crearne di nuovi). Prima di aggiungere qualsiasi carico di lavoro a tali sistemi, vengono aggiunti servizi a ciascun nodo per implementare queste funzionalità:
+  **Gestisci ogni nodo (`kubelet`)**: il server API comunica con il servizio [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) in esecuzione su ciascun nodo per assicurarsi che il nodo sia registrato correttamente e che i pod richiesti dallo Scheduler siano in esecuzione. Il kubelet può leggere i manifest dei pod e configurare volumi di archiviazione o altre funzionalità necessarie ai pod sul sistema locale. Può anche verificare lo stato dei container in esecuzione locale.
+  **Esegui i container su un nodo (runtime del container)**: il [Runtime del container](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) su ciascun nodo gestisce i container richiesti per ogni pod assegnato al nodo. Ciò significa che può estrarre le immagini del container dal registro appropriato, eseguire il container, interromperlo e rispondere alle query sul container. Il runtime predefinito del container è [containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). A partire da Kubernetes 1.24, la speciale integrazione di Docker (`dockershim`) che poteva essere utilizzata come runtime del container è stata eliminata da Kubernetes. Sebbene sia ancora possibile utilizzare Docker per testare ed eseguire container sul sistema locale, per utilizzare Docker con Kubernetes ora è necessario [installare il motore Docker](https://docs.docker.com/engine/install/#server) su ogni nodo per utilizzarlo con Kubernetes.
+  **Gestisci la rete tra container (`kube-proxy`)**: per supportare la comunicazione tra i pod, Kubernetes utilizza una funzionalità denominata [Servizio](https://kubernetes.io/docs/concepts/services-networking/service/) per configurare le reti pod che tengono traccia degli indirizzi IP e delle porte associate a tali pod. Il servizio [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) viene eseguito su ogni nodo per consentire la comunicazione tra i pod.

### Estendere i cluster
<a name="extend-clusters"></a>

Esistono alcuni servizi che puoi aggiungere a Kubernetes per supportare il cluster, ma non vengono eseguiti nel piano di controllo. Questi servizi spesso vengono eseguiti direttamente sui nodi del namespace kube-system o nel relativo namespace (come spesso accade con fornitori di servizi di terzi). Un esempio comune è il servizio CoreDNS, che fornisce servizi DNS al cluster. Fai riferimento a [Discovering builtin services](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/) per informazioni su come vedere quali servizi cluster sono in esecuzione in kube-system sul tuo cluster.

Esistono diversi tipi di componenti aggiuntivi che puoi considerare di aggiungere ai tuoi cluster. Per mantenere integri i cluster, puoi aggiungere funzionalità di osservabilità (consultare [Monitoraggio delle prestazioni del cluster e visualizzazione dei log](eks-observe.md)) che consentono di eseguire operazioni come la registrazione, il controllo e le metriche. Con queste informazioni, puoi risolvere i problemi che si verificano, spesso tramite le stesse interfacce di osservabilità. Esempi di questi tipi di servizi includono [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html), CloudWatch (consultare [Monitora i dati del cluster con Amazon CloudWatch](cloudwatch.md)), [AWSDistro for OpenTelemetry](https://aws-otel.github.io/), il plug-in Amazon VPC CNI per Kubernetes (consultare [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md)) e [Grafana Kubernetes Monitoring](https://grafana.com/docs/grafana-cloud/monitor-infrastructure/kubernetes-monitoring/configuration/config-aws-eks/). Per lo storage (consulta [Utilizzo dell’archiviazione di dati delle applicazioni per il tuo cluster](storage.md)), i componenti aggiuntivi di Amazon EKS includono Driver CSI per Amazon Elastic Block Store (consulta [Utilizzare il volume di archiviazione Kubernetes con Amazon EBS](ebs-csi.md)), Driver CSI per Amazon Elastic File System (consulta [Utilizzo dell’archiviazione di file system elastici con Amazon EFS](efs-csi.md)) e diversi componenti aggiuntivi di storage di terzi come Amazon FSx per NetApp ONTAP (driver CSI [Usa l’archiviazione delle app ad alte prestazioni con FSx per NetApp ONTAP](fsx-ontap.md)).

Per un elenco più completo dei componenti aggiuntivi di Amazon EKS, consultare [Componenti aggiuntivi Amazon EKS](eks-add-ons.md).

## Carichi di lavoro
<a name="workloads"></a>

Kubernetes definisce un [carico di lavoro](https://kubernetes.io/docs/concepts/workloads/) come “un’applicazione in esecuzione su Kubernetes”. Tale applicazione può essere costituita da un set di micro servizi eseguiti come [container](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-container) in [pod](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-pod) oppure può essere eseguita come processo batch o un altro tipo di applicazioni. Il compito di Kubernetes è assicurarsi che le richieste effettuate per la configurazione o la distribuzione di tali oggetti vengano eseguite. Chi distribuisce le applicazioni dovrebbe imparare come vengono creati i container, come vengono definiti i pod e quali metodi è possibile utilizzare per distribuirli.

### Container
<a name="containers"></a>

L’elemento più basilare del carico di lavoro di un’applicazione che distribuisci e gestisci in Kubernetes è un * [pod](https://kubernetes.io/docs/concepts/workloads/pods/) *. Un pod rappresenta un modo per contenere i componenti di un’applicazione e per definire le specifiche che descrivono gli attributi del pod. Confrontalo con qualcosa come un pacchetto RPM o Deb, che raggruppa il software per un sistema Linux, ma non funziona come un’entità.

Poiché il pod è l’unità implementabile più piccola, in genere contiene un singolo container. Tuttavia, in un pod possono essere presenti più container nei casi in cui questi siano strettamente collegati. Ad esempio, un container di server Web potrebbe essere impacchettato in un pod con un tipo di container [secondario](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/) che può fornire la registrazione, il monitoraggio o altri servizi strettamente legati al container del server Web. In questo caso, la presenza nello stesso pod garantisce che per ogni istanza in esecuzione del pod, entrambi i container vengano sempre eseguiti sullo stesso nodo. Allo stesso modo, tutti i container in un pod condividono lo stesso ambiente, con i container in un pod che funzionano come se si trovassero nello stesso host isolato. L’effetto è che i container condividono un unico indirizzo IP che fornisce l’accesso al pod e possono comunicare tra loro come se fossero in esecuzione sul proprio host locale.

Le specifiche del pod ([PodSpec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)) definiscono lo stato desiderato del pod. Puoi implementare uno o più pod utilizzando le risorse del carico di lavoro per gestire i [modelli di pod](https://kubernetes.io/docs/concepts/workloads/pods/#pod-templates). Le risorse del carico di lavoro includono [implementazioni](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) (per gestire più repliche di pod), [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) (per implementare pod che devono essere unici, come i pod del database) e [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) (in cui un pod deve essere eseguito continuamente su ogni nodo). Ne parleremo più avanti.

Sebbene un pod sia l’unità più piccola implementabile, un container è l’unità più piccola da costruire e gestire.

#### Costruire container
<a name="building-containers"></a>

Il pod è in realtà solo una struttura attorno a uno o più container, dove ognuno di essi contiene il file system, gli eseguibili, i file di configurazione, le librerie e altri componenti per eseguire effettivamente l’applicazione. Poiché i container sono diventati popolari grazie a una società chiamata Docker Inc., alcune persone si riferiscono ai container come container Docker. Tuttavia, da allora l’[Open Container Initiative](https://opencontainers.org/) ha definito i runtime, le immagini e i metodi di distribuzione dei container per il settore. A ciò si aggiunge il fatto che i container sono stati creati partendo da molte funzionalità Linux esistenti, per cui spesso le persone si riferiscono ai contenitori come container OCI, container Linux o semplicemente container.

Quando si crea un container, in genere si inizia con un Dockerfile (chiamato letteralmente così). All’interno di quel Dockerfile, si identifica:
+  **Un’immagine di base**: un’immagine container di base è un container che viene in genere creato da una versione minima del file system di un sistema operativo (come [Red Hat Enterprise Linux](https://catalog.redhat.com/software/base-images) o [Ubuntu](https://gallery.ecr.aws/docker/library/ubuntu)) o da un sistema minimale migliorato per fornire software al fine di eseguire tipi specifici di applicazioni (come app [nodejs](https://catalog.redhat.com/software/container-stacks/detail/611c11fabd674341b5c5ed64) o [python](https://gallery.ecr.aws/docker/library/python)).
+  **Software applicativo**: puoi aggiungere il tuo software applicativo al container più o meno nello stesso modo in cui lo aggiungeresti a un sistema Linux. Ad esempio, nel tuo Dockerfile puoi eseguire `npm` e `yarn` per installare un’applicazione Java o `yum` e `dnf` per installare pacchetti RPM. In altre parole, utilizzando un comando RUN in un Dockerfile, è possibile eseguire qualsiasi comando disponibile nel file system dell’immagine di base per installare software o configurare software all’interno dell’immagine del container risultante.
+  **Istruzioni**: il [Dockerfile reference](https://docs.docker.com/reference/dockerfile/) descrive le istruzioni che è possibile aggiungere a un Dockerfile durante la configurazione. Queste includono le istruzioni utilizzate per creare ciò che è contenuto nel container stesso (file `ADD` o `COPY` dal sistema locale), identificare i comandi da eseguire quando il container viene eseguito (`CMD` o `ENTRYPOINT`) e connettere il container al sistema su cui viene eseguito (identificando `USER` eseguire come, un `VOLUME` locale da montare o le porte su `EXPOSE`).

Sebbene il comando e il servizio `docker` siano stati tradizionalmente utilizzati per creare container (`docker build`), altri strumenti disponibili per creare immagini di contenitori includono [podman](https://docs.podman.io/en/stable/markdown/podman-build.1.html) e [nerdctl](https://github.com/containerd/nerdctl). Consultare [Creare immagini di container migliori](https://aws.amazon.com/blogs/containers/building-better-container-images) o [Panoramica di Docker Build](https://docs.docker.com/build/) per saperne di più sulla creazione di container.

#### Archiviazione dei container
<a name="storing-containers"></a>

Dopo aver creato l’immagine del container, puoi archiviarla in un [registro di distribuzione](https://distribution.github.io/distribution/) dei container sulla tua workstation o in un registro pubblico dei container. L’esecuzione di un registro di container privato sulla workstation consente di archiviare le immagini dei container in locale, rendendole immediatamente disponibili.

Per archiviare le immagini dei container in modo più pubblico, puoi inviarle a un registro di container pubblico. I registri pubblici dei container forniscono una posizione centrale per l’archiviazione e la distribuzione delle immagini dei container. Esempi di registri di container pubblici includono [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/), il registro [Red Hat Quay](https://quay.io/) e il registro [Docker Hub](https://hub.docker.com/).

Quando esegui carichi di lavoro containerizzati su Amazon Elastic Kubernetes Service (Amazon EKS), consigliamo di estrarre copie delle immagini ufficiali Docker archiviate in Amazon Elastic Container Registry. Amazon ECR archivia queste immagini dal 2021. Puoi cercare le immagini dei container più comuni nella [Galleria pubblica di Amazon ECR](https://gallery.ecr.aws/) e, in particolare, per le immagini di Docker Hub, puoi cercare nella [Galleria docker di Amazon ECR.](https://gallery.ecr.aws/docker/)

#### Esecuzione dei container
<a name="running-containers"></a>

Poiché i container sono creati in un formato standard, un container può essere eseguito su qualsiasi macchina in grado di eseguire un runtime di container (come Docker) e il cui contenuto corrisponda all’architettura della macchina locale (come `x86_64` o `arm`). Per testare un container o semplicemente eseguirlo sul desktop locale, puoi utilizzare i comandi `docker run` o `podman run` per avviare un container su host locale. Per Kubernetes, tuttavia, ogni nodo worker dispone di un runtime di container implementato e spetta a Kubernetes richiedere che un nodo esegua un container.

Una volta che un container è stato assegnato per l’esecuzione su un nodo, quest’ultimo verifica se la versione richiesta dell’immagine del container esiste già sul nodo. In caso contrario, Kubernetes indica al runtime del container di estrarlo dal registro di container appropriato, quindi di eseguirlo localmente. Tieni presente che un’*immagine del container* si riferisce al pacchetto software che viene spostato tra il laptop, il registro dei container e i nodi Kubernetes. Un *container* si riferisce a un’istanza in esecuzione di quell’immagine.

### Pod
<a name="pods"></a>

Una volta che i container sono pronti, l’utilizzo dei pod include la sua configurazione, implementazione e accessibilità.

#### Configurazione dei pod
<a name="configuring-pods"></a>

Quando definisci un pod, gli assegni una serie di attributi. Questi attributi devono includere almeno il nome del pod e l’immagine del container da eseguire. Tuttavia, ci sono molte altre cose che si possono configurare anche con le definizioni dei pod (consulta la pagina [PodSpec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) per i dettagli su cosa può essere inserito in un pod). Ciò include:
+  **Archiviazione**: quando un container in esecuzione viene interrotto ed eliminato, l’archiviazione di dati in quel container scompare, a meno che non si configuri uno spazio di archiviazione più permanente. Kubernetes supporta molti tipi di storage diversi e li riassume sotto il termine [Volumi](https://kubernetes.io/docs/concepts/storage/volumes/). I tipi di storage includono [CephFS](https://kubernetes.io/docs/concepts/storage/volumes/#cephfs), [NFS,](https://kubernetes.io/docs/concepts/storage/volumes/#nfs) [iSCSI](https://kubernetes.io/docs/concepts/storage/volumes/#iscsi) e altri. È anche possibile utilizzare un [dispositivo a blocchi locale](https://kubernetes.io/docs/concepts/storage/volumes/#local) dal computer locale. Con uno di questi tipi di archiviazione disponibili nel cluster, è possibile montare il volume di archiviazione su un punto di montaggio selezionato nel file system del container. Un [volume persistente](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) è quello che continua a esistere dopo l’eliminazione del pod, mentre un [volume temporaneo](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) viene eliminato quando il pod viene eliminato. Se l’amministratore del cluster ha creato diverse [classi di archiviazione](https://kubernetes.io/docs/concepts/storage/storage-classes/) per il cluster, potrebbe essere possibile scegliere gli attributi dello storage da utilizzare, ad esempio se il volume viene eliminato o recuperato dopo l’uso, se si espanderà se è necessario più spazio e anche se soddisfa determinati requisiti di prestazioni.
+  **Segreti**: rendendo disponibile [Segreti](https://kubernetes.io/docs/concepts/configuration/secret/) ai container nelle specifiche del pod, puoi fornire le autorizzazioni necessarie a tali container per accedere a file system, database o altre risorse protette. Chiavi, password e token sono tra gli elementi che possono essere archiviati come segreti. L’uso dei segreti consente di non dover memorizzare queste informazioni nelle immagini dei container, ma è sufficiente rendere i segreti disponibili ai container in esecuzione. [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/) sono simili a Segreti. `ConfigMap` tende a contenere informazioni meno critiche, come coppie chiave-valore per la configurazione di un servizio.
+  **Risorse del container**: gli oggetti per un’ulteriore configurazione dei container possono assumere la forma di configurazione delle risorse. Per ogni container, puoi richiedere la quantità di memoria e CPU che può utilizzare, nonché porre limiti alla quantità totale di tali risorse che il container può utilizzare. Per degli esempi, consultare [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
+  **Interruzioni**: i pod possono essere interrotti involontariamente (un nodo non funziona) o volontariamente (è necessario un aggiornamento). Configurando un [budget per le interruzioni dei pod](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets), puoi esercitare un certo controllo sulla disponibilità dell’applicazione in caso di interruzioni. Per degli esempi, consultare [Specifica di un budget di interruzioni](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) per la tua applicazione.
+  **Namespace**: Kubernetes offre diversi modi per isolare i componenti e i carichi di lavoro di Kubernetes gli uni dagli altri. L’esecuzione di tutti i pod per una particolare applicazione nello stesso [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) è un modo comune per proteggere e gestire insieme tali pod. Puoi creare i tuoi namespace da utilizzare o scegliere di non indicare un namespace (il che fa sì che Kubernetes utilizzi il namespace `default`). I componenti del piano di controllo di Kubernetes vengono in genere eseguiti nel namespace [kube-system](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).

La configurazione appena descritta viene in genere raccolta in un file YAML da applicare al cluster Kubernetes. Per i cluster Kubernetes personali, è possibile archiviare semplicemente questi file YAML sul proprio sistema locale. Tuttavia, con cluster e carichi di lavoro più critici, [GitOps](https://www.eksworkshop.com/docs/automation/gitops/) è un metodo popolare per automatizzare lo storage e gli aggiornamenti sia del carico di lavoro che delle risorse dell’infrastruttura Kubernetes.

Gli oggetti utilizzati per raccogliere e implementare le informazioni sui pod sono definiti da uno dei seguenti metodi di implementazione.

#### Implementazione di pod
<a name="deploying-pods"></a>

Il metodo da scegliere per implementare i pod dipende dal tipo di applicazione che intendi eseguire con gli stessi. Ecco alcune delle scelte:
+  **Applicazioni stateless**: un’applicazione stateless non salva i dati della sessione di un client, quindi un’altra sessione non deve fare riferimento a ciò che è accaduto a una sessione precedente. In questo modo è più semplice sostituire i pod con altri nuovi se non funzionano bene o spostarli senza salvarne lo stato. Se si esegue un’applicazione stateless (come un server Web), è possibile utilizzare un’[Implementazione](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) per implementare [pod](https://kubernetes.io/docs/concepts/workloads/pods/) e [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/). Un ReplicaSet definisce quante istanze di un pod si desidera eseguire contemporaneamente. Sebbene sia possibile eseguire direttamente un ReplicaSet, è comune eseguire le repliche direttamente all’interno di un’Implementazione, per definire quante repliche di un pod devono essere eseguite contemporaneamente.
+  **Applicazioni stateful**: un’applicazione stateful è un’applicazione in cui l’identità del pod e l’ordine in cui vengono avviati i pod sono importanti. Queste applicazioni necessitano di uno storage persistente che sia stabile e che debba essere distribuito e scalato in modo coerente. Per distribuire un’applicazione stateful in Kubernetes, puoi utilizzare [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/). Un esempio di applicazione che viene in genere eseguita come StatefulSet è un database. All’interno di uno StatefulSet, è possibile definire le repliche, il pod e i relativi container, i volumi di archiviazione da montare e le posizioni nel contenitore in cui sono archiviati i dati. Consultare [Run a Replicated Stateful Application](https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/) per un esempio di database implementato come ReplicaSet.
+  **Applicazioni per nodo**: a volte è necessario eseguire un’applicazione su ogni nodo del cluster Kubernetes. Ad esempio, il tuo data center potrebbe richiedere che ogni computer esegua un’applicazione di monitoraggio o un particolare servizio di accesso remoto. Per Kubernetes, puoi utilizzare un [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) per garantire che l’applicazione selezionata venga eseguita su ogni nodo del cluster.
+  **Applicazioni eseguite fino al completamento**: ci sono alcune applicazioni che desideri eseguire per completare un’attività particolare. Ciò potrebbe includerne una che esegue report mensili sullo stato o elimina i vecchi dati. Un oggetto [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) può essere utilizzato per configurare un’applicazione per l’avvio e l’esecuzione, quindi uscire al termine dell’attività. Un oggetto [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) consente di configurare un’applicazione in modo che venga eseguita a un’ora, un minuto, un giorno del mese, un mese o un giorno della settimana specifici, utilizzando una struttura definita dal formato [crontab](https://man7.org/linux/man-pages/man5/crontab.5.html) di Linux.

#### Rendere le applicazioni accessibili dalla rete
<a name="making-applications-accessible-from-the-network"></a>

Poiché le applicazioni venivano spesso implementate come un insieme di micro servizi che si spostavano in luoghi diversi, Kubernetes aveva bisogno di un modo per consentire a tali micro servizi di trovarsi a vicenda. Inoltre, per consentire ad altri di accedere a un’applicazione esterna al cluster Kubernetes, quest’ultimo aveva bisogno di un modo per esporre tale applicazione su indirizzi e porte esterni. Queste funzionalità relative alla rete vengono eseguite rispettivamente con oggetti Servizi e In ingresso:
+  **Servizi**: poiché un pod può spostarsi su nodi e indirizzi diversi, un altro pod che deve comunicare con il primo pod potrebbe avere difficoltà a localizzarlo. Per risolvere questo problema, Kubernetes ti consente di rappresentare un’applicazione come [servizio](https://kubernetes.io/docs/concepts/services-networking/service/). Con un servizio, puoi identificare un pod o un set di pod con un nome particolare, quindi indicare quale porta espone il servizio di quell’applicazione dal pod e quali porte potrebbe utilizzare un’altra applicazione per contattare quel servizio. Un altro pod all’interno di un cluster può semplicemente richiedere un servizio per nome e Kubernetes indirizzerà la richiesta alla porta appropriata per un’istanza del pod che esegue quel servizio.
+  **In ingresso**: [In ingresso](https://kubernetes.io/docs/concepts/services-networking/ingress/) è ciò che può rendere disponibili le applicazioni rappresentate dai servizi Kubernetes ai client esterni al cluster. Le funzionalità di base di In ingresso includono un sistema di bilanciatore del carico (gestito da In ingresso), il controller In ingresso e regole per il routing delle richieste dal controller al servizio. Con Kubernetes, puoi scegliere tra diversi [controller in ingresso](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).

## Passaggi successivi
<a name="next-steps"></a>

Comprendere i concetti di base di Kubernetes e il modo in cui si relazionano ad Amazon EKS ti aiuterà a navigare sia la [Documentazione su Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/) che la [Documentazione di Kubernetes](https://kubernetes.io/docs) per trovare le informazioni necessarie per gestire i cluster Amazon EKS e implementare i carichi di lavoro su tali cluster. Per iniziare a utilizzare Amazon EKS, scegli tra i seguenti:
+  [Nozioni di base su Amazon EKS: `eksctl`](getting-started-eksctl.md) 
+  [Crea un cluster Amazon EKS.](create-cluster.md) 
+  [Implementazione di un’applicazione esemplificativa](sample-deployment.md) 
+  [Organizzazione e monitoraggio delle risorse del cluster](eks-managing.md) 

# Implementazione di cluster Amazon EKS in ambienti cloud e on-premises
<a name="eks-deployment-options"></a>

## Comprensione delle opzioni di implementazione di Amazon EKS
<a name="understand-deployment-options"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) è un servizio Kubernetes completamente gestito che semplifica l’uso di Kubernetes nel cloud e negli ambienti on-premises.

Nel cloud, Amazon EKS automatizza la gestione dell’infrastruttura del cluster Kubernetes per il piano di controllo (control-plane) e i nodi di Kubernetes. Ciò è essenziale per la pianificazione dei container, la gestione della disponibilità delle applicazioni, il dimensionamento dinamica delle risorse, l’ottimizzazione dell’elaborazione, l’archiviazione dei dati del cluster e l’esecuzione di altre funzioni critiche. Con Amazon EKS, ottieni solide prestazioni, dimensionamento, affidabilità e disponibilità dell’infrastruttura AWS, oltre a integrazioni native con servizi AWS di rete, sicurezza, archiviazione e osservabilità.

Per semplificare l’esecuzione di Kubernetes nei tuoi ambienti on-premises, puoi utilizzare gli stessi cluster, funzionalità e strumenti di Amazon EKS in [Crea nodi Amazon Linux su AWS Outposts](eks-outposts-self-managed-nodes.md) o [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md) sulla tua infrastruttura, oppure puoi usare [Amazon EKS Anywhere](https://anywhere.eks.amazonaws.com/) per ambienti isolati autonomi.

## Amazon EKS nel cloud
<a name="eks-cloud-deployment-options"></a>

Puoi utilizzare Amazon EKS con elaborazione in Regioni AWS, AWS Local Zones e Zone Wavelength AWS. Con Amazon EKS nel cloud, la sicurezza, il dimensionamento e la disponibilità del piano di controllo (control-plane) di Kubernetes sono completamente gestiti da AWS nella Regione AWS. Quando esegui applicazioni con elaborazione in Regioni AWS, ottieni l’intera gamma di funzionalità di AWS e Amazon EKS, incluso Amazon EKS Auto Mode, che automatizza completamente la gestione dell’infrastruttura del cluster Kubernetes per elaborazione, l’archiviazione e la rete su AWS con un solo clic. Quando esegui applicazioni con elaborazione in AWS Local Zones e Zone Wavelength AWS, puoi utilizzare i nodi autogestiti di Amazon EKS per connettere le istanze Amazon EC2 per il cluster computing e utilizzare gli altri servizi AWS disponibili in AWS Local Zones e Zone Wavelength AWS. Per ulteriori informazioni, consulta [AWS Local Zones features](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) and [AWS Wavelength Zones features](https://aws.amazon.com/wavelength/features/).


|  | Amazon EKS nelle Regioni AWS | Amazon EKS nelle Local Zone/Zone Wavelength | 
| --- | --- | --- | 
|  Gestione del piano di controllo (control-plane) di Kubernetes  |   Gestito da AWS  |   Gestito da AWS  | 
|  Posizione del piano di controllo Kubernetes  |   Regioni AWS  |   Regioni AWS  | 
|  Piano dati di Kubernetes  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/eks-deployment-options.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/eks-deployment-options.html)  | 
|  Posizione del piano dati Kubernetes  |   Regioni AWS  |   AWS Local Zones o Zone Wavelength  | 

## Amazon EKS nei tuoi data center o ambienti edge
<a name="dc-or-edge-deployment-options"></a>

Se devi eseguire applicazioni nei tuoi data center o ambienti edge, puoi utilizzare [Implementazione di Amazon EKS on-premises con AWS Outposts](eks-outposts.md) o [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md). Puoi utilizzare nodi autogestiti con istanze Amazon EC2 su AWS Outposts per il cluster computing oppure puoi usare Amazon EKS Hybrid Nodes con la tua infrastruttura on-premises o edge per il cluster computing. AWS Outposts è un’infrastruttura gestita da AWS che esegui nei data center o nelle strutture di co-location, mentre Amazon EKS Hybrid Nodes funziona su macchine fisiche o virtuali gestite in ambienti on-premises o edge. Amazon EKS su AWS Outposts e Amazon EKS Hybrid Nodes richiedono una connessione affidabile dagli ambienti on-premises a una Regione AWS e puoi utilizzare gli stessi cluster, funzionalità e strumenti Amazon EKS che usi per eseguire applicazioni nel cloud. In alternativa, quando esegui su AWS Outposts, puoi implementare l’intero cluster Kubernetes su AWS Outposts con i cluster locali Amazon EKS su AWS Outposts.


|  | Amazon EKS Hybrid Nodes | Amazon EKS su AWS Outposts | 
| --- | --- | --- | 
|  Gestione del piano di controllo (control-plane) di Kubernetes  |   Gestito da AWS  |   Gestito da AWS  | 
|  Posizione del piano di controllo Kubernetes  |   Regioni AWS  |   Regioni AWS o AWS Outposts  | 
|  Piano dati di Kubernetes  |  Macchine fisiche o virtuali gestite dal cliente  |  Nodi di Amazon EC2 autogestiti  | 
|  Posizione del piano dati Kubernetes  |  Data center o ambiente edge del cliente  |  Data center o ambiente edge del cliente  | 

## Amazon EKS Anywhere per ambienti isolati
<a name="air-gapped-deployment-options"></a>

 [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) semplifica la gestione dei cluster Kubernetes attraverso l’automazione di operazioni indifferenziate come la configurazione dell’infrastruttura e le operazioni del ciclo di vita del cluster Kubernetes in ambienti on-premises ed edge. A differenza di Amazon EKS, Amazon EKS Anywhere è un prodotto gestito dai clienti e questi ultimi sono responsabili delle operazioni del ciclo di vita dei cluster e della manutenzione dei cluster Amazon EKS Anywhere. Amazon EKS Anywhere è basato sul sottoprogetto dell’API cluster (CAPI) Kubernetes e supporta una vasta gamma di infrastrutture tra cui VMware vSphere, bare metal, Nutanix, Apache CloudStack e AWS Snow. Amazon EKS Anywhere può essere eseguito in ambienti isolati e offre integrazioni opzionali con servizi AWS regionali per l’osservabilità e la gestione delle identità. Per ricevere supporto per Amazon EKS Anywhere e accedere ai componenti aggiuntivi Kubernetes forniti da AWS, puoi acquistare gli [abbonamenti Amazon EKS Anywhere Enterprise](https://aws.amazon.com/eks/eks-anywhere/pricing/).


|  | Amazon EKS Anywhere | 
| --- | --- | 
|  Gestione del piano di controllo (control-plane) di Kubernetes  |  Gestito dal cliente  | 
|  Posizione del piano di controllo Kubernetes  |  Data center o ambiente edge del cliente  | 
|  Piano dati di Kubernetes  |  Macchine fisiche o virtuali gestite dal cliente  | 
|  Posizione del piano dati Kubernetes  |  Data center o ambiente edge del cliente  | 

## Strumenti di Amazon EKS
<a name="tooling-deployment-options"></a>

Puoi utilizzare [Amazon EKS Connector](eks-connector.md) per registrare e connettere qualsiasi cluster Kubernetes conforme ad AWS e visualizzarlo nella console Amazon EKS. Una volta connesso, è possibile visualizzare lo stato, la configurazione e i carichi di lavoro del cluster nella console Amazon EKS. Puoi utilizzare questa funzionalità per visualizzare i cluster connessi nella console Amazon EKS, ma Amazon EKS Connector non semplifica la gestione o le operazioni di modifica dei cluster connessi tramite tale console.

 [Amazon EKS Distro](https://aws.amazon.com/eks/eks-distro/) è la distribuzione AWS dei componenti Kubernetes sottostanti che alimentano tutte le offerte di Amazon EKS. Include i componenti principali necessari per un cluster Kubernetes funzionante, come i componenti del piano di controllo (control-plane) di Kubernetes (etcd, kube-apiserver, kube-scheduler, kube-controller-manager) e i componenti di rete (CoreDNS, kube-proxy, plug-in della Container Network Interface (CNI)). Amazon EKS Distro può essere utilizzato per gestire autonomamente i cluster Kubernetes con strumenti a tua scelta. Le implementazioni di Amazon EKS Distro non sono coperte dai piani di supporto AWS.