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
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.
-
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. -
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.
-
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.
-
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 Tolerationsna 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:NoScheduleVocê 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
-
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
-
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-dataVocê 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
-
Você pode usar
nodeadm
para interromper e remover os artefatos dos nós híbridos do host. Você deve executarnodeadm
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
-
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
-
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.
-
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 Tolerationsna documentação do Kubernetes. Substitua NODE_NAME
pelo nome do nó híbrido que você está atualizandokubectl taint nodes NODE_NAME key=value:NoSchedule
-
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
-
Execute
nodeadm upgrade
no nó híbrido que você está atualizando. Você deve executarnodeadm
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 denodeConfig.yaml
. SubstituaK8S_VERSION
pela versão do Kubernetes de destino para a qual você está atualizando.nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml
-
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