Roteamento TCP e tráfego UDP com Network Load Balancers - Amazon EKS
Criar um balanceador de carga da rede(Opcional) Implantar uma aplicação de exemplo

Ajudar a melhorar esta página

Quer contribuir para este guia do usuário? Role até o final desta página e selecione Editar esta página no GitHub. Suas contribuições ajudarão a tornar nosso guia do usuário melhor para todos.

Roteamento TCP e tráfego UDP com Network Load Balancers

O tráfego da rede tem a carga balanceada no L4 do modelo OSI. Para balancear a carga do tráfego da aplicação no L7, você implanta um Kubernetes ingress, que provisiona um AWS Application Load Balancer. Para ter mais informações, consulte Aplicação de roteamento e tráfego HTTP com Application Load Balancers. Para saber mais sobre as diferenças entre os dois tipos de balanceamento de carga, consulte Elastic Load Balancing features (Recursos do Elastic Load Balancing) no site da AWS.

Ao criar um Service do Kubernetes do tipo LoadBalancer, o controlador do balanceador de carga de provedor da nuvem da AWS cria AWS Classic Load Balancers por padrão, mas também pode criar AWS Network Load Balancers. Este controlador só receberá correções de erros críticos no futuro. Para obter mais informações sobre como usar o balanceador de carga de provedor de nuvem da AWS, consulte Controlador do balanceador de carga de provedor de nuvem da AWS na documentação do Kubernetes. Seu uso não é abordado neste tópico.

Recomendamos que você use a versão 2.7.2 ou posterior do AWS Load Balancer Controller em vez do controlador do balanceador de carga do provedor de nuvem da AWS. O AWS Load Balancer Controller cria AWS Network Load Balancers, mas não cria AWS Classic Load Balancers. O restante deste tópico refere-se ao uso do AWS Load Balancer Controller.

Um AWS Network Load Balancer pode balancear a carga do tráfego de rede para Pods implantados em destinos de IP e de instâncias do Amazon EC2 ou para destinos IP do AWS Fargate. Para obter mais informações, consulte GitHub Load Balancer Controller (Controlador do AWS Load Balancer) no .

Pré-requisitos

Antes de balancear a carga de tráfego da rede do balanceador de carga usando o AWS Load Balancer Controller, você precisa cumprir os requisitos a seguir.

  • Tem um cluster já existente. Se você não tem um cluster, consulte Começar a usar o Amazon EKS. Se precisar atualizar a versão de um cluster existente, consulte Atualizar um cluster existente para a nova versão do Kubernetes.

  • Ter o AWS Load Balancer Controller implantado no seu cluster. Para ter mais informações, consulte Direcionar o tráfego da Internet com o AWS Load Balancer Controller. Recomendamos a versão 2.7.2 ou posterior.

  • Pelo menos uma sub-rede. Se várias sub-redes marcadas são encontradas em uma zona de disponibilidade, o controlador escolhe a primeira sub-rede por ordem lexicográfica de IDs. A sub-rede deve ter pelo menos oito endereços IP disponíveis.

  • Se você estiver usando o AWS Load Balancer Controller versão 2.1.1 ou anterior, as sub-redes deverão ser marcadas do modo a seguir. Se estiver usando a versão 2.1.2 ou superior, essa etiqueta será opcional. Talvez seja bom marcar uma sub-rede se você tiver vários clusters em execução na mesma VPC ou várias sub-redes de compartilhamento de serviços da AWS em uma VPC e quiser ter mais controle sobre onde os balanceadores de carga são provisionados por cluster. Se você especificar explicitamente os IDs de sub-redes como uma anotação em um objeto de serviço, o Kubernetes e o AWS Load Balancer Controller usarão essas sub-redes diretamente para criar o balanceador de carga. A marcação da sub-rede não é necessária se você optar por usar esse método para provisionar balanceadores de carga, e você pode ignorar os requisitos de marcação de sub-rede privada e pública a seguir. Substitua my-cluster pelo nome do cluster.

    • Chave – kubernetes.io/cluster/my-cluster

    • Valor: shared ou owned

  • As suas sub-redes públicas e privadas devem atender aos requisitos a seguir, a menos que você especifique explicitamente os IDs de sub-rede como uma anotação em um objeto de serviço ou de entrada. Se você provisionar balanceadores de carga especificando explicitamente os IDs de sub-redes como uma anotação em um objeto de serviço ou ingresso, o Kubernetes e o AWS Load Balancer Controller usam essas sub-redes diretamente para criar o balanceador de carga, e as tags a seguir não serão necessárias.

    • Sub-redes privadas – Devem ser marcadas no seguinte formato. Isso permite que o Kubernetes e o Controlador do AWS Load Balancer saibam que as sub-redes podem ser usadas para balanceadores de carga internos. Se você usar o eksctl ou um modelo do AWS AWS CloudFormation no Amazon EKS para criar a VPC após 26 de março de 2020, as sub-redes serão marcadas adequadamente quando forem criadas. Para obter mais informações sobre os modelos de VPC do AWS AWS CloudFormation no Amazon EKS, consulte Criar uma Amazon VPC para o cluster do Amazon EKS.

      • Chave – kubernetes.io/role/internal-elb

      • Value (valor): 1

    • Sub-redes públicas – Devem ser marcadas no seguinte formato. Isso permite o Kubernetes saiba que só deve usar essas sub-redes para balanceadores de carga externos, em vez de escolher uma sub-rede pública em cada zona de disponibilidade (em ordem lexicográfica por ID de sub-rede). Se você usar o eksctl ou um modelo do AWS CloudFormation no Amazon EKS para criar a VPC após 26 de março de 2020, as sub-redes serão marcadas adequadamente quando forem criadas. Para obter mais informações sobre os modelos de VPC do AWS CloudFormation no Amazon EKS, consulte Criar uma Amazon VPC para o cluster do Amazon EKS.

      • Chave – kubernetes.io/role/elb

      • Value (valor): 1

    Se tags de função de sub-rede não forem explicitamente adicionadas, o controlador de serviço do Kubernetes analisará a tabela de rotas das sub-redes da VPC do cluster para determinar se a sub-rede é privada ou pública. Recomendamos que você não confie nesse comportamento e adicione explicitamente as etiquetas de função privada ou pública. O AWS Load Balancer Controller não examina as tabelas de rotas e exige que as etiquetas privadas e públicas estejam presentes para a detecção automática ser bem-sucedida.

Considerações

  • A configuração do balanceador de carga é controlada por anotações que são adicionadas ao manifesto para o serviço. As anotações de serviço são diferentes ao usar o AWS Load Balancer Controller e o controlador do balanceador de carga do provedor da nuvem AWS. Certifique-se de revisar as anotações para o AWS Load Balancer Controller antes de implantar os serviços.

  • Ao usar o Amazon VPC CNI plugin for Kubernetes, o AWS Load Balancer Controller pode balancear a carga para destinos de IP ou de instância do Amazon EC2 e destinos de IP do Fargate. Ao usar Alternate compatible CNI plugins (Alternar plugins da CNI compatíveis), o controlador só poderá balancear a carga para destinos de instância. Para obter mais informações sobre os tipos de destino do Network Load Balancer, consulte Target type (Tipos de destino) no Guia do usuário de Network Load Balancers.

  • Se quiser adicionar etiquetas ao balanceador de carga quando ou depois que ele for criado, adicione a anotação a seguir na especificação do seu serviço. Para obter mais informações, consulte Etiquetas de recurso da AWS na documentação do AWS Load Balancer Controller.

    service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags

  • Você pode atribuir endereços IP elásticos ao Network Load Balancer adicionando a anotação a seguir. Substitua example values pelos Allocation IDs dos endereços de IP elásticos. O número de Allocation IDs deve corresponder ao número de sub-redes usadas para o balanceador de carga. Para obter mais informações, consulte a documentação do AWS Load Balancer Controller.

    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-xxxxxxxxxxxxxxxxx,eipalloc-yyyyyyyyyyyyyyyyy

  • O Amazon EKS adiciona uma regra de entrada ao grupo de segurança do nó para o tráfego de clientes e uma regra para cada sub-rede do balanceador de carga na VPC para as verificações de integridade para cada Network Load Balancer que você criar. A implantação de um serviço do tipo LoadBalancer poderá falhar se o Amazon EKS tentar criar regras que excedam a cota para o número máximo de regras permitidas para um grupo de segurança. Para obter mais informações, consulte Security groups (Grupos de segurança) em Amazon VPC quotas (Cotas da Amazon VPC) no Manual do usuário da Amazon VPC. Considere as opções a seguir para minimizar as chances de exceder o número máximo de regras para um grupo de segurança:

    • Solicite um aumento em suas regras por cota de grupo de segurança. Para obter mais informações, consulte Requesting a quota increase (Solicitar um aumento da cota) no Manual do usuário do Service Quotas.

    • Use destinos IP, em vez de destinos instância. Com destinos IP, você pode compartilhar as regras para as mesmas portas de destino. As sub-redes do balanceador de carga podem ser especificadas manualmente com uma anotação. Para obter mais informações, consulte Annotations (Anotações) no GitHub.

    • Use uma entrada em vez de um serviço do tipo LoadBalancer para enviar tráfego ao seu serviço. O AWS Application Load Balancer exige menos regras do que os Network Load Balancers. Você pode compartilhar um ALB em várias entradas. Para ter mais informações, consulte Aplicação de roteamento e tráfego HTTP com Application Load Balancers. Você não pode compartilhar um Network Load Balancer em vários serviços.

    • Implante seus clusters em várias contas.

  • Se os Pods forem executados no Windows em um cluster do Amazon EKS, um único serviço com um balanceador de carga poderá ser compatível com até 1024 Pods de backend. Cada Pod tem seu próprio endereço IP exclusivo.

  • Recomendamos que você só crie novos Network Load Balancers com o AWS Load Balancer Controller. A tentativa de substituir Network Load Balancers existentes criados pelo controlador do balanceador de carga do provedor da nuvem AWS pode resultar em vários Network Load Balancers, que poderão gerar tempo de inatividade na aplicação.

Criar um balanceador de carga da rede

Você pode criar um balanceador de carga da rede com destinos de IP ou de instância.

IP targets

Use destinos IP com Pods implantados em nós do Amazon EC2 ou Fargate. O serviço do Kubernetes deve ser criado como tipo LoadBalancer. Para obter mais informações, consulte Type LoadBalancer (Tipo LoadBalancer) na documentação do Kubernetes.

Para criar um balanceador de carga que use destinos IP, adicione a anotação a seguir a um manifesto de serviço e implante o seu serviço. O valor external para aws-load-balancer-type faz com que o AWS Load Balancer Controller, em vez do controlador do balanceador de carga do provedor da nuvem AWS, crie o Network Load Balancer. Você pode visualizar um manifesto de serviço de exemplo com as anotações.

service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
nota

Se você estiver balanceando carga para Pods do IPv6, adicione a anotação a seguir. Você só pode balancear a carga em IPv6 para destinos IP, e não para destinos de instâncias. Sem essa anotação, o balanceamento de carga ocorrerá em IPv4.

service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack

Por padrão, os Network Load Balancers são criados com o aws-load-balancer-scheme internal. Você pode iniciar Network Load Balancers em qualquer sub-rede na VPC do cluster, incluindo sub-redes que não foram especificadas quando o cluster foi criado.

O Kubernetes examina a tabela de rotas para as sub-redes a fim de identificar se elas são públicas ou privadas. As sub-redes públicas têm uma rota direta para a Internet usando um gateway da Internet, mas as sub-redes privadas não têm.

Se você quiser criar um Network Load Balancer em uma sub-rede pública para balancear a carga para nós do Amazon EC2 (o Fargate só pode ser em privadas), especifique internet-facing com a seguinte anotação:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
nota

Para fins de compatibilidade com versões anteriores, o suporte a anotações service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" ainda é oferecido. Porém, recomendamos usar as anotações anteriores para novos balanceadores de carga em vez do service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip".

Importante

Não edite as anotações depois de criar o serviço. Se precisar modificá-lo, exclua o objeto de serviço e crie-o novamente com o valor desejado para essa anotação.

Instance targets

O controlador do balanceador de carga do provedor da nuvem AWS cria Network Load Balancers com apenas destinos de instâncias. A versão 2.2.0 e versões superiores do AWS Load Balancer Controller também criam Network Load Balancers com destinos de instâncias. Recomendamos usá-lo para criar novos Network Load Balancers, em vez do controlador do balanceador de carga do provedor da nuvem AWS. Você pode usar os destinos de instância do Network Load Balancer com Pods implantados em nós do Amazon EC2, mas não do Fargate. Para balancear a carga do tráfego de rede em Pods implantados no Fargate, você deve usar destinos IP.

Para implantar um Network Load Balancer em uma sub-rede privada, a sua especificação de serviço deve ter as anotações a seguir. Você pode visualizar um manifesto de serviço de exemplo com as anotações. O valor external para aws-load-balancer-type faz com que o AWS Load Balancer Controller, em vez do controlador do balanceador de carga do provedor da nuvem AWS, crie o Network Load Balancer.

service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance"

Por padrão, os Network Load Balancers são criados com o aws-load-balancer-scheme internal. Para Network Load Balancers internos, o cluster do Amazon EKS deve ser configurado para usar pelo menos uma sub-rede privada na VPC. O Kubernetes examina a tabela de rotas das sub-redes para identificar se elas são públicas ou privadas. As sub-redes públicas têm uma rota direta para a Internet usando um gateway da Internet, mas as sub-redes privadas não têm.

Se você quiser criar um Network Load Balancer em uma sub-rede pública para balancear a carga para nós do Amazon EC2, especifique internet-facing com a seguinte anotação:

service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Importante

Não edite as anotações depois de criar o serviço. Se precisar modificá-lo, exclua o objeto de serviço e crie-o novamente com o valor desejado para essa anotação.

(Opcional) Implantar uma aplicação de exemplo

Pré-requisitos
Para implantar uma aplicação de exemplo

  1. Se estiver implantando no Fargate, certifique-se de ter uma sub-rede privada disponível em sua VPC e crie um perfil do Fargate. Se não estiver implantando no Fargate, ignore esta etapa. Você pode criar o perfil executando o comando a seguir ou no AWS Management Console usando os mesmos valores para name e namespace que estão no comando. Substitua example values pelos seus próprios valores.

    eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name nlb-sample-app \
    --namespace nlb-sample-app

  2. Implante uma aplicação de exemplo.

    1. Crie um namespace para a aplicação.

      kubectl create namespace nlb-sample-app

    2. Salve o conteúdo a seguir em seu computador, em um arquivo chamado sample-deployment.yaml.

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: nlb-sample-app
  namespace: nlb-sample-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: public.ecr.aws/nginx/nginx:1.23
          ports:
            - name: tcp
              containerPort: 80

    3. Aplique o manifesto ao cluster.

      kubectl apply -f sample-deployment.yaml

  3. Crie um serviço com um Network Load Balancer voltado para a Internet que faça o balanceamento de carga para destinos IP.

    1. Salve o conteúdo a seguir em seu computador, em um arquivo chamado sample-service.yaml. Se estiver implantando nos nós do Fargate, remova a linha service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing.

      apiVersion: v1
kind: Service
metadata:
  name: nlb-sample-service
  namespace: nlb-sample-app
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app: nginx

    2. Aplique o manifesto ao cluster.

      kubectl apply -f sample-service.yaml

  4. Verifique se o serviço foi implantado.

    kubectl get svc nlb-sample-service -n nlb-sample-app

    Veja um exemplo de saída abaixo.

    NAME            TYPE           CLUSTER-IP         EXTERNAL-IP                                                                    PORT(S)        AGE
sample-service  LoadBalancer   10.100.240.137   k8s-nlbsampl-nlbsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com  80:32400/TCP   16h
    nota

    Os valores para 10.100.240.137 e xxxxxxxxxx-xxxxxxxxxxxxxxxx serão diferentes da saída do exemplo (eles serão exclusivos do seu balanceador de carga) e us-west-2 podem ser diferentes para você, dependendo de qual Região da AWS for o seu cluster.

  5. Abra o AWS Management Console do Amazon EC2. Selecione Target Groups (Grupos de destino) em Load Balancing (Balanceamento de carga) no painel de navegação à esquerda. Em Name (Nome), selecione o nome do grupo de destino no qual o valor na coluna Load balancer (Balanceador de carga) corresponda a uma parte do nome na coluna EXTERNAL-IP do resultado na etapa anterior. Por exemplo, você selecionaria o grupo de destino chamado k8s-default-samplese-xxxxxxxxxx se o resultado fosse igual ao da saída acima. O tipo de destino é IP, conforme especificado no manifesto de serviço de exemplo.

  6. Selecione o Target group (Grupo de destino) e escolha a guia Targets (Destinos). Em Registered targets (Destinos registrados), você verá três endereços IP das três réplicas implantadas em uma etapa anterior. Aguarde até que o status de todos os destinos seja healthy (íntegro) antes de continuar. Pode levar alguns minutos até que todos os destinos fiquem healthy. Os destinos podem estar em um estado unhealthy antes de serem alterados para um estado healthy.

  7. Envie o tráfego para o serviço, substituindo xxxxxxxxxx-xxxxxxxxxxxxxxxx e us-west-2 pelo valor retornado na saída de uma etapa anterior por EXTERNAL-IP. Se você implantou em uma sub-rede privada, precisará visualizar a página em um dispositivo dentro da VPC, como um bastion host. Para obter mais informações, consulte Bastion hosts Linux na AWS.

    curl k8s-default-samplese-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.region-code.amazonaws.com

    Veja um exemplo de saída abaixo.

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

  8. Ao terminar de usar a implantação, o serviço e o namespace de exemplo, remova-os.

    kubectl delete namespace nlb-sample-app