Connessione dei nodi ibridi con Bottlerocket - Amazon EKS

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

Connessione dei nodi ibridi con Bottlerocket

Questo argomento descrive come connettere i nodi ibridi che eseguono Bottlerocket a un cluster Amazon EKS. 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 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 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.

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 per l'elenco completo di tutte le impostazioni documentate per la versione Bottlerocket che stai utilizzando (ad esempio, ecco 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 = "<cluster-name>" api-server = "<api-server-endpoint>" cluster-certificate = "<cluster-certificate-authority>" hostname-override = "<hostname>" provider-id = "eks-hybrid:///<region>/<cluster-name>/<hostname>" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "<hostname>" [settings.aws] region = "<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 = "<base64-encoded-admin-container-userdata>" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "<base64-encoded-bootstrap-container-userdata>" [settings.host-containers.control] enabled = true

Sostituire i segnaposto con i seguenti valori:

  • <cluster-name>: il nome del cluster Amazon EKS.

  • <api-server-endpoint>: l’endpoint del server API del cluster.

  • <cluster-certificate-authority>: il bundle CA con codifica base64 del cluster.

  • <region>: La AWS regione che ospita il cluster, ad esempio «us-east-1".

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

  • <base64-encoded-admin-container-userdata>: 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 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-user>", "ssh": { "authorized-keys": [ "<ssh-authorized-key>" ] } }
  • <base64-encoded-bootstrap-container-userdata>: il contenuto con codifica base64 della configurazione del container del bootstrap Bottlerocket. Consulta Bottlerocket bootstrap container documentation 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-id> --activation-code=<activation-code> --region=<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 = "<cluster-name>" api-server = "<api-server-endpoint>" cluster-certificate = "<cluster-certificate-authority>" hostname-override = "<hostname>" provider-id = "eks-hybrid:///<region>/<cluster-name>/<hostname>" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "<hostname>" [settings.aws] region = "<region>" config = "<base64-encoded-aws-config-file>" [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 = "<base64-encoded-admin-container-userdata>" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "<base64-encoded-bootstrap-container-userdata>"

Sostituire i segnaposto con i seguenti valori:

  • <cluster-name>: il nome del cluster Amazon EKS.

  • <api-server-endpoint>: l’endpoint del server API del cluster.

  • <cluster-certificate-authority>: il bundle CA con codifica base64 del cluster.

  • <region>: La AWS regione che ospita il cluster, ad esempio «us-east-1"

  • <hostname>: 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. 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}".

  • <base64-encoded-aws-config-file>: 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 <profile-arn> --role-arn <role-arn> --trust-anchor-arn <trust-anchor-arn> --role-session-name <role-session-name>
  • <base64-encoded-admin-container-userdata>: 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 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-user>", "ssh": { "authorized-keys": [ "<ssh-authorized-key>" ] } }
  • <base64-encoded-bootstrap-container-userdata>: il contenuto con codifica base64 della configurazione del container del bootstrap Bottlerocket. Consulta Bottlerocket bootstrap container documentation 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=<certificate> --key=<private-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=<network-adapter> \ -net=<network-name> \ -e guestinfo.userdata.encoding="base64" \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -template=<template-name> \ <vm-name>

Aggiornamento dei dati utente per una macchina virtuale esistente

govc vm.create \ -on=false \ -c=2 \ -m=4096 \ -net.adapter=<network-adapter> \ -net=<network-name> \ -template=<template-name> \ <vm-name> govc vm.change -vm <vm-name> \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -e guestinfo.userdata.encoding="base64" govc vm.power -on <vm-name>

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.

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.