Network Load Balancer for VPC

Em clusters VPC, configure um layer-4 Network Load Balancer for VPC (VPC NLB) em cada zona do seu cluster para que ele funcione como ponto de entrada externo para as solicitações recebidas por 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. Adicionalmente, o VPC NLB suporta a preservação de endereço IP de origem em todas as solicitações do cliente por padrão.

• Os nomes do 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.

• Os nomes persistentes do VPC NLB possuem 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 pela 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 do aplicativo forem implantadas em vários nós de trabalho do cluster, o VPC NLB encaminha as solicitações entre os pods do aplicativo nos diversos nós de trabalho em todas as zonas do cluster.

Application Load Balancer for 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.

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 dos ALBs do VPC seguem 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 ALB da VPC.

• 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.

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.

Como configurar um NLB usando faixa de porta

Os intervalos de portas podem ser usados em NLBs públicos quando houver necessidade de hospedar um serviço a partir de um único nome de host que tenha vários aplicativos backend, cada um atendendo em um número de porta separado. Para usar intervalos de portas no cluster Kubernetes, alguma configuração manual deve ser executada. Primeiro, a opção ibm-load-balancer-cloud-provider-vpc-port-range deve ser configurada Ele pode incluir um ou vários intervalos, cada um delimitado por uma vírgula. O valor spec.ports.port também deve ser configurado para o valor mínimo no intervalo de porta..

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

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 destes serviços Nodeport deve estar dentro do intervalo de porta configurado no serviço NLB.

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

O usuário faz uma solicitação à porta 30001 do NLB contendo o intervalo de porta. Essa solicitação é direcionada para o serviço VPC NLB que direciona a solicitação para o serviço Nodeport no cluster que também está atendendo na porta 30001, que nesse caso é para a Implementação 2. O serviço Nodeport então direciona a solicitação para a porta de destino dos pods selecionados da Implementação 2.

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

1. Salve a configuração do exemplo LoadBalancer 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 estão na faixa de porta especificada 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 está 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 serviços de porta de nó adicionais sejam criados.

Configurando um NLB de VPC privado

Exponha seu aplicativo ao tráfego da rede privada configurando um serviço LoadBalancer do Kubernetes em cada zona do cluster. Ao criar o serviço LoadBalancer do Kubernetes, um balanceador de carga de rede privado para VPC (NLB de VPC) que roteia as solicitações para seu aplicativo é criado automaticamente para você na VPC fora do cluster.

Antes de Iniciar

• 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.
• Conecte-se à rede VPC privada, por exemplo, usando uma conexão VPN de VPC.
• Acesse o seu Red Hat OpenShift cluster.
• 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
  

Para ativar o app para receber solicitações de rede privada,

1. Crie uma sub-rede de VPC dedicada ao NLB de 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.

   1. No Painel de sub-rede VPC, clique em Nova sub-rede.
   2. Insira um nome para sua sub-rede.
   3. Selecione o local do cluster e a zona na qual você deseja criar o NLB de VPC.
   4. Selecione o nome da VPC na qual seu cluster existe.
   5. Especifique o número de endereços IP a serem criados. Como essa sub-rede é dedicada ao NLB de VPC, é possível escolher um tamanho menor, como 16. Não é possível mudar o número de IPs que uma sub-rede VPC terá depois. 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.
   6. Clique em Criar sub-rede. Depois que a sub-rede for provisionada, anote o ID dela.

2. Se o cliente que precisa se conectar ao aplicativo por meio do NLB de VPC existir fora da VPC e da zona nas quais você criou a sub-rede de VPC dedicada, uma tabela customizada de roteamento de ingresso deverá ser criada. Os NLBs de VPC privados podem incluir regras na tabela de roteamento customizada para garantir a disponibilidade do serviço em algumas condições de falha. Para obter mais informações, consulte a tabela em Limitações conhecidas e Sobre as rotas e as tabelas de roteamento.

   1. No Painel de tabelas de roteamento de VPC, clique em Criar.
   2. Digite um nome para sua tabela de roteamento.
   3. Selecione o local e a zona nos quais você criou a sub-rede dedicada.
   4. Selecione o nome da VPC na qual a sub-rede existe.
   5. Para o Tipo de tráfego, selecione Ingress.
   6. Dependendo de onde o cliente está acessando o app, escolha uma Origem de tráfego. Para obter mais informações sobre a configuração de conexões com sua rede VPC privada, consulte a documentação para escolher a conectividade de VPN do IBM Cloud VPC, do Transit Gateway ou do Direct Link for VPC.
      • Rede local: link direto
      • Outra infraestrutura clássica ou VPC: gateway de trânsito
      • Outra zona dentro da mesma VPC:Zona de VPC

3. 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.

4. Crie um arquivo YAML de configuração para o seu serviço LoadBalancer do Kubernetes. 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: "private"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: "<tcp_port"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
     type: LoadBalancer
     selector:
       <selector_key>: <selector_value>
     ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 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.
   

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

   Opcional. Inclua um nome exclusivo para tornar o seu balanceador de carga do VPC persistente Os balanceadores de carga VPC persistentes não são excluídos quando o cluster a que pertencem é excluído. Para obter mais informações, consulte Balanceadores de carga de VPC persistentes

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

   Necessário: anotação para criar um VPC NLB.

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

   Necessário: anotação para especificar um serviço que aceite solicitações privadas.

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

   Necessário: anotação para especificar a sub-rede dedicada na qual o NLB de VPC é implementado. 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> --zone <zone>.

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

   Opcional: a anotação para especificar um seletor de rótulo do nó do trabalhador. Na mesma zona da sub-rede dedicada ao NLB de VPC, é possível configurar nós do trabalhador específicos para receber tráfego selecionando uma das chaves suportadas do seletor de rótulo. Observe que é possível incluir somente um seletor de rótulo na anotação e que o seletor deve ser especificado no formato "key=value". Se esta anotação não for especificada, todos os nós do trabalhador na mesma zona da sub-rede de VPC especificada na anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets serão configurados para receber tráfego do NLB de VPC. Se especificado, qualquer rótulo dedicated: edge em nós do trabalhador será ignorado.

   As chaves a seguir são permitidas. - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

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

   Opcional: especifique uma porta do nó TCP a usar para verificações de funcionamento 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

   Opcional: essa anotação configura o protocolo de verificação de funcionamento no recurso do balanceador de carga do VPC associado ao serviço do balanceador de carga do Kubernetes. Normalmente, o protocolo de verificação de funcionamento do VPC LB é determinado pelo valor da configuração externalTrafficPolicy na especificação do serviço de balanceador de carga do Kubernetes. Essa anotação substitui essa lógica Essa anotação não altera como Kubernetes, e kube-proxy em particular, se comporta em relação às várias configurações de externalTrafficPolicy.

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

   Opcional. A porta do serviço “ TCP ” utilizada para as verificações de integridade. Essa anotação se aplicará apenas 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.

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

   Opcional. A verificação de integridade URL para verificações de integridade do tipo HTTP e HTTPS. Essa anotação se aplicará apenas se ibm-load-balancer-cloud-provider-vpc-health-check-protocol estiver configurado como http ou https

   • O caminho URL deve estar no formato de um destino de solicitação no formato “origin ”.
   • Se esta 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 para esperar entre as tentativas de verificação de saúde. Por padrão, esse valor é configurado como 5 e tem no mínimo 2 e no máximo 60. Esse valor deve ser maior que o valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que é configurado como 2 por padrão.

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

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

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

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

   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 TCP nesta porta de destino. A porta de destino é muitas vezes definida estaticamente na imagem que está em execução no pod do aplicativo A porta de destino configurada no pod é diferente da porta de nó para o serviço e também pode ser diferente da porta externa configurada no LB do VPC.

   externalTrafficPolicy

   Obrigatório. Especificamos Local ou Cluster.

   Defina como “ Local ” para preservar o endereço IP de origem das solicitações dos clientes às suas aplicações. Essa configuração impede que o tráfego recebido seja encaminhado para um nó diferente. Esta opção também configura verificações de funcionamento de HTTP.

   Se a opção “ Cluster ” estiver definida, o DSR será implementado apenas a partir do nó de trabalho para o qual o VPC NLB encaminha inicialmente a solicitação recebida. Após a chegada da solicitação recebida, a solicitação é encaminhada para um nó do trabalhador que contém o pod do app, 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 tipo “ UDP ”, é necessário o “ service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp ” 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 ”.

   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 resulta no roteamento do balanceador de carga 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

   Opcional. Um grupo de segurança gerenciado pelo cliente a ser adicionado ao balanceador de carga VPC. Se você não quiser usar o IBM, especifique um grupo de segurança que você possua e gerencie. Essa opção remove o grupo de segurança gerenciado pela IBM 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 gerenciado pela IBM. 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.

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

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

6. 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 de CLI para um serviço privado `LoadBalancer`:
```sh {: screen}
NAME:                     myvpcnlb
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     10.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.
```

7. 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       no         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.XXX.XXX.XXX           active             -               c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

8. Na conexão com a rede privada da VPC, acesse o endereço IP do serviço LoadBalancer de Kubernetes localizado na etapa 6 e na porta do app no formato <external_IP>:<app_port>.

9. Opcional: repita essas etapas para implementar um NLB de VPC privado 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.

Registrando um registro DNS e certificado TLS

Os VPC NLBs fornecem endereços IP externos estáticos por meio dos quais é possível acessar o seu aplicativo. Para registrar um certificado SSL para seu domínio de aplicativo para suportar HTTPS, é possível criar um subdomínio fornecido pela IBM ou trazer seu próprio domínio customizado.

Por exemplo, digamos que você tenha um cluster multizona e execute réplicas do seu aplicativo em nós do trabalhador em cada zona do seu cluster. Crie um VPC NLB por zona para expor as réplicas do aplicativo. Em seguida, é possível registrar os endereços IP externos fornecidos por cada VPC NLB com uma entrada DNS.

Depois de criar um subdomínio DNS para NLBs da VPC, não será possível usar comandos nlb-dns health-monitor para criar uma verificação de funcionamento customizada. Em vez disso, a verificação de funcionamento padrão da VPC é usada. Para obter mais informações, consulte a documentação do VPC.

• Crie um VPC NLB por zona para o seu aplicativo. Assegure-se de definir uma porta HTTPS em seu serviço Kubernetes LoadBalancer que configura o VPC NLB.
• Para usar o certificado SSL para acessar seu app via HTTPS, seu app deve ser capaz de finalizar as conexões TLS.

Para registrar endereços IP do NLB da VPC com um subdomínio DNS,

1. Recupere o endereço IP externo de seu balanceador de carga.

   oc get svc -o wide
   

   Saída de exemplo

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)            AGE      SELECTOR
   ...
   myapp-vpc-nlb-jp-tok-3    LoadBalancer   172.21.xxx.xxx   169.xx.xxx.xx     8080:30532/TCP     1d       run=webserver
   

2. Crie um subdomínio DNS customizado ou fornecido pela IBM para o endereço IP.

   • Domínio customizado:

     1. Registre um domínio customizado trabalhando com o seu provedor do Domain Name Service (DNS) ou com o IBM Cloud DNS.
     2. Defina um alias para o seu domínio customizado especificando os endereços IP do balanceador de carga como registros A.

   • Subdomínio fornecido pela IBM: use comandos nlb-dns para gerar um subdomínio com um certificado SSL para os endereços IP. A IBM Cloud cuida de gerar e manter o certificado SSL curinga para o subdomínio.

     1. Crie um subdomínio DNS e um certificado SSL.

        ibmcloud oc nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
        

     2. Verifique se o subdomínio foi criado. Para obter mais informações, consulte Entendendo o formato de subdomínio.

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

        Saída de exemplo

        Subdomain                                                                               IP(s)                                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     169.46.xx.x,169.48.xxx.xx,169.48.xxx.xx      None             created                   <certificate>
        

3. Abra um navegador da web e insira a URL para acessar o seu aplicativo por meio do subdomínio.

Para usar o certificado SSL para acessar seu app via HTTPS, assegure-se de que você tenha definido uma porta HTTPS em seu serviço LoadBalancer do Kubernetes. É possível verificar se as solicitações estão sendo roteadas corretamente por meio da porta HTTPS executando curl -v --insecure https://<domain>. Um erro de conexão indica que nenhuma porta HTTPS está aberta no serviço. Além disso, assegure-se de que as conexões TLS possam ser finalizadas por seu app. É possível verificar se o app finaliza correamente o TLS executando curl -v https://<domain>. Um erro de certificado indica que seu app não está finalizando de forma adequada as conexões TLS.

Configurando um VPC ALB público ou privado

Antes de Iniciar

• 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.
• Acesse o seu Red Hat OpenShift cluster.
• Para visualizar os VPC ALBs, instale o plug-in infrastructure-service. O prefixo para a execução de comandos é ibmcloud is.

  ibmcloud plugin install infrastructure-service
  

Para ativar o app para receber solicitações públicas ou privadas,

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 seu serviço LoadBalancer do Kubernetes e nomeie o arquivo myloadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     name: myloadbalancer
     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: "proxy-protocol"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
       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>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   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.
   

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

   Opcional. Inclua um nome exclusivo para tornar o seu balanceador de carga do VPC persistente Os balanceadores de carga VPC persistentes não são excluídos quando o cluster a que pertencem é excluído. Para obter mais informações, consulte Balanceadores de carga de VPC persistentes

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

   Opcional: Ative o protocolo PROXY. O balanceador de carga transmite informações de conexão do cliente, incluindo o endereço IP do cliente, o endereço IP do servidor proxy e ambos os números de porta, em cabeçalhos da solicitação para seu app back-end. Observe que o seu app back-end deve ser configurado para aceitar o protocolo PROXY. Por exemplo, você pode configurar um aplicativo do tipo “ NGINX ” para aceitar o protocolo PROXY seguindo estas etapas.

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

   Anotação para especificar um serviço que aceita solicitações públicas ou privadas. Se você não incluir essa anotação, um LoadBalancer público será criado.

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

   Anotação para especificar um seletor de rótulo de nó de trabalho. Para identificar os nós do trabalhador que recebem o tráfego, é possível selecionar uma das chaves de seletor de rótulo suportadas. Observe que é possível incluir somente um seletor de rótulo na anotação e que o seletor deve ser especificado no formato "key=value". Se esta anotação não for especificada, todos os nós do trabalhador em seu cluster estarão configurados para receber tráfego do VPC ALB. Se especificada, essa anotação terá precedência sobre a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-zone e quaisquer rótulos dedicated: edge em nós do trabalhador serão ignorados.

   As chaves a seguir são permitidas: - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

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

   Anotação para especificar uma ou mais sub-redes nas quais o serviço VPC ALB é implantado. Se especificada, essa anotação terá precedência sobre a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Observe que é possível especificar uma sub-rede diferente na mesma VPC das sub-redes às quais seu cluster está anexado. Nesse caso, mesmo que o VPC ALB seja implementado em uma sub-rede diferente na mesma VPC, o VPC ALB ainda poderá rotear o tráfego para seus nós do trabalhador nas sub-redes do cluster. Para ver sub-redes em todos os grupos de recursos, execute ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>.

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

   Anotação para especificar uma zona da VPC à qual seu cluster está anexado. Ao especificar uma zona nessa anotação, ocorrem dois processos.

   1. O VPC ALB é implementado para a mesma sub-rede naquela zona que seus nós do trabalhador estão conectados.
   2. Somente nós do trabalhador em seu cluster nesta zona estão configurados para receber tráfego do VPC ALB.

   Para ver zonas, execute ibmcloud oc zone ls --provider vpc-gen2.

   Para colocar o balanceador de carga em uma zona específica, deve-se especificar essa anotação ao criar o balanceador de carga. Se posteriormente você mudar essa anotação para uma zona diferente, o balanceador de carga em si não será movido para a nova zona. No entanto, o balanceador de carga é reconfigurado para enviar tráfego apenas para nós do trabalhador na nova zona.

   Se o rótulo dedicated: edge for configurado em nós do trabalhador e você especificar essa anotação, somente nós de borda na zona especificada estarã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.

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

   Opcional: essa anotação configura o protocolo de verificação de funcionamento no recurso do balanceador de carga do VPC associado ao serviço do balanceador de carga do Kubernetes. Normalmente, o protocolo de verificação de funcionamento do VPC LB é determinado pelo valor da configuração externalTrafficPolicy na especificação do serviço de balanceador de carga do Kubernetes. Essa anotação substitui essa lógica Essa anotação não altera como Kubernetes, e kube-proxy em particular, se comporta em relação às várias configurações de externalTrafficPolicy.

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

   Opcional. A porta do serviço “ TCP ” utilizada para as verificações de integridade. Essa anotação se aplicará apenas 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.

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

   Opcional. A verificação de integridade URL para verificações de integridade do tipo HTTP e HTTPS. Essa anotação se aplicará apenas se ibm-load-balancer-cloud-provider-vpc-health-check-protocol estiver configurado como http ou https

   • O caminho URL deve estar no formato de um destino de solicitação no formato “origin ”.
   • Se esta 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 para esperar entre as tentativas de verificação de saúde. Por padrão, esse valor é configurado como 5 e tem no mínimo 2 e no máximo 60. Esse valor deve ser maior que o valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que é configurado como 2 por padrão.

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

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

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

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

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

   Opcional. O tempo limite de conexão inativa do listener, em segundos. O tempo limite inativo padrão depende das configurações da conta. Geralmente, esse valor é 50. No entanto, algumas contas permitidas têm configurações de tempo limite maiores. Se você não configurar a anotação, seus balanceadores de carga usarão a configuração de tempo limite em sua conta.. É possível especificar explicitamente o tempo limite, configurando essa anotação O mínimo é 50. O valor máximo é 7200.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

   Opcional. Pode ser aplicado somente para VPC ALBs privados na versão4.15 ou mais tarde. O DNS instance a ser associado a este balanceador de carga. Para mais informações, veja Registrando um registro DNS privado.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

   Opcional. Pode ser aplicado somente para VPC ALBs privados na versão4.15 ou mais tarde. O DNS zone a ser associado a este balanceador de carga. Para mais informações, veja Registrando um registro DNS privado.

   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 TCP nesta porta de destino. A porta de destino é muitas vezes definida estaticamente na imagem que está em execução no pod do aplicativo A porta de destino configurada no pod é diferente da porta de nó para o serviço e também pode ser diferente da porta externa configurada no LB do VPC.

   externalTrafficPolicy

   Obrigatório. Especifique Local ou Cluster.

   Defina como “ Local ” para preservar o endereço IP de origem das solicitações dos clientes aos seus aplicativos. Essa configuração impede que o tráfego recebido seja encaminhado para um nó diferente. Esta opção também configura verificações de funcionamento de HTTP. Para os balanceadores de carga do UDP, o service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp é necessário caso você escolha a opção Cluster. Para obter mais informações, consulte “Configuração de verificações de integridade d TCP ” para “equilibradores de carga d UDP ”.

   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 resulta no roteamento do balanceador de carga 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

   Opcional. Um grupo de segurança gerenciado pelo cliente a ser adicionado ao balanceador de carga VPC. Se você não quiser usar o IBM, especifique um grupo de segurança que você possua e gerencie. Essa opção remove o grupo de segurança gerenciado pela IBM 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 gerenciado pela IBM. 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.

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

   oc apply -f myloadbalancer.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 nome do host que é designado pelo VPC ALB.

O VPC ALB leva alguns minutos para provisionar em sua VPC. Não é possível acessar o app usando o nome do host do serviço LoadBalancer de Kubernetes até que o ALB da VPC seja totalmente fornecido.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Exemplo de saída da CLI para um serviço `LoadBalancer` público:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/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:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

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

   Não renomeie nenhum VPC ALB que seja criado automaticamente para os serviços LoadBalancer. Se você renomear um VPC ALB, o Red Hat OpenShift on IBM Cloud cria automaticamente outro VPC ALB para o serviço LoadBalancer.

   ibmcloud is load-balancers
   

   Na saída da CLI de exemplo a seguir, o VPC ALB que é nomeado kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 é criado para o serviço Kubernetes LoadBalancer:

   ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
   r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default
   

6. Se você criou um serviço LoadBalancer público, enrole o nome do host do serviço Kubernetes LoadBalancer que é designado pelo VPC ALB localizado na etapa 4. Exemplo:

   curl 06496f64-us-south.lb.appdomain.cloud:8080
   

   Saída de exemplo

   Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!
   

   Se você criou um serviço privado do LoadBalancer, deverá estar conectado à sua rede privada VPC para efetuar curl do nome do host.

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ê excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Os ALBs e NLBs da VPC que não estejam vinculados a clusters d Kubernetes ou OpenShift podem ser atualizados diretamente por meio dos comandos 'ibmcloud is' ou na seção Infraestrutura da VPC no console. Por exemplo, mude um valor de tempo limite de verificação de porta ou de um listener de front-end. No entanto, no caso dos balanceadores de carga do VPC vinculados a clusters d Kubernetes ou OpenShift, quaisquer atualizações neles devem ser realizadas por meio de anotações na configuração do Ingress. O provedor do IBM Cloud realiza periodicamente uma ressincronização com quaisquer ALBs e NLBs da VPC associados, a fim de garantir que o balanceador de carga em execução esteja em conformidade com a configuração esperada do Ingress. Portanto, se você fizer quaisquer mudanças nesse balanceador de carga diretamente por meio de VPC em vez de usar anotações do Ingress, essas mudanças serão revertidas.

Registrando um registro DNS e certificado TLS

O Application Load Balancer para VPC (ALB da VPC) fornece um nome de host HTTP padrão no formato 1234abcd-<region>.lb.appdomain.cloud por meio do qual é possível acessar o app. No entanto, se desejar que um certificado TLS para o domínio do seu aplicativo suporte HTTPS, será possível criar um subdomínio fornecido pela IBM ou trazer seu próprio domínio customizado para os VPC ALBs públicos e privados.

Depois de criar um subdomínio DNS para um ALB da VPC, não será possível usar comandos nlb-dns health-monitor para criar uma verificação de funcionamento customizada. Em vez disso, a verificação de funcionamento do balanceador de carga VPC padrão fornecida para o nome do host do ALB VPC padrão é usada. Para obter mais informações, consulte a documentação do VPC.

Antes de Iniciar

• Configure um VPC ALB. Assegure-se de definir uma porta HTTPS no seu serviço Kubernetes LoadBalancer que configura o VPC ALB.
• Para usar o certificado TLS para acessar seu app via HTTPS, seu app deve ser capaz de finalizar conexões TLS.

Para registrar um nome de host do ALB da VPC com um subdomínio DNS,

1. Recupere o nome do host para seu ALB do VPC executando o comando get svc. Na saída, procure o nome do host na coluna IP EXTERNO. Por exemplo, 1234abcd-us-south.lb.appdomain.cloud.

   oc get svc -o wide
   

   Saída de exemplo

   NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
   ...
   webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver
   

2. Crie um subdomínio DNS customizado ou fornecido pela IBM para o nome do host do balanceador de carga.

   • Domínio customizado: forneça o próprio domínio customizado e dê a ele um alias especificando o IP externo do balanceador de carga, no formato 1234abcd-us-south.lb.appdomain.cloud, como um registro de nome canônico (CNAME).

     1. Registre um domínio customizado trabalhando com o seu provedor do Domain Name Service (DNS) ou com o IBM Cloud DNS.
     2. Defina um alias para o domínio customizado especificando o IP externo do balanceador de carga como um registro de nome canônico (CNAME). No exemplo a seguir, o balanceador de carga com o IP externo de 1234abcd-us-south.lb.appdomain.cloud é alcançável em www.your-custom-domain.com.

     Host/Serviço

     O prefixo no qual você deseja alcançar o app, como www.

     Tipo de Recurso

     Selecione CNAME.

     TTL

     Selecione um tempo de vida.

     Valor/Destino

     O IP externo do LoadBalancer que você recuperou anteriormente. Por exemplo, 1234abcd-us-south.lb.appdomain.cloud.. Observe que ao usar o IBM Cloud DNS, certifique-se de inserir um ponto à direita.

   • Subdomínio fornecido pela IBM: use comandos nlb-dns para gerar um subdomínio com um certificado TLS para o nome de host do ALB da VPC. A IBM Cloud cuida de gerar e manter o certificado TLS curinga para o subdomínio.

     1. Crie um subdomínio DNS e um certificado TLS.

        ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
        

     2. Verifique se o subdomínio foi criado. Para obter mais informações, consulte Entendendo o formato de subdomínio.

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

        Saída de exemplo

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
        

3. Se você tiver criado um subdomínio para um VPC ALB público, abra um navegador da web e insira a URL para acessar o app por meio do subdomínio, como o www.your-custom-domain.com de exemplo. Se você criou um subdomínio para um VPC ALB privado, deve-se estar conectado à sua rede privada VPC para testar o acesso ao seu subdomínio.

Para usar o certificado TLS para acessar seu app via HTTPS, assegure-se de que você tenha definido uma porta HTTPS em seu serviço de Kubernetes LoadBalancer. É possível verificar se as solicitações estão sendo roteadas corretamente por meio da porta HTTPS executando curl -v --insecure https://<domain>. Um erro de conexão indica que nenhuma porta HTTPS está aberta no serviço. Além disso, assegure-se de que as conexões TLS possam ser finalizadas por seu app. É possível verificar se o app finaliza correamente o TLS executando curl -v https://<domain>. Um erro de certificado indica que seu app não está finalizando de forma adequada as conexões TLS.

Registrando um registro DNS privado para um VPC ALB privado

Na versão4.15 ou posterior você pode usar as seguintes anotações opcionais para associar um DNS próprio instance que serve um DNS personalizado zone com um VPC ALB privado. Para isso, ambas as anotações opcionais devem ser definidas. Se eles não forem especificados, então DNS A registros para este balanceador de carga hostname a propriedade será adicionada à zona DNS pública lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

O DNS instance a ser associado a este balanceador de carga. A instância especificada pode estar em uma região ou conta diferente, sujeita às políticas do IAM. Valores possíveis: 9 ≤ comprimento ≤ 512

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

O DNS zone a ser associado a este balanceador de carga. A zona especificada pode estar em uma região ou conta diferente, sujeita às políticas do IAM. Valores possíveis: 1 ≤ comprimento ≤ 128. O valor deve corresponder à expressão regular ^[1]*[a-z0-9]$

Você precisa fazer o seguinte como pré-requisito antes de poder usar este recurso:

• Crie a zona DNS que pode ser vinculada a um balanceador de carga
• Habilite a autorização serviço a serviço entre VPC LBs eDNS Services
• Adicione a VPC do cluster às redes permitidas da zona

Para obter informações detalhadas, consulte os documentos “Integração de um balanceador de carga de aplicativos com o IBM Cloud DNS Services ” e “Adicionar uma VPC como rede permitida à zona de DNS ”.

Exemplo:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

Removendo um balanceador de carga do VPC de um cluster

Os balanceadores de carga do VPC estão vinculados à definição do serviço Kubernetes LoadBalancer com a qual foram criados. Para desanexar um balanceador de carga VPC persistente de um cluster, você deve quebrar o link com o serviço LoadBalancer por renomeando o balanceador de carga VPC, ou removendo a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name da definição de serviço LoadBalancer original. Você também pode descolar um balanceador de carga VPC persistente de um cluster por excluindo o cluster.

Se você remover a anotação, o serviço LoadBalancer original será revertido e cria um balanceador de carga VPC não persistente no cluster original. Este balanceador de carga VPC não persistente segue a convenção de nomenclatura kube-<cluster_ID>-<kubernetes_lb_service_UID>.

Conectando um balanceador de carga VPC a um cluster

Depois que um balanceador de carga da VPC persistente for desassociado de um cluster, você poderá associá-lo a um cluster diferente criando uma nova definição de serviço Kubernetes LoadBalancer que faça referência ao balanceador de carga da VPC.

Ao criar um novo serviço do LoadBalancer no novo cluster, é possível usar a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name para especificar o nome do balanceador de carga do VPC que você deseja anexar

Ao criar o serviço LoadBalancer, o tipo de balanceador de carga do VPC (ALB, NLB) e o tipo de IP (público, privado) devem corresponder às especificações no serviço LoadBalancer. Por exemplo, um serviço LoadBalancer existente no novo cluster que especifica um tipo NLB não pode ser usado para conectar um VPC ALB ao cluster. As anotações que especificam o tipo de balanceador de carga e o tipo de IP são service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features e service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type, respectivamente

As portas de porta e nó especificadas no serviço LoadBalancer não precisam corresponder àquelas que o balanceador de carga VPC foi criado com. O balanceador de carga VPC re-configura com as definições de porta de qualquer qual o serviço LoadBalancer ele está associado no novo cluster.

Customizando verificações de funcionamento para balanceadores de carga VPC

Para obter mais controle sobre suas verificações de funcionamento do balanceador de carga VPC, você pode usar anotações opcionais para customizar suas verificações de funcionamento com configurações avançadas para intervalos de teste, cronometramentos e retentativas. Você pode alterar ou remover essas customizações a qualquer momento.

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

Opcional: essa anotação configura o protocolo de verificação de funcionamento no recurso do balanceador de carga do VPC associado ao serviço do balanceador de carga do Kubernetes. Normalmente, o protocolo de verificação de funcionamento do VPC LB é determinado pelo valor da configuração externalTrafficPolicy na especificação do serviço de balanceador de carga do Kubernetes. Essa anotação substitui essa lógica Essa anotação não altera como Kubernetes, e kube-proxy em particular, se comporta em relação às várias configurações de externalTrafficPolicy.

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

Opcional. A porta do serviço “ TCP ” utilizada para as verificações de integridade. Essa anotação se aplicará apenas 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.

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

Opcional. A verificação de integridade URL para verificações de integridade do tipo HTTP e HTTPS. Essa anotação se aplicará apenas se ibm-load-balancer-cloud-provider-vpc-health-check-protocol estiver configurado como http ou https

• O caminho URL deve estar no formato de um destino de solicitação no formato “origin ”.
• Se esta 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 para esperar entre as tentativas de verificação de saúde. Por padrão, esse valor é configurado como 5 e tem no mínimo 2 e no máximo 60. Esse valor deve ser maior que o valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que é configurado como 2 por padrão.

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

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

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

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

Ativando verificações de funcionamento do TCP para balanceadores de carga UDP

Como não há verificações de funcionamento do UDP, os balanceadores de carga UDP que usam verificações de funcionamento do TCP devem ter uma porta TCP adicional especificada com a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp.

É possível especificar a porta do nó TCP para outro balanceador de carga ou NodePort em execução em seu cluster. No entanto, se a porta do nó residir fora do intervalo 30000-32767, você deverá modificar o grupo de segurança do cluster VPC kube-<cluster-ID> para permitir o tráfego recebido até a porta especificada.

Observe que, se o valor de porta especificado for para um serviço que ficar fora do ar inesperadamente ou cujo valor de porta for reconfigurado, as verificações de integridade do TCP deixarão de funcionar até que o serviço volte a funcionar ou você reconfigure a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp com um novo valor de porta TCP. Para evitar isso, é possível especificar a porta kubelet 10250, que é um valor de porta estática que não passa por interrupções de serviço. No entanto, deve-se modificar o grupo de segurança do cluster VPC kube-<cluster-ID> para aceitar o tráfego recebido da porta kubelet.

Quer evitar a complexidade de especificar portas adicionais do TCP para verificações de integridade em um balanceador de carga UDP? Configure externalTrafficPolicy como Local para usar verificações de funcionamento HTTP, que não requerem especificações de porta adicionais.