Aggiornamento da Amazon Linux 2 ad Amazon Linux 2023

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 modello di avvio che specifica un ID AMI personalizzato, ora devi fornire esplicitamente metadati aggiuntivi del cluster. È necessario fornire questi metadati quando si crea un nuovo gruppo di nodi. Di seguito è riportato un esempio dei parametri minimi richiesti da nodeadm apiServerEndpointcertificateAuthority, dove e il servizio cidr sono ora obbligatori:

---
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 una limitazione (della larghezza di banda della rete) durante gli aumenti verticali su larga scala dei nodi. 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 su certificateAuthority e sul servizio cidr, consulta DescribeCluster nel Riferimento di API Amazon EKS.

Per AL2023, nodeadm modifica anche il formato per applicare i parametri a kubelet per ogni nodo che utilizza NodeConfigSpec. In AL2, ciò è stato fatto con il parametro --kubelet-extra-args. Questo è usato comunemente per aggiungere etichette e taint ai nodi. L’esempio seguente mostra l’applicazione di maxPods e --node-labels al nodo.

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: test-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
  kubelet:
    config:
      maxPods: 110
    flags:
      - --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test

Per AL2023 è richiesta la versione del CNI di Amazon VPC 1.16.2 o superiore.

AL2023 richiede IMDSv2 per impostazione predefinita. IMDSv2 presenta diversi vantaggi che aiutano a migliorare il livello di sicurezza. Usa un metodo di autenticazione orientato alla sessione che prevede la creazione di un token segreto in una semplice richiesta HTTP PUT per avviare la sessione. Il token di una sessione può avere una validità compresa tra 1 secondo e 6 ore. Per ulteriori informazioni su come passare da aIMDSv2, consulta Transition IMDSv1 to using Instance Metadata Service Version 2 e Ottieni tutti i vantaggi di IMDSv2 e disabilita IMDSv1 nella tua infrastruttura. AWS Se desideri usare IMDSv1, puoi farlo comunque sovrascrivendo manualmente le impostazioni usando le proprietà di avvio dell’opzione dei metadati di istanza.

AL2023 presenta la nuova generazione di gerarchia unificata dei gruppi di controllo (cgroupv2). cgroupv2 viene utilizzato per implementare un runtime di container e da parte di systemd. Sebbene AL2023 contenga ancora codice che consentirebbe il funzionamento del sistema con cgroupv1, si tratta di una configurazione sconsigliata o non supportata. Questa configurazione verrà completamente rimossa in una delle future release principali di Amazon Linux.

eksctl versione 0.176.0 o successiva è richiesta affinché eksctl supporti AL2023.

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. Devi assicurarti 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 blue/green strategia. Un blue/green aggiornamento è in genere più complesso e comporta la creazione di un gruppo di nodi completamente nuovo in cui è necessario specificare AL2023 come tipo di 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, i Pod possono essere migrati dal vecchio gruppo di nodi al nuovo gruppo di nodi. Una volta completata la migrazione, puoi eliminare il vecchio gruppo di nodi.