AMI Amazon Linux ottimizzate per Amazon EKS - Amazon EKS

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 versione1.23, puoi utilizzare un flag bootstrap opzionale per testare la migrazione da a. Docker containerd 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 istanze P2 di Amazon EC2 con le AMI Amazon Linux accelerate ottimizzate e preconfigurate per Amazon EKS. Queste AMI per versioni di Kubernetes 1.25 o successive supporteranno driver di serie NVIDIA 525 o successive, che non sono compatibili con le istanze P2. Tuttavia, i driver della serie NVIDIA 525 o versioni successive sono compatibili con le istanze P3, P4 e P5, quindi puoi utilizzare quelle istanze con le AMI per Kubernetes versione 1.25. Prima che i cluster Amazon EKS vengano aggiornati alla versione 1.25, migrano qualsiasi istanza P2 su istanze P3, P4, e P5. È inoltre necessario aggiornare in modo proattivo le applicazioni per funzionare con la serie NVIDIA 525 o successive. Abbiamo intenzione di effettuare il backport dei driver della NVIDIA 525 serie più recente o successiva alle Kubernetes versioni 1.23 e alla 1.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 esempio dei parametri minimi richiesti è il seguente apiServerEndpointcertificateAuthority, dove ora cidr 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 sul certificateAuthority serviziocidr, consulta DescribeCluster 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 IMDSv2presenta 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 Transizione IMDSv1 all'utilizzo di Instance Metadata Service versione 2 e Sfrutta tutti i vantaggi di IMDSv2 e disabilita IMDSv1 nell'infrastruttura. AWS Se desideri utilizzarloIMDSv1, puoi comunque farlo sovrascrivendo manualmente le impostazioni utilizzando le proprietà di avvio dell'opzione dei metadati dell'istanza.

    Nota

    InfattiIMDSv2, 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 credenziali HttpPutResponseHopLimit 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 cgroupv2viene 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 e Trainium.

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 suGitHub.

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 EKS v20200529 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:

  1. Quando i nodi di lavoro GPU si uniscono al cluster, applicare il plugin del dispositivo NVIDIA per Kubernetes come DaemonSet sul cluster. vX.X.XSostituiteli con la s-device-plugin versione di Nvidia/K8 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
  2. È 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
  1. Crea un file denominato nvidia-smi.yaml con i seguenti contenuti. Sostituisci tag con il tag desiderato per 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
  2. Applicare il file manifesto con il comando seguente.

    kubectl apply -f nvidia-smi.yaml
  3. 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-SMI XXX.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 my-nodegroup.yaml con i seguenti contenuti. Sostituisci ogni example value 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 per ami-1234567890abcdef0, consulta la sezione Recupero ID delle AMI Amazon Linux ottimizzate per Amazon EKS.

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.sh my-cluster --container-runtime containerd
Nota

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.yaml

Se 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.sh su 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: