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 resilienti e altamente disponibili i carichi di lavoro eseguiti su EKS

Come utilizzare questa guida

Questa guida è destinata agli sviluppatori e agli architetti che desiderano sviluppare e gestire servizi ad alta disponibilità e tolleranti 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 raccomandazioni e best practice per l'affidabilità dei cluster EKS.

Introduzione

Le migliori pratiche di affidabilità per EKS sono state raggruppate nei seguenti argomenti:

Cosa rende affidabile un sistema? Se un sistema può funzionare in modo coerente e soddisfare le richieste nonostante i cambiamenti del suo ambiente nel corso di un periodo di tempo, può essere definito affidabile. Per raggiungere questo obiettivo, il sistema deve rilevare i guasti, risolversi 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 basati su container, l'esecuzione affidabile dei carichi di lavoro richiede anche un'infrastruttura affidabile. In Kubernetes, l'infrastruttura è costituita dal piano di controllo e dal 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 gestisce il piano di controllo di 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 la distribuzione del piano dati Kubernetes.

EKS Auto Mode, 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 distribuire correzioni CVE e patch di sicurezza. È possibile controllare quando ciò si verifica configurando i controlli delle interruzioni nella modalità Auto. NodePools

Fargate gestisce il provisioning e il ridimensionamento 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. Più piano di AWS-managed dati usi, meno responsabilità hai.

I gruppi di nodi gestiti 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, AWS CLI, CloudFormation Terraform oeksctl) per creare, scalare e aggiornare i 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 esegui il provisioning dei nodi gestiti, questi vengono eseguiti come parte di un EKS-managed Auto Scaling Group che può estendersi su più zone di disponibilità; puoi controllarlo tramite le sottoreti fornite durante la creazione dei nodi gestiti. EKS inoltre etichetta 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 patchate di queste AMI in caso di correzione dei 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, anche se è necessario avviare il processo di aggiornamento. Il processo di aggiornamento del nodo gestito è spiegato nella documentazione EKS.

Se utilizzi nodi autogestiti, puoi utilizzare Amazon EKS-optimized Linux AMI per creare nodi di lavoro. Sei responsabile dell'applicazione delle patch e dell'aggiornamento dell'AMI e dei nodi. È consigliabile utilizzare l'eksctlinfrastruttura come strumenti di codice per il provisioning dei nodi autogestiti CloudFormation, poiché in questo modo sarà facile aggiornare i nodi autogestiti. https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html Prendi in considerazione la possibilità di migrare a nuovi nodi quando aggiorni i nodi di lavoro perché il processo di migrazione contamina 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.

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 piano dati EKS, dei componenti principali di Kubernetes e delle tue applicazioni.

Feedback

Questa guida è stata rilasciata GitHub per raccogliere feedback e suggerimenti diretti dalla comunità più ampia. EKS/Kubernetes Se hai delle best practice che ritieni dovremmo includere 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.