**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à. # Esegui carichi di lavoro on-premises su nodi ibridi In un cluster EKS con nodi ibridi abilitati, puoi eseguire applicazioni on-premises ed edge sulla tua infrastruttura con gli stessi cluster, le stesse funzionalità e gli stessi strumenti Amazon EKS che usi nel cloud AWS. Le seguenti sezioni contengono istruzioni dettagliate per l’utilizzo di nodi ibridi. **Topics** + [Connessione di nodi ibridi](hybrid-nodes-join.md) + [Connessione dei nodi ibridi con Bottlerocket](hybrid-nodes-bottlerocket.md) + [Aggiornamento dei nodi ibridi](hybrid-nodes-upgrade.md) + [Patch per i nodi ibridi](hybrid-nodes-security.md) + [Elimina i nodi ibridi](hybrid-nodes-remove.md) # Connessione di nodi ibridi **Nota** I seguenti passaggi si applicano ai nodi ibridi che eseguono sistemi operativi compatibili ad eccezione di Bottlerocket. Per i passaggi per connettere un nodo ibrido che esegue Bottlerocket, consultare [Connessione dei nodi ibridi con Bottlerocket](hybrid-nodes-bottlerocket.md). In questo argomento viene descritto come connettere nodi ibridi a un cluster Amazon EKS. Dopo che i nodi ibridi si sono uniti al cluster, verranno visualizzati con lo stato Not Ready nella console Amazon EKS e in strumenti compatibili con Kubernetes come kubectl. Dopo aver completato i passaggi in questa pagina, procedi su [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md) per preparare i nodi ibridi per l’esecuzione delle applicazioni. ## Prerequisiti Prima di connettere i nodi ibridi al cluster Amazon EKS, assicurati di aver completato tutti i passaggi relativi ai prerequisiti. + Disponi di una connettività di rete dal proprio ambiente on-premises alla Regione AWS che ospita il cluster Amazon EKS. Per ulteriori informazioni, consulta [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md). + Si dispone di un sistema operativo compatibile per i nodi ibridi installato sugli host on-premises. Per ulteriori informazioni, consulta [Preparazione del sistema operativo per i nodi ibridi](hybrid-nodes-os.md). + Hai creato il ruolo IAM Nodi ibridi e configurato il provider di credenziali on-premises (attivazioni ibride di Systems Manager di AWS o IAM Roles Anywhere di AWS). Per ulteriori informazioni, consulta [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md). + Hai creato il cluster Amazon EKS abilitato per i nodi ibridi. Per ulteriori informazioni, consulta [Creazione di un cluster Amazon EKS con nodi ibridi](hybrid-nodes-cluster-create.md). + Hai associato il ruolo IAM Nodi ibridi alle autorizzazioni con il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes. Per ulteriori informazioni, consulta [Preparazione dell’accesso al cluster per i nodi ibridi](hybrid-nodes-cluster-prep.md). ## Passaggio 1: installazione della CLI per nodi ibridi (`nodeadm`) su ogni host on-premises Se si include la CLI Amazon EKS Hybrid Nodes (`nodeadm`) nelle immagini predefinite del sistema operativo, è possibile saltare questo passaggio. Per maggiori informazioni sulla versione per nodi ibridi del `nodeadm`, consultare [Riferimento `nodeadm` dei nodi ibridi](hybrid-nodes-nodeadm.md). La versione di `nodeadm` per nodi ibridi è ospitata in Amazon S3 e gestita da Amazon CloudFront. Per installare `nodeadm` su ciascun host on-premises, puoi eseguire il seguente comando dagli host on-premises. **Per host x86\$164:** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **Per host ARM** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` Aggiungi l’autorizzazione per i file eseguibili al file binario scaricato su ciascun host. ``` chmod +x nodeadm ``` ## Passaggio 2: installazione delle dipendenze dei nodi ibridi con `nodeadm` Se si stanno installando le dipendenze dei nodi ibridi in immagini del sistema operativo predefinite, è possibile ignorare questo passaggio. Il comando `nodeadm install` può essere utilizzato per installare tutte le dipendenze richieste per i nodi ibridi. Le dipendenze dei nodi ibridi includono containerd, kubelet, kubectl e i componenti SSM di AWS o IAM Roles Anywhere di AWS. Consultare [Riferimento `nodeadm` dei nodi ibridi](hybrid-nodes-nodeadm.md) per ulteriori informazioni sui componenti e le posizioni dei file installati da `nodeadm install`. Consultare la sezione [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md) dedicata ai nodi ibridi per ulteriori informazioni sui domini che devono essere consentiti nel firewall on-premises per il processo `nodeadm install`. Eseguire il comando seguente per installare le dipendenze dei nodi ibridi sull’host on-premises. Il comando seguente deve essere eseguito con un utente con accesso sudo/root sull’host. **Importante** La CLI per nodi ibridi (`nodeadm`) deve essere eseguita con un utente con accesso sudo/root sull’host. + Sostituire `K8S_VERSION` con la versione secondaria Kubernetes del cluster Amazon EKS, ad esempio `1.31`. Consultare [Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) per un elenco delle versioni Kubernetes supportate. + Sostituire `CREDS_PROVIDER` con il provider di credenziali on-premises che si sta utilizzando. I valori validi sono `ssm` per SSM di AWS e `iam-ra` per IAM Roles Anywhere di AWS. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## Passaggio 3: connessione dei nodi ibridi al cluster Prima di connettere i nodi ibridi al cluster, assicurati di aver consentito l’accesso richiesto nel firewall on-premises e nel gruppo di sicurezza del cluster per il piano di controllo di Amazon EKS da/verso la comunicazione tra nodi ibridi. La maggior parte dei problemi in questa Passaggio riguarda la configurazione del firewall, la configurazione del gruppo di sicurezza o la configurazione del ruolo IAM dei nodi ibridi. **Importante** La CLI per nodi ibridi (`nodeadm`) deve essere eseguita con un utente con accesso sudo/root sull’host. 1. Crea un file `nodeConfig.yaml` su ogni host con i valori per la tua implementazione. Per una descrizione completa delle impostazioni di configurazione disponibili, consulta [Riferimento `nodeadm` dei nodi ibridi](hybrid-nodes-nodeadm.md). Se il ruolo IAM dei nodi ibridi non dispone dell’autorizzazione per l’azione `eks:DescribeCluster`, devi passare l’endpoint dell’API Kubernetes, il cluster CA bundle e il servizio Kubernetes IPv4 CIDR nella sezione cluster del tuo `nodeConfig.yaml`. 1. Utilizza il `nodeConfig.yaml` di esempio seguente se utilizzi attivazioni ibride SSM di AWS per il tuo provider di credenziali on-premises. 1. Sostituisci `CLUSTER_NAME` con il nome del cluster. 1. Sostituisci `AWS_REGION` con la Regione AWS in cui si trova il cluster. Ad esempio, `us-west-2`. 1. Sostituisci `ACTIVATION_CODE` con il codice di attivazione che hai ricevuto durante la creazione dell’attivazione ibrida SSM di AWS. Per ulteriori informazioni, consulta [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md). 1. Sostituisci `ACTIVATION_ID` con l’ID di attivazione che hai ricevuto durante la creazione dell’attivazione ibrida SSM di AWS. È possibile recuperare queste informazioni dalla console Systems Manager di AWS o dal comando `aws ssm describe-activations` della AWS CLI. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: ssm: activationCode: ACTIVATION_CODE activationId: ACTIVATION_ID ``` 1. Utilizza il `nodeConfig.yaml` di esempio seguente se utilizzi IAM Roles Anywhere di AWS per il tuo provider di credenziali on-premises. 1. Sostituisci `CLUSTER_NAME` con il nome del cluster. 1. Sostituisci `AWS_REGION` con la Regione AWS in cui si trova il cluster. Ad esempio, `us-west-2`. 1. Sostituisci `NODE_NAME` con il nome del ruolo del nodo. Il nome del nodo deve corrispondere al CN del certificato sull’host se hai configurato la policy di attendibilità del ruolo IAM di Hybrid Nodes con la condizione della risorsa `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. Il `nodeName` che usi non deve superare i 64 caratteri. 1. Sostituisci `TRUST_ANCHOR_ARN` con l’ARN dell’ancora di fiducia che hai configurato nei passaggi per Preparare le credenziali per i nodi ibridi. 1. Sostituisci `PROFILE_ARN` con l’ARN dell’ancora di fiducia che hai configurato nei passaggi per [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md). 1. Sostituisci `ROLE_ARN` con l’ARN del ruolo IAM dei nodi ibridi. 1. Sostituisci `CERTIFICATE_PATH` con il percorso su disco del certificato del tuo nodo. Se non lo specifichi, il valore predefinito è `/etc/iam/pki/server.pem`. 1. Sostituisci `KEY_PATH` con il percorso su disco della chiave privata del certificato. Se non lo specifichi, il valore predefinito è `/etc/iam/pki/server.key`. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: iamRolesAnywhere: nodeName: NODE_NAME trustAnchorArn: TRUST_ANCHOR_ARN profileArn: PROFILE_ARN roleArn: ROLE_ARN certificatePath: CERTIFICATE_PATH privateKeyPath: KEY_PATH ``` 1. Esegui il comando `nodeadm init` con il tuo `nodeConfig.yaml` per connettere i nodi ibridi al cluster Amazon EKS. ``` nodeadm init -c file://nodeConfig.yaml ``` Se il comando precedente viene effettuato correttamente, il nodo ibrido si unisce al cluster Amazon EKS. Puoi verificarlo nella console Amazon EKS accedendo alla scheda Calcolo del tuo cluster ([assicurati che il principale IAM disponga delle autorizzazioni per la visualizzazione](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) o con `kubectl get nodes`. **Importante** I nodi avranno lo stato `Not Ready` previsto, dovuto alla mancanza di una CNI in esecuzione sui nodi ibridi. Se i tuoi nodi non si sono uniti al cluster, consulta [Risoluzione dei problemi relativi ai nodi ibridi](hybrid-nodes-troubleshooting.md). ## Passaggio 4: configurazione di una CNI per i nodi ibridi Per preparare i nodi ibridi all’esecuzione delle applicazioni, continua con i passaggi su [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md). # Connessione dei nodi ibridi con Bottlerocket Questo argomento descrive come connettere i nodi ibridi che eseguono Bottlerocket a un cluster Amazon EKS. [Bottlerocket](https://aws.amazon.com/bottlerocket/) è una distribuzione Linux open source sponsorizzata e supportata da. AWS Bottlerocket è progettato appositamente per ospitare carichi di lavoro in container. Con Bottlerocket, puoi migliorare la disponibilità delle implementazioni containerizzate e ridurre i costi operativi automatizzando gli aggiornamenti dell’infrastruttura dei container. Bottlerocket include solo il software essenziale per eseguire i container, che migliora l’utilizzo delle risorse, riduce le minacce alla sicurezza e riduce i costi di gestione. 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. Le immagini del sistema operativo per queste varianti includono kubelet, containerd aws-iam-authenticator e altri prerequisiti software per EKS Hybrid Nodes. È possibile configurare questi componenti utilizzando un file di [impostazioni](https://github.com/bottlerocket-os/bottlerocket#settings) Bottlerocket che include dati utente codificati in base64 per i contenitori bootstrap e admin di Bottlerocket. La configurazione di queste impostazioni consente a Bottlerocket di utilizzare il provider di credenziali dei nodi ibridi per autenticare i nodi ibridi nel cluster. Dopo che i nodi ibridi si sono uniti al cluster, verranno visualizzati con lo stato `Not Ready` nella console Amazon EKS e in strumenti compatibili con Kubernetes come `kubectl`. Dopo aver completato i passaggi indicati in questa pagina, procedi a preparare i nodi ibridi [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md) per l’esecuzione delle applicazioni. ## Prerequisiti Prima di connettere i nodi ibridi al cluster Amazon EKS, assicurati di aver completato tutti i passaggi relativi ai prerequisiti. + Hai una connettività di rete dal tuo ambiente locale alla AWS regione che ospita il tuo cluster Amazon EKS. Per ulteriori informazioni, consulta [Preparazione della rete per i nodi ibridi](hybrid-nodes-networking.md). + Hai creato il tuo ruolo IAM Hybrid Nodes e configurato il tuo provider di credenziali locale (AWS Systems Manager hybrid activations o AWS IAM Roles Anywhere). Per ulteriori informazioni, consulta [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md). + Hai creato il cluster Amazon EKS abilitato per i nodi ibridi. Per ulteriori informazioni, consulta [Creazione di un cluster Amazon EKS con nodi ibridi](hybrid-nodes-cluster-create.md). + Hai associato il ruolo IAM Nodi ibridi alle autorizzazioni con il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes. Per ulteriori informazioni, consulta [Preparazione dell’accesso al cluster per i nodi ibridi](hybrid-nodes-cluster-prep.md). ## Passaggio 1: creazione del file TOML delle impostazioni Bottlerocket Per configurare Bottlerocket per i nodi ibridi, è necessario creare un file `settings.toml` con la configurazione necessaria. Il contenuto del file TOML sarà diverso in base al provider di credenziali utilizzato (SSM o IAM Roles Anywhere). Questo file verrà passato come dati utente durante il provisioning dell’istanza Bottlerocket. **Nota** I file TOML forniti di seguito rappresentano solo le impostazioni minime richieste per inizializzare una VMWare macchina Bottlerocket come nodo su un cluster EKS. Bottlerocket offre un'ampia gamma di impostazioni per soddisfare diversi casi d'uso, quindi per ulteriori opzioni di configurazione oltre all'inizializzazione del nodo ibrido, consulta la [documentazione di Bottlerocket](https://bottlerocket.dev/en) per l'elenco completo di tutte le impostazioni documentate per la versione Bottlerocket che stai utilizzando (ad esempio, [ecco](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) tutte le impostazioni disponibili per Bottlerocket 1.51.x). ### SSM Se utilizzi AWS Systems Manager come provider di credenziali, crea un `settings.toml` file con il seguente contenuto: ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "ssm" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" [settings.host-containers.control] enabled = true ``` Sostituire i segnaposto con i seguenti valori: + ``: il nome del cluster Amazon EKS. + ``: l’endpoint del server API del cluster. + ``: il bundle CA con codifica base64 del cluster. + ``: La AWS regione che ospita il cluster, ad esempio «us-east-1". + ``: il nome host dell’istanza Bottlerocket, che verrà configurato anche come nome del nodo. Questo può essere un valore univoco a tua scelta, ma deve rispettare le [convenzioni di denominazione degli oggetti Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). Inoltre, il nome host che usi non può superare i 64 caratteri. NOTA: quando si utilizza il provider SSM, il nome host e il nome del nodo verranno sostituiti dall’ID dell’istanza gestita (ad esempio, `mi-*` ID) dopo la registrazione dell’istanza con SSM. + ``: il contenuto con codifica base64 della configurazione del container di amministrazione Bottlerocket. L’abilitazione del container di amministrazione consente di connettersi all’istanza Bottlerocket con SSH per l’esplorazione e il debug del sistema. Sebbene questa non sia un’impostazione obbligatoria, consigliamo di abilitarla per facilitare la risoluzione dei problemi. Consulta [Bottlerocket admin container documentation](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) per ulteriori informazioni sull’autenticazione con il container di amministrazione. Il container di amministrazione accetta l’input dell’utente e della chiave SSH in formato JSON, ad esempio ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: il contenuto con codifica base64 della configurazione del container del bootstrap Bottlerocket. Consulta [Bottlerocket bootstrap container documentation](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) per ulteriori informazioni sulla sua configurazione. Il contenitore bootstrap è responsabile della registrazione dell'istanza come istanza gestita AWS SSM e dell'aggiunta come nodo Kubernetes sul tuo cluster Amazon EKS. I dati utente passati nel container bootstrap assumono la forma di un’invocazione di comando che accetta come input il codice di attivazione ibrido SSM e l’ID creati in precedenza: ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### IAM Roles Anywhere Se utilizzi AWS IAM Roles Anywhere come provider di credenziali, crea un file con il seguente contenuto: `settings.toml` ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" config = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "iam-ra" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" ``` Sostituire i segnaposto con i seguenti valori: + ``: il nome del cluster Amazon EKS. + ``: l’endpoint del server API del cluster. + ``: il bundle CA con codifica base64 del cluster. + ``: La AWS regione che ospita il cluster, ad esempio «us-east-1" + ``: il nome host dell’istanza Bottlerocket, che verrà configurato anche come nome del nodo. Questo può essere un valore univoco a tua scelta, ma deve rispettare le [convenzioni di denominazione degli oggetti Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). Inoltre, il nome host che usi non può superare i 64 caratteri. NOTA: quando si utilizza il provider IAM-RA, il nome del nodo deve corrispondere al CN del certificato sull’host se è stata configurata la policy di attendibilità del ruolo IAM dei nodi ibridi con la condizione della risorsa `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. + ``: I contenuti codificati in base64 del file di configurazione. AWS Il contenuto del file dovrebbe essere il seguente: ``` [default] credential_process = aws_signing_helper credential-process --certificate /root/.aws/node.crt --private-key /root/.aws/node.key --profile-arn --role-arn --trust-anchor-arn --role-session-name ``` + ``: il contenuto con codifica base64 della configurazione del container di amministrazione Bottlerocket. L’abilitazione del container di amministrazione consente di connettersi all’istanza Bottlerocket con SSH per l’esplorazione e il debug del sistema. Sebbene questa non sia un’impostazione obbligatoria, consigliamo di abilitarla per facilitare la risoluzione dei problemi. Consulta [Bottlerocket admin container documentation](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) per ulteriori informazioni sull’autenticazione con il container di amministrazione. Il container di amministrazione accetta l’input dell’utente e della chiave SSH in formato JSON, ad esempio ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: il contenuto con codifica base64 della configurazione del container del bootstrap Bottlerocket. Consulta [Bottlerocket bootstrap container documentation](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) per ulteriori informazioni sulla sua configurazione. Il container bootstrap è responsabile della creazione del certificato host IAM Roles Anywhere e dei file delle chiavi private del certificato sull’istanza. Questi verranno quindi utilizzati da `aws_signing_helper` per ottenere credenziali temporanee per l’autenticazione con il cluster Amazon EKS. I dati utente passati nel container bootstrap assumono la forma di un’invocazione di comando che accetta come input i contenuti del certificato la chiave privata creati in precedenza: ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## Passaggio 2: fornitura dei dati utente alla macchina virtuale Bottlerocket vSphere Dopo aver creato il file TOML, passalo come dati utente durante la creazione della macchina virtuale vSphere. Tieni presente che i dati utente devono essere configurati prima che la macchina virtuale venga accesa per la prima volta. Pertanto, sarà necessario fornirli al momento della creazione dell’istanza o, se si desidera creare la macchina virtuale in anticipo; quest’ultima deve essere nello stato PoweredOff fino a quando non si configurano i relativi dati utente. Ad esempio, se utilizzi la `govc` CLI: ### Creazione della macchina virtuale per la prima volta ``` govc vm.create \ -on=true \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -e guestinfo.userdata.encoding="base64" \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -template= \ ``` ### Aggiornamento dei dati utente per una macchina virtuale esistente ``` govc vm.create \ -on=false \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -template= \ govc vm.change -vm \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -e guestinfo.userdata.encoding="base64" govc vm.power -on ``` Nelle sezioni precedenti, l’opzione `-e guestinfo.userdata.encoding="base64"` specifica che i dati utente sono codificati con Base64. L’opzione `-e guestinfo.userdata` passa i contenuti codificati con Base64 del file `settings.toml` come dati utente all’istanza Bottlerocket. Sostituisci i segnaposto con i tuoi valori specifici, come il modello OVA Bottlerocket e i dettagli di rete. ## Passaggio 3: verifica della connessione del nodo ibrido Dopo l’avvio, l’istanza Bottlerocket tenterà di entrare a far parte del tuo cluster Amazon EKS. Puoi verificare la connessione nella console Amazon EKS accedendo alla scheda Calcolo per il tuo cluster o eseguendo il seguente comando: ``` kubectl get nodes ``` **Importante** I nodi avranno lo stato `Not Ready` previsto, dovuto alla mancanza di una CNI in esecuzione sui nodi ibridi. Se i tuoi nodi non si sono uniti al cluster, consulta [Risoluzione dei problemi relativi ai nodi ibridi](hybrid-nodes-troubleshooting.md). ## Passaggio 4: configurazione di una CNI per i nodi ibridi Per preparare i nodi ibridi all’esecuzione delle applicazioni, continua con i passaggi su [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md). # Aggiornamento dei nodi ibridi per il tuo cluster Le linee guida per l’aggiornamento dei nodi ibridi sono simili ai nodi Amazon EKS autogestiti eseguiti in Amazon EC2. Ti consigliamo di creare nuovi nodi ibridi nella versione di Kubernetes di destinazione, eseguire la migrazione con facilità delle applicazioni esistenti sui nodi ibridi sulla nuova versione di Kubernetes e rimuovere questi ultimi sulla vecchia versione di Kubernetes dal tuo cluster. Assicurati di consultare le [Best practice di Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) per gli aggiornamenti prima di iniziare un aggiornamento. Amazon EKS Hybrid Nodes ha lo stesso [Kubernetes version support](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) per i cluster Amazon EKS con nodi cloud, incluso il supporto standard ed esteso. Amazon EKS Hybrid Nodes segue la stessa [policy di disallineamento delle versioni](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) per i nodi di Kubernetes upstream. Amazon EKS Hybrid Nodes non può avere una versione più recente del piano di controllo di Amazon EKS e i nodi ibridi possono contenere fino a tre versioni secondarie di Kubernetes precedenti a quella secondaria del piano di controllo Amazon EKS. Se non disponi di capacità di riserva per creare nuovi nodi ibridi sulla versione Kubernetes di destinazione per una strategia di conversione della migrazione, puoi in alternativa utilizzare la CLI di Amazon EKS Hybrid Nodes (`nodeadm`) per aggiornare la versione Kubernetes dei tuoi nodi ibridi sul posto. **Importante** Se stai aggiornando i tuoi nodi ibridi sul posto con `nodeadm`, è previsto un tempo di inattività per il nodo durante la procedura, in cui la versione precedente dei componenti di Kubernetes viene chiusa e i componenti della nuova versione vengono installati e avviati. ## Prerequisiti Prima di effettuare la connessione, assicurati di avere soddisfatto tutti i prerequisiti. + La versione Kubernetes di destinazione per l’aggiornamento dei nodi ibridi deve essere uguale o inferiore a quella del piano di controllo di Amazon EKS. + Se stai seguendo una strategia di conversione della migrazione e dell’aggiornamento, i nuovi nodi ibridi che stai installando sulla versione Kubernetes di destinazione devono soddisfare i requisiti [Configurazione dei prerequisiti per i nodi ibridi](hybrid-nodes-prereqs.md). Ciò include la presenza di indirizzi IP all’interno del CIDR della rete di nodi remoti che hai trasferito durante la creazione del cluster Amazon EKS. + Sia per la conversione della migrazione che per gli aggiornamenti sul posto, i nodi ibridi devono avere accesso ai [domini richiesti](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) per sfruttare le nuove versioni delle dipendenze dei nodi ibridi. + Devi avere kubectl installato sul computer o sull’istanza locale che stai utilizzando per interagire con l’endpoint dell’API Amazon EKS Kubernetes. + La versione del tuo CNI deve supportare la versione di Kubernetes verso cui stai effettuando l’aggiornamento. In caso contrario, aggiorna la versione del CNI prima di aggiornare i nodi ibridi. Per ulteriori informazioni, consulta [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md). ## Aggiornamenti conversione migrazione (blu-verde) *Gli aggiornamenti della conversione della migrazione* si riferiscono al processo di creazione di nuovi nodi ibridi su nuovi host con la versione di Kubernetes di destinazione, con la migrazione graduale delle applicazioni esistenti ai nuovi nodi ibridi sulla versione Kubernetes di destinazione e la rimozione dei nodi ibridi sulla vecchia versione di Kubernetes dal cluster. Questa strategia è anche chiamata migrazione blu-verde. 1. Connetti i tuoi nuovi host come nodi ibridi seguendo i passaggi di [Connessione di nodi ibridi](hybrid-nodes-join.md). Quando esegui il comando `nodeadm install`, utilizza la versione di Kubernetes di destinazione. 1. Abilita la comunicazione tra i nuovi nodi ibridi nella versione Kubernetes di destinazione e quelli nella vecchia versione di Kubernetes. Ciò consente ai pod di comunicare tra loro durante la migrazione del carico di lavoro verso i nodi ibridi nella versione Kubernetes di destinazione. 1. Verifica che i nodi ibridi sulla versione di Kubernetes di destinazione si uniscano correttamente al cluster e mostrino lo stato Pronto. 1. Utilizza il comando seguente per contrassegnare come non programmabile ciascuno dei nodi che desideri rimuovere. In questo modo i nuovi pod non vengono pianificati né riprogrammati sui nodi che stai sostituendo. Per ulteriori informazioni, consulta [cordonazione di kubelet](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) nella documentazione di Kubernetes. Sostituisci `NODE_NAME` con il nome dei nodi ibridi nella vecchia versione di Kubernetes. ``` kubectl cordon NODE_NAME ``` Puoi individuare e isolare tutti i nodi di una determinata versione di Kubernetes (in questo caso `1.28`) con il seguente frammento di codice. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Cordoning $node" kubectl cordon $node done ``` 1. Se l’implementazione attuale è in esecuzione per un numero di volte inferiore a due repliche CoreDNS, aumenta orizzontalmente l’implementazione a due repliche. Consigliamo di eseguire almeno due repliche CoreDNS su nodi ibridi per garantire la resilienza durante le normali operazioni. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Svuota ciascuno dei nodi della vecchia versione di Kubernetes che desideri rimuovere dal cluster con il comando seguente. Per ulteriori informazioni su come svuotare i nodi, consulta [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) nella documentazione di Kubernetes. Sostituisci `NODE_NAME` con il nome dei nodi ibridi nella vecchia versione di Kubernetes. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` Puoi individuare e svuotare tutti i nodi di una determinata versione di Kubernetes (in questo caso, `1.28`) con il seguente frammento di codice. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-emptydir-data done ``` 1. Puoi utilizzare `nodeadm` per arrestare e rimuovere gli artefatti dei nodi ibridi dall’host. Devi eseguire `nodeadm` con un utente con privilegi root/sudo. Per impostazione predefinita, `nodeadm uninstall` non proseguirà se sul nodo rimangono dei pod. Per ulteriori informazioni, consulta [Riferimento `nodeadm` dei nodi ibridi](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` 1. Una volta interrotti e disinstallati gli artefatti dei nodi ibridi, rimuovi la risorsa del nodo dal cluster. ``` kubectl delete node node-name ``` Puoi individuare ed eliminare tutti i nodi di una determinata versione di Kubernetes (in questo caso `1.28`) con il seguente frammento di codice. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Deleting $node" kubectl delete node $node done ``` 1. A seconda del CNI scelto, potrebbero rimanere degli artefatti sui nodi ibridi dopo aver eseguito i passaggi precedenti. Per ulteriori informazioni, consulta [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md). ## Aggiornamenti sul posto La procedura di aggiornamento sul posto si riferisce all’utilizzo di `nodeadm upgrade` per l’aggiornamento della versione di Kubernetes per nodi ibridi senza utilizzare nuovi host fisici o virtuali e alla conversione della strategia di migrazione. Il processo `nodeadm upgrade` chiude i componenti Kubernetes precedenti esistenti in esecuzione sul nodo ibrido, disinstalla i componenti Kubernetes precedenti esistenti, installa i nuovi componenti Kubernetes di destinazione e avvia i nuovi componenti Kubernetes di destinazione. Si consiglia vivamente di aggiornare un nodo alla volta per ridurre al minimo l’impatto sulle applicazioni in esecuzione sui nodi ibridi. La durata di questo processo dipende dalla larghezza di banda e dalla latenza della rete. 1. Usa il comando seguente per contrassegnare come non programmabile il nodo che stai aggiornando. In questo modo i nuovi pod non vengono pianificati né riprogrammati sul nodo che stai sostituendo. Per ulteriori informazioni, consulta [cordonazione di kubelet](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) nella documentazione di Kubernetes. Sostituisci `NODE_NAME` con il nome del nodo ibrido che stai aggiornando ``` kubectl cordon NODE_NAME ``` 1. Svuota il nodo da aggiornare con il comando seguente. Per ulteriori informazioni su come svuotare i nodi, consulta [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) nella documentazione di Kubernetes. Sostituisci `NODE_NAME` con il nome del nodo ibrido che stai aggiornando. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. Esegui `nodeadm upgrade` sul nodo ibrido che stai aggiornando. Devi eseguire `nodeadm` con un utente con privilegi root/sudo. Il nome del nodo viene preservato durante l’aggiornamento per i provider di credenziali SSM di AWS e IAM Roles Anywhere di AWS. Durante il processo di aggiornamento non puoi modificare i provider di credenziali. Consulta [Riferimento `nodeadm` dei nodi ibridi](hybrid-nodes-nodeadm.md) per i valori di configurazione per `nodeConfig.yaml`. Sostituisci `K8S_VERSION` con la versione di Kubernetes di destinazione verso cui esegui l’aggiornamento. ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. Per consentire la pianificazione dei pod sul nodo dopo l’aggiornamento, digita quanto segue. Sostituisci `NODE_NAME` con il nome del nodo. ``` kubectl uncordon NODE_NAME ``` 1. Osserva lo stato dei nodi ibridi e attendi fino a quando i nodi si chiudono e si riavviano sulla nuova versione di Kubernetes con lo stato Pronto. ``` kubectl get nodes -o wide -w ``` # Aggiornamenti di sicurezza delle patch per i nodi ibridi Questo argomento descrive la procedura per eseguire l’applicazione sul posto delle patch degli aggiornamenti di sicurezza per pacchetti e dipendenze specifici in esecuzione sui nodi ibridi. Come best practice, ti consigliamo di aggiornare regolarmente i nodi ibridi per ricevere CVE e patch di sicurezza. Per i passaggi per aggiornare la versione di Kubernetes, consulta [Aggiornamento dei nodi ibridi per il tuo cluster](hybrid-nodes-upgrade.md). Un esempio di software che potrebbe richiedere l’applicazione di patch di sicurezza è `containerd`. ## `Containerd` `containerd` è il runtime standard del container Kubernetes e la dipendenza principale per EKS Hybrid Nodes. Viene utilizzato per gestire il ciclo di vita dei container, inclusa l’estrazione delle immagini e la gestione dell’esecuzione dei container. Su un nodo ibrido, puoi installare `containerd` tramite la [CLI nodeadm](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) o manualmente. A seconda del sistema operativo del nodo, `nodeadm` installerà `containerd` dal pacchetto distribuito dal sistema operativo o dal pacchetto Docker. Una volta pubblicato un CVE in `containerd`, hai le seguenti opzioni per eseguire l’aggiornamento alla versione con patch di `containerd` sui tuoi nodi ibridi. ## Passaggio 1: controlla se la patch è stata pubblicata sui gestori di pacchetti Puoi verificare se la patch CVE `containerd` è stata pubblicata su ogni rispettivo gestore di pacchetti del sistema operativo facendo riferimento ai corrispondenti bollettini sulla sicurezza: + [Amazon Linux 2023](https://alas.aws.amazon.com/alas2023.html) + [RHEL](https://access.redhat.com/security/security-updates/security-advisories) + [Ubuntu 20.04](https://ubuntu.com/security/notices?order=newest&release=focal) + [Ubuntu 22.04](https://ubuntu.com/security/notices?order=newest&release=jammy) + [Ubuntu 24.04](https://ubuntu.com/security/notices?order=newest&release=noble) Se utilizzi il repository Docker come fonte di `containerd`, puoi controllare gli [annunci di sicurezza del Docker](https://docs.docker.com/security/security-announcements/) per identificare la disponibilità della versione con patch nel repository di Docker. ## Passaggio 2: scegli il metodo per installare la patch Esistono tre metodi per applicare le patch e installare gli aggiornamenti di sicurezza sui nodi. Il metodo che puoi utilizzare dipende dal fatto che la patch sia disponibile o meno nel sistema operativo nel gestore di pacchetti: 1. Per installare le patch con `nodeadm upgrade` pubblicate nei gestori di pacchetti, consulta [Step 2 a](#hybrid-nodes-security-nodeadm). 1. Per installare direttamente le patch con i gestori di pacchetti, consulta [Step 2 b](#hybrid-nodes-security-package). 1. Per installare patch personalizzate che non sono pubblicate nei gestori di pacchetti. Nota che ci sono considerazioni speciali per le patch personalizzate per `containerd`, [Step 2 c](#hybrid-nodes-security-manual). ## Passaggio 2 a: applicazione delle patch con `nodeadm upgrade` Dopo aver confermato che la patch CVE `containerd` è stata pubblicata nel sistema operativo o nei repository di Docker (Apt o RPM), puoi utilizzare il comando `nodeadm upgrade` per eseguire l’aggiornamento alla versione più recente di `containerd`. Poiché non si tratta di un aggiornamento della versione di Kubernetes, devi passare alla versione corrente di Kubernetes al comando `nodeadm` upgrade. ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## Passaggio 2 b: applicazione di patch con i gestori di pacchetti del sistema operativo In alternativa puoi eseguire l’aggiornamento anche tramite il rispettivo gestore di pacchetti e utilizzarlo per aggiornare il pacchetto `containerd` come segue. **Amazon Linux 2023** ``` sudo yum update -y sudo yum install -y containerd ``` **RHEL** ``` sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo sudo yum update -y sudo yum install -y containerd ``` **Ubuntu** ``` sudo mkdir -p /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update -y sudo apt install -y --only-upgrade containerd.io ``` ## Passaggio 2 c: patch CVE `Containerd` non pubblicata nei gestori di pacchetti Se la `containerd` versione con patch è disponibile solo con altri mezzi anziché nel gestore di pacchetti, ad esempio nelle versioni di GitHub, puoi installare `containerd` dal sito ufficiale di GitHub. 1. Se il computer è già entrato a far parte del cluster come nodo ibrido, devi eseguire il comando `nodeadm uninstall`. 1. Installa i binari ufficiali `containerd`. Puoi utilizzare le [fasi di installazione ufficiali](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) su GitHub. 1. Esegui il comando `nodeadm install` con l’argomento `--containerd-source` impostato su `none`, che salterà l’installazione di `containerd` fino a `nodeadm`. Puoi utilizzare il valore di `none` nella sorgente `containerd` per qualsiasi sistema operativo in esecuzione sul nodo. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # Rimuovi i nodi ibridi In questa sezione viene descritto come eliminare i nodi ibridi dal cluster Amazon EKS. Devi eliminare i nodi ibridi utilizzando strumenti compatibili con Kubernetes di propria scelta, come [kubectl](https://kubernetes.io/docs/reference/kubectl/). I costi per i nodi ibridi si interrompono quando l’oggetto nodo viene rimosso dal cluster Amazon EKS. Per ulteriori informazioni sui prezzi dei nodi ibridi, consulta i [Prezzi di Amazon EKS](https://aws.amazon.com/eks/pricing/). **Importante** La rimozione dei nodi interrompe i carichi di lavoro in esecuzione sul nodo. Prima di eliminare i nodi ibridi, ti consigliamo innanzitutto di svuotare il nodo per spostare i pod su un altro nodo attivo. Per ulteriori informazioni su come svuotare i nodi, consulta [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) nella documentazione Kubernetes. Esegui i seguenti passaggi di kubectl dal computer o dall’istanza locale che usi per interagire con l’endpoint API Kubernetes del cluster Amazon EKS. Se stai usando un file `kubeconfig` specifico, usa il flag `--kubeconfig`. ## Passaggio 1: elenca i nodi ``` kubectl get nodes ``` ## Passaggio 2: svuota il nodo Consulta [kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) nella documentazione di Kubernetes per maggiori informazioni sul comando `kubectl drain`. ``` kubectl drain --ignore-daemonsets ``` ## Passaggio 3: arrestare e disinstallare gli artefatti dei nodi ibridi Puoi utilizzare il CLI Amazon EKS Hybrid Nodes (`nodeadm`) per arrestare e rimuovere gli artefatti dei nodi ibridi dall’host. Devi eseguire `nodeadm` con un utente che abbia privilegi root/sudo. Per impostazione predefinita, `nodeadm uninstall` non proseguirà se sul nodo rimangono dei pod. Se utilizzi AWS Systems Manager (SSM) come provider di credenziali, il comando `nodeadm uninstall` annulla la registrazione dell’host come istanza gestita AWS SSM. Per ulteriori informazioni, consulta [Riferimento `nodeadm` dei nodi ibridi](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` ## Passaggio 4: eliminare il nodo dal cluster Una volta interrotti e disinstallati gli artefatti dei nodi ibridi, rimuovi la risorsa del nodo dal cluster. ``` kubectl delete node ``` ## Passaggio 5: verifica la presenza di artefatti rimanenti A seconda del CNI scelto, potrebbero rimanere degli artefatti sui nodi ibridi dopo aver eseguito i passaggi precedenti. Per ulteriori informazioni, consulta [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md).