View a markdown version of this page

Referência de configuração para o gateway do Amazon EKS Hybrid Nodes - Amazon EKS

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.

Referência de configuração para o gateway do Amazon EKS Hybrid Nodes

Esta página apresenta a documentação de todos os parâmetros configuráveis para o gateway do Amazon EKS Hybrid Nodes. Para obter instruções de instalação de , consulte Comece a usar o gateway do EKS Hybrid Nodes. Para obter uma visão geral do gateway, consulte Gateway do Amazon EKS Hybrid Nodes.

Valores do chart do Helm

A tabela a seguir lista todos os valores presente no chart do Helm do eks-hybrid-nodes-gateway. É possível definir esses valores usando sinalizadores --set ou um arquivo values.yaml personalizado ao executar o helm install ou o helm upgrade.

Valor Tipo Padrão Obrigatório Descrição

image.repository

string

public.ecr.aws/eks/eks-hybrid-nodes-gateway

Não

Repositório de imagens de contêiner para a imagem do gateway. O padrão é o registro público do Amazon ECR.

image.tag

string

Chart appVersion

Não

Tag da imagem. O padrão é a appVersion definida no Chart.yaml.

image.pullPolicy

string

IfNotPresent

Não

Política de extração de imagem. Valores válidos: Always, IfNotPresent, Never.

replicas

integer

2

Não

Número de réplicas de pods do gateway. Duas réplicas são a configuração recomendada para a obtenção de alta disponibilidade em ambientes de produção.

nodeLabel

string

hybrid-gateway-node

Não

Chave de rótulo do nó usada para selecionar nós do gateway. Os nós devem ter esse rótulo definido como "true".

vpcCIDR

string

""

Sim

Bloco CIDR da VPC usado para a configuração do Cilium VTEP. Exemplo: : 10.0.0.0/16.

podCIDRs

string

""

Sim

Lista separada por vírgulas de CIDRs de pods usados pelo Cilium em nós híbridos. Exemplo: : 10.85.0.0/16,10.86.0.0/16.

routeTableIDs

string

""

Sim

Lista separada por vírgulas de IDs de tabelas de rotas da VPC para a programação com rotas de pods híbridos. Exemplo: rtb-0123456789abcdef0,rtb-0123456789abcdef1.

autoMode.enabled

booleano

true

Não

Habilita a integração do Modo Automático do EKS. Quando true, o chart adiciona um seletor de nó eks.amazonaws.com/compute-type: auto e usa uma estratégia de atualização contínua sem tempo de inatividade. Defina como false para grupos de nós gerenciados ou para nós autogerenciados.

Exemplos de comandos de instalação

Modo Automático do EKS (padrão):

helm install eks-hybrid-nodes-gateway oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \ --version 1.0.0 \ --namespace eks-hybrid-nodes-gateway \ --create-namespace \ --set vpcCIDR=VPC_CIDR \ --set podCIDRs=POD_CIDRS \ --set routeTableIDs=ROUTE_TABLE_IDS

Grupos de nós gerenciados ou nós autogerenciados:

helm install eks-hybrid-nodes-gateway oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \ --version 1.0.0 \ --namespace eks-hybrid-nodes-gateway \ --create-namespace \ --set autoMode.enabled=false \ --set vpcCIDR=VPC_CIDR \ --set podCIDRs=POD_CIDRS \ --set routeTableIDs=ROUTE_TABLE_IDS

Modo Automático em comparação com a configuração de um grupo de nós gerenciados

O valor autoMode.enabled do Helm controla dois comportamentos no modelo de Deployment:

Comportamento autoMode.enabled=true (padrão) autoMode.enabled=false

Seletor de nó

Adiciona eks.amazonaws.com/compute-type: auto além do rótulo do nó de gateway.

Usa somente o rótulo do nó de gateway (hybrid-gateway-node: "true").

Estratégia de atualização contínua

maxSurge: 1 e maxUnavailable: 0: garantem tempo de inatividade zero durante as atualizações ao iniciar um novo pod antes de encerrar o pod antigo.

maxSurge: 0 e maxUnavailable: 1: encerram o pod antigo antes de iniciar um pod novo, porque a capacidade do nó é provisionada previamente.

Ao usar o Modo Automático do EKS, você deve criar um NodePool e uma NodeClass antes de instalar o chart do Helm. O NodePool provisiona instâncias do EC2 com rótulos adequados, taints e configuração de verificação destinada à origem e ao destino. Para obter o YAML necessário, consulte Comece a usar o gateway do EKS Hybrid Nodes. Ao usar grupos de nós gerenciados ou nós autogerenciados, você precisará provisionar e rotular os nós manualmente antes de instalar o chart.

Para todos os destinos de implantação, Deployment usa hostNetwork: true e requer a funcionalidade NET_ADMIN. A antiafinidade de pods garante que os dois pods de gateway sejam executados em nós distintos.

Ajuste de eleição de líder

O gateway usa eleição de líder baseada em Lease do Kubernetes para manter um modelo ativo e em espera. Os parâmetros padrão são ajustados para failover rápido:

Parâmetro Padrão Descrição

--leader-election-lease-duration

3s

Tempo que um candidato não líder aguarda desde a última renovação de lease observada antes de tentar adquirir o lease. Valores menores aceleram a detecção de falhas do líder, porém aumentam o risco de failovers indevidos durante instabilidades temporárias da rede.

--leader-election-renew-deadline

2s

Tempo máximo que o líder ativo permanece tentando renovar o lease antes de ceder a liderança. Precisa ser menor do que a duração do lease.

--leader-election-retry-period

1s

Frequência com que os candidatos repetem as tentativas de aquisição ou de renovação do lease.

Com os valores padrão, o tempo estimado de failover em caso de falha do gateway ativo é de, aproximadamente, três a cinco segundos. Esse tempo inclui a detecção da expiração do lease pelo nó em espera, a aquisição do lease e a execução da sequência de configuração do líder (atualizações da tabela de rotas da VPC e configuração do Cilium VTEP).

Quando ajustar os parâmetros de eleição de líder

  • Aumente a duração do lease se você observar transições frequentes de líder causadas por latência temporária de rede entre os pods do gateway e o servidor de API do Kubernetes.

  • Diminua a duração do lease se precisar de uma detecção de failover mais rápida e a rede entre os nós do gateway e o servidor de API for confiável e de baixa latência.

  • Aumente o período de novas tentativas para reduzir a carga sobre o servidor de API decorrente da eleição de líder em clusters de grande porte.

nota

O --leader-election-renew-deadline deve ser sempre menor do que --leader-election-lease-duration. Caso o prazo de renovação ultrapasse a duração do lease, o líder poderá perder o lease antes de conseguir renová-lo.