**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. # Execução de workloads on-premises em nós híbridos Em um cluster do EKS com nós híbridos habilitados, você pode executar aplicações on-premises e de borda em sua própria infraestrutura com os mesmos clusters, recursos e ferramentas do Amazon EKS que você usa na Nuvem AWS. As seções a seguir contêm instruções passo a passo para usar nós híbridos. **Topics** + [Conectar nós híbridos](hybrid-nodes-join.md) + [Conectar nós híbridos com o Bottlerocket](hybrid-nodes-bottlerocket.md) + [Atualizar os nós híbridos](hybrid-nodes-upgrade.md) + [Patches em nós híbridos](hybrid-nodes-security.md) + [Excluir nós híbridos](hybrid-nodes-remove.md) # Conectar nós híbridos **nota** As etapas a seguir se aplicam aos nós híbridos que executam sistemas operacionais compatíveis, exceto o Bottlerocket. Para obter as etapas para conectar um nó híbrido que executa o Bottlerocket, consulte [Conectar nós híbridos com o Bottlerocket](hybrid-nodes-bottlerocket.md). Este tópico descreve como conectar nós híbridos a um cluster do Amazon EKS. Depois que os nós híbridos se unirem ao cluster, eles aparecerão com o status Não pronto no console do Amazon EKS e em ferramentas compatíveis com o Kubernetes, como o kubectl. Depois de concluir as etapas desta página, prossiga para [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para preparar os nós híbridos para executar aplicações. ## Pré-requisitos Antes de conectar nós híbridos ao cluster do Amazon EKS, certifique-se de ter concluído as etapas de pré-requisitos. + Você tem conectividade de rede do ambiente on-premises para a região da AWS que hospeda o cluster do Amazon EKS. Consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) para obter mais informações. + Você tem um sistema operacional compatível para nós híbridos instalado nos hosts on-premises. Consulte [Preparar o sistema operacional para nós híbridos](hybrid-nodes-os.md) para obter mais informações. + Você criou o perfil do IAM de nós híbridos e configurou o provedor de credenciais on-premises (ativações híbridas do AWS Systems Manager ou o AWS IAM Roles Anywhere). Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. + Você criou o cluster do Amazon EKS habilitado para nós híbridos. Consulte [Criar um cluster do Amazon EKS com nós híbridos](hybrid-nodes-cluster-create.md) para obter mais informações. + Você associou o perfil do IAM de nós híbridos às permissões de controle de acesso por perfil (RBAC) do Kubernetes. Consulte [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md) para obter mais informações. ## Etapa 1: instalar a CLI de nós híbridos (`nodeadm`) em cada host on-premises Caso esteja incluindo a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes nas imagens pré-criadas do sistema operacional, você pode pular esta etapa. Para obter mais informações sobre a versão de nós híbridos de `nodeadm`, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). 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 ``` ## Etapa 2: instalar as dependências dos nós híbridos com `nodeadm` Caso esteja instalando as dependências de nós híbridos em imagens pré-criadas do sistema operacional, você pode pular esta etapa. O comando `nodeadm install` pode ser usado para instalar todas as dependências necessárias para nós híbridos. As dependências dos nós híbridos incluem containerd, kubelet, kubectl e componentes do AWS SSM ou AWS IAM Roles Anywhere. Consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md) para obter mais informações sobre os componentes e os locais dos arquivos instalados por `nodeadm install`. Consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) para conferir os nós híbridos e obter mais informações sobre os domínios que devem ser permitidos no firewall on-premises para o processo de `nodeadm install`. Execute o comando abaixo para instalar as dependências dos nós híbridos no host on-premises. O comando abaixo deve ser executado com um usuário que tenha acesso sudo/root no host. **Importante** A CLI de nós híbridos (`nodeadm`) deve ser executada com um usuário que tenha acesso sudo/root no host. + Substitua `K8S_VERSION` pela versão secundária do Kubernetes do cluster do Amazon EKS, por exemplo, `1.31`. Consulte as [versões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para obter uma lista das versões do Kubernetes compatíveis. + Substitua `CREDS_PROVIDER` pelo provedor de credenciais on-premises que você está usando. Os valores válidos são `ssm` para o AWS SSM e `iam-ra` para o AWS IAM Roles Anywhere. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## Etapa 3: conectar nós híbridos ao cluster Antes de conectar os nós híbridos ao cluster, certifique-se de ter permitido o acesso necessário no firewall on-premises e no grupo de segurança do cluster para a comunicação do ambiente de gerenciamento do Amazon EKS de/para nós híbridos. A maioria dos problemas nesta etapa está relacionada à configuração do firewall, à configuração do grupo de segurança ou à configuração do perfil do IAM de nós híbridos. **Importante** A CLI de nós híbridos (`nodeadm`) deve ser executada com um usuário que tenha acesso sudo/root no host. 1. Crie um arquivo `nodeConfig.yaml` em cada host com os valores da implantação. Para obter uma descrição completa das configurações disponíveis, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). Se o perfil do IAM de nós híbridos não tiver permissão para a ação `eks:DescribeCluster`, você deverá passar o endpoint da API Kubernetes, o pacote de CA do cluster e o CIDR IPv4 do serviço do Kubernetes na seção de clusters do `nodeConfig.yaml`. 1. Use o exemplo de `nodeConfig.yaml` abaixo se estiver usando ativações híbridas do AWS SSM para o provedor de credenciais on-premises. 1. Substitua o `CLUSTER_NAME` pelo nome do cluster. 1. Substitua `AWS_REGION` pela região da AWS que está hospedando o cluster. Por exemplo, .`us-west-2` 1. Substitua `ACTIVATION_CODE` pelo código de ativação que você recebeu ao criar a ativação híbrida do AWS SSM. Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. 1. Substitua `ACTIVATION_ID` pelo ID de ativação que você recebeu ao criar a ativação híbrida do AWS SSM. Você pode recuperar essas informações no console do AWS Systems Manager ou com o comando `aws ssm describe-activations` da 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. Use o exemplo de `nodeConfig.yaml` abaixo se estiver usando o AWS IAM Roles Anywhere para o provedor de credenciais on-premises. 1. Substitua o `CLUSTER_NAME` pelo nome do cluster. 1. Substitua `AWS_REGION` pela região da AWS que está hospedando o cluster. Por exemplo, .`us-west-2` 1. Substitua `NODE_NAME` pelo nome do nó. O nome do nó deve corresponder ao CN do certificado no host caso tenha configurado a política de confiança do perfil do IAM de nós híbridos com a condição de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. O `nodeName` que você usar não deve ter mais de 64 caracteres. 1. Substitua `TRUST_ANCHOR_ARN` pelo ARN da âncora de confiança que você configurou nas etapas de Preparar credenciais para nós híbridos. 1. Substitua `PROFILE_ARN` pelo ARN da âncora de confiança que você configurou nas etapas de [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md). 1. Substitua `ROLE_ARN` pelo ARN do perfil do IAM de nós híbridos. 1. Substitua `CERTIFICATE_PATH` pelo caminho no disco para o certificado do nó. Caso não seja especificado, o padrão será `/etc/iam/pki/server.pem`. 1. Substitua `KEY_PATH` pelo caminho no disco para a chave privada do certificado. Caso não seja especificado, o padrão será `/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. Execute o comando `nodeadm init` com o `nodeConfig.yaml` para conectar os nós híbridos ao cluster do Amazon EKS. ``` nodeadm init -c file://nodeConfig.yaml ``` Se o comando acima for concluído com sucesso, o nó híbrido terá se unido ao cluster do Amazon EKS. Você pode verificar isso no console do Amazon EKS navegando até a guia Computação do cluster ([certifique-se de que a entidade principal do IAM tenha permissões para visualizar](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) ou com `kubectl get nodes`. **Importante** Seus nós terão o status `Not Ready`, o que é esperado e se deve à falta de uma CNI em execução nos nós híbridos. Se os nós não tiverem se unido ao cluster, consulte [Solução de problemas de nós híbridos](hybrid-nodes-troubleshooting.md). ## Etapa 4: configurar uma CNI para nós híbridos Para preparar os nós híbridos para executar aplicações, continue com as etapas em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). # Conectar nós híbridos com o Bottlerocket Este tópico descreve como conectar nós híbridos que executam o Bottlerocket a um cluster do Amazon EKS. O [Bottlerocket](https://aws.amazon.com/bottlerocket/) é uma distribuição de código aberto do Linux patrocinada e apoiada pela AWS. O Bottlerocket foi desenvolvido especificamente para hospedar workloads de contêineres. Com o Bottlerocket, você pode melhorar a disponibilidade de implantações em contêineres e reduzir os custos operacionais automatizando as atualizações em sua infraestrutura de contêineres. O Bottlerocket inclui somente o software essencial para executar contêineres, o que melhora o uso de recursos, reduz as ameaças à segurança e diminui a sobrecarga de gerenciamento. Somente as variantes VMware do Bottlerocket versão v1.37.0 e superior são compatíveis com os nós híbridos do EKS. As variantes de VMware do Bottlerocket estão disponíveis para as versões v1.28 e superiores do Kubernetes. As imagens do sistema operacional para essas variantes incluem o kubelet, containerd, aws-iam-authenticator e outros pré-requisitos de software para nós híbridos do EKS. É possível configurar esses componentes usando um arquivo de [configurações](https://github.com/bottlerocket-os/bottlerocket#settings) do Bottlerocket que inclui dados do usuário codificados em base64 para os contêineres de bootstrap e administração do Bottlerocket. Configurar essas opções permite que o Bottlerocket use seu provedor de credenciais de nós híbridos para autenticar nós híbridos em seu cluster. Depois que os nós híbridos se unirem ao cluster, eles aparecerão com o status `Not Ready` no console do Amazon EKS e em ferramentas compatíveis com o Kubernetes, como o `kubectl`. Depois de concluir as etapas desta página, prossiga para [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para preparar os nós híbridos para executar aplicações. ## Pré-requisitos Antes de conectar nós híbridos ao cluster do Amazon EKS, certifique-se de ter concluído as etapas de pré-requisitos. + Você tem conectividade de rede do ambiente on-premises para a região da AWS que hospeda o cluster do Amazon EKS. Consulte [Preparar a rede para nós híbridos](hybrid-nodes-networking.md) para obter mais informações. + Você criou o perfil do IAM de nós híbridos e configurou o provedor de credenciais on-premises (ativações híbridas do AWS Systems Manager ou o AWS IAM Roles Anywhere). Consulte [Preparar as credenciais para nós híbridos](hybrid-nodes-creds.md) para obter mais informações. + Você criou o cluster do Amazon EKS habilitado para nós híbridos. Consulte [Criar um cluster do Amazon EKS com nós híbridos](hybrid-nodes-cluster-create.md) para obter mais informações. + Você associou o perfil do IAM de nós híbridos às permissões de controle de acesso por perfil (RBAC) do Kubernetes. Consulte [Preparar o acesso ao cluster para nós híbridos](hybrid-nodes-cluster-prep.md) para obter mais informações. ## Etapa 1: criar o arquivo TOML de configurações do Bottlerocket Para configurar o Bottlerocket para nós híbridos, você precisa criar um arquivo `settings.toml` com a configuração necessária. O conteúdo do arquivo TOML será diferente com base no provedor de credenciais utilizado (SSM ou IAM Roles Anywhere). Esse arquivo será passado como dados do usuário ao provisionar a instância do Bottlerocket. **nota** Os arquivos no formato TOML fornecidos abaixo representam somente as configurações mínimas necessárias para inicializar uma máquina com sistema operacional Bottlerocket na VMWare como um nó em um cluster do EKS. O Bottlerocket oferece uma ampla variedade de configurações para atender a diversos casos de uso. Portanto, para explorar outras opções de configuração além da inicialização de nós híbridos, consulte a [documentação do Bottlerocket](https://bottlerocket.dev/en). Nessa documentação, você encontrará a lista completa de todas as configurações documentadas da versão do Bottlerocket que você está usando (por exemplo, [estas](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) são as configurações disponíveis para o Bottlerocket 1.51.x). ### SSM Se você estiver usando o AWS Systems Manager como seu provedor de credenciais, crie um arquivo `settings.toml` com o seguinte conteúdo: ``` [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 ``` Substitua os espaços reservados pelos seguintes valores: + ``: o nome do cluster do Amazon EKS. + ``: o endpoint do servidor de API do seu cluster. + ``: o pacote de CA codificado em base64 do seu cluster. + ``: a região da AWS que hospeda seu cluster, por exemplo, "us-east-1". + ``: o nome do host da instância do Bottlerocket que também será configurado como o nome do nó. Esse pode ser qualquer valor exclusivo escolhido por você, mas deve seguir as convenções de nomenclatura de [objetos do Kubernetes.](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names) Além disso, o nome do host utilizado não pode ter mais de 64 caracteres. OBSERVAÇÃO: quando o provedor SSM for usado, esse nome de host e nome de nó serão substituídos pelo ID da instância gerenciada (por exemplo, ID `mi-*`) depois que a instância for registrada no SSM. + ``: o conteúdo codificado em base64 da configuração do contêiner administrativo do Bottlerocket. A ativação do contêiner administrativo permite que você se conecte à sua instância do Bottlerocket com SSH para exploração e depuração do sistema. Embora essa não seja uma configuração obrigatória, recomendamos ativá-la para facilitar a solução de problemas. Consulte a [documentação do contêiner administrativo do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obter mais informações sobre a autenticação com o contêiner administrativo. O contêiner administrativo recebe a entrada do usuário e da chave SSH no formato JSON, por exemplo, ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: o conteúdo codificado em base64 da configuração do contêiner de bootstrap do Bottlerocket. Consulte a [documentação do contêiner de bootstrap do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obter mais informações sobre sua configuração. O contêiner de bootstrap é responsável por registrar a instância como uma instância gerenciada do AWS SSM e adicioná-la como um nó Kubernetes em seu cluster do Amazon EKS. Os dados do usuário passados para o contêiner de bootstrap assumem a forma de uma invocação de comando que aceita como entrada o código de ativação híbrida do SSM e o ID que você criou anteriormente: ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### IAM Roles Anywhere Se você estiver usando o AWS IAM Roles Anywhere como seu provedor de credenciais, crie um arquivo `settings.toml` com o seguinte conteúdo: ``` [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 = "" ``` Substitua os espaços reservados pelos seguintes valores: + ``: o nome do cluster do Amazon EKS. + ``: o endpoint do servidor de API do seu cluster. + ``: o pacote de CA codificado em base64 do seu cluster. + ``: a região da AWS que hospeda seu cluster, por exemplo, "us-east-1" + ``: o nome do host da instância do Bottlerocket que também será configurado como o nome do nó. Esse pode ser qualquer valor exclusivo escolhido por você, mas deve seguir as convenções de nomenclatura de [objetos do Kubernetes.](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names) Além disso, o nome do host utilizado não pode ter mais de 64 caracteres. OBSERVAÇÃO: quando um provedor IAM-RA é usado, o nome do nó deve corresponder ao CN do certificado no host caso tenha configurado a política de confiança do perfil do IAM do Hybrid Nodes com a condição de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. + ``: o conteúdo codificado em base64 do seu arquivo de configuração da AWS. O conteúdo do arquivo deve ser o seguinte: ``` [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 ``` + ``: o conteúdo codificado em base64 da configuração do contêiner administrativo do Bottlerocket. A ativação do contêiner administrativo permite que você se conecte à sua instância do Bottlerocket com SSH para exploração e depuração do sistema. Embora essa não seja uma configuração obrigatória, recomendamos ativá-la para facilitar a solução de problemas. Consulte a [documentação do contêiner administrativo do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obter mais informações sobre a autenticação com o contêiner administrativo. O contêiner administrativo recebe a entrada do usuário e da chave SSH no formato JSON, por exemplo, ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: o conteúdo codificado em base64 da configuração do contêiner de bootstrap do Bottlerocket. Consulte a [documentação do contêiner de bootstrap do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obter mais informações sobre sua configuração. O contêiner de bootstrap é responsável por criar os arquivos de certificado de host e chave privada do certificado do IAM Roles Anywhere na instância. Eles serão consumidos pelo `aws_signing_helper` para obter as credenciais temporárias necessárias para autenticação com seu cluster do Amazon EKS. Os dados do usuário passados para o contêiner de bootstrap assumem a forma de uma invocação de comando que aceita como entrada o conteúdo do arquivo de certificado e chave privada que você criou anteriormente: ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## Etapa 2: provisionar a VM vSphere do Bottlerocket com dados do usuário Depois de construir o arquivo TOML, passe-o como dados do usuário durante a criação da VM vSphere. Lembre-se de que os dados do usuário devem ser configurados antes que a VM seja ligada pela primeira vez. Dessa forma, você precisará fornecê-los ao criar a instância ou, se desejar criar a VM com antecedência, a VM deverá estar no estado poweredOff até que você configure os dados do usuário para ela. Por exemplo, se estiver usando a CLI do `govc`: ### Criar uma VM pela primeira vez ``` 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= \ ``` ### Atualizar dados do usuário para uma VM existente ``` 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 ``` Nas seções acima, a opção `-e guestinfo.userdata.encoding="base64"` especifica que os dados do usuário são codificados em base64. A opção `-e guestinfo.userdata` passa o conteúdo codificado em base64 do arquivo `settings.toml` como dados do usuário para a instância do Bottlerocket. Substitua os espaços reservados por seus valores específicos, como o modelo OVA do Bottlerocket e detalhes da rede. ## Etapa 3: verificar a conexão do nó híbrido Depois que a instância do Bottlerocket for iniciada, ela tentará se juntar ao seu cluster do Amazon EKS. Você pode verificar a conexão no console do Amazon EKS navegando até a guia Computação do seu cluster ou executando o seguinte comando: ``` kubectl get nodes ``` **Importante** Seus nós terão o status `Not Ready`, o que é esperado e se deve à falta de uma CNI em execução nos nós híbridos. Se os nós não tiverem se unido ao cluster, consulte [Solução de problemas de nós híbridos](hybrid-nodes-troubleshooting.md). ## Etapa 4: configurar uma CNI para nós híbridos Para preparar os nós híbridos para executar aplicações, continue com as etapas em [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md). # Atualizar os nós híbridos do cluster A orientação para atualizar nós híbridos é semelhante aos nós autogerenciados do Amazon EKS que são executados no Amazon EC2. Recomendamos que você crie nós híbridos na versão de destino do Kubernetes, migre gradualmente as aplicações existentes para os nós híbridos na nova versão do Kubernetes e remova os nós híbridos na versão antiga do Kubernetes do cluster. Certifique-se de revisar as [Práticas recomendadas do Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) para obter atualizações antes de iniciar uma atualização. O Amazon EKS Hybrid Nodes tem o mesmo [suporte de versão do Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para clusters do Amazon EKS com nós na nuvem, incluindo suporte padrão e estendido. O Amazon EKS Hybrid Nodes segue a mesma [política de diferença de versão](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) para nós que o Kubernetes upstream. O Amazon EKS Hybrid Nodes não pode estar em uma versão mais recente do que o ambiente de gerenciamento do Amazon EKS, e os nós híbridos podem estar até três versões secundárias do Kubernetes mais antigas do que a versão secundária do ambiente de gerenciamento do Amazon EKS. Se você não tiver capacidade disponível para criar nós híbridos na versão de destino do Kubernetes para uma estratégia de atualização de migração por substituição, você também poderá usar a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes para atualizar a versão do Kubernetes dos nós híbridos no local. **Importante** Se você estiver atualizando os nós híbridos localmente com `nodeadm`, haverá um tempo de inatividade do nó durante o processo em que a versão mais antiga dos componentes do Kubernetes é desligada e os novos componentes da versão do Kubernetes são instalados e iniciados. ## Pré-requisitos Antes de atualizar, certifique-se de ter atendido aos pré-requisitos a seguir. + A versão de destino do Kubernetes para a atualização dos nós híbridos deve ser igual ou inferior à versão do ambiente de gerenciamento do Amazon EKS. + Se você estiver seguindo uma estratégia de atualização de migração por substituição, os novos nós híbridos que você está instalando na versão de destino do Kubernetes deverão atender aos requisitos de [Configuração de pré-requisitos para nós híbridos](hybrid-nodes-prereqs.md). Isso inclui ter endereços IP no CIDR da rede remota de nós que você passou durante a criação do cluster do Amazon EKS. + Tanto para a migração por substituição quanto para as atualizações locais, os nós híbridos devem ter acesso aos [domínios necessários](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) para extrair as novas versões das dependências dos nós híbridos. + Você deve ter o kubectl instalado na instância ou máquina local que você está usando para interagir com o endpoint da API do Kubernetes do Amazon EKS. + A versão da CNI deve ser compatível com a versão do Kubernetes para a qual você está atualizando. Caso contrário, atualize a versão da CNI antes de atualizar os nós híbridos. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para obter mais informações. ## Atualizações de migração por substituição (azul-verde) As *atualizações de migração por substituição* referem-se ao processo de criar nós híbridos em novos hosts com a versão de destino do Kubernetes, migrar tranquilamente as aplicações existentes para os novos nós híbridos na versão de destino do Kubernetes e remover os nós híbridos da versão antiga do Kubernetes do cluster. Essa estratégia também é chamada de migração azul-verde. 1. Conecte os novos hosts como nós híbridos seguindo as etapas de [Conectar nós híbridos](hybrid-nodes-join.md). Ao executar o comando `nodeadm install`, use a versão de destino do Kubernetes. 1. Habilite a comunicação entre os novos nós híbridos na versão de destino do Kubernetes e os nós híbridos na versão antiga do Kubernetes. Essa configuração permite que os pods se comuniquem entre si enquanto você está migrando a workload para os nós híbridos na versão de destino do Kubernetes. 1. Confirme se os nós híbridos na versão de destino do Kubernetes se uniram com êxito ao cluster e se têm o status Pronto. 1. Use o comando a seguir para marcar cada um dos nós que deseja remover como não programável. Isso serve para que novos pods não sejam programados ou reprogramados nos nós que você está substituindo. Para obter mais informações, consulte [isolar kubectl](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome dos nós híbridos na versão antiga do Kubernetes. ``` kubectl cordon NODE_NAME ``` Você pode identificar e isolar todos os nós de uma determinada versão do Kubernetes (neste caso, `1.28`) com o trecho de código a seguir. ``` 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 a implantação atual estiver executando menos de duas réplicas de CoreDNS nos nós híbridos, aumente a escala horizontalmente da implantação para pelo menos duas réplicas. Recomendamos executar pelo menos duas réplicas do CoreDNS em nós híbridos para resiliência durante as operações normais. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Drene cada um dos nós híbridos na versão antiga do Kubernetes que você deseja remover do cluster com o comando a seguir. Para obter mais informações sobre como drenar nós, consulte [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome dos nós híbridos na versão antiga do Kubernetes. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` Você pode identificar e drenar todos os nós de determinada versão do Kubernetes (neste caso, `1.28`) com o trecho de código a seguir. ``` 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. Você pode usar `nodeadm` para interromper e remover os artefatos dos nós híbridos do host. Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo. Por padrão, `nodeadm uninstall` não prosseguirá se houver pods restantes no nó. Para obter mais informações, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` 1. Com os artefatos dos nós híbridos interrompidos e desinstalados, remova o recurso do nó do cluster. ``` kubectl delete node node-name ``` Você pode identificar e excluir todos os nós de uma determinada versão do Kubernetes (neste caso, `1.28`) com o trecho de código a seguir. ``` 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. Dependendo da sua escolha de CNI, poderá haver artefatos restantes nos nós híbridos após a execução das etapas acima. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para obter mais informações. ## Atualizações no local O processo de atualização no local refere-se ao uso de `nodeadm upgrade` para atualizar a versão do Kubernetes para nós híbridos sem usar novos hosts físicos ou virtuais e uma estratégia de migração por substituição. O processo de `nodeadm upgrade` desliga os componentes antigos existentes do Kubernetes em execução no nó híbrido, desinstala os componentes antigos do Kubernetes existentes, instala os novos componentes do Kubernetes de destino e inicia os novos componentes do Kubernetes de destino. É altamente recomendável atualizar um nó por vez para minimizar o impacto nas aplicações em execução nos nós híbridos. A duração desse processo depende da largura de banda e da latência da rede. 1. Use o comando a seguir para marcar o nó que você está atualizando como não programável. Isso serve para que novos pods não sejam programados ou reprogramados nos nós que você está atualizando. Para obter mais informações, consulte [isolar kubectl](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome do nó híbrido que você está atualizando ``` kubectl cordon NODE_NAME ``` 1. Drene o nó que você está atualizando com o comando a seguir. Para obter mais informações sobre como drenar nós, consulte [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) na documentação do Kubernetes. Substitua `NODE_NAME` pelo nome do nó híbrido que você está atualizando. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. Execute `nodeadm upgrade` no nó híbrido que você está atualizando. Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo. O nome do nó é preservado durante a atualização para os provedores de credenciais do AWS SSM e AWS IAM Roles Anywhere. Você não pode alterar os provedores de credenciais durante o processo de atualização. Consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md) para obter os valores de configuração de `nodeConfig.yaml`. Substitua `K8S_VERSION` pela versão do Kubernetes de destino para a qual você está atualizando. ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. Para permitir que os pods sejam agendados no nó após a atualização, digite o seguinte. Substitua `NODE_NAME` pelo nome do nó. ``` kubectl uncordon NODE_NAME ``` 1. Observe o status dos nós híbridos e aguarde até que os nós sejam desligados e reiniciados na nova versão do Kubernetes com o status Pronto. ``` kubectl get nodes -o wide -w ``` # Atualizações de segurança de patches para nós híbridos Este tópico descreve o procedimento para executar patches in-loco de atualizações de segurança para pacotes e dependências específicos em execução nos nós híbridos. Como prática recomendada, sugerimos que você atualize regularmente seus nós híbridos para receber CVEs e patches de segurança. Para ver as etapas de atualização da versão do Kubernetes, consulte [Atualizar os nós híbridos do cluster](hybrid-nodes-upgrade.md). Um exemplo de software que pode precisar de patches de segurança é `containerd`. ## `Containerd` `containerd` é o runtime padrão do contêiner Kubernetes e a dependência principal dos EKS Hybrid Nodes, usado para gerenciar o ciclo de vida do contêiner, incluindo a extração de imagens e o gerenciamento da execução do contêiner. Em um nó híbrido, você pode instalar o `containerd` por meio da [CLI do nodeadm](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) ou manualmente. Dependendo do sistema operacional do seu nó, o `nodeadm` instalará o `containerd` por meio do pacote distribuído pelo sistema operacional ou do pacote Docker. Quando um CVE em `containerd` é publicado, você tem as opções a seguir de atualização para a versão corrigida do `containerd` em seus nós híbridos. ## Etapa 1: verificar se o patch foi publicado nos gerenciadores de pacotes Você pode verificar se o patch `containerd` CVE foi publicado em cada gerenciador de pacotes do sistema operacional respectivo consultando os boletins de segurança correspondentes: + [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 você usa o repositório Docker como fonte do `containerd`, pode verificar os [anúncios de segurança do Docker](https://docs.docker.com/security/security-announcements/) para identificar a disponibilidade da versão corrigida no repositório Docker. ## Etapa 2: escolher o método para instalar o patch Existem três métodos para corrigir e instalar atualizações de segurança in-loco nos nós. O método que você pode usar depende de se o patch está ou não disponível no sistema operacional do gerenciador de pacotes: 1. Instale os patches com `nodeadm upgrade` que estão publicados nos gerenciadores de pacotes. Consulte a [Etapa 2 a](#hybrid-nodes-security-nodeadm). 1. Instale os patches diretamente com os gerenciadores de pacotes. Consulte a [Etapa 2 b](#hybrid-nodes-security-package). 1. Instale patches personalizados que não estão publicados nos gerenciadores de pacotes. Observe que há considerações especiais sobre patches personalizados para `containerd`, [Etapa 2 c](#hybrid-nodes-security-manual). ## Etapa 2 a: aplicar patches com `nodeadm upgrade` Depois de confirmar que o patch `containerd` da CVE foi publicado nos repositórios do sistema operacional ou do Docker (Apt ou RPM), você pode usar o comando `nodeadm upgrade` a fim de atualizar para a versão mais recente do `containerd`. Como não se trata de uma atualização da versão do Kubernetes, você deve passar sua versão atual do Kubernetes para o comando de upgrade do `nodeadm`. ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## Etapa 2 b: aplicar patches com gerenciadores de pacotes do sistema operacional Alternativamente, você também pode atualizar por meio do respectivo gerenciador de pacotes e usá-lo para atualizar o pacote `containerd` como se 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 ``` ## Etapa 2 c: patch `Containerd` da CVE não publicado nos gerenciadores de pacotes Se a versão corrigida de `containerd` estiver disponível apenas por outros meios e não no gerenciador de pacotes, por exemplo, nas versões do GitHub, você poderá instalar o `containerd` pelo site oficial do GitHub. 1. Se a máquina já fizer parte do cluster como um nó híbrido, será necessário executar o comando `nodeadm uninstall`. 1. Instale os arquivos binários oficiais do `containerd` . Você pode usar as [etapas oficiais de instalação](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) no GitHub. 1. Execute o comando `nodeadm install` com o argumento `--containerd-source` definido como `none`, o que ignorará a instalação do `containerd` por meio do `nodeadm`. Você pode usar o valor de `none` na origem do `containerd` para qualquer sistema operacional que o nó estiver executando. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # Remoção de nós híbridos Este tópico descreve como excluir nós híbridos do cluster do Amazon EKS. Você deve excluir os nós híbridos com as ferramentas de sua escolha compatíveis com o Kubernetes, como o [kubectl](https://kubernetes.io/docs/reference/kubectl/). As cobranças por nós híbridos param quando o objeto do nó é removido do cluster do Amazon EKS. Para obter mais informações sobre preços de nós híbridos, consulte [Preços do Amazon EKS](https://aws.amazon.com/eks/pricing/). **Importante** Remover os nós interrompe as workloads em execução no nó. Antes de excluir os nós híbridos, recomendamos primeiro drenar o nó para mover os pods para outro nó ativo. Para obter mais informações sobre como drenar nós, consulte [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) na documentação do Kubernetes. Execute as etapas do kubectl abaixo na instância ou máquina local que você usa para interagir com o endpoint da API do Kubernetes do cluster do Amazon EKS. Se você estiver usando um arquivo `kubeconfig` específico, use o sinalizador `--kubeconfig`. ## Etapa 1: listar os nós ``` kubectl get nodes ``` ## Etapa 2: drenar o nó Consulte [kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) na documentação do Kubernetes para obter mais informações sobre o comando `kubectl drain`. ``` kubectl drain --ignore-daemonsets ``` ## Etapa 3: interromper e desinstalar os artefatos dos nós híbridos Você pode usar a CLI (`nodeadm`) do Amazon EKS Hybrid Nodes para interromper e remover os artefatos dos nós híbridos do host. Você deve executar `nodeadm` com um usuário que tenha privilégios root/sudo. Por padrão, `nodeadm uninstall` não prosseguirá se houver pods restantes no nó. Se você estiver usando o AWS Systems Manager (SSM) como o provedor de credenciais, o comando `nodeadm uninstall` cancelará o registro do host como uma instância gerenciada do AWS SSM. Para obter mais informações, consulte [Referência do `nodeadm` para nós híbridos](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` ## Etapa 4: excluir o nó do cluster Com os artefatos dos nós híbridos interrompidos e desinstalados, remova o recurso do nó do cluster. ``` kubectl delete node ``` ## Etapa 5: verificar se há artefatos restantes Dependendo da sua escolha de CNI, poderá haver artefatos restantes nos nós híbridos após a execução das etapas acima. Consulte [Configurar a CNI para nós híbridos](hybrid-nodes-cni.md) para obter mais informações.