Tipos de balanceadores de carga

A tabela a seguir descreve as características básicas de cada opção de balanceamento de carga.

Balanceador de carga do aplicativo para a VPC

Configure um Application Load Balancer for VPC (VPC ALB) multizona de camada 7 para servir como o ponto de entrada externo para solicitações recebidas em um app em seu cluster. Tenha em mente os seguintes pontos ao planejar a configuração do VPC ALB.

Não confunda o Application Load Balancer for VPC com os balanceadores de carga do aplicativo Ingress do Red Hat OpenShift on IBM Cloud. Os Application Load Balancers for VPC (VPC ALBs) são executados fora do seu cluster em sua VPC e são configurados pelos serviços Kubernetes LoadBalancer que você cria. Balanceadores de carga do aplicativo (ALBs) do Ingress são controladores do Ingress que são executados em nós do trabalhador em seu cluster.

• Os nomes do VPC ALB têm o formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Para ver seu ID de cluster, execute ibmcloud oc cluster get --cluster <cluster_name>. Para ver o número do usuário do serviço LoadBalancer do Kubernetes, execute oc get svc myloadbalancer -o yaml e procure o campo metadata.uid na saída. Os hífens (-) são removidos do UID do serviço Kubernetes LoadBalancer no nome do VPC ALB.

• Por padrão, ao criar um serviço de Kubernetes LoadBalancer para um app em seu cluster, um Application Load Balancer for VPC é criado em sua VPC fora do seu cluster. O VPC ALB roteia as solicitações para o seu aplicativo por meio de NodePorts privadas que são abertas automaticamente em seus nós do trabalhador.

• Se você criar um serviço LoadBalancer público Kubernetes, será possível acessar o app na Internet por meio do nome do host designado pelo ALB da VPC ao serviço LoadBalancer de Kubernetes no formato 1234abcd-<region>.lb.appdomain.cloud. Mesmo que seus nós do trabalhador estejam conectados a apenas uma sub-rede privada de VPC, o VPC ALB poderá receber e rotear solicitações públicas para o serviço que expõe o seu aplicativo. Note que não é necessário nenhum gateway público em sua sub-rede de VPC para permitir solicitações públicas para o seu VPC ALB. No entanto, se o seu app precisa acessar uma URL pública, deve-se anexar gateways públicos às sub-redes de VPC as quais os seus nós do trabalhador estão conectados.

• Se você criar um serviço ** do Kubernetes **privadoLoadBalancer, o seu app será acessível apenas para sistemas que estejam conectados às suas sub-redes privadas dentro da mesma região e VPC. Se estiver conectado à rede privada da VPC, você poderá acessar o app por meio do nome do host designado pelo ALB da VPC para o serviço LoadBalancer de Kubernetes no formato 1234abcd-<region>.lb.appdomain.cloud.

• Você pode usar um VPC ALB existente em um cluster diferente renomeando o VPC ALB.

O diagrama a seguir ilustra como um usuário acessa um aplicativo da internet por meio do VPC ALB.

1. Uma solicitação para o app usa o nome do host designado ao serviço LoadBalancer de Kubernetes pelo ALB da VPC, como 1234abcd-<region>.lb.appdomain.cloud.
2. A solicitação é encaminhada automaticamente pelo VPC ALB para uma das portas do nó no nó do trabalhador e, em seguida, para o endereço IP privado da pod do app.
3. Se instâncias de app forem implementadas em diversos nós do trabalhador no cluster, o balanceador de carga roteará as solicitações entre os pods do app em diversos nós do trabalhador. Além disso, se você tiver um cluster multizona, o VPC ALB roteará as solicitações para nós do trabalhador entre todas as sub-redes e zonas em seu cluster.

Network Load Balancer for VPC

Em clusters de VPC, configure um layer-4 Network Load Balancer for VPC (VPC NLB) em cada zona do seu cluster para servir como ponto de entrada externo para solicitações de entrada em um aplicativo.

Os VPC NLBs fornecem várias vantagens, como proporcionar maior rendimento e melhor desempenho utilizando o retorno direto do servidor (DSR). Com o DSR, o nó do trabalhador pode enviar pacotes de resposta do aplicativo diretamente para o endereço IP do cliente e ignorar o VPC NLB, diminuindo a quantidade de tráfego que o VPC NLB deve manipular. Além disso, você pode configurar o VPC NLB para incluir a preservação do endereço IP de origem em todas as solicitações de clientes, incluindo o externalTrafficPolicy: Local especificação.

• Os nomes VPC NLB padrão têm um formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Para ver seu ID de cluster, execute ibmcloud oc cluster get --cluster <cluster_name>. Para ver o número do usuário do serviço LoadBalancer do Kubernetes, execute oc get svc myloadbalancer -o yaml e procure o campo metadata.uid na saída. Os hífens (-) são removidos do UID do serviço Kubernetes LoadBalancer no nome do VPC NLB.

• Quando você cria um serviço Kubernetes LoadBalancer para um aplicativo em seu cluster e inclui a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb", um VPC NLB é criado em seu VPC fora do cluster. O VPC NLB roteia as solicitações para o seu aplicativo por meio das NodePorts privadas que são abertas automaticamente em seus nós do trabalhador.

• Se você criar um serviço público Kubernetes LoadBalancer, poderá acessar seu aplicativo da Internet por meio do endereço IP público externo atribuído pelo VPC NLB ao serviço Kubernetes LoadBalancer. Mesmo que seus nós do trabalhador estejam conectados apenas a uma sub-rede de VPC privada, o VPC NLB pode receber e rotear solicitações públicas para o serviço que expõe o seu aplicativo. Observe que nenhum gateway público é necessário em sua sub-rede de VPC para permitir solicitações públicas para o seu VPC NLB. No entanto, se o seu app precisa acessar uma URL pública, deve-se anexar gateways públicos às sub-redes de VPC as quais os seus nós do trabalhador estão conectados.

• Se você criar um serviço ** do Kubernetes **privadoLoadBalancer, o seu app será acessível apenas para sistemas que estejam conectados às suas sub-redes privadas dentro da mesma região e VPC. Se você estiver conectado à rede VPC privada, será possível acessar o app por meio do endereço IP privado externo que é designado pelo NLB de VPC ao serviço LoadBalancer do Kubernetes.

O diagrama a seguir ilustra como um usuário acessa um aplicativo da internet por meio do VPC NLB.

1. Uma solicitação ao seu aplicativo usa o endereço IP externo que é designado ao serviço Kubernetes LoadBalancer pelo VPC NLB.
2. A solicitação é encaminhada automaticamente pelo VPC NLB para uma das portas do nó no nó do trabalhador e, em seguida, para o endereço IP privado do pod do app.
3. Se as instâncias de aplicativos forem implantadas em vários nós de trabalho no cluster, o VPC NLB encaminhará as solicitações entre os pods de aplicativos em vários nós de trabalho em todas as zonas do cluster.

Limitações

Revise as configurações padrão e as limitações a seguir.

• Revise limitações conhecidas dos VPC ALBs e limitações conhecidas para os VPC NLBs.
• Os ALBs da VPC privada não aceitam todo o tráfego, apenas o tráfego RFC 1918.
• Os NLBs da VPC privada devem ser criados em uma sub-rede de VPC dedicada que deve existir na mesma VPC e mesma localização do cluster, mas a sub-rede não pode ser conectada ao cluster ou a nenhum nó do trabalhador.
• Red Hat OpenShift: Embora o Kubernetes protocolo SCTP esteja geralmente disponível na versão da comunidade Kubernetes, a criação de balanceadores de carga que usam esse protocolo não é compatível com clusters IBM Cloud Kubernetes Service.
• Um balanceador de carga do VPC é criado para cada serviço LoadBalancer do Kubernetes criado e roteia solicitações somente para o serviço LoadBalancer do Kubernetes. Em todos os clusters de VPC na VPC, podem ser criados no máximo 50 balanceadores de carga da VPC. Para obter mais informações, consulte a Documentação de cotas de VPC.
• O balanceador de carga da VPC pode rotear solicitações para um número limitado de nós de trabalho. O número máximo de nós para os quais você pode rotear solicitações depende de como você define a anotação externalTrafficPolicy.
  • Se você definir externalTrafficPolicy: Cluster na configuração do balanceador de carga:
    • O balanceador de carga da VPC roteia para os primeiros 8 nós de trabalho descobertos em cada zona. Para um cluster com nós de trabalho em três zonas, isso resulta no roteamento do balanceador de carga para um total de 24 nós de trabalho. Para um cluster de zona única, o balanceador de carga roteia para um total de 8 nós de trabalho. Você pode alterar o número de nós de trabalho por zona para os quais o balanceador de carga roteia com o service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota, mas o número total em todas as zonas não pode exceder 50. Se o cluster tiver menos de 50 nós de trabalho em todas as zonas, especifique 0 para rotear para todos os nós de trabalho em uma zona. O kube-proxy configura tabelas IP para rotear o tráfego de entrada do nó de trabalho para o pod de aplicativo em qualquer nó em que o pod de aplicativo resida.
  • Se você definir externalTrafficPolicy: Local na configuração do balanceador de carga, o balanceador de carga VPC será criado somente se houver 50 ou menos nós de trabalho no cluster. Esse limite é definido pelas limitações de cota da VPC de 50 membros de pool por pool de balanceador de carga da VPC. Para evitar essa limitação, use a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector para limitar quais nós de trabalho estão no pool do balanceador de carga. Por exemplo, você pode usar essa anotação para forçar o tráfego de entrada para um pool de trabalho específico. Se você usar essa anotação para forçar o tráfego para um pool de trabalho específico, também deverá garantir que o pod do aplicativo também seja executado no mesmo pool de trabalho.
• Ao definir o arquivo YAML de configuração para um serviço LoadBalancer do Kubernetes, as anotações e as configurações a seguir não serão suportadas:
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
  • spec.loadBalancerIP
  • spec.loadBalancerSourceRanges
  • Apenas VPC NLBs: service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
  • Apenas VPC ALBs: a configuração externalTrafficPolicy: Local é suportada, mas a configuração não preserva o IP de origem da solicitação.
• Quando você exclui um cluster de VPC, todos os balanceadores de carga de VPC não persistentes, nomeados no formato kube-<cluster_ID>-<kubernetes_lb_service_UID> e criados automaticamente por Red Hat OpenShift on IBM Cloud para os serviços Kubernetes LoadBalancer nesse cluster, também são excluídos automaticamente. No entanto, os balanceadores de carga persistentes com nomes exclusivos e os balanceadores de carga VPC que você criou manualmente em sua VPC não são excluídos.
• É possível registrar até 128 subdomínios para os nomes do host do balanceador de carga do VPC. Esse limite pode ser aumentado solicitando um caso de suporte.
• Os subdomínios que você registra para os balanceadores de carga VPC são limitados a 130 caracteres ou menos.
• Os ALBs de VPC escutam nas mesmas sub-redes de VPC em que os nós de trabalho do cluster estão alocados, a menos que o serviço de balanceador de carga Kubernetes seja criado com as anotações service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, que limitam o tráfego a nós específicos.
  • As sub-redes e zonas do VPC ALB podem ser atualizadas ou modificadas após a criação do ALB. Se você adicionar mais zonas ao cluster ou atualizar o serviço de balanceador de carga Kubernetes com as anotações service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, o VPC ALB será atualizado para escutar nas novas sub-redes.
• Os NLBs de VPC escutam apenas em uma única sub-rede de VPC em uma única zona. Eles não podem ser configurados para escutar em várias sub-redes VPC ou escutar em várias zonas. Você pode especificar a sub-rede única para um NLB escutar com as anotações service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone.
  • Os NLBs VPC encaminham o tráfego de entrada para todos os nós de trabalho do cluster, a menos que você restrinja o tráfego de entrada a nós de trabalho específicos com service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations. Para limitar o tráfego a uma zona específica, você pode usar essas anotações para especificar os nós de trabalho nessa zona.
• A desativação da alocação de NodePort do balanceador de carga não é suportada para balanceadores de carga do VPC.
• Os NLBs de VPC podem ser configurados com UDP e TCP no mesmo VPC LB, mas a porta de escuta deve ser diferente.