**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Referência do `nodeadm` para nós híbridos
A CLI (`nodeadm`) do Amazon EKS Hybrid Nodes simplifica a instalação, a configuração, o registro e a desinstalação dos componentes dos nós híbridos. Você pode incluir o `nodeadm` nas imagens do sistema operacional para automatizar o bootstrap de nós híbridos. Consulte [Preparar o sistema operacional para nós híbridos](hybrid-nodes-os.md) para obter mais informações.
A versão do `nodeadm` para nós híbridos difere da versão do `nodeadm` usada para inicializar instâncias do Amazon EC2 como nós nos clusters do Amazon EKS. Siga a documentação e as referências para a versão apropriada do `nodeadm`. Esta página da documentação é para a versão do `nodeadm` para nós híbridos.
O código-fonte do `nodeadm` para nós híbridos é publicado no repositório https://github.com/aws/eks-hybrid do GitHub.
**Importante**
Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo.
## Baixar `nodeadm`
A versão de nós híbridos do `nodeadm` está hospedada no Amazon S3 com o Amazon CloudFront na frente. Para instalar `nodeadm` em cada host on-premises, você pode executar o comando a seguir nos hosts on-premises.
**Para hosts x86\$164**
```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm'
```
**Para hosts ARM**
```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm'
```
Adicione uma permissão de arquivo executável ao binário baixado em cada host.
```
chmod +x nodeadm
```
## `nodeadm install`
O comando `nodeadm install` é usado para instalar os artefatos e dependências necessários para executar e unir nós híbridos a um cluster do Amazon EKS. O comando `nodeadm install` pode ser executado individualmente em cada nó híbrido ou durante os pipelines de criação de imagens para pré-instalar as dependências dos nós híbridos nas imagens do sistema operacional.
**Usage**
```
nodeadm install [KUBERNETES_VERSION] [flags]
```
**Argumentos posicionais**
(Obrigatório) `KUBERNETES_VERSION` A versão major.minor do Kubernetes do EKS a ser instalada, por exemplo, `1.32`
**Sinalizadores**
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `-p`, `--credential-provider` | TRUE | Provedor de credenciais a ser instalado. Os valores compatíveis são `iam-ra` e `ssm`. Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. |
| `-s`, `--containerd-source` | FALSE | Fonte para `containerd`. O `nodeadm` é compatível com a instalação de `containerd` do distro do sistema operacional, os pacotes do Docker e a omissão da instalação de `containerd`. **Valores** `distro`: este é o valor padrão. O `nodeadm` instalará o pacote `containerd` mais recente distribuído pelo sistema operacional do nó que seja compatível com a versão do Kubernetes do EKS. O `distro` não é um valor compatível com sistemas operacionais do Red Hat Enterprise Linux (RHEL). `docker`: o `nodeadm` instalará o pacote `containerd` mais recente desenvolvido e distribuído pelo Docker que seja compatível com a versão do Kubernetes do EKS. O `docker` não é um valor compatível com o Amazon Linux 2023. `none`: o `nodeadm` não vai instalar o pacote `containerd`. Você deve instalar `containerd` manualmente antes de executar `nodeadm init`. |
| `-r`, `--region` | FALSE | Especifica a região da AWS para baixar artefatos, como o Agente SSM. O padrão é `us-west-2`. |
| `-t`, `--timeout` | FALSE | Duração máxima do comando de instalação. A entrada segue o formato de duração. Por exemplo, . `1h23m`. O tempo limite de download padrão para o comando de instalação é definido como 20 minutos. |
| `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. |
**Exemplos**
Instale a versão `1.32` do Kubernetes com o AWS Systems Manager (SSM) como o provedor de credenciais
```
nodeadm install 1.32 --credential-provider ssm
```
Instale a versão `1.32` do Kubernetes com o AWS Systems Manager (SSM) como o provedor de credenciais, e o Docker como a fonte do containerd, com um tempo limite de download de 20 minutos.
```
nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m
```
Instale a versão `1.32` do Kubernetes com o AWS IAM Roles Anywhere como o provedor de credenciais
```
nodeadm install 1.32 --credential-provider iam-ra
```
## `nodeadm config check`
O comando `nodeadm config check` verifica se há erros na configuração do nó fornecido. Esse comando pode ser usado para verificar e validar a exatidão de um arquivo de configuração de nó híbrido.
**Usage**
```
nodeadm config check [flags]
```
**Sinalizadores**
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Fonte da configuração do nodeadm. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. |
| `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. |
**Exemplos**
```
nodeadm config check -c file://nodeConfig.yaml
```
## `nodeadm init`
O comando `nodeadm init` inicia e conecta o nó híbrido com o cluster configurado do Amazon EKS. Consulte [Configuração de nó para ativações híbridas do SSM](#hybrid-nodes-node-config-ssm) ou [Configuração de nó para o IAM Roles Anywhere](#hybrid-nodes-node-config-iamra) para obter detalhes sobre como configurar o arquivo `nodeConfig.yaml`.
**Usage**
```
nodeadm init [flags]
```
**Sinalizadores**
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Fonte de configuração do `nodeadm`. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. |
| `-s`, `--skip` | FALSE | Fases de `init` a serem ignoradas. Não é recomendável pular nenhuma das fases, a menos que isso ajude a corrigir um problema. **Valores** `install-validation` vai ignorar a verificação se o comando de instalação anterior tiver sido executado com êxito. A `cni-validation` vai ignorar a verificação se as portas VXLAN da CNI do Cilium ou do Calico estiverem abertas, caso o firewall esteja habilitado no nó `node-ip-validation` ignorará a verificação se o IP do nó estiver dentro de um CIDR nas redes de nós remotos |
| `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. |
**Exemplos**
```
nodeadm init -c file://nodeConfig.yaml
```
## `nodeadm upgrade`
O comando `nodeadm upgrade` atualiza todos os artefatos instalados para a versão mais recente e inicializa o nó para configurar os artefatos atualizados e unir o cluster do EKS na AWS. O upgrade é um comando de interrupção para as workloads em execução no nó. Mova as workloads para outro nó antes de executar o comando upgrade.
**Usage**
```
nodeadm upgrade [KUBERNETES_VERSION] [flags]
```
**Argumentos posicionais**
(Obrigatório) `KUBERNETES_VERSION` A versão major.minor do Kubernetes do EKS a ser instalada, por exemplo, `1.32`
**Sinalizadores**
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Fonte de configuração do `nodeadm`. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. |
| `-t`, `--timeout` | FALSE | Tempo limite para download de artefatos. A entrada segue o formato de duração. Por exemplo, 1h23m. O tempo limite de download padrão para o comando de atualização é definido para dez minutos. |
| `-s`, `--skip` | FALSE | Fases da atualização a serem ignoradas. Não é recomendável pular nenhuma fase, a menos que isso ajude a corrigir um problema. **Valores** `pod-validation` ignora a verificação se todos os pods não estão em execução no nó, exceto conjuntos de daemons e pods estáticos. `node-validation` ignora a verificação se o nó foi isolado. `init-validation` ignora a verificação se o nó foi inicializado com sucesso antes de executar a atualização. O valor `containerd-major-version-upgrade` impede atualizações da versão principal do containerd durante a atualização do nó. |
| `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. |
**Exemplos**
```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml
```
```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m
```
## `nodeadm uninstall`
O comando `nodeadm uninstall` interrompe e remove os artefatos do `nodeadm` instalados durante a `nodeadm install`, incluindo o kubelet e o containerd. Observe que o comando uninstall não drena nem exclui os nós híbridos do cluster. Você deve executar as operações de drenagem e exclusão separadamente. Consulte [Remoção de nós híbridos](hybrid-nodes-remove.md) para obter mais informações. Por padrão, `nodeadm uninstall` não prosseguirá se houver pods restantes no nó. Da mesma forma, `nodeadm uninstall` não remove dependências da CNI ou dependências de outros complementos do Kubernetes que você executa no cluster. Para remover totalmente a instalação da CNI do host, consulte as instruções em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). Se você estiver usando ativações híbridas do AWS SSM como o provedor de credenciais on-premises, o comando `nodeadm uninstall` vai cancelar o registro dos hosts como instâncias gerenciadas pelo AWS SSM.
**Usage**
```
nodeadm uninstall [flags]
```
**Sinalizadores**
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `-s`, `--skip` | FALSE | Fases de desinstalação a serem ignoradas. Não é recomendável pular nenhuma das fases, a menos que isso ajude a corrigir um problema. **Valores** `pod-validation` ignora a verificação se todos os pods não estão em execução no nó, exceto conjuntos de daemons e pods estáticos. `node-validation` ignora a verificação se o nó foi isolado. A `init-validation` vai ignorar a verificação se o nó tiver sido inicializado com êxito antes de executar a desinstalação. |
| `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. |
| `-f`, `--force` | FALSE | Força a exclusão de diretórios adicionais que possam conter arquivos restantes dos componentes do Kubernetes e da CNI. **AVISO** Isso excluirá todo o conteúdo nos diretórios padrão do Kubernetes e da CNI (`/var/lib/cni`, `/etc/cni/net.d`, etc). Não use esse sinalizador se você armazenar seus próprios dados nesses locais. A partir do nodeadm `v1.0.9`, o comando `./nodeadm uninstall --skip node-validation,pod-validation --force` não exclui mais o diretório `/var/lib/kubelet`. Isso ocorre porque ele pode conter volumes de pod e diretórios de subcaminhos de volume que às vezes incluem o sistema de arquivos do nó montado. **Dicas de manuseio seguro** - A exclusão de caminhos montados pode levar à exclusão acidental do sistema de arquivos real do nó montado. Antes de excluir manualmente o diretório `/var/lib/kubelet`, inspecione cuidadosamente todas as montagens ativas e desmonte os volumes com segurança para evitar perda de dados. |
**Exemplos**
```
nodeadm uninstall
```
```
nodeadm uninstall --skip node-validation,pod-validation
```
## `nodeadm debug`
O comando `nodeadm debug` pode ser usado para solucionar problemas de nós híbridos não íntegros ou mal configurados. Ele valida se os requisitos a seguir estão em vigor.
+ O nó tem acesso de rede às APIs da AWS necessárias para obter credenciais.
+ O nó é capaz de obter credenciais da AWS para o perfil do IAM configurado de nós híbridos.
+ O nó tem acesso de rede ao endpoint da API do Kubernetes do EKS e à validade do certificado do endpoint da API do Kubernetes do EKS.
+ O nó é capaz de se autenticar com o cluster do EKS, sua identidade no cluster é válida e o nó tem acesso ao cluster do EKS por meio da VPC configurada para o cluster do EKS.
Se forem encontrados erros, a saída do comando vai sugerir etapas de solução de problemas. Certas etapas de validação mostram processos secundários. Se estes falharem, a saída será mostrada em uma seção stderr abaixo do erro de validação.
**Usage**
```
nodeadm debug [flags]
```
**Sinalizadores**
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `-c`, `--config-source` | TRUE | Fonte de configuração do `nodeadm`. Para nós híbridos, a entrada deve seguir um URI com esquema de arquivo. |
| `--no-color` | FALSE | Desativa a saída de cores. Útil para automação. |
| `-h`, `--help` | FALSE | Exibe a mensagem de ajuda com os parâmetros de sinalização, subcomando e valor posicional disponíveis. |
**Exemplos**
```
nodeadm debug -c file://nodeConfig.yaml
```
## Locais dos arquivos do nodeadm
### Instalação do nodeadm
Durante a execução da `nodeadm install`, os arquivos e as localizações de arquivos a seguir são configurados.
| Artifact | Caminho |
| --- | --- |
| CLI do IAM Roles Anywhere | /usr/local/bin/aws\$1signing\$1helper |
| Binário do Kubelet | /usr/bin/kubelet |
| Binário do Kubectl | usr/local/bin/kubectl |
| Provedor de credenciais do ECR | /etc/eks/image-credential-provider/ecr-credential-provider |
| AWS IAM Authenticator | /usr/local/bin/aws-iam-authenticator |
| CLI de configuração do SSM | /opt/ssm/ssm-setup-cli |
| SSM Agent | No Ubuntu: /snap/amazon-ssm-agent/current/amazon-ssm-agent No RHEL e AL2023: /usr/bin/amazon-ssm-agent |
| Containerd | No Ubuntu e AL2023: /usr/bin/containerd No RHEL: /bin/containerd |
| Iptables | No Ubuntu e AL2023: /usr/sbin/iptables No RHEL: /sbin/iptables |
| Plug-ins da CNI | /opt/cni/bin |
| rastreador de artefatos instalado | /opt/nodeadm/tracker |
### Inicialização do nodeadm
Durante a execução da `nodeadm init`, os arquivos e as localizações de arquivos a seguir são configurados.
| Nome | Caminho |
| --- | --- |
| kubeconfig do Kubelet | /var/lib/kubelet/kubeconfig |
| Configuração do Kubelet | /etc/kubernetes/kubelet/config.json |
| Unidade systemd do Kubelet | /etc/systemd/system/kubelet.service |
| Configuração do provedor de credenciais de imagem | /etc/eks/image-credential-provider/config.json |
| Arquivo env do Kubelet | /etc/eks/kubelet/environment |
| Certificados do Kubelet | /etc/kubernetes/pki/ca.crt |
| Configuração do containerd | /etc/containerd/config.toml |
| Configuração dos módulos do containerd do kernel | /etc/modules-load.d/containerd.conf |
| AWSArquivo de configuração da | /etc/aws/hybrid/config |
| Arquivo de credenciais da AWS (se habilitar arquivo de credenciais) | /eks-hybrid/.aws/credentials |
| Unidade do sistema auxiliar de assinatura da AWS | /etc/systemd/system/aws\$1signing\$1helper\$1update.service |
| Arquivo de configuração Sysctl | /etc/sysctl.d/99-nodeadm.conf |
| Ca-certificates | /etc/ssl/certs/ca-certificates.crt |
| Arquivo de chaves GPG | /etc/apt/keyrings/docker.asc |
| Arquivo de origem do repositório do Docker | /etc/apt/sources.list.d/docker.list |
## Configuração de nó para ativações híbridas do SSM
Veja a seguir um exemplo de `nodeConfig.yaml` ao usar ativações híbridas do AWS SSM para credenciais de nós híbridos.
```
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
```
## Configuração de nó para o IAM Roles Anywhere
Veja a seguir um exemplo de `nodeConfig.yaml` do AWS IAM Roles Anywhere para credenciais de nós híbridos.
Ao usar o AWS IAM Roles Anywhere como seu provedor de credenciais on-premises, o `nodeName` que você usa na configuração do `nodeadm` deve estar alinhado com as permissões que você definiu como escopo para o perfil do IAM de nós híbridos. Por exemplo, se as permissões para o perfil do IAM de nós híbridos só permitirem que o AWS IAM Roles Anywhere assuma o perfil quando o nome da sessão do perfil for igual ao CN do certificado do host, o `nodeName` na configuração do `nodeadm` deverá ser o mesmo que o CN dos certificados. O `nodeName` que você usa não pode exceder 64 caracteres. Para obter mais informações, consulte [Preparar as credenciais para nós híbridos](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
```
## Configuração de nó para personalizar o kubelet (opcional)
Você pode passar a configuração e os sinalizadores do kubelet na configuração do `nodeadm`. Veja o exemplo abaixo para saber como adicionar um rótulo de nó `abc.amazonaws.com/test-label` e como configurar para definir `shutdownGracePeriod` como 30 segundos.
```
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
```
## Configuração de nó para personalizar o containerd (opcional)
Você pode passar uma configuração personalizada do containerd na configuração do `nodeadm`. A configuração do containerd para `nodeadm` aceita TOML em linha. Veja o exemplo abaixo para saber como configurar o containerd para desabilitar a exclusão de camadas de imagens descompactadas no armazenamento de conteúdo do 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**
As versões 1.x e 2.x do containerd contam com formatos de configuração distintos. O containerd 1.x usa a versão 2 da configuração, enquanto o containerd 2.x usa a versão 3. Embora o containerd 2.x seja compatível com versões anteriores da configuração 2, a versão 3 é recomendada para obtenção da performance ideal. Confira a versão do containerd com `containerd --version` ou analise os logs de instalação do `nodeadm`. Para obter mais detalhes sobre o versionamento da configuração, consulte https://containerd.io/releases/.
Você também pode usar a configuração do containerd para habilitar a compatibilidade com o SELinux. Com o SELinux habilitado no containerd, certifique-se de que os pods programados no nó tenham o securityContext e o seLinuxOptions adequados habilitados. Você pode encontrar mais informações sobre como configurar um contexto de segurança na [documentação do Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
**nota**
O Red Hat Enterprise Linux (RHEL) 8 e o RHEL 9 têm o SELinux habilitado por padrão e configurado como estrito no host. Por padrão, o Amazon Linux 2023 tem o SELinux habilitado e configurado para o modo permissivo. Quando o SELinux está configurado para o modo permissivo no host, ativá-lo no containerd não bloqueará as solicitações, mas as registrará em log de acordo com a configuração do SELinux no host.
```
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
```