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.

Configuração de pré-requisitos para nós híbridos

Para usar o Amazon EKS Hybrid Nodes, você deve ter uma conectividade privada do ambiente on-premises de/para a AWS, servidores bare metal ou máquinas virtuais com um sistema operacional compatível e ativações híbridas do AWS IAM Roles Anywhere ou do AWS Systems Manager (SSM) configuradas. Você é responsável por gerenciar esses pré-requisitos durante todo o ciclo de vida dos nós híbridos.

Conectividade de rede híbrida

A comunicação entre o ambiente de gerenciamento do Amazon EKS e os nós híbridos é roteada pela VPC e pelas sub-redes que você passa durante a criação do cluster, que se baseia no mecanismo existente no Amazon EKS do ambiente de gerenciamento para a rede de nós. Há várias opções documentadas disponíveis para você conectar o ambiente on-premises à VPC, incluindo o AWS VPN Site-to-Site, o AWS Direct Connect ou sua própria conexão da VPN. Consulte os guias de usuário do AWS VPN Site-to-Site e do AWS Direct Connect para obter mais informações sobre como usar essas soluções para a conexão de rede híbrida.

Para uma experiência ideal, recomendamos uma conectividade de rede confiável de pelo menos 100 Mbps e uma latência máxima de ida e vinda de 200 ms para a conexão dos nós híbridos com a região da AWS. Esta é uma orientação geral que engloba a maioria dos casos de uso, mas não é um requisito rigoroso. Os requisitos de largura de banda e latência podem variar dependendo do número de nós híbridos e das características da workload, como tamanho da imagem da aplicação, elasticidade da aplicação, configurações de monitoramento e registro em log e dependências da aplicação no acesso aos dados armazenados em outros serviços da AWS. Recomendamos que você teste com suas próprias aplicações e seus próprios ambientes antes da implantação na produção para validar se a configuração de rede atende aos requisitos das workloads.

Configuração de rede on-premises

Você deve habilitar o acesso à rede de entrada no ambiente de gerenciamento do Amazon EKS para o ambiente on-premises a fim de permitir que o ambiente de gerenciamento do Amazon EKS se comunique com o kubelet em execução em nós híbridos e, opcionalmente, com webhooks em execução nos nós híbridos. Além disso, você deve habilitar o acesso à rede de saída para que os nós híbridos e os componentes executados neles se comuniquem com o ambiente de gerenciamento do Amazon EKS. Você pode configurar essa comunicação para permanecer totalmente privada no AWS Direct Connect, no AWS VPN Site-to-Site ou em sua própria conexão da VPN.

Os intervalos de Encaminhamento Entre Domínios Sem Classificação (CIDR) que você usa para as redes on-premises de nós e pods devem usar intervalos de endereços IPv4 RFC-1918. O roteador on-premises deve ser configurado com rotas para os nós on-premises e, opcionalmente, pods. Consulte Configuração de rede on-premises para obter mais informações sobre os requisitos de rede on-premises, incluindo a lista completa de portas e protocolos necessários que devem ser habilitados em seu firewall e ambiente on-premises.

Configuração do cluster do EKS

Para minimizar a latência, recomendamos criar o cluster do Amazon EKS na região da AWS mais próxima do ambiente on-premises ou de borda. Você passa os CIDRs de nós e pods on-premises durante a criação do cluster do Amazon EKS por meio de dois campos de API: RemoteNodeNetwork e RemotePodNetwork. Talvez seja necessário discutir com a equipe de rede on-premises para identificar os CIDRs de nós e pods on-premises. O CIDR de nós é alocado da rede on-premises, e o CIDR de pods é alocado da interface de rede de contêineres (CNI) que você usa caso esteja utilizando uma rede de sobreposição para a CNI. O Cilium e o Calico usam redes de sobreposição por padrão.

Os CIDRs de nós e pods on-premises que você configura nos campos RemoteNodeNetwork e RemotePodNetwork são usados para configurar o ambiente de gerenciamento do Amazon EKS para rotear o tráfego por meio da VPC para o kubelet e os pods em execução nos nós híbridos. Os CIDRs de nós e pods on-premises não podem se sobrepor entre si, com o CIDR da VPC que você passa durante a criação do cluster ou com a configuração do IPv4 do serviço para o cluster do Amazon EKS.

Recomendamos usar o acesso de endpoint público ou privado para o endpoint do servidor da API do Kubernetes do Amazon EKS. Se você escolher “Público e Privado”, o endpoint do servidor da API do Kubernetes do Amazon EKS sempre resolverá para os IPs públicos dos nós híbridos em execução fora da VPC, o que pode impedir que os nós híbridos se juntem ao cluster. Quando você usa o acesso ao endpoint público, o endpoint do servidor da API do Kubernetes é resolvido para IPs públicos, e a comunicação dos nós híbridos com o ambiente de gerenciamento do Amazon EKS será roteada pela internet. Quando você escolhe o acesso privado ao endpoint, o endpoint do servidor da API do Kubernetes é resolvido para IPs privados, e a comunicação dos nós híbridos com o ambiente de gerenciamento do Amazon EKS será roteada pelo link de conectividade privada, na maioria dos casos o AWS Direct Connect ou o AWS Site-to-Site VPN.

Configuração de VPC

Você deve configurar a VPC que você passa durante a criação do cluster do Amazon EKS com rotas em sua tabela de roteamento para o nó on-premises e, opcionalmente, redes de pods como o gateway privado virtual (VGW) ou o gateway de trânsito (TGW) como destino. Um exemplo é mostrado abaixo. Substitua REMOTE_NODE_CIDR e REMOTE_POD_CIDR pelos valores da rede on-premises.

Configuração do security group

Ao criar um cluster, o Amazon EKS cria um grupo de segurança com o nome eks-cluster-sg-<cluster-name>-<uniqueID>. Você não pode alterar as regras de entrada desse grupo de segurança de clusters, mas pode restringir as regras de saída. Você deve adicionar um grupo de segurança adicional ao cluster para permitir que o kubelet e, opcionalmente, os webhooks em execução nos nós híbridos façam contato com o ambiente de gerenciamento do Amazon EKS. As regras de entrada necessárias para esse grupo de segurança adicional são mostradas abaixo. Substitua REMOTE_NODE_CIDR e REMOTE_POD_CIDR pelos valores da rede on-premises.

Infraestrutura

Você deve ter servidores bare metal ou máquinas virtuais disponíveis para uso como nós híbridos. Os nós híbridos são independentes da infraestrutura subjacente e são compatíveis com as arquiteturas x86 e ARM. O Amazon EKS Hybrid Nodes segue uma abordagem de “traga sua própria infraestrutura”, em que você é responsável por provisionar e gerenciar os servidores bare metal ou as máquinas virtuais que você usa para nós híbridos. Embora não haja um requisito mínimo rigoroso de recursos, recomendamos usar hosts com pelo menos 1 vCPU e 1 GiB de RAM para nós híbridos.

Sistema operacional

O Bottlerocket, o Amazon Linux 2023 (AL2023), o Ubuntu e o RHEL são validados continuamente para uso como o sistema operacional de nós para nós híbridos. O Bottlerocket tem suporte da AWS somente em ambientes VMware vSphere. O AL2023 não é coberto pelos planos do AWS Support quando executado fora do Amazon EC2. O AL2023 só pode ser usado em ambientes virtualizados on-premises. Consulte o Guia do usuário do Amazon Linux 2023 para obter mais informações. A AWS oferece suporte à integração de nós híbridos com os sistemas operacionais Ubuntu e RHEL, mas não oferece suporte para os sistemas operacionais em si.

Você é responsável pelo provisionamento e gerenciamento do sistema operacional. Quando você estiver testando nós híbridos pela primeira vez, é mais fácil executar a CLI (nodeadm) do Amazon EKS Hybrid Nodes em um host já provisionado. Para implantações de produção, recomendamos incluir nodeadm nas imagens golden do sistema operacional configurado para ser executado como um serviço systemd para unir automaticamente os hosts aos clusters do Amazon EKS na inicialização do host.

Provedor de credenciais do IAM on-premises

O Amazon EKS Hybrid Nodes usa credenciais temporárias do IAM provisionadas por ativações híbridas do AWS SSM ou pelo AWS IAM Roles Anywhere para se autenticar com o cluster do Amazon EKS. Você deve usar as ativações híbridas do AWS SSM ou o AWS IAM Roles Anywhere com a CLI do Amazon EKS Hybrid Nodes (nodeadm). Recomendamos usar as ativações híbridas do AWS SSM caso não tenha uma infraestrutura de chave pública (PKI) existente com uma Certificate Authority (CA) e certificados para seus ambientes on-premises. Se você já tem uma PKI e certificados on-premises, use o AWS IAM Roles Anywhere.

Semelhante ao Perfil do IAM em nós do Amazon EKS para nós em execução no Amazon EC2, você criará um perfil do IAM de nós híbridos com as permissões necessárias para unir nós híbridos aos clusters do Amazon EKS. Caso esteja usando o AWS IAM Roles Anywhere, configure uma política de confiança que permita que o AWS IAM Roles Anywhere assuma o perfil do IAM de nós híbridos, e configure seu usuário do AWS IAM Roles Anywhere com o perfil do IAM de nós híbridos como um perfil assumível. Caso esteja usando o AWS SSM, configure uma política de confiança que permita que o AWS SSM assuma o perfil do IAM de nós híbridos e crie a ativação híbrida com o perfil do IAM de nós híbridos. Confira Preparar as credenciais para nós híbridos para saber como criar o perfil do IAM de nós híbridos com as permissões necessárias.