**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](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) 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](hybrid-nodes-nodeadm.md). + 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](hybrid-nodes-proxy.md). ### 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](hybrid-nodes-bottlerocket.md), anziché nelle istruzioni di [Connessione di nodi ibridi](hybrid-nodes-join.md). + 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](https://bottlerocket.dev/en/os/1.36.x/concepts/variants) 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 + [Se usi Ubuntu 24.04, potresti dover aggiornare la tua versione di containerd o modificare AppArmor la configurazione per adottare una correzione che consenta ai pod di terminare correttamente, vedi Ubuntu \#2065423.](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/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 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](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) 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](https://github.com/aws/eks-hybrid/tree/main/example/packer) 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](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli) 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-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](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). | | 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](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere) 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](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) 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](https://github.com/vmware/govmomi/blob/main/govc/README.md) su. GitHub 1. 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" ``` 1. 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](hybrid-nodes-nodeadm.md). **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 ``` 1. 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 metadata.yaml.tmp export METADATA=$(gzip -c9