Antes de Iniciar

1. Certifique-se de ter a função de acesso de serviço Gravador ou Gerenciador do IBM CloudIAM para o espaço de nomes no qual o serviço LoadBalancer do Kubernetes é implementado para o NLB de VPC.
2. Acesse o seu Red Hat OpenShift cluster.
3. Para visualizar os VPC NLBs, instale o plug-in infrastructure-service. O prefixo para a execução de comandos é ibmcloud is.

   ibmcloud plugin install infrastructure-service
   

4. Para NLBs de VPC privadas: Conecte-se à sua rede privada VPC, por exemplo, por meio de uma conexão VPN VPC.
5. Para NLBs de VPC privadas: Habilite seu aplicativo para receber solicitações de rede privada.
   1. Crie uma sub-rede da VPC dedicada ao seu NLB da VPC. Essa sub-rede deve existir na mesma VPC e mesma localização do cluster, mas não pode ser conectada ao cluster ou a nenhum nó do trabalhador. Se você inserir um intervalo de IP específico, não use os intervalos reservados a seguir: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16. Depois de provisionar a sub-rede, anote sua ID.
   2. Se o cliente que se conecta ao seu aplicativo por meio do VPC NLB estiver fora da VPC e da zona da sua sub-rede VPC dedicada, você deverá criar uma tabela de roteamento de entrada personalizada. Para obter mais informações, consulte a tabela em Limitações conhecidas e Sobre as rotas e as tabelas de roteamento. Selecione uma das seguintes origens de tráfego para sua tabela de roteamento de entrada personalizada: Para o tráfego de uma rede local, escolha Direct link. Para o tráfego de outra VPC ou da infraestrutura clássica, escolha Transit gateway. Para o tráfego de outra zona dentro da mesma VPC, selecione Zona VPC. Para obter mais informações, consulte Configuração da conectividade VPC VPN.

Configurar o serviço “ LoadBalancer ”

1. Implemente o seu app no cluster. Certifique-se de incluir um rótulo na seção de metadados de seu arquivo de configuração de implementação. Esse rótulo customizado identifica todos os pods nos quais seu app é executado para incluí-los no balanceamento de carga.

2. Crie um arquivo YAML de configuração para o seu serviço LoadBalancer do Kubernetes. No arquivo YAML, especifique a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type como "public" ou "private". A seção annotations no arquivo de exemplo inclui apenas algumas anotações disponíveis. Para obter uma lista completa das anotações necessárias e opcionais do VPC NLB, consulte Anotações e especificações.

   Para tornar seu VPC NLB facilmente identificável, considere nomear o serviço no formato <app_name>-vpc-nlb-<VPC_zone>.

   apiVersion: v1
   kind: Service
   metadata:
     name: <app_name>-vpc-nlb-<VPC_zone>
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "public"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
   spec:
     type: LoadBalancer
     selector:
       <selector_key>: <selector_value>
     ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

3. Crie o serviço LoadBalancer do Kubernetes em seu cluster.

   oc apply -f <filename>.yaml -n <namespace>
   

4. Verifique se o serviço LoadBalancer do Kubernetes foi criado com êxito em seu cluster. Quando o serviço é criado, o campo LoadBalancer Ingress é preenchido com um endereço IP externo designado pelo VPC NBL.

O VPC NLB leva alguns minutos para ser provisionado em sua VPC. O endereço IP externo do seu serviço Kubernetes LoadBalancer pode estar pending até que o VPC NLB esteja totalmente provisionado.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Exemplo de saída da CLI para um serviço `LoadBalancer` público:
```sh {: screen}
NAME:                     myapp-vpc-nlb-us-east
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     169.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Warning  SyncLoadBalancerFailed           13m (x5 over 15m)    service-controller  Error syncing load balancer: failed to ensure load balancer: kube-bqcssbbd0bsui62odcdg-2d93b07decf641d2ad3f9c2985122ec1 for service default/myvpcnlb is busy: offline/create_pending
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/myvpcnlb with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

5. Verifique se o VPC NLB é criado com sucesso em sua VPC. Na saída, verifique se o VPC NLB está com o Status operacional como online e o Status de provisão como active.

   ibmcloud is load-balancers
   

   Na saída da CLI de exemplo a seguir, o VPC NLB que é denominado kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e é criado para o serviço Kubernetes LoadBalancer:

   ID                                     Name                                                         Created          Host Name                                  Is Public   Listeners                               Operating Status   Pools                                   Private IPs              Provision Status   Public IPs                    Subnets                                Resource Group
   06496f64-a689-4693-ba23-320959b7b677   kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e   8 minutes ago    1234abcd-us-south.lb.appdomain.cloud       yes         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.241.0.7               active             169.63.99.184                 c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

6. Acesse o endereço IP do serviço LoadBalancer de Kubernetes localizado na etapa 4 e a porta do app no formato <external_IP>:<app_port>.

7. Opcional: repita essas etapas para implementar um VPC NLB público em cada zona na qual você deseja expor seu aplicativo. Em seguida, é possível registrar os endereços IP externos do VPC NLB em cada zona com um subdomínio de DNS.

Não exclua as sub-redes que você anexou ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você exclui uma sub-rede VPC que seu cluster usou, qualquer VPC NLB que usa endereços IP da sub-rede pode ter problemas e talvez você não consiga criar novos balanceadores de carga.

Configuração de um NLB público usando um intervalo de portas

Os intervalos de portas podem ser usados em NLBs públicas quando há necessidade de hospedar um serviço de um único nome de host que tenha vários aplicativos de backend, cada um escutando em um número de porta separado. Para usar intervalos de portas em seu cluster Kubernetes, é necessário realizar algumas configurações manuais. Primeiro, a opção ibm-load-balancer-cloud-provider-vpc-port-range deve ser definida. Ele pode incluir um ou vários intervalos, cada um delimitado por uma vírgula. O valor spec.ports.port também deve ser definido como o valor mínimo no intervalo de portas.

No exemplo a seguir, é usado um intervalo de portas de 30000-30010.

Os serviços Nodeport devem ser criados manualmente para cada implementação na qual o serviço NLB encaminha a solicitação. O número da porta de cada um desses serviços Nodeport deve estar dentro do intervalo de portas configurado no serviço NLB.

No diagrama de exemplo a seguir, um serviço Nodeport com a porta 30000 é criado para o Deployment 1, enquanto um serviço Nodeport com a porta 30001 é criado para o Deployment 2.

O usuário faz uma solicitação à porta 30001 do NLB que contém o intervalo de portas. Essa solicitação é direcionada para o serviço VPC NLB, que a direciona para o serviço Nodeport no cluster que também está escutando na porta 30001, que, nesse caso, é para o Deployment 2. Em seguida, o serviço Nodeport direciona a solicitação para a porta de destino dos pods selecionados do Deployment 2.

Crie um NLB que use um intervalo de portas usando o exemplo a seguir. O seletor e os pods de backend devem ser associados ao serviço de balanceador de carga de intervalo de portas para que as verificações de integridade retornem com êxito e os dados sejam entregues às portas no intervalo de portas. Para usar o intervalo de portas, você deve criar serviços NodePort adicionais que tenham valores de porta no intervalo definido pelo serviço de balanceador de carga.

1. Salve o exemplo de configuração LoadBalancer a seguir como um arquivo chamado loadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-port-range: 30000-30010
     name: nlb-port-range
   spec:
     externalTrafficPolicy: Cluster
     ports:
     - port: 30000 # Must match min from the port range
       protocol: TCP
       nodePort: 30011 # Can be port in range or not
       targetPort: 8080
     selector:
       app: echo-server  # Must be valid for health checks to work
     type: LoadBalancer
   

2. Crie o serviço.

   oc apply -f loadbalancer.yaml
   

3. Crie um serviço NodePort com valores de porta que estejam no intervalo de portas especificado no LoadBalancer que você criou anteriormente.

   apiVersion: v1
   kind: Service
   metadata:
     name: echo-server-node-port
   spec:
     ports:
     - port: 80
       protocol: TCP # The protocol of the port range
       nodePort: 30003 # Node port in the port range
       targetPort: 8080
     selector:
       app: echo-server
     type: NodePort
   

4. Crie o serviço “ NodePort ”.

   oc apply -f nodeport.yaml
   

5. Para acessar uma porta que esteja no intervalo fornecido pelo NLB.

   curl https://<public ip assigned to NLB>:30003
   

   • 30003 = É uma porta de nó no intervalo que responde à solicitação
   • Outras portas no intervalo não respondem, a menos que sejam criados serviços adicionais de porta de nó.

Anotações e especificações necessárias

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"

Anotação para criar um VPC NLB. Se você não incluir essa anotação e especificar nlb, um VPC ALB será criado por padrão.

service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

(Obrigatório para NLBs privados) Anotação para especificar um serviço que aceita solicitações privadas. Se essa anotação não for incluída, será criado um VPC NLB público.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

(Obrigatório para NLBs privados, opcional para NLBs públicos) Anotação para especificar a sub-rede dedicada para a qual o NLB da VPC é implantado. O valor pode ser especificado como um ID de sub-rede de VPC, um nome de sub-rede de VPC ou um CIDR de sub-rede de VPC. Deve-se especificar somente uma sub-rede. A sub-rede deve existir na mesma VPC do cluster e em uma zona na qual ele tenha nós do trabalhador, mas nenhum nó do trabalhador pode ser anexado a ela. Os nós do trabalhador que existem na mesma zona dessa sub-rede estão configurados para receber tráfego do NLB de VPC. Para ver sub-redes em todos os grupos de recursos, execute ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE.

externalTrafficPolicy

Especifique Local ou Cluster.

Configure como Local para preservar o endereço IP de origem das solicitações do cliente para seus apps. Essa configuração impede que o tráfego de entrada seja encaminhado para um nó diferente. Esta opção também configura verificações de funcionamento de HTTP.

Se Cluster estiver configurado, o DSR será implementado apenas no nó do trabalhador para o qual o VPC NLB encaminha inicialmente a solicitação recebida. Após a chegada da solicitação de entrada, ela é encaminhada para um nó de trabalho que contém o pod do aplicativo, que pode estar em uma zona diferente. A resposta do pod do app é enviada ao nó do trabalhador original, e esse nó do trabalhador usa DSR para enviar a resposta diretamente de volta ao cliente, ignorando o VPC NLB. Esta opção também configura verificações de funcionamento do TCP. Para os balanceadores de carga do UDP, o service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp é obrigatório caso você escolha a opção Cluster. Para obter mais informações, consulte “Configurando verificações de integridade d TCP ” para “balanceadores de carga UDP ”.

Anotações e especificações opcionais

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name

Inclua um nome exclusivo para tornar seu balanceador de carga VPC persistente. Os balanceadores de carga VPC persistentes não são excluídos quando o cluster ao qual pertencem é excluído. Para obter mais informações, consulte Balanceadores de carga VPC persistentes. Essa anotação pode ser definida somente na criação do balanceador de carga. Ele não pode ser usado em uma operação de atualização.

service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

Anotação para especificar uma zona da VPC à qual seu cluster está anexado. O VPC NLB é implementado para a mesma sub-rede na zona que seus nós do trabalhador estão conectados. Se depois você mudar essa anotação para uma zona diferente, o NLB da VPC não será deslocado para a nova zona. Se você não especificar essa anotação ou o endereço service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets annotation, o VPC NLB será implantado na zona mais ideal (por exemplo, uma zona que tenha nós de trabalho no estado Ready ). Se o rótulo “ dedicated: edge ” estiver definido nos nós de trabalho e você especificar essa anotação, apenas os nós de borda na zona especificada serão configurados para receber tráfego. Nós de borda em outras zonas e nós não de borda na zona especificada não recebem tráfego do balanceador de carga. Para ver as zonas, execute ibmcloud ks zone ls --provider vpc-gen2.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

Anotação para especificar um seletor de rótulo de nó de trabalho. Você pode configurar nós de trabalho específicos em seu cluster para receber tráfego especificando chaves seletoras de rótulo. É possível incluir apenas um seletor de rótulo na anotação, e esse seletor deve ser especificado no formato "key=value". Se essa anotação não for especificada, todos os nós de trabalho do seu cluster serão configurados para receber tráfego do VPC NLB. Essa anotação tem precedência sobre a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-zone , e quaisquer rótulos dedicated: edge nos nós de trabalho são ignorados. Para limitar o tráfego a uma zona específica, você pode usar essa anotação para especificar os nós de trabalho nessa zona. Observe que a definição de um novo rótulo em um nó de trabalho do cluster não configura automaticamente o nó de trabalho para receber tráfego; é necessário recriar ou atualizar o VPC NLB para que o nó de trabalho recém-rotulado receba tráfego.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp

A porta do nó “ TCP ” a ser utilizada para as verificações de integridade do “ TCP ” em um balanceador de carga “ UDP ”. Necessário para balanceadores de carga UDP que têm externalTrafficPolicy configurado como Cluster. Consulte Configurando verificações de funcionamento TCP para balanceadores de carga UDP para obter mais considerações antes de definir um valor de porta.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

Essa anotação define o protocolo de verificação de integridade no recurso de balanceador de carga VPC associado ao serviço de balanceador de carga Kubernetes. As opções disponíveis são http, https, ou tcp. Normalmente, o protocolo de verificação de integridade do VPC LB é determinado pelo valor da configuração externalTrafficPolicy na especificação de serviço do balanceador de carga Kubernetes. No entanto, essa anotação substitui essa lógica. Essa anotação não altera o comportamento de Kubernetes, e do kube-proxy em particular, em relação às várias configurações de externalTrafficPolicy.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

A porta do serviço “ TCP ” utilizada para as verificações de integridade. Essa anotação se aplica somente se ibm-load-balancer-cloud-provider-vpc-health-check-protocol também for especificado. Se a porta TCP especificada estiver fora do intervalo de portas dos nós Kubernetes (30.000–32.767), o grupo de segurança da VPC aplicado aos nós de trabalho do cluster deverá ser modificado para permitir o tráfego de entrada nessa porta. Se essa anotação for aplicada a um serviço de balanceador de carga do Kubernetes associado a um VPC ALB, as regras de saída do grupo de segurança atribuído ao VPC ALB deverão ser modificadas para permitir o tráfego de saída para a porta TCP especificada. Para obter mais informações, consulte Noções básicas sobre redes de VPC de cluster seguras por padrão e Criação e gerenciamento de grupos de segurança de VPC.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

A verificação de integridade URL caminho para verificações de integridade de HTTP e HTTPs. Essa anotação se aplica somente se ibm-load-balancer-cloud-provider-vpc-health-check-protocol estiver definido como http ou https. O caminho URL deve estar no formato de um destino de solicitação de formato de origem. Se essa anotação não for especificada e a anotação ibm-load-balancer-cloud-provider-vpc-health-check-protocol for definida como http ou https, o valor padrão / será aplicado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

Opcional. O número de segundos de espera entre as tentativas de verificação de integridade. Por padrão, esse valor é definido como 5, e tem um mínimo de 2 e um máximo de 60. Esse valor deve ser maior que o valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que é definido como 2 por padrão.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

Opcional. O número de segundos para aguardar uma resposta a uma verificação de integridade. Por padrão, esse valor é definido como 2, e tem um mínimo de 1 e um máximo de 59. Esse valor deve ser menor que ibm-load-balancer-cloud-provider-vpc-health-check-delay, que é definido como 5 por padrão.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

O número máximo de novas tentativas de verificação de integridade para o balanceador de carga VPC. Por padrão, esse valor é definido como 2, e tem um mínimo de 1 e um máximo de 10.

service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"

Versão 4.16 ou posterior.

Registre o endereço IP do balanceador de carga com o domínio Ingress especificado. Se o domínio especificado não existir, será criado um domínio que usa o provedor interno gerenciado pelo IBM (IBM NS1). Para criar um novo domínio, o nome deve ser exclusivo em todos os domínios existentes (não apenas naqueles em seu cluster). A exclusão do serviço de balanceador de carga remove o endereço IP do domínio. No entanto, a remoção da anotação não remove o endereço IP do domínio.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

Opcional. O número de nós de trabalho por zona para os quais o balanceador de carga roteia. O valor padrão é 8. Para um cluster com nós de trabalho em três zonas, isso faz com que o balanceador de carga encaminhe o tráfego para um total de 24 nós de trabalho. O número total de nós de trabalho em todas as zonas para as quais o balanceador de carga roteia 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.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

Versão 1.30 e e posteriores.

Opcional. Um grupo de segurança gerenciado pelo cliente a ser adicionado ao balanceador de carga VPC. Se não quiser usar o grupo de segurança IBM-managed, especifique um grupo de segurança que você possui e gerencia. Essa opção remove o grupo de segurança IBM-managed e o substitui pelo grupo de segurança que você especificar. A remoção da anotação de um balanceador de carga existente substitui o grupo de segurança que você adicionou pelo grupo de segurança IBM-managed. Você pode adicionar ou remover essa anotação a qualquer momento. Você é responsável por gerenciar seu grupo de segurança e mantê-lo atualizado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic

Disponível para clusters que executam o Secure by Default. Anotação para criar grupos de segurança para cada endereço IP de um ALB associado a uma porta externa que você especificar. Essas regras são criadas no grupo de segurança do cluster. Especifique as portas externas válidas em uma lista separada por vírgulas, como 80,443. Neste exemplo, se cada ALB público associado a cada valor de porta externa tiver dois endereços IP, será criada uma regra de saída por endereço IP, em um total de 4 novas regras. Você pode adicionar ou remover essa anotação a qualquer momento.

selector

A chave de rótulo (<selector_key>) e o valor (<selector_value>) usados na seção spec.template.metadata.labels do YAML de implementação do app. Esse rótulo customizado identifica todos os pods nos quais seu app é executado para incluí-los no balanceamento de carga.

port

A porta na qual o serviço atende.

targetPort

Opcional: a porta para a qual o serviço direciona o tráfego. O aplicativo em execução no pod deve estar à escuta para tráfego de entrada do tipo TCP nessa porta de destino. A porta de destino geralmente é definida estaticamente na imagem que está sendo executada no pod do aplicativo. A porta de destino configurada no pod é diferente da porta do nó para o serviço e também pode ser diferente da porta externa que está configurada no VPC LB.