Compatibilità con la versione Considerazioni sul sistema operativo Creazione di immagini del sistema operativo

Preparazione del sistema operativo per i nodi ibridi

Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu e RHEL vengono convalidati su base continuativa per l’uso come sistema operativo di nodi per nodi ibridi. Bottlerocket è supportato da AWS solo in ambienti VMware vSphere. AL2023 non è coperto dai piani di supporto di AWS se eseguito al di fuori di Amazon EC2. AL2023 può essere utilizzato solo in ambienti virtualizzati on-premises, consulta Amazon Linux 2023 User Guide per ulteriori informazioni. AWS supporta l’integrazione dei nodi ibridi con i sistemi operativi Ubuntu e RHEL ma non fornisce supporto per il sistema operativo stesso.

Il provisioning e la gestione del sistema operativo sono una tua responsabilità. Quando testi i nodi ibridi per la prima volta, è più semplice eseguire la CLI Amazon EKS Hybrid Nodes (nodeadm) su un host già fornito. Per le implementazioni di produzione, ti consigliamo di includere nodeadm nelle immagini del tuo sistema operativo configurate per l’esecuzione come servizio systemd per unire automaticamente gli host ai cluster Amazon EKS all’avvio dell’host. Se utilizzi Bottlerocket come sistema operativo del nodo su vSphere, non è necessario utilizzare nodeadm poiché Bottlerocket contiene già le dipendenze necessarie per i nodi ibridi e si connetterà automaticamente al cluster configurato all’avvio dell’host.

Compatibilità con la versione

La tabella seguente rappresenta le versioni del sistema operativo compatibili e convalidate per l’uso come sistema operativo dei nodi per i nodi ibridi. Se utilizzi altre varianti o versioni del sistema operativo non incluse in questa tabella, la compatibilità dei nodi ibridi con la variante o la versione del sistema operativo non è coperta dall’Assitenza AWS. I nodi ibridi sono indipendenti dall’infrastruttura sottostante e supportano le architetture x86 e ARM.

Sistema operativo	Versioni
Amazon Linux	Amazon Linux 2023 (AL2023)
Bottlerocket	La versione 1.37.0 e le versioni successive VMware che eseguono Kubernetes 1.28 e versioni successive
Ubuntu	Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04
Red Hat Enterprise Linux	RHEL 8, RHEL 9

Considerazioni sul sistema operativo

Domande generali

La CLI Amazon EKS Hybrid Nodes (nodeadm) può essere utilizzata per semplificare l’installazione e la configurazione dei componenti e delle dipendenze dei nodi ibridi. Puoi eseguire il processo nodeadm install durante le pipeline di creazione dell’immagine del sistema operativo o in Passaggio di runtime su ogni host on-premises. Per ulteriori informazioni sui componenti che nodeadm installa, consulta Riferimento nodeadm dei nodi ibridi.
Se utilizzi un proxy nell’ambiente on-premises per accedere a Internet, è necessaria una configurazione aggiuntiva del sistema operativo per i processi di installazione e aggiornamento per configurare il gestore di pacchetti per l’utilizzo del proxy. Per istruzioni, consulta Configurare il proxy per i nodi ibridi.

Bottlerocket

I passaggi e gli strumenti per connettere un nodo Bottlerocket sono diversi da quelli per altri sistemi operativi e sono descritti separatamente in Connessione dei nodi ibridi con Bottlerocket, anziché nelle istruzioni di Connessione di nodi ibridi.
I passaggi per Bottlerocket non utilizzano lo strumento CLI dei nodi ibridi, nodeadm.
Solo le varianti VMware della versione Bottlerocket 1.37.0 e successive sono supportate con EKS Hybrid Nodes. Le varianti VMware di Bottlerocket sono disponibili per le versioni 1.28 e successive di Kubernetes. Altre varianti di Bottlerocket non sono supportate come sistema operativo dei nodi ibridi. NOTA: le varianti VMware di Bottlerocket sono disponibili solo per l’architettura x86_64.

Containerd

Containerd è il runtime del container Kubernetes standard ed è una dipendenza per i nodi ibridi, nonché per tutti i tipi di calcolo dei nodi Amazon EKS. La CLI di Amazon EKS Hybrid Nodes (nodeadm) tenta di installare containerd durante il processo nodeadm install. È possibile configurare l’installazione containerd nella Passaggio di runtime di nodeadm install con l’opzione --containerd-source della riga di comando. Le opzioni valide sono none, distro e docker. Se stai usando RHEL, distro non è un’opzione valida e puoi configurare nodeadm per installare la build containerd dai repository di Docker oppure puoi installare containerd manualmente. Quando utilizzi AL2023 o Ubuntu, nodeadm installa containerd per impostazione predefinita dalla distribuzione del sistema operativo. Se non vuoi che nodeadm installi containerd, usa l’opzione --containerd-source none.

Ubuntu

Se utilizzi Ubuntu 24.04, potresti dover aggiornare la versione di containerd o modificare la configurazione di AppArmor per adottare una correzione che consenta ai pod di chiudersi correttamente, consulta Ubuntu #2065423. È necessario un riavvio per applicare le modifiche al profilo AppArmor. L’ultima versione di Ubuntu 24.04 ha una versione containerd aggiornata nel suo gestore di pacchetti con la correzione (versione containerd 1.7.19 o successive).

ARM

Se utilizzi hardware ARM, è necessario un processore compatibile con ARM v8.2 con la Cryptography Extension (ARMv8.2+crypto) per eseguire la versione 1.31 e successive del componente aggiuntivo EKS kube-proxy. Tutti i sistemi Raspberry Pi precedenti al Raspberry Pi 5, così come i processori basati su Cortex-A72, non soddisfano questo requisito. Come soluzione alternativa, puoi continuare a utilizzare la versione 1.30 del componente aggiuntivo EKS kube-proxy fino alla fine del supporto esteso a luglio del 2026, consultare il Calendario delle versioni di Kubernetes o utilizzare un’immagine kube-proxy personalizzata dall’upstream.
Il seguente messaggio di errore nel registro kube-proxy indica questa incompatibilità:

Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later.

Creazione di immagini del sistema operativo

Amazon EKS fornisce modelli di Packer di esempio che puoi utilizzare per creare immagini del sistema operativo che includono nodeadm e lo configurano per l’esecuzione all’avvio dell’host. Questa procedura è consigliata per evitare di trasferire le dipendenze dei nodi ibridi singolarmente su ciascun host e per automatizzare il processo di bootstrap dei nodi ibridi. Puoi utilizzare i modelli Packer di esempio con un’immagine ISO di Ubuntu 22.04, Ubuntu 24.04, RHEL 8 o RHEL 9 e produrre immagini con questi formati: OVA, Qcow2 o raw.

Prerequisiti

Prima di utilizzare i modelli Packer di esempio, è necessario che sul computer da cui esegui Packer sia installato quanto segue.

Packer versione 1.11.0 o successiva. Per istruzioni sull’installazione di Packer, consulta Install Packer nella documentazione di Packer.
Se stai creando OVA, VMware vSphere plug-in 1.4.0 o successivo
Se stai creando immagini Qcow2 o grezze, plug-in QEMU versione 1.x

Impostazione delle variabili di ambiente

Prima di eseguire la build di Packer, imposta le seguenti variabili di ambiente sul computer da cui stai eseguendo Packer.

Generale

Le seguenti variabili di ambiente devono essere impostate per creare immagini con tutti i sistemi operativi e i formati di output.

Variabile di ambiente	Tipo	Descrizione
PKR_SSH_PASSWORD	Stringa	Packer utilizza le variabili `ssh_username` e `ssh_password` di SSH nella macchina creata durante il provisioning. Ciò deve corrispondere alle password utilizzate per creare l’utente iniziale all’interno dei file kickstart o di dati utente del rispettivo sistema operativo. L’impostazione predefinita è “builder” o “ubuntu” a seconda del sistema operativo. Quando imposti la password, assicurati di cambiarla all’interno del file `ks.cfg` o `user-data`corrispondente.
ISO_URL	Stringa	URL dell’ISO da utilizzare. Può essere un collegamento web da scaricare da un server o un percorso assoluto verso un file locale
ISO_CHECKSUM	Stringa	Checksum associato per l’ISO fornito.
CREDENTIAL_PROVIDER	Stringa	Provider di credenziali per nodi ibridi. I valori validi sono `ssm` (impostazione predefinita) per le attivazioni ibride SSM e `iam` per IAM Roles Anywhere
K8S_VERSION	Stringa	Versione di Kubernetes per nodi ibridi (ad esempio `1.31`). Per le versioni di Kubernetes supportate, consulta la pagina Amazon EKS supported versions.
NODEADM_ARCH	Stringa	Architettura per `nodeadm install`. Seleziona `amd` oppure `arm`.

RHEL

Se utilizzi RHEL, è necessario impostare le seguenti variabili di ambiente.

Variabile di ambiente	Tipo	Descrizione
RH_USERNAME	Stringa	nome utente del gestore di sottoscrizioni RHEL
RH_PASSWORD	Stringa	password del gestore delle sottoscrizioni RHEL
RHEL_VERSION	Stringa	Versione iso di Rhel in uso. I valori validi sono `8` e `9`.

Ubuntu

Non sono richieste variabili di ambiente specifiche per Ubuntu.

vSphere

Se stai creando un OVA VMware vSphere, è necessario impostare le seguenti variabili di ambiente.

Variabile di ambiente	Tipo	Descrizione
VSPHERE_SERVER	Stringa	Indirizzo del server vSphere
VSPHERE_USER	Stringa	Nome utente vSphere
VSPHERE_PASSWORD	Stringa	Password vSphere
VSPHERE_DATACENTER	Stringa	Nome del data center vSphere
VSPHERE_CLUSTER	Stringa	Nome del cluster vSphere
VSPHERE_DATASTORE	Stringa	Nome del datastore vSphere
VSPHERE_NETWORK	Stringa	Nome della rete vSphere
VSPHERE_OUTPUT_FOLDER	Stringa	Cartella di output vSphere per i modelli

QEMU

Variabile di ambiente	Tipo	Descrizione
PACKER_OUTPUT_FORMAT	Stringa	Formato di output per il generatore QEMU. I valori validi sono `qcow2` e `raw`.

Convalida del modello

Prima di eseguire la build, convalida il modello con il seguente comando dopo aver impostato le variabili di ambiente. Sostituisci template.pkr.hcl se stai usando un nome diverso per il tuo modello.


packer validate template.pkr.hcl

Creazione di immagini

Crea le tue immagini con i seguenti comandi e usa il flag -only per specificare la destinazione e il sistema operativo delle tue immagini. Sostituisci template.pkr.hcl se stai usando un nome diverso per il tuo modello.

OVA vSphere

Nota

Se utilizzi RHEL con vSphere, devi convertire i file kickstart in un’immagine OEMDRV e passarla come ISO da cui avviare il sistema. Per ulteriori informazioni, consulta il Packer Readme nel repository GitHub di EKS Hybrid Nodes.

OVA Ubuntu 22.04


packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl

OVA Ubuntu 24.04


packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl

OVA RHEL 8


packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl

OVA RHEL 9


packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl

QEMU

Nota

Se stai creando un’immagine per una CPU host specifica che non corrisponde all’host del tuo generatore, consulta la documentazione QEMU per cercare il nome che corrisponde alla tua CPU host e usa il flag -cpu con il nome della CPU host quando esegui i seguenti comandi.

Qcow2/Raw Ubuntu 22.04


packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl

Qcow2/Raw Ubuntu 24.04


packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl

Qcow2/Raw RHEL 8


packer build -only=general-build.qemu.rhel8 template.pkr.hcl

Qcow2/Raw RHEL 9


packer build -only=general-build.qemu.rhel9 template.pkr.hcl

Trasferimento della configurazione di nodeadm tramite i dati utente

Puoi trasferire la configurazione per nodeadm ai tuoi dati utente tramite cloud-init per configurare e connettere automaticamente i nodi ibridi al cluster EKS all’avvio dell’host. Di seguito è riportato un esempio di come eseguire questa operazione quando utilizzi VMware vSphere come infrastruttura per i nodi ibridi.

Installa la CLI govc seguendo le istruzioni nel govc readme su GitHub.
Dopo aver eseguito la build di Packer nella sezione precedente e aver effettuato il provisioning del modello, puoi clonare il modello per creare più nodi diversi utilizzando quanto segue. Devi clonare il modello per ogni nuova macchina virtuale che stai creando e che verrà utilizzata per i nodi ibridi. Sostituisci le variabili nel comando seguente con i valori per il tuo ambiente. Il comando VM_NAME riportato di seguito viene utilizzato come NODE_NAME quando inserisci i nomi delle macchine virtuali tramite il file metadata.yaml.
```
govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
    -on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"
```

Dopo aver clonato il modello per ciascuna delle tue nuove macchine virtuali, crea un userdata.yaml e un metadata.yaml per le tue macchine virtuali. Le macchine virtuali possono condividerle gli stessi userdata.yaml e metadata.yaml e le popolerai singolarmente nei passaggi seguenti. La configurazione di nodeadm viene creata e definita nella sezione write_files del tuo userdata.yaml. L’esempio seguente utilizza le attivazioni ibride SSM di AWS come provider di credenziali on-premises per i nodi ibridi. Per ulteriori informazioni sulla configurazione di nodeadm, consulta Riferimento nodeadm dei nodi ibridi.

userdata.yaml:


#cloud-config
users:
  - name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu.
    passwd: # password to login. Default is 'builder' for RHEL.
    groups: [adm, cdrom, dip, plugdev, lxd, sudo]
    lock-passwd: false
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash

write_files:
  - path: /usr/local/bin/nodeConfig.yaml
    permissions: '0644'
    content: |
      apiVersion: node.eks.aws/v1alpha1
      kind: NodeConfig
      spec:
          cluster:
              name: # Cluster Name
              region: # AWS region
          hybrid:
              ssm:
                  activationCode: # Your ssm activation code
                  activationId: # Your ssm activation id

runcmd:
  - /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1

metadata.yaml:

Crea un metadata.yaml per il tuo ambiente. Mantieni il formato della variabile "$NODE_NAME" nel file poiché questo verrà compilato con valori in un passaggio successivo.


instance-id: "$NODE_NAME"
local-hostname: "$NODE_NAME"
network:
  version: 2
  ethernets:
    nics:
      match:
        name: ens*
      dhcp4: yes

Aggiungi i file userdata.yaml e metadata.yaml come stringhe gzip+base64 con i seguenti comandi. I seguenti comandi devono essere eseguiti per ciascuna delle macchine virtuali che si stanno creando. Sostituisci VM_NAME con il nome della macchina virtuale che stai aggiornando.


export NODE_NAME="VM_NAME"
export USER_DATA=$(gzip -c9 <userdata.yaml | base64)

govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata="${USER_DATA}"
govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata.encoding=gzip+base64

envsubst '$NODE_NAME' < metadata.yaml > metadata.yaml.tmp
export METADATA=$(gzip -c9 <metadata.yaml.tmp | base64)

govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata="${METADATA}"
govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata.encoding=gzip+base64

Accendi le tue nuove macchine virtuali, che dovrebbero connettersi automaticamente al cluster EKS che hai configurato.
```
govc vm.power -on "${NODE_NAME}"
```

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Preparazione della rete

Preparazione delle credenziali