Selecione suas preferências de cookies

Usamos cookies essenciais e ferramentas semelhantes que são necessárias para fornecer nosso site e serviços. Usamos cookies de desempenho para coletar estatísticas anônimas, para que possamos entender como os clientes usam nosso site e fazer as devidas melhorias. Cookies essenciais não podem ser desativados, mas você pode clicar em “Personalizar” ou “Recusar” para recusar cookies de desempenho.

Se você concordar, a AWS e terceiros aprovados também usarão cookies para fornecer recursos úteis do site, lembrar suas preferências e exibir conteúdo relevante, incluindo publicidade relevante. Para aceitar ou recusar todos os cookies não essenciais, clique em “Aceitar” ou “Recusar”. Para fazer escolhas mais detalhadas, clique em “Personalizar”.

Atualizar os nós híbridos do cluster

Modo de foco
Atualizar os nós híbridos do cluster - Amazon EKS

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Escolha o link Editar esta página no GitHub, disponível no painel direito de cada página. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Escolha o link Editar esta página no GitHub, disponível no painel direito de cada página. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

A orientação para atualizar nós híbridos é semelhante aos nós autogerenciados do Amazon EKS que são executados no Amazon EC2. É recomendável criar nós híbridos na versão de destino do Kubernetes, migrar gradualmente as aplicações existentes para os nós híbridos na nova versão do Kubernetes e remover os nós híbridos na versão antiga do Kubernetes do cluster. Certifique-se de revisar as Práticas recomendadas do Amazon EKS para obter atualizações antes de iniciar uma atualização. O Amazon EKS Hybrid Nodes tem o mesmo suporte de versão do Kubernetes 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 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. 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 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 uma CNI para nós híbridos para obter mais informações.

Atualizações de migração por substituição

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.

  1. Conecte os novos hosts como nós híbridos seguindo as etapas de Conectar nós híbridos. Ao executar o comando nodeadm install, use a versão de destino do Kubernetes.

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

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

  4. Use o comando a seguir para aplicar taint em cada um dos nós que deseja remover com NoSchedule. 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 Taints and Tolerations na documentação do Kubernetes. Substitua NODE_NAME pelo nome dos nós híbridos na versão antiga do Kubernetes.

    kubectl taint nodes NODE_NAME key=value:NoSchedule

    Você pode identificar e marcar 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 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done
  5. 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. É recomendável executar pelo menos duas réplicas de CoreDNS em nós híbridos para maior resiliência durante as operações normais.

    kubectl scale deployments/coredns --replicas=2 -n kube-system
  6. 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 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 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-emptydir-data done
  7. 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 ter mais informações, consulte Referência do nodeadm para nós híbridos.

    nodeadm uninstall
  8. 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 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Deleting $node" kubectl delete node $node done
  9. 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 uma CNI para nós híbridos 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 com NoSchedule. 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 Taints and Tolerations na documentação do Kubernetes. Substitua NODE_NAME pelo nome do nó híbrido que você está atualizando

    kubectl taint nodes NODE_NAME key=value:NoSchedule
  2. 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 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
  3. 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 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
  4. 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 -w
PrivacidadeTermos do sitePreferências de cookies
© 2025, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.