Aplicação de roteamento e tráfego HTTP com Application Load Balancers - Amazon EKS
(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.

Aplicação de roteamento e tráfego HTTP com Application Load Balancers

Quando você cria um ingress do Kubernetes, um AWS Application Load Balancer (ALB) é provisionado e equilibra a carga de tráfego da aplicação. Para saber mais, consulte What is an Application Load Balancer? (O que é um balanceador de carga de aplicação?) no Application Load Balancers (Guia do usuário de Application Load Balancers) e Ingress (Ingresso) na documentação do Kubernetes. Os ALBs podem ser usados com Pods implantados em nós ou no AWS Fargate. Você pode implantar um ALB em sub-redes públicas ou privadas.

O tráfego de aplicações é equilibrado no L7 do modelo OSI. Para balancear a carga de tráfego de rede em L4, você implanta um service do Kubernetes do tipo LoadBalancer. Este tipo provisiona um tipo provisiona um AWS Network Load Balancer. Para ter mais informações, consulte Roteamento TCP e tráfego UDP com Network 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.

Pré-requisitos

Antes de balancear a carga de tráfego de uma aplicação específica, 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.

  • As duas sub-redes devem estar em diferentes zonas de disponibilidade. O AWS Load Balancer Controller escolhe uma sub-rede de cada zona de disponibilidade. Quando 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. Cada sub-rede deve ter pelo menos oito endereços IP disponíveis.

    Se você estiver usando vários grupos de segurança anexados ao nó de processamento, exatamente um grupo de segurança deve ser marcado como se segue. Substitua my-cluster pelo nome do cluster.

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

    • Valor: shared ou owned

  • Se você estiver usando o AWS Load Balancer Controller versão 2.1.1 ou anterior, as sub-redes deverão ser marcadas como se segue. Se estiver usando a versão 2.1.2 ou superior, essa marcação é opcional. Porém, recomendamos que você marque uma sub-rede em qualquer um dos seguintes casos. Você tiver vários clusters que estão sendo executados na mesma VPC ou tiver vários serviços da AWS que compartilham sub-redes em uma VPC. Ou, você quiser ter mais controle sobre onde os balanceadores de carga são provisionados para cada cluster. Substitua my-cluster pelo nome do cluster.

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

    • Valor: shared ou owned

  • As sub-redes públicas e privadas devem atender aos seguintes requisitos, Isso só não ocorre caso você especifique explicitamente IDs de sub-redes como uma anotação em um objeto de serviço ou entrada. Pressuponha que você provisione balanceadores de carga especificando explicitamente os IDs de sub-redes como uma anotação em um objeto de serviço ou entrada. Nessa situação, o Kubernetes e o AWS Load Balancer Controller usam as sub-redes diretamente para criar o balanceador de carga e as tags a seguir não são necessárias.

    • Sub-redes privadas – Devem ser marcadas no seguinte formato. Isso ocorre para que o Kubernetes e o AWS Load Balancer Controller saibam que as sub-redes podem ser usadas para balanceadores de carga internos. Se você usar o eksctl ou um modelo de AWS CloudFormation do 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/internal-elb

      • Value (valor): 1

    • Sub-redes públicas – Devem ser marcadas no seguinte formato. Isso ocorre para que o Kubernetes saiba que só deve usar as sub-redes especificadas para balanceadores de carga externos. Dessa forma, o Kubernetes não escolhe uma sub-rede pública em cada zona de disponibilidade (por ordem lexicográfica dos IDs de sub-rede). Se você usar o eksctl ou um modelo de AWS CloudFormation do 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 as 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. Isso ocorre para determinar se a sub-rede é privada ou pública. Recomendamos que você não confie nesse comportamento. Em vez disso, adicione explicitamente as etiquetas de função privada ou pública. O AWS Load Balancer Controller não examina tabelas de rotas. Também requer que as etiquetas privadas e públicas estejam presentes para a detecção automática ser bem-sucedida.

Considerações

  • O AWS Load Balancer Controller criará ALBs e os recursos da AWS de apoio necessários sempre que um recurso de entrada do Kubernetes for criado no cluster com a anotação kubernetes.io/ingress.class: alb. O recurso de ingresso configura o ALB para rotear o tráfego HTTP ou HTTPS para diferentes Pods no cluster. Para garantir que os seus objetos de ingresso usem o AWS Load Balancer Controller, adicione a anotação a seguir à sua especificação de ingresso do Kubernetes. Para obter mais informações, consulte Ingress specification (Especificação de ingresso) no GitHub.

    annotations:
    kubernetes.io/ingress.class: alb
    nota

    Se você estiver balanceando a carga para Pods IPv6, adicione a anotação a seguir à sua especificação de ingresso. 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.

    alb.ingress.kubernetes.io/ip-address-type: dualstack

  • O AWS Load Balancer Controller é compatível com os seguintes modos de tráfego:

    • Instance: registra nós dentro do cluster como destinos para o ALB. O tráfego que chega ao ALB é roteado para NodePort para o serviço e, depois, enviado por proxy para os Pods. Esse é o modo de tráfego padrão. Também é possível especificá-lo explicitamente com a anotação alb.ingress.kubernetes.io/target-type: instance.

      nota

      O serviço Kubernetes deve especificar o tipo NodePort ou “LoadBalancer” para usar esse modo de tráfego.

    • IP: registra Pods como destinos para o ALB. O tráfego que chega ao ALB é roteado diretamente para os Pods do serviço. É necessário especificar a anotação alb.ingress.kubernetes.io/target-type: ip para usar esse modo de tráfego. O tipo de destino IP é necessário quando os Pods de destino estão sendo executados no Fargate.

  • Para marcar ALBs criados pelo controlador, adicione a seguinte anotação ao controlador: alb.ingress.kubernetes.io/tags. Para obter uma lista de todas as anotações disponíveis compatíveis com o AWS Load Balancer Controller, consulte Ingress annotations (Anotações de ingresso) no GitHub.

  • Atualizar ou retroceder a versão do controlador de ALB pode introduzir alterações importantes para recursos que dependem dele. Para obter mais informações sobre as alterações que são introduzidas em cada versão, consulte ALB controller release notes (Notas de versão do ALB Controller) no GitHub.

Para compartilhar um balanceador de carga da aplicação entre vários recursos de serviço usando IngressGroups

Para integrar um ingresso e um grupo, adicione a anotação a seguir a uma especificação do recurso de ingresso do Kubernetes. 

alb.ingress.kubernetes.io/group.name: my-group

O nome do grupo deve:

  • Ter no máximo 63 caracteres de comprimento.

  • Consistir em letras minúsculas, números, - e .

  • Iniciar e terminar com um número ou letra.

O controlador mescla automaticamente as regras de entrada para todas as entradas no mesmo grupo de entrada. Ele os suporta com um único ALB. A maioria das anotações definidas em uma entrada só se aplica aos caminhos definidos por essa entrada. Por padrão, os recursos de entrada não pertencem a nenhum grupo de entrada.

Atenção

Risco potencial de segurança: só especifique um grupo de ingresso para um ingresso quando todos os usuários do Kubernetes com permissão RBAC para criar ou modificar os recursos de ingresso estiverem dentro da mesma barreira de confiança. Se você adicionar a anotação com um nome de grupo, talvez outros usuários do Kubernetes possam criar ou modificar os ingressos para pertencerem ao mesmo grupo de ingresso. Fazer isso pode causar comportamento indesejável, como substituir regras existentes por regras de prioridade mais alta.

Você pode adicionar um número de ordem para o seu recurso de entrada.

alb.ingress.kubernetes.io/group.order: '10'

O número pode ser de 1 a 1000. O número mais baixo para todas as entradas no mesmo grupo de entrada será avaliado primeiro. Todas as entradas sem essa anotação são avaliadas com um valor zero. As regras duplicadas com um número mais alto podem substituir as regras com um número mais baixo. Por padrão, a ordem de regra entre as entradas no mesmo grupo de entrada é determinada por ordem léxica com base no namespace e no nome.

Importante

Certifique-se de que cada entrada no mesmo grupo de entrada tenha um número de prioridade exclusivo. Não é possível ter números de ordens duplicados nas entradas.

(Opcional) Implantar uma aplicação de exemplo

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

É possível executar a aplicação de amostra em um cluster que tenha nós do Amazon EC2, Pods do Fargate ou ambos.

  1. Se não estiver implantando no Fargate, ignore esta etapa. Se estiver implantando no Fargate, crie um perfil do Fargate. 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 alb-sample-app \
    --namespace game-2048

  2. Implante o jogo 2048 como uma aplicação de exemplo para verificar se o AWS Load Balancer Controller cria um AWS ALB como resultado do objeto de entrada. Realize as etapas para o tipo de sub-rede em que está implantando.

    1. Se você estiver implantando em Pods de um cluster criado com a família IPv6, pule para a próxima etapa.

      • Public

        kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

      • Private

        1. Faça download do manifesto.

          curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

        2. Edite o arquivo e encontre a linha que diz alb.ingress.kubernetes.io/scheme: internet-facing.

        3. Altere internet-facing para internal e salve o arquivo.

        4. Aplique o manifesto ao cluster.

          kubectl apply -f 2048_full.yaml

    2. Se você estiver implantando em Pods de um cluster criado com a família IPv6, conclua as etapas a seguir.

      1. Faça download do manifesto.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

      2. Abra o arquivo em um editor e adicione a linha a seguir às anotações nas especificações de entrada.

        alb.ingress.kubernetes.io/ip-address-type: dualstack

      3. Se você estiver balanceando a carga para Pods internos, em vez de Pods que fazem interface com a Internet, altere a linha que diz alb.ingress.kubernetes.io/scheme: internet-facing para alb.ingress.kubernetes.io/scheme: internal

      4. Salve o arquivo.

      5. Aplique o manifesto ao cluster.

        kubectl apply -f 2048_full.yaml

  3. Após alguns minutos, verifique se o recurso de entrada foi criado com o comando a seguir.

    kubectl get ingress/ingress-2048 -n game-2048

    Veja um exemplo de saída abaixo.

    NAME           CLASS    HOSTS   ADDRESS                                                                   PORTS   AGE
ingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.region-code.elb.amazonaws.com   80      2m32s
    nota

    Se você criou o balanceador de carga em uma sub-rede privada, o valor de ADDRESS na saída anterior é prefaciado com internal-.

    Se a sua entrada não for criada após alguns minutos com êxito, execute o comando a seguir para exibir os logs do AWS Load Balancer Controller. Os logs podem conter mensagens de erro que podem ajudar a diagnosticar problemas na sua implantação.

    kubectl logs -f -n kube-system -l app.kubernetes.io/instance=aws-load-balancer-controller

  4. Se implantou em uma sub-rede pública, abra um navegador e acesse o URL ADDRESS do resultado do comando anterior para ver a aplicação de exemplo. Se não vir nada, atualize o navegador e tente novamente. 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.

    Aplicação de exemplo 2048

  5. Ao terminar de fazer os testes com a aplicação de exemplo, exclua-a executando um dos comandos a seguir.

    • Se você aplicou o manifesto, em vez de aplicar uma cópia que baixou, use o comando a seguir.

      kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.7.2/docs/examples/2048/2048_full.yaml

    • Se você baixou e editou o manifesto, use o comando a seguir.

      kubectl delete -f 2048_full.yaml