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à.
# Le migliori pratiche per l'affidabilità
Questa sezione fornisce indicazioni su come rendere i carichi di lavoro in esecuzione su EKS resilienti e altamente disponibili
## Come utilizzare questa guida
Questa guida è destinata a sviluppatori e architetti che desiderano sviluppare e gestire servizi ad alta disponibilità e con tolleranza ai guasti in EKS. La guida è organizzata in diverse aree tematiche per facilitarne la fruizione. Ogni argomento inizia con una breve panoramica, seguita da un elenco di consigli e best practice per l'affidabilità dei cluster EKS.
## Introduzione
Le migliori pratiche di affidabilità per EKS sono state raggruppate nei seguenti argomenti:
+ Applicazioni
+ Piano di controllo
+ Piano dei dati
Cosa rende affidabile un sistema? Se un sistema può funzionare in modo coerente e soddisfare le esigenze nonostante i cambiamenti dell'ambiente nel corso di un periodo di tempo, può essere definito affidabile. A tal fine, il sistema deve rilevare i guasti, correggersi automaticamente e avere la capacità di scalare in base alla domanda.
I clienti possono utilizzare Kubernetes come base per gestire applicazioni e servizi mission-critical in modo affidabile. Ma oltre a incorporare principi di progettazione delle applicazioni basate su container, l'esecuzione affidabile dei carichi di lavoro richiede anche un'infrastruttura affidabile. In Kubernetes, l'infrastruttura comprende il piano di controllo e il piano dati.
EKS fornisce un piano di controllo Kubernetes di livello di produzione progettato per essere altamente disponibile e tollerante ai guasti.
In EKS, AWS è responsabile dell'affidabilità del piano di controllo Kubernetes. EKS esegue il piano di controllo Kubernetes su tre zone di disponibilità in una regione AWS. Gestisce automaticamente la disponibilità e la scalabilità dei server API Kubernetes e del cluster etcd.
La responsabilità dell'affidabilità del piano dati è condivisa tra te, il cliente e AWS. EKS offre quattro opzioni di nodi di lavoro per l'implementazione del piano dati Kubernetes.
[EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html), che è l'opzione più gestita, gestisce il provisioning, il ridimensionamento e gli aggiornamenti del piano dati oltre a fornire funzionalità gestite di elaborazione, rete e archiviazione. Le AMI in modalità automatica vengono rilasciate frequentemente e i cluster vengono aggiornati automaticamente all'AMI più recente per implementare correzioni CVE e patch di sicurezza. [È possibile controllare quando ciò si verifica configurando i controlli delle interruzioni nella modalità Auto.](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption) NodePools
Fargate gestisce il provisioning e la scalabilità del piano dati eseguendo un Pod per nodo. La terza opzione, i gruppi di nodi gestiti, gestisce il provisioning e gli aggiornamenti del piano dati. Infine, i nodi autogestiti sono l'opzione meno gestita per il piano dati. Maggiore è il piano AWS-managed dati utilizzato, minore è la responsabilità.
[I gruppi di nodi gestiti](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) automatizzano il provisioning e la gestione del ciclo di vita dei nodi EC2. Puoi utilizzare l'API EKS (utilizzando la console EKS, l'API AWS, l'AWS CLICloudFormation, Terraform o`eksctl`) per creare, scalare e aggiornare nodi gestiti. I nodi gestiti eseguono istanze EKS-optimized Amazon Linux 2 EC2 nel tuo account e puoi installare pacchetti software personalizzati abilitando l'accesso SSH. Quando effettui il provisioning dei nodi gestiti, questi vengono eseguiti come parte di un gruppo di EKS-managed Auto Scaling che può estendersi su più zone di disponibilità; puoi controllare questo tramite le sottoreti che fornisci durante la creazione di nodi gestiti. EKS inoltre contrassegna automaticamente i nodi gestiti in modo che possano essere utilizzati con Cluster Autoscaler.
Amazon EKS segue il modello di responsabilità condivisa per i CVE e le patch di sicurezza sui gruppi di nodi gestiti. Poiché i nodi gestiti eseguono le EKS-optimized AMI Amazon, Amazon EKS è responsabile della creazione di versioni con patch di queste AMI in caso di correzioni di bug. L'utente è invece responsabile della distribuzione di queste versioni AMI con patch ai gruppi di nodi gestiti.
EKS [gestisce anche l'aggiornamento dei nodi](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html), sebbene sia necessario avviare il processo di aggiornamento. Il processo di [aggiornamento del nodo gestito](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html) è spiegato nella documentazione EKS.
Se esegui nodi autogestiti, puoi utilizzare l'[AMI Amazon EKS-optimized Linux](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) per creare nodi di lavoro. L'utente è responsabile dell'applicazione di patch e dell'aggiornamento dell'AMI e dei nodi. [È consigliabile utilizzare l'`eksctl`infrastruttura come strumenti di codice per il provisioning di nodi autogestiti CloudFormation, poiché in questo modo sarà più semplice aggiornare i nodi autogestiti.](https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html) Prendi in considerazione [la migrazione a nuovi nodi](https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html) quando aggiorni i nodi di lavoro, poiché il processo di migrazione altera **il** vecchio gruppo di nodi `NoSchedule` e **prosciuga** i nodi dopo che un nuovo stack è pronto ad accettare il carico di lavoro del pod esistente. Tuttavia, puoi anche eseguire un aggiornamento sul posto dei nodi [autogestiti.](https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html)
**Modello di responsabilità condivisa - Fargate**
**Modello di responsabilità condivisa - MNG**
Questa guida include una serie di consigli che puoi utilizzare per migliorare l'affidabilità del tuo piano dati EKS, dei componenti principali di Kubernetes e delle tue applicazioni.
## Feedback
Questa guida è stata pubblicata GitHub per raccogliere feedback e suggerimenti diretti dalla community più ampia. EKS/Kubernetes Se hai una best practice che ritieni debba essere inclusa nella guida, segnala un problema o invia un PR nell' GitHub archivio. Intendiamo aggiornare periodicamente la guida man mano che vengono aggiunte nuove funzionalità al servizio o quando si evolve una nuova best practice.