Clássico: sobre os balanceadores de carga de rede (NLBs)

Balançadores de carga de rede podem ser criados apenas em clusters clássicos. Para balancear a carga em clusters VPC, consulte Expondo apps com balanceadores de carga para VPC.

Ao criar um cluster padrão, o Red Hat® OpenShift® on IBM Cloud® provisiona automaticamente uma sub-rede pública móvel e uma sub-rede privada móvel.

  • A sub-rede pública móvel fornece cinco endereços IP utilizáveis. Um endereço IP público móvel é usado pelo padrão ALB do Ingress público. Os 4 endereços IP públicos móveis restantes podem ser usados para expor apps únicos à Internet, criando serviços de balanceador de carga de rede pública ou NLBs.
  • A sub-rede privada portátil fornece 5 endereços IP utilizáveis. 1 endereço IP privado portátil é usado pelo ALB de entrada privado padrão. Os 4 endereços IP privados móveis restantes podem ser usados para expor apps únicos a uma rede privada, criando serviços de balanceador de carga privado ou NLBs.

Para tornar um app acessível por meio de um endereço IP público móvel e privado móvel, deve-se criar tanto um NLB público quanto um NLB privado. Endereços IP públicos e privados móveis são IPs flutuantes estáticos e não mudam quando um nó do trabalhador é removido. Se o nó de trabalho no qual o endereço IP do NLB está localizado for removido, um daemon Keepalive que monitora constantemente o IP moverá automaticamente o IP para outro nó de trabalho. É possível designar qualquer porta para seu NLB. O NLB atua como o ponto de entrada externo para solicitações recebidas para o app. Para acessar o NLB na Internet, é possível utilizar o endereço IP público do NLB e a porta designada no formato <IP_address>:<port>. Também é possível criar entradas DNS para NLBs registrando os endereços IP do NLB com subdomínios.

Quando você expõe um app com um serviço NLB, ele é disponibilizado automaticamente por meio do NodePorts do serviço também. Os NodePorts são acessíveis em cada endereço IP público e privado de cada nó do trabalhador dentro do cluster. Para bloquear o tráfego para NodePorts enquanto estiver usando um NLB, consulte Controlando o tráfego de entrada para o balanceador de carga de rede (NLB) ou os serviços NodePort.

Embora o Kubernetes protocolo SCTP esteja geralmente disponível na liberação da comunidade Kubernetes, a criação de balanceadores de carga que usam esse protocolo não é suportada em clusters IBM Cloud Kubernetes Service.

Comparação do balanceamento de carga básico e DSR nos NLBs da versão 1.0 e 2.0

Ao criar um NLB, é possível escolher um NLB da versão 1.0, que executa o balanceamento de carga básico, ou um NLB da versão 2.0, que executa o balanceamento de carga de retorno do servidor direto (DSR).

Como as versões 1.0 e 2.0 NLBs são semelhantes?
Os NLBs versão 1.0 e 2.0 são balanceadores de carga de Camada 4 que existem no espaço kernel do Linux. Ambas as versões são executadas dentro do cluster e usam os recursos do nó do trabalhador. Portanto, a capacidade disponível dos NLBs é sempre dedicada a seu próprio cluster. Além disso, ambas as versões do NLBs não finalizam a conexão. Em vez disso, eles encaminham conexões para um pod de app.
Quais são as diferenças entre as versões 1.0 e 2.0 dos NLBs?
Quando um cliente envia uma solicitação ao seu app, o NLB roteia pacotes de solicitações para o endereço IP do nó do trabalhador no qual um pod de app existe. Os NLBs da versão 1.0 usam a conversão de endereço de rede (NAT) para regravar o endereço IP de origem do pacote de solicitações para o IP do nó do trabalhador no qual um pod do balanceador de carga existe. Quando o nó do trabalhador retorna o pacote de resposta do app, usa esse IP do nó do trabalhador no qual o NLB existe. Em seguida, o NLB deve enviar o pacote de resposta para o cliente. Para evitar que o endereço IP seja reescrito, é possível ativar a preservação de IP de origem. No entanto, a preservação de IP de origem requer que os pods do balanceador de carga e os pods de app sejam executados no mesmo trabalhador para que a solicitação não tenha que ser encaminhada para outro trabalhador. Deve-se incluir afinidade de nó e tolerâncias nos pods do app. Para obter mais informações sobre o balanceamento de carga básico com NLBs da versão 1.0, consulte Componentes e arquitetura de um NLB 1.0.

Ao contrário dos NLBs da versão 1.0, os da versão 2.0 não usam o NAT ao encaminhar solicitações para os pods de app em outros trabalhadores. Quando um NLB 2.0 roteia uma solicitação do cliente, ele usa IP sobre IP (IPIP) para encapsular o pacote de solicitações original em outro pacote. Esse pacote de IPIP de encapsulamento tem um IP de origem do nó do trabalhador no qual o pod do balanceador de carga está, que permite que o pacote de solicitações original preserve o IP do cliente como seu endereço IP de origem. O nó do trabalhador então usa o retorno de retorno do servidor direto (DSR) para enviar o pacote de resposta do app para o IP do cliente. O pacote de resposta ignora o NLB e é enviado diretamente ao cliente, diminuindo a quantidade de tráfego que deve ser manipulada pelo NLB. Para obter mais informações sobre o balanceamento de carga DSR com NLBs versão 2.0, consulte Componentes e arquitetura de um NLB 2.0.

Componentes e arquitetura de um NLB 1.0

O balanceador de carga de rede TCP/UDP (NLB) 1.0 usa os Iptables, um recurso kernel do Linux para carregar solicitações de balanceamento nos pods de um app.

Fluxo de tráfego em um cluster com uma única zona

O diagrama a seguir mostra como um NLB 1.0 direciona a comunicação da Internet para um app em um cluster de zona única.

Exponha um aplicativo em um cluster de zona única usando um NLB 1.0.
Expose an app in a single-zone cluster by using an NLB 1.0

  1. Uma solicitação para seu app usa o endereço IP público de seu NLB e a porta designada no nó do trabalhador. Observe que, se você criar um subdomínio do DNS para seu NLB, os usuários poderão acessar seu app por meio do subdomínio do NLB no lugar. Um serviço do sistema DNS resolve o subdomínio para o endereço IP público móvel do NLB.

  2. O NLB recebe a solicitação e a encaminha para o endereço IP privado do pod do app por meio da rede privada. O endereço IP de origem do pacote de solicitação é mudado para o endereço IP público do nó do trabalhador no qual o pod do NLB é executado. Se diversas instâncias de app forem implementadas no cluster, o NLB roteará as solicitações entre os pods do app.

  3. Quando o app retorna um pacote de respostas, ele usa o endereço IP do nó do trabalhador no qual o NLB que encaminhou a solicitação do cliente existe. O NLB envia, então, o pacote de respostas para o cliente.

Fluxo de tráfego em um cluster com diversas zonas

O diagrama a seguir mostra como um balanceador de carga de rede (NLB) 1.0 direciona a comunicação da Internet para um app em um cluster multizona.

Use um NLB 1.0 para balancear a carga de aplicativos em um
de várias zonas*Use um NLB 1.0 para balancear a carga de aplicativos em um cluster de várias

  1. Uma solicitação para seu app usa o subdomínio do DNS para seus NLBs. Também é possível acessar o NLB em cada zona usando seu endereço IP público e porta no nó do trabalhador. Observe que, por padrão, cada NLB 1.0 é configurado em uma zona apenas. Para alcançar alta disponibilidade, deve-se implementar um NLB 1.0 em cada zona na qual haja instâncias do app.

  2. Um serviço do sistema DNS resolve o subdomínio para o endereço IP público móvel de um dos NLBs e sua porta designada no nó do trabalhador. As solicitações são manipuladas pelos NLBs em diversas zonas em um ciclo round-robin.

  3. O NLB recebe a solicitação e a encaminha para o endereço IP privado do pod do app por meio da rede privada. O endereço IP de origem do pacote de solicitação é mudado para o endereço IP público do nó do trabalhador no qual o pod do NLB é executado. Cada NLB roteia solicitações para as instâncias do app em sua própria zona e para instâncias do app em outras zonas. Além disso, se múltiplas instâncias do app forem implementadas em uma zona, o NLB roteará as solicitações entre os pods do app na zona.

  4. Quando o app retorna um pacote de respostas, ele usa o endereço IP do nó do trabalhador no qual o NLB que encaminhou a solicitação do cliente existe. O NLB envia, então, o pacote de respostas para o cliente.

Componentes e arquitetura de um NLB 2.0

O NLB 2.0 é um balanceador de carga de Camada 4 que usa o IP Virtual Server (IPVS) do kernel do Linux. O NLB 2.0 suporta TCP e UDP, é executado na frente de diversos nós do trabalhador e usa o tunelamento IP sobre IP (IPIP) para distribuir o tráfego que chega a um único endereço IP do NLB em todos esses nós do trabalhador.

Fluxo de tráfego em um cluster com uma única zona

O diagrama a seguir mostra como um NLB 2.0 direciona a comunicação da Internet para um app em um cluster de zona única.

Exponha um aplicativo em Red Hat OpenShift on IBM Cloud usando uma versão 2.0
um aplicativo em Red Hat OpenShift on IBM Cloud usando uma versão 2.0

  1. Uma solicitação do cliente para seu app usa o endereço IP público de seu NLB e a porta designada no nó do trabalhador. Neste exemplo, o NLB tem um endereço IP virtual de 169.61.23.130 e é executado no nó do trabalhador que tem o endereço IP privado de 10.73.13.25. Observe que, se você criar um subdomínio do DNS para seu NLB, os usuários poderão acessar seu app por meio do subdomínio do NLB no lugar. Um serviço do sistema DNS resolve o subdomínio para o endereço IP público móvel do NLB.

  2. O NLB encapsula o pacote de solicitações do cliente (rotulado como "CR" na imagem) dentro de um pacote IPIP (rotulado como "IPIP"). O pacote de solicitação do cliente retém o IP do cliente como seu endereço IP de origem. O pacote de encapsulamento IPIP usa o nó do trabalhador 10.73.14.25 IP como seu endereço IP de origem.

  3. O NLB roteia o pacote IPIP para um trabalhador no qual um pod do app está e que tem o endereço IP privado 10.73.13.26. Se diversas instâncias de app forem implementadas no cluster, o NLB roteará as solicitações entre os trabalhadores nos quais os pods do app estão implementados.

  4. O trabalhador 10.73.14.26 descompacta o pacote de encapsulamento do IPIP e, em seguida, descompacta o pacote de solicitações do cliente. O pacote de solicitações do cliente é encaminhado para o pod de app nesse nó do trabalhador.

  5. O trabalhador 10.73.14.26 usa o endereço IP de origem do pacote de solicitações original, o IP do cliente, para retornar o pacote de resposta do pod do app diretamente para o cliente.

Fluxo de tráfego em um cluster com diversas zonas

O diagrama a seguir mostra como os NLBs da versão 2.0 direcionam o tráfego da Internet em cada zona para um app em um cluster multizona.

Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0
Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0

  1. Uma solicitação para seu app usa o subdomínio do DNS para seus NLBs. Também é possível acessar o NLB em cada zona usando seu endereço IP público e porta no nó do trabalhador. Observe que, por padrão, cada NLB 2.0 é configurado em uma zona apenas. Para atingir a alta disponibilidade, deve-se implementar um NLB 2.0 em cada zona que tiver instâncias de app.

  2. Um serviço do sistema DNS resolve o subdomínio para o endereço IP público móvel de um dos NLBs e sua porta designada no nó do trabalhador. Neste exemplo, o NLB tem um endereço IP virtual de 169.61.23.130 e é executado no nó do trabalhador que tem o endereço IP privado de 10.73.13.25. As solicitações são manipuladas pelos NLBs em diversas zonas em um ciclo round-robin.

  3. O NLB encapsula o pacote de solicitações do cliente (rotulado como "CR" na imagem) dentro de um pacote IPIP (rotulado como "IPIP"). O pacote de solicitação do cliente retém o IP do cliente como seu endereço IP de origem. O pacote de encapsulamento do IPIP usa o IP 10.73.14.25 IP como seu endereço IP de origem.

  4. O NLB roteia o pacote IPIP para um trabalhador no qual um pod do app está e que tem o endereço IP privado 10.73.13.26. Observe que cada NLB roteia solicitações para as instâncias do app em sua própria zona e para instâncias do app em outras zonas. Além disso, se múltiplas instâncias do app forem implementadas em uma zona, o NLB roteará as solicitações entre os pods do app na zona.

  5. O trabalhador 10.73.14.26 descompacta o pacote de encapsulamento do IPIP e, em seguida, descompacta o pacote de solicitações do cliente. O pacote de solicitações do cliente é encaminhado para o pod de app nesse nó do trabalhador.

  6. O trabalhador 10.73.14.26 usa o endereço IP de origem do pacote de solicitações original, o IP do cliente, para retornar o pacote de resposta do pod do app diretamente para o cliente.