

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

# Riferimento `nodeadm` dei nodi ibridi
<a name="hybrid-nodes-nodeadm"></a>

La CLI Amazon EKS Hybrid Nodes (`nodeadm`) semplifica l’installazione, la configurazione, la registrazione e la disinstallazione dei componenti dei nodi ibridi. Puoi includere il `nodeadm` nelle immagini del tuo sistema operativo per automatizzare il bootstrap dei nodi ibridi, consulta [Preparazione del sistema operativo per i nodi ibridi](hybrid-nodes-os.md) per ulteriori informazioni.

La `nodeadm` versione per i nodi ibridi è diversa dalla `nodeadm` versione utilizzata per avviare le istanze EC2 Amazon come nodi nei cluster Amazon EKS. Consulta la documentazione e i riferimenti per la versione del `nodeadm` appropriata. Questa pagina di documentazione riguarda la versione del `nodeadm` per i nodi ibridi.

Il codice sorgente per i nodi ibridi `nodeadm` è pubblicato nel repository eks-hybrid. https://github.com/aws/ GitHub 

**Importante**  
È necessario eseguire l'esecuzione `nodeadm` con un utente con privilegi. root/sudo 

## Scarica `nodeadm`
<a name="_download_nodeadm"></a>

La versione con nodi ibridi di `nodeadm` è ospitata in Amazon S3 gestita da Amazon. CloudFront Per installare `nodeadm` su ciascun host on-premises puoi eseguire il seguente comando dai tuoi 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
```

## `nodeadm install`
<a name="_nodeadm_install"></a>

Il comando `nodeadm install` viene utilizzato per installare gli artefatti e le dipendenze necessari per eseguire e unire nodi ibridi a un cluster Amazon EKS. Il comando `nodeadm install` può essere eseguito singolarmente su ciascun nodo ibrido o può essere eseguito durante le pipeline di creazione delle immagini per preinstallare le dipendenze dei nodi ibridi nelle immagini del sistema operativo.

 **Utilizzo** 

```
nodeadm install [KUBERNETES_VERSION] [flags]
```

 **Argomenti posizionali** 

(Obbligatorio) `KUBERNETES_VERSION` La versione major.minor di EKS Kubernetes da installare, ad esempio `1.32` 

 **Flag** 


| Name | Richiesto | Description | 
| --- | --- | --- | 
|   `-p`,  `--credential-provider`   |  TRUE  |  Provider di credenziali da installare. I valori supportati sono `iam-ra` e `ssm`. Per ulteriori informazioni, consulta [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md).  | 
|   `-s`,  `--containerd-source`   |  FALSE  |  Origine per `containerd`. `nodeadm` supporta l’installazione di `containerd` dalla distribuzione del sistema operativo, i pacchetti Docker e la possibilità di saltare l’installazione di `containerd`.  **Valori**   `distro`- Questo è il valore predefinito. `nodeadm`installerà il `containerd` pacchetto più recente distribuito dal sistema operativo del nodo compatibile con la versione EKS Kubernetes. `distro`non è un valore supportato per i sistemi operativi Red Hat Enterprise Linux (RHEL).  `docker`- `nodeadm` installerà l'ultimo `containerd` pacchetto creato e distribuito da Docker compatibile con la versione EKS Kubernetes. `docker`non è un valore supportato per Amazon Linux 2023.  `none`: `nodeadm` non installerà il pacchetto `containerd`. Devi installare manualmente `containerd` prima di eseguire `nodeadm init`.  | 
|   `-r`,  `--region`   |  FALSE  |  Speciifica la AWS regione per il download di artefatti come l'agente SSM. L’impostazione predefinita è `us-west-2`.  | 
|   `-t`,  `--timeout`   |  FALSE  |  Durata massima del comando di installazione. L’input segue il formato della durata. Ad esempio, `1h23m`. Il timeout per il download predefinito per il comando di installazione è impostato su 20 minuti.  | 
|   `-h`, `--help`   |  FALSE  |  Mostra un messaggio di aiuto con i parametri di flag, sottocomando e valore posizionale disponibili.  | 

 **Esempi** 

Installa la versione Kubernetes con AWS Systems `1.32` Manager (SSM) come provider di credenziali

```
nodeadm install 1.32 --credential-provider ssm
```

Installa la versione Kubernetes con AWS Systems `1.32` Manager (SSM) come provider di credenziali, Docker come origine containerd, con un timeout di download di 20 minuti.

```
nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m
```

Installa la versione Kubernetes con IAM Roles Anywhere come provider di credenziali `1.32` AWS 

```
nodeadm install 1.32 --credential-provider iam-ra
```

## `nodeadm config check`
<a name="_nodeadm_config_check"></a>

Il comando `nodeadm config check` verifica la presenza di errori nella configurazione del nodo fornita. Questo comando può essere utilizzato per verificare e confermare la correttezza di un file di configurazione del nodo ibrido.

 **Utilizzo** 

```
nodeadm config check [flags]
```

 **Flag** 


| Name | Richiesto | Description | 
| --- | --- | --- | 
|   `-c`,  `--config-source`   |  TRUE  |  Origine della configurazione di nodeadm. Per i nodi ibridi, l’input deve seguire un URI con schema di file.  | 
|   `-h`, `--help`   |  FALSE  |  Mostra un messaggio di aiuto con i parametri di flag, sottocomando e valore posizionale disponibili.  | 

 **Esempi** 

```
nodeadm config check -c file://nodeConfig.yaml
```

## `nodeadm init`
<a name="_nodeadm_init"></a>

Il comando `nodeadm init` avvia e connette il nodo ibrido con il cluster Amazon EKS configurato. Consulta [Configurazione del modo per attivazioni ibride SSM](#hybrid-nodes-node-config-ssm) o [Configurazione del nodo per IAM Roles Anywhere](#hybrid-nodes-node-config-iamra) per i dettagli su come configurare il file `nodeConfig.yaml`.

 **Utilizzo** 

```
nodeadm init [flags]
```

 **Flag** 


| Name | Richiesto | Description | 
| --- | --- | --- | 
|   `-c`,  `--config-source`   |  TRUE  |  Origine della configurazione di `nodeadm`. Per i nodi ibridi, l’input deve seguire un URI con schema di file.  | 
|   `-s`,  `--skip`   |  FALSE  |  Fasi di `init` da saltare. Non è consigliabile saltare nessuna delle fasi a meno che non sia utile per risolvere un problema.  **Valori**   `install-validation` salta la verifica se il comando di installazione precedente è stato eseguito correttamente.  `cni-validation` salta la verifica se le porte VXLAN della CNI di Cilium o di Calico sono aperte se il firewall è abilitato sul nodo  `node-ip-validation` salta la verifica se l’IP del nodo rientra in un CIDR nelle reti dei nodi remoti  | 
|   `-h`, `--help`   |  FALSE  |  Mostra un messaggio di aiuto con i parametri di flag, sottocomando e valore posizionale disponibili.  | 

 **Esempi** 

```
nodeadm init -c file://nodeConfig.yaml
```

## `nodeadm upgrade`
<a name="_nodeadm_upgrade"></a>

Il comando `nodeadm upgrade` aggiorna tutti gli artefatti installati alla versione più recente e avvia il nodo per configurare gli artefatti aggiornati e unirsi al cluster EKS su AWS. Upgrade è un comando che interrompe i carichi di lavoro in esecuzione sul nodo. Devi spostare i carichi di lavoro su un altro nodo prima di eseguire l’aggiornamento.

 **Utilizzo** 

```
nodeadm upgrade [KUBERNETES_VERSION] [flags]
```

 **Argomenti posizionali** 

(Obbligatorio) `KUBERNETES_VERSION` La versione major.minor di EKS Kubernetes da installare, ad esempio `1.32` 

 **Flag** 


| Name | Richiesto | Description | 
| --- | --- | --- | 
|   `-c`,  `--config-source`   |  TRUE  |  Origine della configurazione di `nodeadm`. Per i nodi ibridi, l’input deve seguire un URI con schema di file.  | 
|   `-t`,  `--timeout`   |  FALSE  |  Timeout per il download degli artefatti. L’input segue il formato della durata. Ad esempio 1h23m. Il timeout per il download predefinito per il comando di aggiornamento è impostato su 10 minuti.  | 
|   `-s`,  `--skip`   |  FALSE  |  Fasi dell’aggiornamento da saltare. Non è consigliabile saltare nessuna Passaggio a meno che non sia utile per risolvere un problema.  **Valori**   `pod-validation` salta la verifica se tutti i pod sono in esecuzione sul nodo, tranne i set daemon e i pod statici.  `node-validation` salta la verifica se il nodo è stato isolato.  `init-validation` salta la verifica se il nodo è stato inizializzato correttamente prima di eseguire l’aggiornamento.  `containerd-major-version-upgrade`impedisce gli aggiornamenti delle versioni principali di containerd durante l'aggiornamento del nodo.  | 
|   `-h`, `--help`   |  FALSE  |  Mostra un messaggio di aiuto con i parametri di flag, sottocomando e valore posizionale disponibili.  | 

 **Esempi** 

```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml
```

```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m
```

## `nodeadm uninstall`
<a name="_nodeadm_uninstall"></a>

Il comando `nodeadm uninstall` arresta e rimuove gli artefatti che `nodeadm` installa durante `nodeadm install`, inclusi kubelet e containerd. Attenzione, il comando di disinstallazione non scarica né elimina i nodi ibridi dal cluster. Devi eseguire le operazioni di scaricamento ed eliminazione separatamente, consulta [Rimuovi i nodi ibridi](hybrid-nodes-remove.md) per ulteriori informazioni. Per impostazione predefinita, `nodeadm uninstall` non proseguirà se sul nodo rimangono dei pod. Allo stesso modo, `nodeadm uninstall` non rimuove le dipendenze CNI o le dipendenze di altri componenti aggiuntivi di Kubernetes eseguiti sul cluster. Per rimuovere completamente l’installazione CNI dal tuo host, consulta le istruzioni contenute in [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md). Se utilizzi attivazioni ibride AWS SSM come provider di credenziali locale, il `nodeadm uninstall` comando annulla la registrazione degli host come istanze gestite tramite SSM. AWS 

 **Utilizzo** 

```
nodeadm uninstall [flags]
```

 **Flag** 


| Name | Richiesto | Description | 
| --- | --- | --- | 
|   `-s`,  `--skip`   |  FALSE  |  Fasi di disinstallazione da saltare. Non è consigliabile saltare nessuna delle fasi a meno che non sia utile per risolvere un problema.  **Valori**   `pod-validation` salta la verifica se tutti i pod sono in esecuzione sul nodo, tranne i set daemon e i pod statici.  `node-validation` salta la verifica se il nodo è stato isolato.  `init-validation` salta la verifica se il nodo è stato inizializzato correttamente prima di eseguire la disinstallazione.  | 
|   `-h`,  `--help`   |  FALSE  |  Mostra un messaggio di aiuto con i parametri di flag, sottocomando e valore posizionale disponibili.  | 
|   `-f`,  `--force`   |  FALSE  |  Forza l’eliminazione delle directory aggiuntive che potrebbero contenere file rimanenti dai componenti Kubernetes e CNI.  **ATTENZIONE**  Ciò eliminerà tutti i contenuti nelle directory Kubernetes e CNI predefinite (`/var/lib/cni`, `/etc/cni/net.d`, ecc.). Non utilizzare questo flag se memorizzi i tuoi dati in queste posizioni. A partire dalla versione `v1.0.9` di nodeadm, il comando `./nodeadm uninstall --skip node-validation,pod-validation --force` non elimina più la directory `/var/lib/kubelet`. Questo perché può contenere volumi Pod e directory volume-subpath che a volte includono il filesystem dei nodi montato.  **Suggerimenti per una gestione sicura**  L’eliminazione dei percorsi montati può portare alla cancellazione accidentale dell’effettivo filesystem dei nodi montati. Prima di eliminare manualmente la directory `/var/lib/kubelet`, ispeziona attentamente tutti i montaggi attivi e smonta i volumi in modo sicuro per evitare la perdita di dati.  | 

 **Esempi** 

```
nodeadm uninstall
```

```
nodeadm uninstall --skip node-validation,pod-validation
```

## `nodeadm debug`
<a name="_nodeadm_debug"></a>

Il comando `nodeadm debug` può essere utilizzato per risolvere i problemi relativi ai nodi ibridi non integri o configurati in modo errato. Verifica che i seguenti requisiti siano soddisfatti.
+ Il nodo ha accesso alla rete necessaria per ottenere le credenziali, AWS APIs 
+ Il nodo è in grado di ottenere AWS le credenziali per il ruolo IAM di Hybrid Nodes configurato,
+ Il nodo ha accesso di rete all’endpoint dell’API EKS Kubernetes e ha la validità del certificato endpoint dell’API EKS Kubernetes.
+ Il nodo è in grado di autenticarsi con il cluster EKS, la sua identità nel cluster è valida e ha accesso al cluster EKS tramite il VPC configurato per il cluster EKS.

Se vengono rilevati errori, l’output del comando suggerisce le procedure per la risoluzione dei problemi. Alcuni passaggi di conferma mostrano le procedure secondarie. Se queste non funzionano, l’output viene mostrato in una sezione stderr sotto l’errore di convalida.

 **Utilizzo** 

```
nodeadm debug [flags]
```

 **Flag** 


| Name | Richiesto | Description | 
| --- | --- | --- | 
|   `-c`, `--config-source`   |  TRUE  |  Origine della configurazione di `nodeadm`. Per i nodi ibridi, l’input deve seguire un URI con schema di file.  | 
|   `--no-color`   |  FALSE  |  Disattiva l’output a colori. Utile per l’automazione.  | 
|   `-h`, `--help`   |  FALSE  |  Mostra un messaggio di aiuto con i parametri di flag, sottocomando e valore posizionale disponibili.  | 

 **Esempi** 

```
nodeadm debug -c file://nodeConfig.yaml
```

## Posizioni dei file nodeadm
<a name="_nodeadm_file_locations"></a>

### installazione di nodeadm
<a name="_nodeadm_install_2"></a>

Durante l’esecuzione di `nodeadm install`, vengono configurati i seguenti file e posizioni dei file.


| Artifact | Path | 
| --- | --- | 
|  CLI IAM Roles Anywhere  |  /usr/local/bin/aws\$1signing\$1helper  | 
|  Binario Kubelet  |  /usr/bin/kubelet  | 
|  Binario Kubectl  |  usr/local/bin/kubectl  | 
|  Provider di credenziali ECR  |  /etc/eks/image-credential-provider/ecr-fornitore di credenziali  | 
|   AWS Autenticatore IAM  |  /-iam-authenticator usr/local/bin/aws  | 
|  CLI di configurazione SSM  |  /opt/ssm/ssm-setup-cli  | 
|  Agente SSM  |  Su Ubuntu -/-ssm-agent snap/amazon-ssm-agent/current/amazon Su RHEL e 023 -/-ssm-agent AL2 usr/bin/amazon  | 
|  Containerd  |  Su Ubuntu e 023 -/ AL2usr/bin/containerd Su RHEL - /bin/containerd  | 
|  Iptables  |  Su Ubuntu e AL2 023 -/usr/sbin/iptables Su RHEL - /sbin/iptables  | 
|  Plug-in CNI  |  /opt/cni/bin  | 
|  tracciatore di artefatti installati  |  /opt/nodeadm/tracker  | 

### nodeadm init
<a name="_nodeadm_init_2"></a>

Durante l’esecuzione di `nodeadm init`, vengono configurati i file e le posizioni seguenti dei file.


| Name | Path | 
| --- | --- | 
|  Kubelet kubeconfig  |  /var/lib/kubelet/kubeconfig  | 
|  Configurazione di Kubelet  |  /.json etc/kubernetes/kubelet/config  | 
|  Unità Kubelet systemd  |  /.servizio etc/systemd/system/kubelet  | 
|  Configurazione del provider di credenziali di immagine  |  /.json etc/eks/image-credential-provider/config  | 
|  File env Kubelet  |  /etc/eks/kubelet/environment  | 
|  Certificati Kubelet  |  /.crt etc/kubernetes/pki/ca  | 
|  Configurazione di Containerd  |  /.toml etc/containerd/config  | 
|  Configurazione dei moduli del kernel Containerd  |  /.conf etc/modules-load.d/contianerd  | 
|   AWS file di configurazione  |  /etc/aws/hybrid/config  | 
|   AWS file di credenziali (se abilita il file delle credenziali)  |  /eks-hybrid/.aws/credentials  | 
|   AWS unità di sistema di supporto alla firma  |  /etc/systemd/system/aws\$1signing\$1helper\$1update.service  | 
|  File conf sysctl  |  /etc/sysctl.d/99-nodeadm.conf  | 
|  Ca-certificates  |  /etc/ssl/certs/ca-certificati.crt  | 
|  File chiave Gpg  |  /etc/apt/keyrings/docker.asc  | 
|  File di origine del repository Docker  |  /.lista etc/apt/sources.list.d/docker  | 

## Configurazione del modo per attivazioni ibride SSM
<a name="hybrid-nodes-node-config-ssm"></a>

Di seguito è riportato un esempio `nodeConfig.yaml` di utilizzo delle attivazioni ibride AWS SSM per le credenziali dei nodi ibridi.

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```

## Configurazione del nodo per IAM Roles Anywhere
<a name="hybrid-nodes-node-config-iamra"></a>

Di seguito è riportato un esempio di `nodeConfig.yaml` credenziali AWS IAM Roles Anywhere per nodi ibridi.

Quando utilizzi AWS IAM Roles Anywhere come provider di credenziali locale, le `nodeName` credenziali utilizzate nella `nodeadm` configurazione devono essere in linea con le autorizzazioni previste per il ruolo IAM di Hybrid Nodes. Ad esempio, se le autorizzazioni per il ruolo IAM di Hybrid Nodes consentono a AWS IAM Roles Anywhere di assumere il ruolo solo quando il nome della sessione del ruolo è uguale al CN del certificato host, allora la `nodeName` `nodeadm` configurazione deve essere la stessa del CN dei tuoi certificati. Il `nodeName` che usi non può contenere più di 64 caratteri. Per ulteriori informazioni, consulta [Preparazione delle credenziali per i nodi ibridi](hybrid-nodes-creds.md).

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:              # Name of the EKS cluster
    region:            # AWS Region where the EKS cluster resides
  hybrid:
    iamRolesAnywhere:
      nodeName:        # Name of the node
      trustAnchorArn:  # ARN of the IAM Roles Anywhere trust anchor
      profileArn:      # ARN of the IAM Roles Anywhere profile
      roleArn:         # ARN of the Hybrid Nodes IAM role
      certificatePath: # Path to the certificate file to authenticate with the IAM Roles Anywhere trust anchor
      privateKeyPath:  # Path to the private key file for the certificate
```

## Configurazione del nodo per personalizzare kubelet (Facoltativo)
<a name="hybrid-nodes-nodeadm-kubelet"></a>

Puoi passare la configurazione e i flag di kubelet nella tua configurazione `nodeadm`. Vedi l’esempio seguente su come aggiungere un’etichetta `abc.amazonaws.com/test-label` e una configurazione del nodo aggiuntive per l’impostazione di `shutdownGracePeriod` su 30 secondi.

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  kubelet:
    config:           # Map of kubelet config and values
       shutdownGracePeriod: 30s
    flags:            # List of kubelet flags
       - --node-labels=abc.company.com/test-label=true
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```

## Configurazione del nodo per personalizzare containerd (Facoltativo)
<a name="_node_config_for_customizing_containerd_optional"></a>

Puoi passare la configurazione containerd personalizzata nella tua configurazione `nodeadm`. La configurazione containerd per `nodeadm` accetta TOML in linea. Vedi l’esempio seguente su come configurare containerd per disabilitare l’eliminazione dei livelli di immagine decompressi nel content store containerd.

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  containerd:
    config: |         # Inline TOML containerd additional configuration
       [plugins."io.containerd.grpc.v1.cri".containerd]
       discard_unpacked_layers = false
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```

**Nota**  
Le versioni 1.x e 2.x di Containerd utilizzano formati di configurazione diversi. Containerd 1.x utilizza la versione 2 di configurazione, mentre containerd 2.x utilizza la versione 3 di configurazione. Sebbene containerd 2.x rimanga retrocompatibile con la versione 2 di configurazione, la versione 3 è consigliata per prestazioni ottimali. Controlla la versione containerd in uso o `nodeadm` consulta i log di `containerd --version` installazione. Per maggiori dettagli sul controllo delle versioni di configurazione, consulta https://containerd.io/releases/

Puoi anche usare la configurazione containerd per abilitare il supporto. SELinux Con SELinux enabled on containerd, assicurati che i pod programmati sul nodo abbiano il SecurityContext corretto e siano abilitati. seLinuxOptions Ulteriori informazioni sulla configurazione di un contesto di sicurezza sono disponibili in [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).

**Nota**  
Red Hat Enterprise Linux (RHEL) 8 e RHEL 9 sono SELinux abilitati di default e impostati su strict sull'host. Amazon Linux 2023 è SELinux abilitato per impostazione predefinita e impostato in modalità permissiva. Quando SELinux è impostata la modalità permissiva sull'host, abilitarla su containerd non bloccherà le richieste ma le registrerà in base alla configurazione sull'host. SELinux 

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  containerd:
    config: |         # Inline TOML containerd additional configuration
       [plugins."io.containerd.grpc.v1.cri"]
       enable_selinux = true
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```