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.
Saiba mais sobre as redes de VPC e sobre o balanceamento de carga no modo automático do EKS
Este tópico explica como configurar os recursos de balanceamento de carga e rede da Virtual Private Cloud (VPC) no Modo Automático do EKS. Embora o Modo Automático do EKS gerencie a maioria dos componentes de rede automaticamente, você ainda pode personalizar certos aspectos da configuração de rede do cluster por meio dos recursos do NodeClass e das anotações do balanceador de carga.
Quando você usa o Modo Automático do EKS, a AWS gerencia a configuração da interface de rede de contêineres (CNI) da VPC e o provisionamento de balanceador de carga para o cluster. Você pode influenciar os comportamentos de rede definindo objetos NodeClass e aplicando anotações específicas aos seus recursos de Service e Ingress, mantendo o modelo operacional automatizado fornecido pelo Modo Automático do EKS.
Funcionalidade de redes
O modo automático do EKS oferece uma nova funcionalidade de redes para gerenciar a rede de nós e de pods. É possível configurá-la criando um objeto NodeClass no Kubernetes.
As opções de configuração para o plug-in CNI da AWS VPC anterior não se aplicarão ao modo automático do EKS.
Configurar a rede com um NodeClass
O recurso NodeClass no Modo Automático do EKS possibilita a personalização de determinados aspectos dos recursos de redes. Por meio do NodeClass, você pode especificar seleções de grupos de segurança, controlar o posicionamento dos nós em sub-redes da VPC, definir políticas de SNAT, configurar políticas de rede e habilitar o registro em log de eventos de rede. Essa abordagem mantém o modelo operacional automatizado do Modo Automático do EKS e, ao mesmo tempo, fornece flexibilidade para a personalização da rede.
Você pode usar um NodeClass para:
-
Selecionar um grupo de segurança para nós
-
Controlar como os nós são posicionados nas sub-redes da VPC
-
Definir a política de SNAT do nó como
randomoudisabled -
Habilitar as políticas de rede do Kubernetes, incluindo:
-
Definir a política de rede como Negar por padrão ou Permitir por padrão
-
Habilite o registro em log de eventos de rede em um arquivo.
-
-
Isole o tráfego de pods do tráfego de nós anexando os pods a sub-redes diferentes.
Saiba como Criar um NodeClass do Amazon EKS.
Considerações
Modo Automático do EKS é compatível com:
-
Políticas de rede do EKS.
-
As opções
HostPorteHostNetworkpara pods do Kubernetes. -
Pods e nós em sub-redes públicas ou privadas.
-
Armazenamento em cache de consultas ao DNS no nó.
O Modo Automático do EKS não é compatível com:
-
Grupos de segurança por pod (SGPP).
-
Rede personalizada no
ENIConfig. Você pode colocar pods em várias sub-redes ou isolá-los exclusivamente do tráfego de nós com Seleção de sub-rede para pods. -
Configurações de IP warm, prefixo warm e ENI warm.
-
Configuração de destinos de IP mínimos.
-
Outras configurações compatíveis com a CNI de código aberto da AWS VPC.
-
Configurações de política de rede, como personalização do temporizador conntrack (o padrão é 300 s).
-
Exportação de logs de eventos de rede para o CloudWatch.
Gerenciamento de recursos de rede
O Modo Automático do EKS lida com o gerenciamento de prefixo, endereçamento IP e interface de rede monitorando os recursos do NodeClass para as configurações de rede. O serviço executa várias operações importantes automaticamente:
Delegação de prefixo
O modo automático do EKS utiliza por padrão a delegação de prefixos (prefixos /28) para a rede dos pods e mantém um grupo de recursos IP definido previamente que é escalado com base no número de pods agendados. Quando é detectada fragmentação da sub-rede do pod, o modo automático provisiona endereços IP secundários (prefixos /32). Devido a esse algoritmo de rede de pods padrão, o modo automático calcula o número máximo de pods por nó com base na quantidade de ENIs e de IPs com suporte por tipo de instância (considerando o pior cenário de fragmentação). Para obter mais informações sobre o número máximo de ENIs e de IPs com suporte por tipo de instância, consulte Máximo de endereços IP por interface de rede no Guia do usuário do EC2. As famílias de instâncias da geração mais recente (Nitro v6 e versões posteriores) geralmente têm um número maior de ENIs e de IPs com suporte por tipo de instância, e o modo automático ajusta o cálculo do número máximo de pods de acordo.
Para clusters IPv6, apenas a delegação de prefixo é utilizada, e o modo automático sempre usa um limite máximo de 110 pods por nó.
Gerenciamento do período de espera
O serviço implementa um grupo de espera para prefixos ou endereços IPv4 secundários que não estão mais em uso. Depois que o período de espera expirar, esses recursos serão liberados de volta para a VPC. No entanto, se os pods reutilizarem esses recursos durante o período de espera, eles serão restaurados do grupo de espera.
Compatibilidade com IPv6
Para clusters IPv6, o Modo Automático do EKS provisiona um prefixo IPv6 /80 por nó na interface de rede primária.
O serviço também garante o gerenciamento adequado e a coleta de resíduos de todas as interfaces de rede.
Balanceamento de carga
Você configura os AWS Elastic Load Balancers provisionados pelo Modo Automático do EKS usando anotações nos recursos de Service e Ingress.
Para ter mais informações, consulte Criar uma IngressClass para configurar um Application Load Balancer ou Usar anotações de serviço para configurar Network Load Balancers.
Considerações sobre o balanceamento de carga com o Modo Automático do EKS
-
O modo de direcionamento padrão é o modo de IP, não o modo de instância.
-
O Modo Automático do EKS é compatível apenas com o modo de grupo de segurança para Network Load Balancers.
-
A AWS não é compatível com a migração de balanceadores de carga do controlador de balanceador de carga autogerenciado da AWS para o gerenciamento pelo Modo Automático do EKS.
-
O campo
networking.ingress.ipBlockna especificaçãoTargetGroupBindingnão é compatível. -
Se os nós de processamento usarem grupos de segurança personalizados (não o padrão de nomenclatura
eks-cluster-sg-), o perfil do cluster precisará de permissões adicionais do IAM. A política padrão gerenciada pelo EKS só permite que o EKS modifique grupos de segurança denominadoseks-cluster-sg-. Sem permissão para modificar os grupos de segurança personalizados, o EKS não pode adicionar as regras de entrada necessárias que permitem que o tráfego de ALB e NLB chegue aos pods.
Considerações sobre o CoreDNS
O modo automático do EKS não usa a implantação tradicional do CoreDNS para fornecer resolução de DNS dentro do cluster. Em vez disso, os nós do modo automático empregam o CoreDNS, que é executado como um serviço do sistema diretamente em cada nó. Ao migrar um cluster tradicional para o modo automático, você pode remover a implantação do CoreDNS do cluster assim que as workloads forem movidas para os nós do modo automático.
Importante
Se você planeja manter um cluster com nós no modo automático e nós que não estejam no modo automático, deve manter a implantação do CoreDNS. Os nós que não operam no modo automático dependem dos pods do CoreDNS tradicionais para a resolução de DNS, pois não têm acesso ao serviço de DNS em nível de nó fornecido pelo modo automático.