Preparazione del sistema operativo per i nodi ibridi - Amazon EKS
Compatibilità delle versioniConsiderazioni sul sistema operativoCreazione di immagini del sistema operativo

Contribuisci a migliorare questa pagina

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

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

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

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 solo da AWS ambienti VMware vSphere. AL2023 non è coperto dai piani di AWS supporto se eseguito al di fuori di Amazon EC2. AL2023 può essere utilizzato solo in ambienti virtualizzati locali, consulta la Guida per l'utente di Amazon Linux 2023 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à delle versioni

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 si utilizzano 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 da AWS Support. I nodi ibridi sono indipendenti dall’infrastruttura sottostante e supportano le architetture x86 e ARM.

Sistema operativo Versioni

Amazon Linux

Amazon Linux 2023 (AL2023)

Portabottiglie

v1.37.0 e versioni successive che eseguono Kubernetes v1.28 e VMware versioni successive

Ubuntu

Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04

Red Hat Enterprise Linux

RHEL 8, RHEL 9

Considerazioni sul sistema operativo

Ambito generale

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

Portabottiglie

  • 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 VMware le varianti della versione Bottlerocket v1.37.0 e successive sono supportate con EKS Hybrid Nodes. VMware le varianti di Bottlerocket sono disponibili per le versioni Kubernetes v1.28 e successive. Altre varianti di Bottlerocket non sono supportate come sistema operativo dei nodi ibridi. NOTA: le VMware varianti 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 si usa AL2 023 o Ubuntu, per nodeadm impostazione predefinita installa containerd dalla distribuzione del sistema operativo. Se non vuoi che nodeadm installi containerd, usa l’opzione --containerd-source none.

Ubuntu

ARM

  • Se si utilizza hardware ARM, è necessario un processore compatibile con ARMv8 .2 con l'estensione di crittografia (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.

  • In fase di compilazione OVAs, VMware vSphere plugin 1.4.0 o versione successiva

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

Ambito 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 Description

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

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 Description

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 si sta creando un VMware vSphere OVA, è necessario impostare le seguenti variabili di ambiente.

Variabile di ambiente Tipo Description

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 Description

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.

vSphere OVAs

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 file Readme di Packer nell'archivio EKS Hybrid Nodes. GitHub

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 si utilizza VMware vSphere come infrastruttura per i nodi ibridi.

  1. Installa la govc CLI seguendo le istruzioni nel readme di govc su. GitHub

  2. 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 VM_NAME comando seguente viene usato come tuo NODE_NAME quando inserisci i nomi per te tramite il tuo file. VMs metadata.yaml

    govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
    -on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"

  3. Dopo aver clonato il modello per ognuno dei tuoi nuovi VMs, crea un userdata.yaml e metadata.yaml per il tuo. VMs VMs Puoi condividerli userdata.yaml metadata.yaml e li compilerai per ogni singola macchina virtuale 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 AWS SSM come provider di credenziali locali 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

  4. Aggiungi i file userdata.yaml e metadata.yaml come stringhe gzip+base64 con i seguenti comandi. I seguenti comandi devono essere eseguiti per ciascuno dei comandi che si stanno creando. VMs 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

  5. Accendi il tuo nuovo VMs, che dovrebbe connettersi automaticamente al cluster EKS che hai configurato.

    govc vm.power -on "${NODE_NAME}"