AMI Amazon Linux ottimizzate per Amazon EKS
L'AMI Amazon Linux ottimizzata per Amazon EKS è stata sviluppata sulla base di Amazon Linux 2 ed è configurata per fungere da immagine di base per i nodi Amazon EKS. L'AMI è configurata per funzionare con Amazon EKS e include Docker, kubelet, e AWS l'autenticatore IAM.
-
Per tenere traccia degli eventi di sicurezza o di privacy per Amazon Linux 2, consultare il Centro di sicurezza di Amazon Linux
o iscriviti al feed RSS corrispondente. 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, consultare le informazioni in AMI Amazon Linux accelerata ottimizzata per Amazon EKS e AMI Arm Amazon Linux ottimizzate per Amazon EKS.
-
Amazon Linux 2 ottimizzato per Amazon EKS contiene un flag di bootstrap opzionale per abilitare il tempo di esecuzione di
containerd. Kubernetes versione 1.21 sarà l'ultima con il supporto del tempo di esecuzione del container Docker. Questa caratteristica fornisce un percorso chiaro per la migrazione acontainerd. Il tempo di esecuzione dicontainerdè 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. Per ulteriori informazioni, consulta . Abilitazione del tempo di esecuzione del flag di bootstrap containerd. Se protratti in AMI Amazon Linux accelerate ottimizzate per Amazon EKS per la versione 1.21, i carichi di lavoro e AWS Inferentianon sono supportati.
Apri un collegamento in una delle seguenti tabelle per visualizzare l'ID dell'ultima AMI Amazon Linux ottimizzata per Amazon EKS per identificare una Regione AWS e la versione Kubernetes corrispondente. Puoi anche recuperare gli ID con un parametro AWS Systems Manager utilizzando diversi strumenti. Per ulteriori informazioni, consulta . Recupero ID delle AMI Amazon Linux ottimizzate per Amazon EKS.
Queste AMI richiedono il modello di nodo AWS CloudFormation più recente. Non è possibile utilizzare queste AMI con una versione precedente del modello di nodo. Se lo fai, non riescono a unirsi al cluster. Assicurati di aggiornare qualsiasi pila di nodi AWS CloudFormation con il modello più recente (URL mostrato di seguito) prima di tentare di utilizzare queste AMI.
https://amazon-eks.s3.us-west-2.amazonaws.com/cloudformation/2020-10-29/amazon-eks-nodegroup.yaml
Il modello di nodo AWS CloudFormation avvia i nodi di lavoro con i dati utente Amazon EC2, i quali attivano uno script di bootstrap
Abilitazione del tempo di esecuzione del flag di bootstrap containerd
L'AMI Amazon Linux 2 ottimizzata per Amazon EKS contiene un flag di bootstrap opzionale per abilitare il tempo di esecuzione containerd. Questa caratteristica fornisce un percorso chiaro per la migrazione a containerd. Amazon EKS sta per interrompere il supporto per Docker a partire dal lancio di Kubernetes versione 1.23. Per ulteriori informazioni, consulta . Definizione come obsoleto di Dockershim.
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 in Avvio di nodi Amazon Linux autogestiti. Specifica un'AMI ottimizzata per Amazon EKS e il seguente testo per il parametro BootstrapArguments.
--container-runtime containerd -
Gestito – Se si utilizza
eksctl, crea un file denominatomy-nodegroup.yamlexample-valueapiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name:my-clusterregion:region-codemanagedNodeGroups: - name:my-nodegroupami:eks-optimized-AMI-IDoverrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.shmy-cluster--container-runtime containerdEsegui i seguenti comandi per creare il gruppo di nodi.
eksctl create nodegroup -fmy-nodegroup.yaml--version1.21Se 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 un ID AMI ottimizzata per Amazon EKS, quindi implementa il gruppo di nodi utilizzando un modello di avvio e fornisci 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.shmy-cluster\ --container-runtime containerd
AMI Amazon Linux accelerata ottimizzata per Amazon EKS
L'AMI Amazon Linux accelerata ottimizzata per Amazon EKS è basata sull'AMI Amazon Linux standard ottimizzata per Amazon EKS. È configurata per fungere da immagine facoltativa per i nodi Amazon EKS per supportare i carichi di lavoro basati su GPU e Inferentia
Oltre alla configurazione standard dell'AMI ottimizzata per Amazon EKS, l'AMI accelerata include quanto segue:
-
Driver NVIDIA
-
Il
nvidia-container-runtime(come tempo di esecuzione predefinito) -
AWSTempo di esecuzione del container Neuron
-
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 modello di nodo AWS CloudFormation. 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 EKSv20200529e 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 ulteriori informazioni sull'utilizzo dei carichi di lavoro basati su Inferentia, vedere Inferenza del machine learning utilizzando AWS Inferentia.
-
Quando i nodi di lavoro GPU si uniscono al cluster, applicare il plug-in del dispositivo NVIDIA per Kubernetes
come set di daemon sul cluster attraverso il seguente comando. kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/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"
Per implementare un pod utile a verificare che i nodi della GPU siano configurati correttamente
-
Creare un file denominato
nvidia-smi.yamlcon i seguenti contenuti. Questo manifesto avvia un container Cuda che eseguenvidia-smisu un nodo.apiVersion: v1 kind: Pod metadata: name: nvidia-smi spec: restartPolicy: OnFailure containers: - name: nvidia-smi image: nvidia/cuda:9.2-devel 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, visualizzarne i log:
kubectl logs nvidia-smiL'output è il seguente.
Mon Aug 6 20:23:31 2018 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 396.26 Driver Version: 396.26 | |-------------------------------+----------------------+----------------------+ | 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 Arm Amazon Linux 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, flotte 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 Kubernetes di un cluster Amazon EKS . Se il cluster è stato implementato il 17 agosto 2020 o dopo il 17 agosto 2020, il
coredns,kube-proxye i plug-in Amazon VPC CNI per i componenti aggiuntivi di Kubernetes sono già predisposti alla multi-architettura. -
Le applicazioni distribuite nei nodi Arm devono essere compilate per Arm.
-
Non è possibile utilizzare il Driver CSI per Amazon FSx for Lustre con Arm.
-
Se si dispone di DaemonSets implementati in un cluster esistente o si desidera distribuirli in un nuovo cluster in cui si vuole 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 immagini contenitore multi-architettura in un container repository come Amazon Elastic Container Registry, quindi aggiungere 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
.
