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à.
AMI Amazon Linux ottimizzate per Amazon EKS
L'AMI Amazon Linux ottimizzata per Amazon EKS è basata su Amazon Linux 2 (AL2) e Amazon Linux 2023 (AL2023). È configurata per fungere da immagine di base per i nodi Amazon EKS. L'AMI è configurata per l'uso con Amazon EKS e include i seguenti componenti:
-
kubelet
-
AWS Autenticatore IAM
-
Docker (Amazon EKS versione
1.23
e precedenti) -
containerd
Nota
-
Puoi tenere traccia degli eventi di sicurezza o privacy per AL2 presso il centro di sicurezza di Amazon Linux
o abbonarti al feed RSS associato. Gli eventi di sicurezza e privacy includono una panoramica del problema, quali sono i pacchetti interessati e come aggiornare le istanze per risolvere il problema. -
Prima di implementare un'AMI accelerata o di tipo Arm, consulta le informazioni in AMI Amazon Linux accelerata ottimizzata per Amazon EKS e AMI Amazon Linux Arm ottimizzate per Amazon EKS.
-
Per quanto riguarda la Kubernetes versione
1.23
, puoi utilizzare un flag bootstrap opzionale per testare la migrazione da a. Dockercontainerd
Per ulteriori informazioni, consulta Prova la migrazione da Docker a containerd. -
A partire da Kubernetes versione
1.25
, non sarai più in grado di utilizzare le istanzeP2
di Amazon EC2 con le AMI Amazon Linux accelerate ottimizzate e preconfigurate per Amazon EKS. Queste AMI per versioni di Kubernetes1.25
o successive supporteranno driver di serieNVIDIA 525
o successive, che non sono compatibili con le istanzeP2
. Tuttavia, i driver della serieNVIDIA 525
o versioni successive sono compatibili con le istanzeP3
,P4
eP5
, quindi puoi utilizzare quelle istanze con le AMI per Kubernetes versione1.25
. Prima che i cluster Amazon EKS vengano aggiornati alla versione1.25
, migrano qualsiasi istanzaP2
su istanzeP3
,P4
, eP5
. È inoltre necessario aggiornare in modo proattivo le applicazioni per funzionare con la serieNVIDIA 525
o successive. Abbiamo intenzione di effettuare il backport dei driver dellaNVIDIA 525
serie più recente o successiva alle Kubernetes versioni1.23
e alla1.24
fine di gennaio 2024. -
A partire dalla versione Amazon EKS
1.30
o successiva, qualsiasi gruppo di nodi gestiti appena creato utilizzerà automaticamente AL2023 come sistema operativo del nodo. In precedenza, i nuovi gruppi di nodi utilizzavano di default AL2. Puoi continuare a utilizzare AL2 scegliendolo come tipo AMI durante la creazione di un nuovo gruppo di nodi. -
Il supporto per AL2 terminerà il 30 giugno 2025. Per ulteriori informazioni, consulta Domande frequenti su Amazon Linux 2
.
Aggiornamento da AL2 a AL2023
L'AMI ottimizzata per Amazon EKS è disponibile in due famiglie basate su AL2 e AL2023. AL2023 è un nuovo sistema operativo basato su Linux progettato per fornire un ambiente sicuro, stabile e ad alte prestazioni per le tue applicazioni cloud. È la nuova generazione di Amazon Linux di Amazon Web Services ed è disponibile in tutte le versioni supportate di Amazon EKS, incluse le versioni 1.23
e 1.24
con supporto esteso. Le AMI accelerate di Amazon EKS basate su AL2023 saranno disponibili in un secondo momento. Se hai carichi di lavoro accelerati, dovresti continuare a utilizzare l'AMI accelerata AL2 o Bottlerocket.
AL2023 offre diversi miglioramenti rispetto ad AL2. Per un confronto completo, consulta Comparing AL2 e Amazon Linux 2023 nella Amazon Linux 2023 User Guide. Diversi pacchetti sono stati aggiunti, aggiornati e rimossi da AL2. Si consiglia vivamente di testare le applicazioni con AL2023 prima dell'aggiornamento. Per un elenco di tutte le modifiche ai pacchetti in AL2023, consulta Modifiche ai pacchetti in Amazon Linux 2023 nelle Note di rilascio di Amazon Linux 2023.
Oltre a queste modifiche, dovresti essere consapevole di quanto segue:
-
AL2023 introduce un nuovo processo di inizializzazione dei nodi
nodeadm
che utilizza uno schema di configurazione YAML. Se utilizzi gruppi di nodi autogestiti o un'AMI con un modello di avvio, ora dovrai fornire esplicitamente metadati del cluster aggiuntivi quando crei un nuovo gruppo di nodi. Un esempiodei parametri minimi richiesti è il seguente apiServerEndpoint
certificateAuthority
, dove oracidr
sono richiesti e il servizio:--- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name:
my-cluster
apiServerEndpoint:https://example.com
certificateAuthority:Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr:10.100.0.0/16
In AL2, i metadati di questi parametri sono stati rilevati dalla chiamata
DescribeCluster
API di Amazon EKS. Con AL2023, questo comportamento è cambiato poiché la chiamata API aggiuntiva rischia di rallentare durante l'up-up di nodi su larga scala. Questa modifica non ha effetto su di te se utilizzi gruppi di nodi gestiti senza un modello di avvio o se utilizzi. Karpenter Per ulteriori informazioni sulcertificateAuthority
serviziocidr
, consultaDescribeCluster
la pagina Amazon EKS API Reference. -
Dockernon è supportato in AL2023 per tutte le versioni di Amazon EKS supportate. Il supporto per Docker è terminato ed è stato rimosso con la versione Amazon EKS
1.24
o successiva in AL2. Per ulteriori informazioni sull'obsolescenza, consulta Amazon EKS ha terminato il supporto per.Dockershim
-
Per AL2023 è richiesta la versione Amazon VPC CNI
1.16.2
o superiore. -
AL2023 richiede per impostazione predefinita.
IMDSv2
IMDSv2
presenta diversi vantaggi che aiutano a migliorare il livello di sicurezza. Utilizza un metodo di autenticazione orientato alla sessione che richiede la creazione di un token segreto in una semplice richiesta HTTP PUT per avviare la sessione. Il token di una sessione può essere valido per un periodo compreso tra 1 secondo e 6 ore. Per ulteriori informazioni su come passare da aIMDSv2
, consulta TransizioneIMDSv1
all'utilizzo di Instance Metadata Service versione 2 e Sfrutta tutti i vantaggi di IMDSv2 e disabilita IMDSv1nell'infrastruttura. AWS Se desideri utilizzarlo IMDSv1
, puoi comunque farlo sovrascrivendo manualmente le impostazioni utilizzando le proprietà di avvio dell'opzione dei metadati dell'istanza.Nota
Infatti
IMDSv2
, il numero di hop predefinito per i gruppi di nodi gestiti è impostato su 1. Ciò significa che i contenitori non avranno accesso alle credenziali del nodo tramite IMDS. Se hai bisogno dell'accesso del contenitore alle credenziali del nodo, puoi comunque farlo sovrascrivendo manualmente le credenzialiHttpPutResponseHopLimit
in un modello di lancio Amazon EC2 personalizzato, aumentandolo a 2. In alternativa, puoi utilizzare Amazon EKS Pod Identity per fornire credenziali anzichéIMDSv2
. -
AL2023 presenta la nuova generazione di gerarchia unificata dei gruppi di controllo ().
cgroupv2
cgroupv2
viene utilizzato per implementare un runtime di container e da.systemd
Sebbene AL2023 includa ancora codice che può far funzionare il sistemacgroupv1
, questa non è una configurazione consigliata o supportata. Questa configurazione verrà completamente rimossa in una delle future release principali di Amazon Linux.
Per i gruppi di nodi gestiti in precedenza, puoi eseguire un aggiornamento sul posto o un aggiornamento blu/verde a seconda di come utilizzi un modello di lancio:
-
Se utilizzi un'AMI personalizzata con un gruppo di nodi gestito, puoi eseguire un aggiornamento sul posto scambiando l'ID AMI nel modello di avvio. È necessario assicurarsi che le applicazioni e tutti i dati utente vengano trasferiti ad AL2023 prima di eseguire questa strategia di aggiornamento.
-
Se utilizzi gruppi di nodi gestiti con il modello di avvio standard o con un modello di avvio personalizzato che non specifica l'ID AMI, devi eseguire l'aggiornamento utilizzando una strategia blu/verde. Un aggiornamento blu/verde è in genere più complesso e comporta la creazione di un gruppo di nodi completamente nuovo in cui specificare AL2023 come tipo AMI. Il nuovo gruppo di nodi dovrà quindi essere configurato con cura per garantire che tutti i dati personalizzati del gruppo di nodi AL2 siano compatibili con il nuovo sistema operativo. Una volta che il nuovo gruppo di nodi è stato testato e convalidato con le applicazioni, Pods può essere migrato dal vecchio gruppo di nodi al nuovo gruppo di nodi. Una volta completata la migrazione, puoi eliminare il vecchio gruppo di nodi.
Se utilizzi Karpenter e desideri utilizzare AL2023, dovrai modificare il EC2NodeClass
amiFamily
campo con AL2023. Per impostazione predefinita, Drift è abilitato in. Karpenter Ciò significa che, una volta modificato il amiFamily
campo, Karpenter aggiornerà automaticamente i nodi di lavoro all'AMI più recente, quando disponibile.
AMI Amazon Linux accelerata ottimizzata per Amazon EKS
Nota
Le AMI accelerate di Amazon EKS basate su AL2023 saranno disponibili in un secondo momento. Se disponi di carichi di lavoro accelerati, dovresti continuare a utilizzare l'AMI accelerata AL2 o. Bottlerocket
L'AMI Amazon Linux accelerata ottimizzata per Amazon EKS è basata sull'AMI Amazon Linux standard ottimizzata per Amazon EKS. È configurato per fungere da immagine opzionale per i nodi Amazon EKS per supportare carichi di lavoro basati su GPU, Inferentia
Oltre alla configurazione standard dell'AMI ottimizzata per Amazon EKS, l'AMI accelerata include quanto segue:
-
Driver NVIDIA
-
Il
nvidia-container-runtime
(come runtime predefinito) -
AWS Neuronruntime del contenitore
Per un elenco dei componenti più recenti inclusi nell'AMI accelerata, consulta le amazon-eks-ami
versioni
Nota
-
L'AMI accelerata ottimizzata per Amazon EKS supporta solo i tipi di istanza basati su GPU e Inferentia. Assicurati di specificare questi tipi di istanza nel tuo AWS CloudFormation modello di nodo. Utilizzando l'AMI accelerata ottimizzata per Amazon EKS, si accettano i termini del contratto di licenza con l'utente finale (EULA) di NVIDIA
. -
L'AMI accelerata ottimizzata per Amazon EKS era precedentemente denominata AMI ottimizzata per Amazon EKS con supporto GPU.
-
Le versioni precedenti dell'AMI accelerata ottimizzata per Amazon EKS prevedevano l'installazione del repository
nvidia-docker
. Il repository non è più incluso nella versione dell'AMI di Amazon EKSv20200529
e successive.
Abilitazione dei carichi di lavoro basati su GPU
Nella sezione seguente viene descritto come eseguire un carico di lavoro su un'istanza basata su GPU con l'AMI accelerata e ottimizzata per Amazon EKS. Per altre opzioni, consulta i seguenti riferimenti:
-
Per ulteriori informazioni sull'utilizzo dei carichi di lavoro basati su Inferentia, consulta Inferenza del machine learning utilizzando AWS Inferentia.
-
Per ulteriori informazioni sull'utilizzo di Neuron, consulta la sezione Containers - Kubernetes - Getting Started
nella documentazione di AWS Neuron.
-
Quando i nodi di lavoro GPU si uniscono al cluster, applicare il plugin del dispositivo NVIDIA per Kubernetes
come DaemonSet sul cluster.
Sostituiteli con la s-device-plugin versione di Nvidia/K8vX.X.X
desiderata prima di eseguire il seguente comando. kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/
vX.X.X
/nvidia-device-plugin.yml -
È possibile verificare che i nodi abbiano GPU allocabili con il seguente comando.
kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"
Implementazione di un Pod utile a verificare che i nodi della GPU siano configurati correttamente
-
Crea un file denominato
nvidia-smi.yaml
con i seguenti contenuti. Sostituisci
con il tag desiderato pertag
nvidia/cuda
. Questo manifesto avvia un container NVIDIA CUDA che esegue nvidia-smi
su un nodo.apiVersion: v1 kind: Pod metadata: name: nvidia-smi spec: restartPolicy: OnFailure containers: - name: nvidia-smi image: nvidia/cuda:
tag
args: - "nvidia-smi" resources: limits: nvidia.com/gpu: 1 -
Applicare il file manifesto con il comando seguente.
kubectl apply -f nvidia-smi.yaml
-
Quando il Pod ha terminato l'esecuzione, visualizzane i registri tramite il comando seguente.
kubectl logs nvidia-smi
Di seguito viene riportato un output di esempio:
Mon Aug 6 20:23:31 20XX
+-----------------------------------------------------------------------------+ | NVIDIA-SMIXXX.XX
Driver Version:XXX.XX
| |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 Tesla V100-SXM2... On | 00000000:00:1C.0 Off | 0 | | N/A 46C P0 47W / 300W | 0MiB / 16160MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+
AMI Amazon Linux Arm ottimizzate per Amazon EKS
Le istanze Arm offrono significativi risparmi sui costi per applicazioni aumentabili orizzontalmente e basate su Arm come server Web, microservizi containerizzati, parchi istanze di memorizzazione nella cache e archivi di dati distribuiti. Quando si aggiungono nodi Arm al cluster, esaminare le considerazioni riportate di seguito.
Considerazioni
-
Se il cluster è stato implementato prima del 17 agosto 2020, è necessario eseguire un aggiornamento una tantum dei manifesti critici dei componenti aggiuntivi del cluster. In questo modo Kubernetes può estrarre l'immagine corretta per ogni architettura hardware utilizzata nel cluster. Per ulteriori informazioni sull'aggiornamento dei componenti aggiuntivi del cluster, consultare Aggiornamento della versione di Kubernetes per il cluster Amazon EKS. Se il cluster è stato implementato il 17 agosto 2020 o in una data successiva, i componenti aggiuntivi CoreDNS,
kube-proxy
e Amazon VPC CNI plugin for Kubernetes sono già predisposti per un sistema multi-architettura. -
Le applicazioni implementate nei nodi Arm devono essere compilate per Arm.
-
Se si dispone di DaemonSets implementati in un cluster esistente o si desidera distribuirli in un nuovo cluster in cui implementare anche i nodi Arm, verificare che DaemonSet possa essere eseguito su tutte le architetture hardware del cluster.
-
È possibile eseguire gruppi di nodi Arm e gruppi di nodi x86 nello stesso cluster. In tal caso, è consigliabile implementare le immagini di container multiarchitettura in un repository del container, come Amazon Elastic Container Registry (Amazon ECR), quindi aggiungere i selettori di nodi ai manifesti in modo che Kubernetes sappia in quale architettura hardware può essere implementato un Pod. Per ulteriori informazioni, consultare Inviare un'immagine multi-architettura nella Guida per l'utente di Amazon ECR ed il blog post Presentazione di immagini container multi-architettura per Amazon ECR
.
Prova la migrazione da Docker a containerd
Amazon EKS ha interrotto il supporto per Docker a partire dal lancio di Kubernetes versione 1.24
. Per ulteriori informazioni, consulta Amazon EKS ha terminato il supporto per Dockershim.
Per quanto riguarda la Kubernetes versione1.23
, puoi utilizzare un flag bootstrap opzionale per abilitare il containerd
runtime per le AMI AL2 ottimizzate per Amazon EKS. Questa funzione fornisce un percorso chiaro per la migrazione a containerd
quando viene eseguito l'aggiornamento alla versione 1.24
o successiva. Amazon EKS ha interrotto il supporto per Docker a partire dal lancio di Kubernetes versione 1.24
. Il runtime di containerd
è stato ampiamente adottato nella community Kubernetes ed è un progetto promosso con il CNCF (Cloud Native Computer Foundation). È possibile testarlo aggiungendo un gruppo di nodi a un cluster nuovo o esistente.
Creando uno tra i seguenti tipi di gruppi di nodi, è possibile abilitare il flag di bootstrap.
- Autogestito
-
Crea il gruppo di nodi utilizzando le istruzioni riportate in Avvio di nodi Amazon Linux autogestiti. Specifica un'AMI ottimizzata per Amazon EKS e il testo seguente per il parametro
BootstrapArguments
.--container-runtime containerd
- Gestiti
-
Se si utilizza
eksctl
, è necessario creare un file denominato
con i seguenti contenuti. Sostituisci ognimy-nodegroup
.yaml
con i valori in tuo possesso. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura. Per recuperare l'ID di un'AMI ottimizzata perexample value
ami-
, consulta la sezione Recupero ID delle AMI Amazon Linux ottimizzate per Amazon EKS.1234567890abcdef0
apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name:
my-cluster
region:region-code
version:1.23
managedNodeGroups: - name:my-nodegroup
ami: ami-1234567890abcdef0
overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.shmy-cluster
--container-runtime containerdNota
Se si avviano più nodi contemporaneamente, potrebbe essere necessario specificare anche i valori per gli argomenti di bootstrap
--apiserver-endpoint
,--b64-cluster-ca
e--dns-cluster-ip
, al fine di evitare errori. Per ulteriori informazioni, consulta Specifica di un'AMI.Esegui i seguenti comandi per creare il gruppo di nodi.
eksctl create nodegroup -f
my-nodegroup
.yamlSe si preferisce utilizzare uno strumento diverso per creare il gruppo di nodi gestiti, è necessario implementare il gruppo di nodi utilizzando un modello di avvio. Nel modello di avvio, specifica l'ID di un'AMI ottimizzata per Amazon EKS, quindi implementa il gruppo di nodi utilizzando un modello di avvio e fornisci i seguenti dati utente. Questi dati utente passano gli argomenti nel file
bootstrap.sh
. Per ulteriori informazioni sul file bootstrap, consulta bootstrap.shsu GitHub. /etc/eks/bootstrap.sh
my-cluster
--container-runtime containerd
Ulteriori informazioni
Per ulteriori informazioni sull'utilizzo delle AMI Amazon Linux ottimizzate per Amazon EKS, consulta le sezioni seguenti:
-
Per utilizzare Amazon Linux con gruppi di nodi gestiti, consulta la sezione Gruppi di nodi gestiti.
-
Per avviare nodi Amazon Linux autogestiti, consulta la sezione Recupero ID delle AMI Amazon Linux ottimizzate per Amazon EKS.
-
Per informazioni sulla versione, consulta AMI Amazon Linux ottimizzata per Amazon EKS.
-
Per recuperare gli ID più recenti delle AMI Amazon Linux ottimizzate per Amazon EKS, consulta la sezione Recupero ID delle AMI Amazon Linux ottimizzate per Amazon EKS.
-
Per consultare gli script open-source che vengono utilizzati per creare l'AMI ottimizzata per Amazon EKS, consulta la sezione Script di build per AMI Amazon Linux ottimizzata per Amazon EKS.