Versioni Kubernetes per Amazon EKS - Amazon EKS

Versioni Kubernetes per Amazon EKS

Il progetto Kubernetes è in rapida evoluzione, con nuove funzionalità, aggiornamenti di progettazione e correzioni di bug. La community rilascia nuove versioni secondarie di Kubernetes, come ad esempio 1.21, generalmente ogni tre mesi. Ogni versione secondaria è supportata per circa dodici mesi dalla data di prima pubblicazione.

Versioni di Kubernetes disponibili per Amazon EKS

Le versioni di Kubernetes attualmente disponibili per nuovi cluster Amazon EKS sono le seguenti:

  • 1.21.5

  • 1.20.7

  • 1.19.15

  • 1.18.16

A meno che l'applicazione non richieda una versione specifica di Kubernetes, per i cluster consigliamo di scegliere la versione di Kubernetes più recente disponibile supportata da Amazon EKS. Man mano che nuove versioni di Kubernetes diventano disponibili in Amazon EKS, ti consigliamo di aggiornare tempestivamente i cluster in modo da usare la versione più recente disponibile. Per istruzioni sull'aggiornamento del cluster, consultare Aggiornamento di un cluster. Per ulteriori informazioni sulle versioni di Kubernetes, consultare Calendario di rilascio di Amazon EKS Kubernetes e Supporto per la versione di Amazon EKS e domande frequenti.

Nota

A cominciare dal lancio della versione 1.23 di Kubernetes, le AMI Amazon EKS pubblicate ufficialmente includeranno containerd come unico tempo di esecuzione. Le versioni dalla 1.17 alla 1.21 di Kurbernetes utilizzano Docker come tempo di esecuzione predefinito, ma dispongono di un'opzione di flag di bootstrap che consente di testare i carichi di lavoro su qualsiasi cluster supportato oggi con containerd. Per ulteriori informazioni, consulta . Definizione come obsoleto di Dockershim.

Kubernetes 1.21

Kubernetes 1.21 è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes 1.21, consultare l'annuncio del rilascio ufficiale.

Importante

  • Rete dual-stack supporto (indirizzi IPv4 e IPv6) su pod, servizi e nodi ha raggiunto lo stato beta. Tuttavia, Amazon EKS ed il CNI di Amazon VPC attualmente non supportano la rete dual stack.

  • L'AMI Amazon Linux 2 ottimizzata per Amazon EKS ora contiene un flag di bootstrap per abilitare il tempo di esecuzione containerd come alternativa a Docker. Questo flag consente la preparazione per la rimozione di Docker come tempo di esecuzione supportato nella prossima versione di Kubernetes. Per ulteriori informazioni, consulta . Abilitazione del tempo di esecuzione del flag di bootstrap containerd. Questo può essere monitorato attraverso il Roadmap dei container su Github.

  • Supporto di gruppi di nodi gestiti per l'espansore di priorità Cluster Autoscaler.

    I gruppi di nodi gestiti appena creati sui cluster Amazon EKS v1.21 utilizzano il seguente formato per il nome del gruppo Auto Scaling sottostante:

    eks-<managed-node-group-name>-<uuid>

    In questo modo è possibile utilizzare la caratteristica priority expander di Cluster Autoscaler per scalare i gruppi di nodi in base alle priorità definite dall'utente. Un caso d'uso comune consiste nel preferire il ridimensionamento dei gruppi di nodi spot rispetto ai gruppi on demand. Questa modifica al comportamento risolve il problema di roadmap dei container #1304.

Le seguenti caratteristiche di Kubernetes sono ora supportate nei cluster Amazon EKS di Kubernetes 1.21:

  • CronJobs (in precedenza ScheduledJobs) ha ora raggiunto lo stato stabile. Con questa modifica, gli utenti possono eseguire regolarmente azioni pianificate, come backup e generazione di report.

  • Segreti Immutabili e ConfigMaps sono ora passati allo stato stabile. A questi oggetti è stato aggiunto un nuovo campo immutabile per rifiutare le modifiche. Questa impossibilità di modifica protegge il cluster da aggiornamenti che possono involontariamente interrompere le applicazioni. Poiché queste risorse sono immutabili, kubelet non esegue la ricerca aggiornamenti. Questo riduce il carico kube-apiserver e migliora la scalabilità e le prestazioni.

  • Terminazione aggraziata del nodo è ora passata allo stato beta. Con questo aggiornamento, il kubelet è a conoscenza dell'arresto del nodo e può terminare correttamente i pod di tale nodo. Prima di questo aggiornamento, in caso di arresto di un nodo, i rispettivi pod non seguivano il ciclo di vita di terminazione previsto. Ciò provocava problemi di carico di lavoro. Ora, il kubelet può rilevare l'imminente arresto del sistema attraverso systemd, e informare i pod in esecuzione in modo che terminino correttamente.

  • Ora è possibile, per i pod con più container, utilizzare l'annotazione kubectl.kubernetes.io/default-container per avere un container preselezionato per i comandi kubectl.

  • PodSecurityPolicy è in fase di graduale eliminazione. PodSecurityPolicy sarà ancora funzionale per diverse versioni in base alle linee guida di deprecazione di Kubernetes. Per ulteriori informazioni, consultare Deprecazione di PodSecurityPolicy: passato, presente e futuro e il blog AWS.

Per il changelog completo di Kubernetes 1.21, consultare https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md.

Kubernetes 1.20

Per ulteriori informazioni su Kubernetes 1.20, consultare l'annuncio del rilascio ufficiale.

Importante

Le seguenti caratteristiche di Kubernetes sono ora supportate nei cluster Amazon EKS di Kubernetes 1.20:

  • Priorità e correttezza delle API ha raggiunto lo stato beta ed è abilitato per impostazione predefinita. Ciò consente a kube-apiserver di classificare le richieste in entrata in base ai livelli di priorità.

  • RunTimeClass ha raggiunto lo stato stabile. La risorsa RuntimeClass fornisce un meccanismo per supportare più tempi di esecuzione in un cluster e fornisce informazioni sul tempo di esecuzione del container al piano di controllo.

  • Limiti ID di processo ha acquisito disponibilità generale.

  • debug di Kubectl ha raggiunto lo stato beta. kubectl debug fornisce il supporto per i flussi di lavoro di debug comuni direttamente da kubectl.

  • Il tempo di esecuzione del container Docker è stato eliminato. La community di Kubernetes ha scritto un post su un blog dedicato al tema, assieme ad una pagina dedicata alle Domande frequenti. Le immagini prodotte da Docker possono continuare ad essere utilizzate e funzioneranno come sempre. È possibile ignorare in modo sicuro il messaggio di avviso relativo al rendere obsoleto Dockershim stampato nei registri di avvio di kubelet. EKS alla fine passerà a containerd come tempo di esecuzione per l'AMI Amazon Linux 2 ottimizzata per EKS. Per ulteriori dettagli, è possibile seguire la discussione sulla roadmap dei container.

  • Il nome host del pod come FQDN è passato allo stato beta. Questa caratteristica consente di impostare il nome host di un pod sul suo Fully Qualified Domain Name (Nome di dominio completo, FQDN), dando la possibilità di impostare il campo hostname del kernel sul nome di dominio completo di un pod.

  • Ora è possibile passare il plug-in delle credenziali client-go nelle informazioni correnti del cluster tramite la variabile di ambiente KUBERNETES_EXEC_INFO. Questo miglioramento consente ai client Go di eseguire l'autenticazione utilizzando provider di credenziali esterni, ad esempio un sistema di gestione delle chiavi (KMS).

Per il changelog completo di Kubernetes 1.20, consultare https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md.

Kubernetes 1.19

Per ulteriori informazioni su Kubernetes 1.19, consultare l'annuncio del rilascio ufficiale.

Importante

  • A partire dalla versione 1.19, Amazon EKS non aggiunge più il tag kubernetes.io/cluster/<cluster-name> alle sottoreti passate quando vengono creati i cluster. Questo tag di sottorete è necessario solo se si desidera influenzare la posizione in cui il controller di servizio Kubernetes o AWS Load Balancer Controller posiziona l'Elastic Load Balancer. Per maggiori informazioni sui requisiti delle sottoreti passate ad Amazon EKS durante la creazione del cluster, consultare gli aggiornamenti a Considerazioni su cluster VPC e sottoreti.

  • Non è più necessario fornire un contesto di protezione per i contenitori non root che devono accedere al file token di identità Web per essere utilizzati con i ruoli IAM per gli account di servizio. Per ulteriori informazioni, consultare Ruoli IAM per gli account di servizio eproposta per la gestione delle autorizzazioni di file nel volume di account di servizio previsto su GitHub.

  • Il webhook dell'identità del pod è stato aggiornato per rispondere al problema di GitHub Controllo di avvio mancante Il webhook ora supporta anche un'annotazione per controllare la scadenza del token. Per ulteriori informazioni, consultare l'articolo relativo alla creazione di una richiesta pull GitHub.

  • CoreDNS versione 1.8.0 è la versione consigliata per i cluster Amazon EKS 1.19. Questa versione è installata per impostazione predefinita nei nuovi cluster Amazon EKS 1.19. Per ulteriori informazioni, consulta . Gestione del componente aggiuntivo CoreDNS.

  • Le AMI Amazon Linux 2 ottimizzate per Amazon EKS includono la versione 5.4 del kernel Linux per Kubernetes versione 1.19. Per ulteriori informazioni, consulta . AMI Amazon Linux ottimizzata per Amazon EKS.

  • La CertificateSigningRequest API è stato promosso a certificates.k8s.io/v1 stabile con le seguenti modifiche:

    • spec.signerName è ora obbligatoria. Non è possibile creare richieste per kubernetes.io/legacy-unknown con l'API certificates.k8s.io/v1.

    • È possibile continuare a creare CSR con il nome del firmatario kubernetes.io/legacy-unknown con l'API certificates.k8s.io/v1beta1.

    • È possibile continuare a richiedere che un CSR sia firmato per un certificato server non nodo, webhook (ad esempio, con l'API certificates.k8s.io/v1beta1). Questi CSR non sono approvati automaticamente.

    • Per approvare i certificati, un utente con privilegi richiede la versione di kubectl 1.18.8 o successive.

    Per ulteriori informazioni sull'API del certificato v1, consultare Richieste di firma certificati nella documentazione Kubernetes.

Le seguenti risorse Amazon EKS Kubernetes sono fondamentali per il funzionamento del piano di controllo Kubernetes. Si consiglia di non eliminarle o modificarle.

Autorizzazione Tipo Spazio dei nomi Motivo
eks:certificate-controller Rolebinding kube-system Impatto sulla funzionalità del firmatario e dell'approvatore nel piano di controllo.
eks:certificate-controller Role kube-system Impatto sulla funzionalità del firmatario e dell'approvatore nel piano di controllo.
eks:certificate-controller ClusterRolebinding Tutti Impatto sulla capacità di kubelet di richiedere certificati server che influiscono su determinate funzionalità del cluster come kubectl exec e kubectl logs.

Le seguenti caratteristiche di Kubernetes sono ora supportate nei cluster Amazon EKS di Kubernetes 1.19:

  • Il controller di ammissione ExtendedResourceToleration è ora abilitato. Questo controller di ammissione aggiunge automaticamente tolleranza per le contaminanti per pod che richiedono risorse estese, come le GPU, in modo da non dover aggiungere manualmente le tolleranze. Per ulteriori informazioni, consultare ExtendResourceOleration nella documentazione Kubernetes.

  • I Bilanciatori di carico elastici (CLB e NLB) forniti dal controller di servizio interno di Kubernetes supportano il filtraggio dei nodi inclusi come destinazioni di istanza. Ciò consente di evitare di raggiungere i limiti dei gruppi target in cluster di grandi dimensioni. Per ulteriori informazioni, consultare l'articolo GitHub relativo e service.beta.kubernetes.io/aws-load-balancer-target-node-labels l'annotazione sotto Altre annotazioni ELB nella documentazione Kubernetes.

  • Pod Topology Spread ha raggiunto lo stato stabile. È possibile utilizzare i vincoli di distribuzione della topologia per controllare la distribuzione dei pod nel cluster tra domini di fallimento quali aree, zone, nodi e altri domini di topologia definiti dall'utente. Ciò può aiutare a raggiungere un'elevata disponibilità e un utilizzo efficiente delle risorse. Per ulteriori informazioni, consultare Vincoli Pod Topology Spread Constraints nella documentazione di Kubernetes.

  • L'API Ingress ha raggiunto la disponibilità generale. Per ulteriori informazioni, consultare Ingress nella documentazione Kubernetes.

  • EndpointSlices sono attivate per impostazione predefinita. EndpointSlices è una nuova API che fornisce un'alternativa più scalabile ed estendibile all'API Endpoint per tenere traccia di indirizzi IP, porte, disponibilità e informazioni sulla topologia per i pod che supportano un servizio. Per ulteriori informazioni, consultare Scalare la rete Kubernetes con EndpointSlices nel blog di Kubernetes.

  • Ora è possbile contrassegnare i volumi Secret e ConfigMap come immutabili. Ciò riduce significativamente il carico sul server API se sono presenti molti volumi Secret e ConfigMap nel cluster. Per ulteriori informazioni, consultare ConfigMap e Segreti nella documentazione di Kubernetes.

Per il changelog completo di Kubernetes 1.19, consultare https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md.

Kubernetes 1.18

Per ulteriori informazioni su Kubernetes 1.18, consultare l'annuncio del rilascio ufficiale.

Le seguenti caratteristiche di Kubernetes sono ora supportate nei cluster Amazon EKS di Kubernetes 1.18:

  • Topology Manager ha raggiunto lo stato beta. Questa funzione consente alla CPU e a Gestione periferiche di coordinare le decisioni di allocazione delle risorse, ottimizzando la bassa latenza con carichi di lavoro di machine learning e analisi dei dati. Per ulteriori informazioni, consultare Controllo dei criteri di gestione della topologia su un nodo nella documentazione Kubernetes.

  • Server-side Apply viene aggiornato con una nuova versione beta. Questa funzione tiene traccia e gestisce le modifiche ai campi di tutti i nuovi oggetti Kubernetes, consentendo all'utente di sapere cosa ha cambiato le sue risorse e quando. Per ulteriori informazioni, consultare Server-side Apply nella documentazione di Kubernetes.

  • Un nuovo pathType campo e una nuova IngressClass risorsa è stata aggiunta alla specifica di Ingress. Queste funzionalità semplificano la personalizzazione della configurazione di Ingress e sono supportate dal AWS Controller di bilanciatore del carico (precedentemente denominato ALB Ingress Controller (Controller di Ingress ALB)). Per ulteriori informazioni, consultare Miglioramenti all'API Ingress in Kubernetes 1.18 nella documentazione di Kubernetes.

  • Comportamento di scalabilità automatica orizzontale del pod configurabile. Per ulteriori informazioni, consultare Support per il comportamento di scalabilità configurabile nella documentazione Kubernetes.

  • Nelle Regioni Cinesi, non è più necessario aggiungere nei cluster 1.18 la variabile di ambiente AWS_DEFAULT_REGION=<region-code> ai pod che utilizzano i ruoli IAM per gli account di servizio, sia che si utilizzi il webhook di modifica sia che si configurino manualmente le variabili di ambiente. È comunque necessario includere la variabile per tutti i pod nelle versioni precedenti.

  • I nuovi cluster contengono valori predefiniti aggiornati in externalTrafficPolicy. HealthyThresholdCount e UnhealthyThresholdCount sono 2 ciascuno e HealthCheckIntervalSeconds viene ridotto a 10 secondi. I cluster creati nelle versioni precedenti e aggiornati mantengono i valori precedenti.

Per il changelog completo di Kubernetes 1.18, consultare https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md.

Kubernetes 1.17

Per ulteriori informazioni su Kubernetes 1.17, consultare l'annuncio del rilascio ufficiale.

Importante
  • EKS non ha abilitato l'opzione flag della caratteristica CSIMigrationAWS. Quest'ultima sarà abilitato in una versione futura, insieme a istruzioni dettagliate sulla migrazione. Per ulteriori informazioni sulla migrazione CSI, consultare il blog Kubernetes.

Le seguenti caratteristiche di Kubernetes sono ora supportate nei cluster Amazon EKS di Kubernetes 1.17:

  • Cloud Provider Labels ha raggiunto la disponibilità generale. Se si utilizza le etichette beta nelle specifiche del proprio pod per funzioni come l'affinità dei nodi o in qualsiasi controller personalizzato, è consigliabile iniziare la migrazione alle nuove etichette GA. Per informazioni sulle nuove etichette, consultare la seguente documentazione di Kubernetes:

  • La caratteristica ResourceQuotaScopeSelectors è passata a generalmente disponibile. È possibile utilizzare questa caratteristica per limitare il numero di risorse supportate da una quota solo alle risorse relative all'ambito.

  • La caratteristica TaintNodesByCondition è passata a generalmente disponibile. Questa caratteristica consente di eseguire il taint dei nodi che presentano condizioni come un'alta pressione del disco o della memoria.

  • La caratteristica Topologia CSI si è passata a generalmente disponibile ed è pienamente supportata dal Driver CSI EBS. È possibile utilizzare la topologia per limitare la zona di disponibilità in cui viene eseguito il provisioning di un volume.

  • Protezione del finalizzatore per servizi di tipo LoadBalancer è passato a disponibile a livello generale. Questa caratteristica garantisce che una risorsa di servizio non venga eliminata completamente fino a quando non viene eliminato anche il bilanciatore del carico correlato.

  • Le risorse personalizzate ora supportano valori di default. È possibile specificare i valori in uno Schema di convalida OpenAPI v3.

  • La caratteristica Container Windows RunAsUsername è ora in versione beta. È possibile utilizzarla per eseguire applicazioni Windows in un container con un nome utente diverso da quello di default.

Per il changelog completo di Kubernetes 1.17, consultare https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md.

Calendario di rilascio di Amazon EKS Kubernetes

Nota

Le date con solo un mese e un anno sono approssimative e vengono aggiornate con una data esatta quando nota.

Versione di Kubernetes Versione upstream Versione Amazon EKS Fine del supporto Amazon EKS
1,17 9 dicembre 2019 10 luglio 2020 2 novembre 2021
1.18 23 marzo 2020 13 ottobre 2020 31 marzo 2022
1.19 26 agosto 2020 16 febbraio 2021 Giugno 2022
1.20 8 dicembre 2020 18 maggio 2021 Settembre 2022
1.21 8 aprile 2021 19 luglio 2021 Febbraio 2023
1.22 4 agosto 2021 Marzo 2022 Maggio 2023

Supporto per la versione di Amazon EKS e domande frequenti

Amazon EKS, in linea con il supporto della community Kubernetes per le versioni di Kubernetes, si impegna a eseguire almeno quattro versioni di Kubernetes pronte per la produzione in qualunque momento. L'annuncio della data di fine supporto di una qualsiasi versione secondaria di Kubernetes sarà comunicato almeno 60 giorni prima. A causa del processo di qualifica e rilascio di Amazon EKS per le nuove versioni di Kubernetes, la data di fine supporto di una versione di Kubernetes in Amazon EKS avverrà in corrispondenza o dopo la data in cui il progetto Kubernetes smetterà di supportare la versione a monte.

Domande frequenti

D: Quanto dura il supporto Amazon EKS per una versione Kubernetes?

R: Una versione Kubernetes è completamente supportata per 14 mesi dopo la prima disponibilità su Amazon EKS. Ciò è confermato anche se l'upstream Kubernetes non supporterà più una versione disponibile in Amazon EKS. Viene eseguito il backporting delle patch di sicurezza applicabili alle versioni di Kubernetes supportate in Amazon EKS.

D: Riceverò un avviso quando il supporto per una versione Kubernetes su Amazon EKS è terminato?

R: Sì, se un cluster nel tuo account sta eseguendo la versione che si avvicina alla fine del supporto, Amazon EKS invia un avviso tramite il AWS Health Dashboard circa 12 mesi dopo il rilascio della versione Kubernetes su Amazon EKS. L'avviso include la data di fine supporto. Questo è di almeno 60 giorni dalla data dell'invio dell'avviso.

D: Cosa succede allo scadere della data di fine supporto?

R: Allo scadere della data di fine di supporto, non è più possibile creare nuovi cluster Amazon EKS con la versione non supportata. I piani di controllo esistenti vengono automaticamente aggiornati da Amazon EKS alla versione più vecchia supportata tramite un processo di implementazione graduale dopo la data di fine supporto. Dopo l'aggiornamento automatico del piano di controllo, è necessario aggiornare manualmente i componenti aggiuntivi del cluster e i nodi Amazon EC2. Per ulteriori informazioni, consulta . Aggiornamento della versione Kubernetes di un cluster Amazon EKS .

D: Allo scadere della data di fine supporto, quando avverrà esattamente l'aggiornamento automatico del piano di controllo?

R: Amazon EKS non è in grado di fornire periodi di tempo specifici. Gli aggiornamenti automatici possono avvenire in qualsiasi momento dopo la data di fine supporto. Ti consigliamo di intraprendere azioni proattive e aggiornare il tuo piano di controllo senza fare affidamento sul processo di aggiornamento automatico di Amazon EKS. Per ulteriori informazioni, consulta . Aggiornamento di un cluster.

D: Posso lasciare il mio piano di controllo su una versione Kubernetes a tempo indeterminato?

R: No, per AWS, la sicurezza del cloud ha la massima priorità. Dopo un certo periodo (di solito 1 anno), la community Kubernetes smette di rilasciare patch CVE e scoraggia l'invio di CVE per le versioni obsolete. Ciò significa che le vulnerabilità specifiche di una versione precedente di Kubernetes potrebbero non essere segnalate, lasciando i cluster esposti senza preavviso e senza opzioni di correzione in caso di vulnerabilità. Amazon EKS ritiene che questa sia una posizione di sicurezza inaccettabile e, di conseguenza, non consente ai piani di controllo di rimanere su una versione che ha raggiunto la fine del supporto.

D: Quali funzionalità di Kubernetes sono supportate da Amazon EKS?

R: Amazon EKS supporta tutte le funzionalità di disponibilità generale dell'API Kubernetes, nonché le funzionalità beta abilitate per impostazione predefinita. Alcune caratteristiche alfa non sono supportate.

D: I gruppi di nodi gestiti da Amazon EKS vengono aggiornati automaticamente insieme alla versione del piano di controllo cluster?

R: No, un gruppo di nodi gestiti crea istanze Amazon EC2 nel tuo account. Queste istanze non vengono aggiornate automaticamente quando l'utente o Amazon EKS aggiorna il piano di controllo. Se Amazon EKS aggiornasse automaticamente il tuo piano di controllo, la versione Kubernetes del tuo gruppo di nodi gestito potrebbe essere aggiornato a più di una versione precedente al tuo piano di controllo. Se un gruppo di nodi gestiti contiene istanze che eseguono Kubernetes aggiornato a più di una versione precedente al piano di controllo, il gruppo di nodi presenta un problema di integrità nella sezione Gruppi nodi nella scheda Calcolo, contenuta a sua volta nella scheda Configurazione del cluster nella console. Se un gruppo di nodi presente un aggiornamento alla versione disponibile, Aggiorna ora viene visualizzato accanto al gruppo di nodi nella console. Per ulteriori informazioni, consulta . Aggiornamento di un gruppo di nodi gestiti. Si consiglia di mantenere la stessa versione di Kubernetes sul piano di controllo e sui nodi.

D: I gruppi di nodi autogestiti vengono aggiornati automaticamente insieme alla versione del piano di controllo cluster?

R: No, un gruppo di nodi autogestito include istanze Amazon EC2 nel tuo account. Queste istanze non vengono aggiornate automaticamente quando l'uente o Amazon EKS aggiorna la versione del piano di controllo. Nella console, un gruppo di nodi autogestito non ha riceve alcuna indicazione di aggiornamento. È possibile visualizzare la versione di kubelet installata su un nodo selezionando il nodo nella finestra di dialogo Nodi nella scheda Panoramica del cluster per determinare quali nodi devono essere aggiornati. È necessario aggiornare manualmente i nodi. Per ulteriori informazioni, consulta . Aggiornamenti del nodo autogestito.

Il progetto Kubernetes verifica la compatibilità tra il piano di controllo e i nodi per un massimo di due versioni secondarie. Ad esempio, i nodi 1.19 continuano a funzionare se orchestrati da un piano di controllo 1.21. Tuttavia, non è consigliabile l'esecuzione di un cluster con nodi che sono persistentemente aggiornati a due versioni secondarie precedenti rispetto al piano di controllo. Per ulteriori informazioni, consultare Policy per la versione Kubernetes e il supporto Skew della versione nella documentazione di Kubernetes. Si consiglia di mantenere la stessa versione di Kubernetes sul piano di controllo e sui nodi.

D: I pod in esecuzione su Fargate vengono aggiornati automaticamente con un aggiornamento automatico della versione del piano di controllo cluster?

Sì, i pod Fargate funzionano sull'infrastruttura in account di proprietà AWS sul lato Amazon EKS del Modello di responsabilità condivisa. Amazon EKS utilizza l'API di espulsione Kubernetes per tentare di terminare in modo aggraziato i pod in esecuzione su Fargate. Per ulteriori informazioni, consultare l'argomento relativo alle espulsioni API nella documentazione di Kubernetes. Se un pod non può essere espulso, Amazon EKS emette un comando Kubernetes delete pod. Si consiglia vivamente di eseguire pod Fargate come parte di un controller di replica, così come avviene in una implementazione Kubernetes, in modo che un pod venga riprogrammato automaticamente dopo l'eliminazione. Per ulteriori informazioni, consultare l'argomento relativo alla funzionalità Deployments nella documentazione Kubernetes. La nuova versione del pod Fargate viene implementata con una kubelet versione che è la stessa versione aggiornata del piano di controllo cluster.

Importante

Se si aggiorna il piano di controllo, è necessario aggiornare personalmente i nodi Fargate. Per aggiornare i nodi Fargate, eliminare il contenitore Fargate rappresentato dal nodo e implementare nuovamente il pod. Il nuovo pod viene implementato con una versione kubelet che è la stessa versione del cluster.