View a markdown version of this page

Operações de gateway do Amazon EKS Hybrid Nodes - Amazon EKS
Alta disponibilidade e failoverGerenciamento da tabela de rotas da VPCMonitoramentoConsiderações sobre dimensionamentoCiclo de vida do túnel VXLANPróximas etapas

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.

Operações de gateway do Amazon EKS Hybrid Nodes

Esta página aborda as operações de rotina e de manutenção do gateway do Amazon EKS Hybrid Nodes, incluindo obtenção de alta disponibilidade, comportamento de failover, monitoramento, escalabilidade e ciclo de vida do túnel VXLAN. Para obter instruções de instalação de , consulte Comece a usar o gateway do EKS Hybrid Nodes.

Alta disponibilidade e failover

O gateway do Hybrid Nodes usa um modelo ativo e em espera com eleição de líder baseada em Leases do Kubernetes. Dois pods de gateway são executados em nós separados do EC2, uma configuração imposta por antiafinidade de pod. Ambos os pods criam uma interface VXLAN na inicialização e executam um reconciliador de nós que mantém as entradas VTEP para todos os nós híbridos. Apenas o pod líder gerencia as tabelas de rotas da VPC e a CRD CiliumVTEPConfig. O pod em espera está sempre pronto para encaminhar o tráfego em três a cinco segundos em caso de failover, pois já conta com um conjunto completo de entradas de túnel.

Sequência de failover

Quando a instância do gateway ativo falha, a seguinte sequência ocorre:

  1. O pod em espera detecta que o lease do líder expirou.

  2. O pod em espera adquire o lease e se torna o novo líder.

  3. O novo líder executa a sequência de configuração do líder:

    • Atualiza as entradas da tabela de rotas da VPC para direcionamento aos CIDRs dos pods híbridos para a ENI primária do novo líder.

    • Insere e atualiza o recurso personalizado CiliumVTEPConfig com o endereço IP do nó e o endereço MAC do protocolo VXLAN do novo líder.

  4. O fluxo de tráfego é retomado por meio do novo líder.

Pelo fato de ambos os pods manterem interfaces VXLAN e entradas VTEP ativas continuamente, o novo líder não precisa recriar a interface VXLAN nem reprogramar as entradas de túnel durante o failover. São necessárias apenas as atualizações na tabela de rotas da VPC e na CiliumVTEPConfig.

O tempo de failover previsto é de cerca de três a cinco segundos. O tráfego entre a VPC e os pods híbridos é interrompido durante o failover.

Recomendação de zona de disponibilidade

Distribua os nós de gateway em duas zonas de disponibilidade (AZ, na sigla em inglês) para que uma falha em uma AZ não afete tanto o líder quanto o nó em espera. Ao usar o Modo Automático do EKS, configure a NodeClass com seletores de sub-rede em várias AZs. Para grupos de nós gerenciados ou nós autogerenciados, escolha nós em AZs diferentes ao rotulá-los.

nota

O tráfego entre AZs envolvendo o gateway e outros recursos na VPC está sujeito às tarifas padrão da AWS para transferência de dados entre AZs.

Parâmetros de eleição de líder

Os parâmetros padrão de eleição de líder são ajustados para um failover rápido:

Parâmetro Padrão Descrição

--leader-election-lease-duration

3s

Quanto tempo um não líder espera antes de tentar adquirir o lease após o líder parar de renová-lo.

--leader-election-renew-deadline

2s

Quanto tempo o líder tenta renovar o lease antes de desistir.

--leader-election-retry-period

1s

Com que frequência os candidatos tentam novamente adquirir o lease.

A redução desses valores diminui o tempo de failover, porém aumenta o risco de falsos failovers em caso de partição de rede. Para a maioria das implantações, os valores padrão são adequados. Para obter mais informações, consulte Referência de configuração para o gateway do Amazon EKS Hybrid Nodes.

Gerenciamento da tabela de rotas da VPC

O gateway gerencia as entradas da tabela de rotas da VPC para que o tráfego destinado aos CIDRs dos pods híbridos alcance a instância ativa do gateway.

Como as rotas são gerenciadas

Ao se tornar o líder, o pod de gateway cria ou substitui as rotas em todas as tabelas de rotas configuradas na VPC. Cada rota define o CIDR de destino para um CIDR de pod híbrido e o destino para a ENI primária do líder. Se uma rota já existir e referenciar a ENI correta, o gateway ignora a atualização.

Durante o failover, o novo líder substitui as rotas existentes para que direcionem o tráfego para sua própria ENI. Este é o mecanismo que redireciona o tráfego da VPC para o novo gateway ativo.

Exemplo de entrada na tabela de rotas

Após o gateway configurar as rotas, a tabela de rotas da VPC conterá entradas semelhantes às seguintes:

Destination (Destino) Alvo Status

10.0.0.0/16

local

active

HYBRID_POD_CIDR

eni-LEADER_ENI_ID

active

Permissões do IAM

O gateway requer as seguintes ações do IAM para gerenciar tabelas de rotas:

  • ec2:DescribeRouteTables

  • ec2:CreateRoute

  • ec2:ReplaceRoute

  • ec2:DescribeInstances

Vincule essas permissões ao perfil do IAM associado ao perfil de instância dos nós do gateway, à identidade de pods ou à configuração de IRSA.

Monitoramento

Endpoints de integridade e prontidão

O gateway disponibiliza os endpoints de integridade e prontidão na porta 8088:

Endpoint Caminho Descrição

Verificação de integridade

/healthz

Retorna HTTP 200 quando o processo do gateway está íntegro. É utilizado pela liveness probe do Kubernetes.

Verificação de prontidão

/readyz

Retorna HTTP 200 quando o gateway está pronto para receber tráfego. É utilizado pela readiness probe do Kubernetes.

É possível consultar esses endpoints manualmente para fins de diagnóstico executando um contêiner temporário de depuração ou realizando um encaminhamento de portas:

kubectl port-forward -n eks-hybrid-nodes-gateway POD_NAME 8088:8088 &
curl -s http://localhost:8088/healthz
curl -s http://localhost:8088/readyz

Endpoint de métricas

O gateway disponibiliza métricas compatíveis com o Prometheus na porta 10080, no caminho /metrics. Além das métricas padrão do controller-runtime, as métricas personalizadas apresentadas a seguir estão disponíveis.

Informações sobre o gateway:

Métrica Tipo Descrição

hybrid_gateway_info

Indicador

Informações estáticas a respeito da instância do gateway. Sempre 1. Rótulos: node_ip, node_name, vxlan_interface, vpc_cidr, pod_cidr.

Nós híbridos:

Métrica Tipo Descrição

hybrid_gateway_hybrid_nodes_configured

Indicador

Quantidade atual de nós híbridos com as entradas de VTEP configuradas.

Operações de VTEP:

Métrica Tipo Descrição

hybrid_gateway_vtep_add_total

Contador

Número total de operações de adição de VTEP bem-sucedidas.

hybrid_gateway_vtep_add_errors_total

Contador

Número total de operações de adição de VTEP com falha.

hybrid_gateway_vtep_remove_total

Contador

Número total de operações de remoção de VTEP bem-sucedidas.

hybrid_gateway_vtep_remove_errors_total

Contador

Número total de operações de remoção de VTEP com falha.

Eleição de líder e tabelas de rotas:

Métrica Tipo Descrição

hybrid_gateway_leader_is_active

Indicador

1 se este pod for o líder ativo e 0 se estiver em espera.

hybrid_gateway_leader_setup_duration_seconds

Histograma

Tempo de duração das operações de configuração do líder (tabelas de rotas + CiliumVTEPConfig), em segundos.

hybrid_gateway_aws_route_table_update_total

Contador

Número total de atualizações bem-sucedidas nas tabelas de rotas da AWS.

hybrid_gateway_aws_route_table_update_errors_total

Contador

Número total de atualizações com falha nas tabelas de rotas da AWS.

hybrid_gateway_aws_route_table_update_duration_seconds

Histograma

Tempo de duração das operações de atualização da tabela de rotas da AWS, em segundos.

Estatísticas de rede (coletadas sob demanda a cada extração de dados):

Métrica Tipo Descrição

hybrid_gateway_vxlan_rx_bytes_total

Indicador

Total de bytes recebidos na interface VXLAN.

hybrid_gateway_vxlan_tx_bytes_total

Indicador

Total de bytes transmitidos na interface VXLAN.

hybrid_gateway_vxlan_rx_packets_total

Indicador

Total de pacotes recebidos na interface VXLAN.

hybrid_gateway_vxlan_tx_packets_total

Indicador

Total de pacotes transmitidos na interface VXLAN.

hybrid_gateway_vxlan_rx_dropped_total

Indicador

Total de pacotes descartados no recebimento pela interface VXLAN.

hybrid_gateway_vxlan_tx_dropped_total

Indicador

Total de pacotes descartados na transmissão pela interface VXLAN.

hybrid_gateway_vxlan_rx_errors_total

Indicador

Total de erros de recebimento ocorridos na interface VXLAN.

hybrid_gateway_vxlan_tx_errors_total

Indicador

Total de erros de transmissão ocorridos na interface VXLAN.

hybrid_gateway_vxlan_interface_up

Indicador

1 se a interface VXLAN estiver em estado UP e 0 se estiver de outra forma.

hybrid_gateway_vxlan_fdb_entries

Indicador

Quantidade atual de entradas do FDB na interface VXLAN.

hybrid_gateway_vxlan_route_count

Indicador

Quantidade atual de rotas direcionadas pela interface VXLAN.

hybrid_gateway_primary_nic_rx_bytes_total

Indicador

Total de bytes recebidos na interface de rede primária.

hybrid_gateway_primary_nic_tx_bytes_total

Indicador

Total de bytes transmitidos na interface de rede primária.

hybrid_gateway_primary_nic_rx_packets_total

Indicador

Total de pacotes recebidos na interface de rede primária.

hybrid_gateway_primary_nic_tx_packets_total

Indicador

Total de pacotes transmitidos na interface de rede primária.

hybrid_gateway_primary_nic_rx_dropped_total

Indicador

Total de pacotes descartados no recebimento pela NIC primária.

hybrid_gateway_primary_nic_tx_dropped_total

Indicador

Total de pacotes descartados na transmissão pela NIC primária.

hybrid_gateway_primary_nic_rx_errors_total

Indicador

Total de erros de recebimento na NIC primária.

hybrid_gateway_primary_nic_tx_errors_total

Indicador

Total de erros de transmissão na NIC primária.

hybrid_gateway_primary_nic_info

Indicador

Nome da NIC primária. Sempre 1. Rótulos: interface_name.

Complemento de observabilidade do CloudWatch

Você pode usar o complemento de observabilidade do Amazon CloudWatch para coletar métricas e logs do gateway. Configure o complemento para realizar a extração de métricas do namespace do gateway (eks-hybrid-nodes-gateway) na porta 10080. Para obter o formato de configuração correto, consulte a documentação do complemento cujo link está acima.

Considerações sobre dimensionamento

O gateway do Hybrid Nodes usa um modelo ativo e em espera, com eleição de líder; portanto, apenas um pod gerencia o tráfego em determinado momento. A escalabilidade horizontal do gateway (por meio do aumento do número de réplicas) pode aumentar a disponibilidade ao disponibilizar pods adicionais em espera que estão prontos para assumir a operação em caso de failover, porém, isso não melhora a performance ou o throughput, já que o tráfego não é distribuído entre as réplicas. Para otimizar a performance, escale verticalmente escolhendo um tipo de instância do EC2 com largura de banda da rede suficiente para o volume de tráfego.

Orientação sobre os tipos de instâncias

O throughput do gateway é limitado pela performance de rede da instância do EC2. Considere o seguinte ao selecionar um tipo de instância:

  • Largura de banda da rede: o gateway encaminha todo o tráfego entre a VPC e os pods híbridos. Escolha um tipo de instância cuja largura de banda da rede atenda aos seus requisitos de pico de tráfego.

  • Pacotes por segundo (PPS): o encapsulamento VXLAN adiciona uma sobrecarga por pacote. As workloads com muitos pacotes pequenos (por exemplo, microsserviços com altas taxas de solicitação) se beneficiam de tipos de instâncias com limites de PPS mais altos.

  • Número de nós híbridos: cada nó híbrido adiciona um endpoint de túnel VXLAN pelo qual o gateway encaminha o tráfego. À medida que o número de nós híbridos aumenta, o tráfego agregado por meio do gateway cresce. Selecione um tipo de instância com largura de banda da rede suficiente para lidar com o pico de tráfego entre redes do cluster.

Tipos de instâncias recomendados

Produção (dez a cem nós híbridos e tráfego moderado)

Apropriado para workloads padrão do ambiente de produção com tráfego constante entre as redes.

Tipo de instância vCPUs Memória Rede Observações

c6i.xlarge

4

8 GiB

Até 12,5 Gbps

Bom equilíbrio entre custo e performance

c6in.xlarge

4

8 GiB

Até 30 Gbps

Otimizado para rede e recomendado para produção

c7i.xlarge

4

8 GiB

Até 12,5 Gbps

Otimizado para computação de última geração

m6i.xlarge

4

16 GiB

Até 12,5 Gbps

Adequado se houver a colocalização de outras workloads em nós de gateway

Produção de alto throughput (mais de cem nós híbridos e tráfego intenso)

Para ambientes com requisitos significativos de largura de banda entre redes, como workloads com uso intensivo de dados ou muitas conexões simultâneas.

Tipo de instância vCPUs Memória Rede Observações

c6in.2xlarge

8

16 GiB

Até 40 Gbps

Recomendado para produção de alto throughput

c5n.2xlarge

8

21 GiB

Até 25 Gbps

Geração anterior otimizada para rede e com excelente custo-benefício

c6in.4xlarge

16

32 GiB

Até 50 Gbps

Throughput máximo para workloads com tráfego muito intenso

c5n.4xlarge

16

42 GiB

Até 25 Gbps

Elevado número de vCPUs para taxas extremas de pacotes

Monitore o uso da rede por meio das métricas do gateway (consulte Endpoint de métricas) e ajuste o tipo de instância conforme a necessidade.

Ciclo de vida do túnel VXLAN

O gateway mantém automaticamente os túneis VXLAN para os nós híbridos conforme eles entram ou saem do cluster.

Como os túneis são gerenciados

Um controlador de nós monitora os objetos CiliumNode no cluster. O controlador é executado em cada pod do gateway (não apenas no líder) para que tanto o líder quanto o líder em espera tenham o estado do túnel atualizado. Quando um evento do CiliumNode ocorre, o controlador verifica se o nó é um nó híbrido procurando pelo rótulo eks.amazonaws.com/compute-type: hybrid.

Quando um nó híbrido ingressa no cluster:

  1. O controlador detecta o novo objeto CiliumNode.

  2. Ele extrai o endereço IP interno do nó e o CIDR do pod usando a especificação do CiliumNode.

  3. Ele programa o seguinte na interface VXLAN:

    • Uma rota para o CIDR do pod do nó via IP do nó por meio da interface VXLAN.

    • Uma entrada ARP estática que realiza o mapeamento do IP do nó para um endereço MAC determinístico.

    • Uma entrada do FDB com instrução para o módulo VXLAN destinada ao envio de pacotes encapsulados para o IP do nó.

Quando um nó híbrido egressa no cluster:

  1. O controlador identifica a remoção do CiliumNode.

  2. Ele remove a rota, a entrada de ARP e a entrada do FDB para o determinado nó na interface VXLAN.

Esse ciclo de vida é totalmente automático. Você não precisa configurar manualmente os túneis ao adicionar ou remover nós híbridos.

Próximas etapas