**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. # Roteamento de aplicações e tráfego HTTP com Application Load Balancers **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: [Implantação de uma workload de amostra do balanceador de carga no modo automático do EKS](auto-elb-example.md) [Criar uma IngressClass para configurar um Application Load Balancer](auto-configure-alb.md) 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?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) (O que é um balanceador de carga da aplicação?) no *Guia do usuário de balanceadores de carga da aplicação * e [Ingress](https://kubernetes.io/docs/concepts/services-networking/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 AWS Network Load Balancer. Para obter mais informações, consulte [Roteamento de tráfego TCP e UDP com Network Load Balancers](network-load-balancing.md). Para saber mais sobre as diferenças entre os dois tipos de balanceamento de carga, consulte [Elastic Load Balancing features](https://aws.amazon.com/elasticloadbalancing/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](getting-started.md). Se precisar atualizar a versão de um cluster existente, consulte [Atualizar um cluster existente para a nova versão do Kubernetes](update-cluster.md). + Tenha o AWS Load Balancer Controller implantado no cluster. Para obter mais informações, consulte [Direcionar o tráfego da Internet com o AWS Load Balancer Controller](aws-load-balancer-controller.md). 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/` + **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/` + **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](creating-a-vpc.md). + **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](creating-a-vpc.md). + **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](https://github.com/kubernetes-sigs/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](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/spec/) (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 do Kubernetes deve especificar o tipo de `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 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](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/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](https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases) 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 obter mais informações, consulte [Direcionar o tráfego da Internet com o AWS Load Balancer Controller](aws-load-balancer-controller.md). 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. 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 [Console de gerenciamento da AWS](fargate-profile.md#create-fargate-profile) 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 ``` 1. Implante o jogo [2048](https://play2048.co/) 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.14.1/docs/examples/2048/2048_full.yaml ``` + **Privado**: 1. Faça download do manifesto. ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml ``` 1. Edite o arquivo e encontre a linha que diz `alb.ingress.kubernetes.io/scheme: internet-facing`. 1. Altere o endereço {{voltado à Internet}} para `internal` e salve o arquivo. 1. Aplique o manifesto ao cluster. ``` kubectl apply -f 2048_full.yaml ``` 1. Se você estiver implantando em pods em um cluster criado com a [família do IPv6](cni-ipv6.md), conclua as etapas a seguir. 1. Faça download do manifesto. ``` curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/examples/2048/2048_full.yaml ``` 1. 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 ``` 1. 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`. 1. Salve o arquivo. 1. Aplique o manifesto ao cluster. ``` kubectl apply -f 2048_full.yaml ``` 1. 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 * 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 ``` 1. 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](https://aws.amazon.com/quickstart/architecture/linux-bastion/). ![Aplicação de exemplo 2048](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/2048.png) 1. 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.14.1/docs/examples/2048/2048_full.yaml ``` + Se você baixou e editou o manifesto, use o comando a seguir. ``` kubectl delete -f 2048_full.yaml ```