Roteamento de aplicações e tráfego HTTP com Application Load Balancers

Modo de foco

Roteamento de aplicações e tráfego HTTP com Application Load Balancers - Amazon EKS

Pré-requisitos Reutilizar ALBs com grupos de entrada (Opcional) Implantar uma aplicação de exemplo

nota

Novo: o Modo Automático do Amazon EKS automatiza as tarefas de rotina para o balanceamento de carga. Para obter mais informações, consulte:

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 da aplicação?) no Guia do usuário de balanceadores de carga da aplicação e Ingress (Entrada) na documentação do Kubernetes. 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 do tráfego de rede na 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 de tráfego TCP e 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.
Tenha o AWS Load Balancer Controller implantado no 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 a seguir. 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 é 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 do AWS CloudFormation para Amazon EKS a fim de criar sua VPC após 26 de março de 2020, as sub-redes serão marcadas adequadamente quando criadas. Para obter mais informações sobre modelos de VPC do AWS CloudFormation para 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 deve usar somente 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 do AWS CloudFormation para Amazon EKS a fim de criar sua VPC após 26 de março de 2020, as sub-redes serão marcadas adequadamente quando criadas. Para obter mais informações sobre modelos de VPC do AWS CloudFormation para 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 perfil 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.
O AWS Load Balancer Controller criará ALBs e os recursos compatíveis da AWS necessários sempre que um recurso de entrada do Kubernetes for criado em um cluster com a anotação kubernetes.io/ingress.class: alb. O recurso de entrada configura o ALB para rotear o tráfego de HTTP ou HTTPS para diferentes pods no cluster. Para garantir que os seus objetos de entrada usem o AWS Load Balancer Controller, adicione a anotação a seguir à sua especificação de entrada do Kubernetes. Para obter mais informações, consulte Ingress specification (Especificação de entrada) na documentação do 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 entrada. 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 oferece suporte aos 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 o NodePort para o seu 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 de “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 seu 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 IP de destino é necessário quando os pods de destino estão em execução no Fargate ou no Amazon EKS Hybrid Nodes.
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 entrada) 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 apresentadas em cada versão, consulte as Notas de release do controlador de ALB no GitHub.

Reutilizar ALBs com grupos de entrada

Você pode compartilhar um Application Load Balancer em vários recursos de serviço usando o IngressGroups.

Para integrar uma entrada em um grupo, adicione a anotação a seguir a uma especificação do recurso de entrada 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

Especifique um grupo de entrada para uma entrada somente quando todos os usuários do Kubernetes que têm permissão RBAC para criar ou modificar recursos de entrada estiverem dentro do mesmo limite de confiança. Se você adicionar a anotação com um nome de grupo, talvez outros usuários do Kubernetes possam criar ou modificar suas entradas para pertencerem ao mesmo grupo de entrada. 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

Pelo menos uma sub-rede pública ou privada na VPC do cluster.
Tenha o AWS Load Balancer Controller implantado no 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.

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

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 os valores de exemplo pelos seus próprios.
```
eksctl create fargateprofile \
    --cluster my-cluster \
    --region region-code \
    --name alb-sample-app \
    --namespace game-2048
```
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 em um cluster criado com a família do IPv6, pule para a próxima etapa.
  - Público:
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/examples/2048/2048_full.yaml
```
  - Privado:
    
    Faça download do manifesto.
    
    curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/examples/2048/2048_full.yaml
    
    Edite o arquivo e encontre a linha que diz alb.ingress.kubernetes.io/scheme: internet-facing.
    
    Altere o endereço voltado à Internet para internal e salve o arquivo.
    
    Aplique o manifesto ao cluster.
    
    kubectl apply -f 2048_full.yaml
2. Se você estiver implantando em pods em um cluster criado com a família do 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.11.0/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 para pods voltados para a internet, altere a linha que apresenta 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

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 com êxito após alguns minutos, execute o comando a seguir para visualizar 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

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 do Linux na AWS.
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.11.0/docs/examples/2048/2048_full.yaml
```
- Se você baixou e editou o manifesto, use o comando a seguir.
```
kubectl delete -f 2048_full.yaml
```