Configurando o MetalLB

MetalLB é uma implementação de balanceador de carga para clusters de Kubernetes bare metal, usando protocolos de roteamento padrão. Para obter mais informações, consulte Sobre MetalLB e Operador MetalLB na documentação Red Hat OpenShift.

Para instalar e configurar MetalLB, siga as instruções em Instalando o MetalLB Operator na documentação Red Hat OpenShift. Antes de começar, certifique-se de que você tenha uma sub-rede dedicada (IPAddressPool) para o IP externo dos serviços LoadBalancer. Verifique se os endereços IP incluídos no IPAddressPool não estão reservados ou usados para outros propósitos, caso contrário, a função de equilíbrio de carga poderá falhar.

Expondo apps com rotas do Red Hat OpenShift

Exponha rapidamente os serviços em seu cluster no endereço IP externo do controlador de ingresso do Red Hat OpenShift usando uma rota.

Uma rota do Red Hat OpenShift expõe um serviço como um nome de host no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud. Um controlador de ingresso é implementado por padrão em seu cluster, que possibilita que as rotas sejam usadas por clientes externos. O controlador de ingresso utiliza o seletor de serviço para encontrar o serviço e os terminais que apoiam o serviço. É possível configurar o seletor de serviço para direcionar o tráfego por meio de uma rota para diversos serviços. Também é possível criar rotas não seguras ou seguras usando o certificado TLS que é atribuído pelo controlador de ingresso para o seu nome de host. Observe que o controlador de ingresso suporta apenas os protocolos HTTP e HTTPS.

Antes de iniciar com rotas, revise as considerações a seguir.

Conectividade de rede do host

Se os hosts para o seu cluster tiverem conectividade de rede pública, seu cluster será criado com um controlador de ingresso público por padrão. É possível usar este controlador de ingresso para criar rotas públicas para o seu app. Se os hosts para o seu cluster tiverem conectividade de rede privada apenas, seu cluster será criado com um controlador de ingresso público por padrão. É possível usar este controlador de ingresso para criar rotas privadas para o seu app que são acessíveis apenas de dentro da rede privada de seus hosts. Para configurar rotas públicas em clusters que possuem conectividade de rede privada apenas, primeiro configure seu próprio balanceador de carga de terceiro que tem conectividade de rede pública na frente do seu controlador de ingresso privado antes de concluir as etapas a seguir.

Verificações de funcionamento

O gerenciamento de registro de DNS é fornecido por padrão para o controlador de ingresso do seu cluster. Por exemplo, se você remover um host que foi atribuído ao seu cluster por meio de sua localização e substituí-lo por um host diferente, a IBM atualizará os endereços IP do host no registro DNS do controlador de ingresso para você. Note que enquanto o registro de DNS para rotas é fornecido para você, nenhum serviço do balanceador de carga é implementado em frente ao controlador de ingresso em seu cluster. Para verificar o funcionamento dos endereços IP dos hosts que estão registrados nos registros de DNS do controlador de ingresso, é possível configurar seu próprio balanceador de carga de terceiro na frente do seu controlador de ingresso antes de concluir as etapas a seguir.

Para criar rotas para seus apps:

1. Crie um serviço ClusterIP do Kubernetes para a implementação do seu app. O serviço fornece um endereço IP interno para o app ao qual o controlador de ingresso pode enviar tráfego.

   oc expose deploy <app_deployment_name> --name my-app-svc
   

2. Configure um domínio para o seu app.

   • Domínio fornecido pela IBM: se você não precisar usar um domínio customizado, um nome de host de rota será gerado para você no formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud. Continue com a próxima etapa.
   • Domínio customizado: trabalhe com o seu provedor DNS para criar um domínio customizado. Note que se você previamente configurar um balanceador de carga de terceiro na frente do seu controlador de ingresso, trabalhe com o seu provedor DNS para criar um domínio customizado para o balanceador de carga em vez disso.

3. Obtenha os endereços IP para o serviço de controlador de ingresso na coluna IP EXTERNO.

   oc get svc router-external-default -n openshift-ingress
   

4. Crie um domínio customizado com seu provedor DNS. Se você deseja usar o mesmo subdomínio para diversos serviços em seu cluster, você pode registrar um subdomínio curinga, como *.example.com.

5. Mapeie seu domínio customizado para os endereços IP do controlador de ingresso, incluindo os endereços IP como registros A.

6. Configure uma rota que se baseie no tipo de finalização TLS requerida por seu app. Se você não tiver um domínio personalizado, não inclua a opção --hostname para que um nome de host de rota seja gerado automaticamente para você. Se você tiver registrado um subdomínio curinga, especifique um subdomínio exclusivo em cada rota que for criada. Por exemplo, é possível especificar --hostname svc1.example.com nessa rota e --hostname svc2.example.com em outra rota.

   • Simples:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Passagem:
   ```sh {: pre}
       oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
       ```
       É necessário manipular conexões HTTP/2? Depois de criar a rota, execute `oc edit route <app_service_name>` e mude o valor de `targetPort` da rota para `https`. É possível testar a rota executando `curl -I --http2 https://<route> --insecure`.
       {: tip}
   
   * Dica: Se você usar um domínio personalizado, inclua as opções `--hostname`, `--cert` e `--key` e, opcionalmente, a opção `--ca-cert`. Para obter mais informações sobre os requisitos de certificação do serviço “ TLS ”, consulte a [documentação sobre a rota de borda do serviço “ Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external} ”.
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Re-criptografar: Se você usar um domínio personalizado, inclua as opções `--hostname`, `--cert` e `--key` e, opcionalmente, a opção `--ca-cert`. Para obter mais informações sobre os requisitos de certificado do serviço “ TLS ”, consulte a [documentação sobre a rota de recodificação do serviço “ Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external} ”.
   ```sh {: pre}
       oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   

7. Verifique se a rota para o seu serviço de app é criada.

   oc get routes
   

8. Opcional: Personalize as regras de roteamento padrão com configurações opcionais. Por exemplo, você pode usar anotações HAProxy específicas para cada rota.

Configurando um balanceador de carga de terceiro na frente do controlador de ingresso do Red Hat OpenShift

Para verificar o integridade dos endereços IP dos hosts registrados nos registros DNS do controlador Ingress, você pode configurar seu próprio balanceador de carga de terceiros na frente dos endereços IP dos hosts designados como nós de trabalho do seu cluster.

Por exemplo, se você remover um host que foi atribuído ao seu cluster por meio de sua localização e substituí-lo por um host diferente, a IBM atualizará os endereços IP do host no registro DNS do controlador de ingresso para você. Mas se você desligar um host, como por meio do gerenciamento de infraestrutura do seu provedor de nuvem, o endereço IP do host não será removido dos registros de DNS do seu controlador de ingresso e pode fazer com que uma chamada falhe se o registro de DNS for resolvido para aquele endereço IP do host. Ao configurar um balanceador de carga em frente ao seu controlador de ingresso, é possível garantir que os endereços IP do host sejam regularmente verificados, como para assegurar alta disponibilidade para cargas de trabalho em nível de produção.

Depois de criar um balanceador de carga na frente do seu controlador de ingresso, é possível usar o controlador de ingresso para criar rotas para o seu app. Quando uma solicitação é enviada para a rota para o seu app, a solicitação é recebida pela primeira vez pelo seu balanceador de carga antes de ser encaminhada para o seu controlador de ingresso que, então, encaminha a solicitação para o seu app.

1. Liste os detalhes do controlador de ingresso padrão para o seu cluster. Na coluna IP EXTERNO da saída, obtenha os endereços IP do nó do trabalhador que estão registrados para o controlador de ingresso do seu cluster. Na coluna PORTA(S) da saída, dependendo se você deseja criar um balanceador de carga público ou privado, obtenha a porta do nó que o serviço de controlador de ingresso expõe atualmente para tráfego de rede pública ou privada.

   oc get svc router-external-default -n openshift-ingress
   

   Na saída de exemplo a seguir, a porta de nó 30783 é exposta para o tráfego público (80).

   NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP                            PORT(S)                      AGE
   router-external-default   LoadBalancer   172.21.84.172   169.xx.xxx.xxx, 169.xx.xxx.xxx         80:30783/TCP,443:30413/TCP   24h
   

2. Usando esses endereços IP e a porta de nó, crie um balanceador de carga de camada 4 que esteja conectado à rede privada dos seus hosts. Por exemplo, é possível implementar um balanceador de carga do provedor de nuvem de seus hosts ou um balanceador de carga F5 em sua rede no local. Para criar rotas públicas, o balanceador de carga deve ter a conectividade de rede pública e deve poder encaminhar o tráfego TCP e UDP para a porta do tráfego público que você localizou na etapa anterior. Para criar rotas privadas, o balanceador de carga deve poder encaminhar o tráfego TCP e UDP para a porta do tráfego privado que você localizou na etapa anterior.

3. Obtenha o Nome do host para o seu cluster. Este subdomínio no formato <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud é registrado com o controlador de ingresso do seu cluster.

   ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
   

4. Inclua os endereços IP públicos do seu balanceador de carga no subdomínio do seu cluster. Repita este comando para todos os endereços IP públicos que você deseja incluir.

   ibmcloud oc nlb-dns add --ip <public_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>
   

5. Remova os endereços IP do nó do trabalhador do subdomínio do seu cluster. Repita este comando para todos os endereços IP que você recuperou anteriormente.

   ibmcloud oc nlb-dns rm classic --ip <private_IP> --cluster <cluster_name_or_ID> --nlb-host <hostname>
   

6. Verifique se os endereços IP públicos para o seu balanceador de carga agora estão registrados com o subdomínio do seu cluster.

   ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
   

7. Continue com as etapas em Expondo apps com rotas do Red Hat OpenShift para criar rotas para seus apps.

Se você configurar um balanceador de carga externo ou um VIP para se registrar no subdomínio, em vez de usar o registro padrão, esse balanceador de carga precisa de acesso de entrada aos hosts do cluster, e os hosts do cluster precisam de acesso de saída ao balanceador de carga.

Expondo apps com NodePorts

Se você não puder usar o controlador de ingresso do Red Hat OpenShift para expor um app, como se você deve expor um app TCP ou UDP, será possível criar um NodePort para o seu app.

1. Crie um NodePort para o seu app. Um NodePort no intervalo de 30000 - 32767 e um endereço IP de cluster interno são designados ao seu app.

   oc expose deployment <deployment_name> --type=NodePort --name=<nodeport_svc_name>
   

2. Obtenha o NodePort que foi designado ao seu app.

   oc describe svc <nodeport_svc_name>
   

3. Obtenha o Nome do host para o seu cluster no formato <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud.

   ibmcloud oc nlb-dns ls --cluster <cluster_name_or_ID>
   

4. Acesse o seu app usando o subdomínio do seu cluster e o NodePort no formato <cluster_name>-<random_hash>-0000.upi.containers.appdomain.cloud:<nodeport>. Observe que se seus hosts tiverem a conectividade de rede privada apenas, você terá que estar conectado à rede privada dos hosts, como por meio do acesso de VPN.

5. Opcional: se você não quiser acessar o NodePort diretamente, ou se você deve expor seus apps em uma porta específica como 443, será possível configurar seu próprio balanceador de carga de camada 4 de terceiro que está conectado à rede privada de seus hosts e encaminhar o tráfego para a NodePort. Por exemplo, é possível implementar um balanceador de carga do provedor de nuvem de seus hosts ou um balanceador de carga F5 em sua rede no local. O balanceador de carga deve ser capaz de encaminhar o tráfego de TCP e UDP para as portas 30000 - 32767.

Expondo apps com rotas e terminais de Link para tráfego da IBM Cloud

Se você deseja acessar um app em seu cluster Satellite por meio de um recurso na IBM Cloud sobre a rede privada, é possível usar o seu controlador de ingresso privado para criar uma rota privada para o seu app. Em seguida, será possível criar um terminal de Link do tipo location para a rota, que é acessível somente de dentro da rede privada da IBM Cloud.

1. Siga as etapas em Expondo apps com rotas do Red Hat OpenShift para criar uma rota privada para o seu app. Essa rota é acessível apenas de dentro da rede privada dos seus hosts.

2. Siga as etapas em Criando terminais location para se conectar a recursos em uma localização para criar um terminal de Link do Satellite para a rota privada do seu app.

3. Opcional: para permitir acesso ao terminal apenas por meio recurso específico na IBM Cloud, inclua o recurso na lista de origem do terminal.