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 do ambiente on-premises de/para a AWS

• Infraestrutura na forma de máquinas físicas ou virtuais

• Sistema operacional compatível com nós híbridos

• Provedor de credenciais do IAM on-premises configurado

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, a AWS recomenda uma conectividade de rede confiável de pelo menos 100 Mbps e uma latência máxima de ida e volta de 200 ms para a conexão dos nós híbridos com a região da AWS. 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. Para obter uma lista completa das portas e protocolos necessários que você deve habilitar no firewall e no ambiente on-premises, consulte Preparar a rede para nós híbridos.

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 RFC1918. Ao criar o cluster do Amazon EKS habilitado para nós híbridos, você passa seus CIDRs de nós on-premises e, opcionalmente, de pods para permitir a comunicação do ambiente de gerenciamento do Amazon EKS com os nós híbridos e os recursos executados neles. O roteador on-premises deve ser configurado com rotas para os nós on-premises e, opcionalmente, pods. Você pode usar o Protocolo de Gateway da Borda (BGP) ou as configurações estáticas para anunciar IPs de pods para o roteador.

Configuração do cluster do EKS

Para minimizar a latência, é recomendável 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.

Os CIDRs de nós e pods on-premises 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. O CIDR de pods é opcional. Você deve configurar o CIDR de pods caso a CNI não use a conversão de endereços de rede (NAT) ou o mascaramento para endereços IP de pods quando o tráfego de pods sair dos hosts on-premises. Além disso, você deverá configurar o CIDR de pods se estiver executando webhooks do Kubernetes em nós híbridos. Por exemplo, o AWS Distro para OpenTelemetry (ADOT) usa webhooks.

É recomendável usar o acesso ao 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. Você pode usar o acesso ao endpoint público ou privado para o endpoint do servidor da API do Kubernetes do Amazon EKS. Você não pode escolher “Público e privado”. 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.

Destino	Alvo	Descrição
10,226.0.0/16	local	O tráfego local para as rotas da VPC dentro da VPC
REMOTE_NODE_CIDR	tgw-abcdef123456	CIDR de nós on-premises, rotear tráfego para o TGW
REMODE_POD_CIDR	tgw-abcdef123456	CIDR de pods on-premises, rotear tráfego para o TGW

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.

Name	ID da regra do grupo de segurança	Versão de IP	Tipo	Protocolo	Intervalo de portas	Origem
Entrada de nós on-premises	sgr-abcdef123456	IPv4	HTTPS	TCP	443	REMOTE_NODE_CIDR
Entrada de pods on-premises	sgr-abcdef654321	IPv4	HTTPS	TCP	443	REMOTE_POD_CIDR

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 estrito de recursos, é recomendável usar hosts com pelo menos 1 vCPU e 1 GiB de RAM para nós híbridos.

Sistema operacional

O Amazon Linux 2023 (AL2023), o Ubuntu e o RHEL são validados continuamente para uso como o sistema operacional de nós híbridos. A AWS oferece suporte à integração de nós híbridos com esses sistemas operacionais, mas não fornece suporte para os sistemas operacionais em si. 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.

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, é recomendável incluir o nodeadm nas imagens áureas 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). É recomendável usar as ativações híbridas do AWS SSM caso não tenha uma infraestrutura de chave pública (PKI) existente com uma autoridade de certificação (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.