Antes de Iniciar

Conclua os pré-requisitos do NLB 2.0 antes de continuar.

• Para criar NLBs públicos em diversas zonas, pelo menos uma VLAN pública deve ter sub-redes móveis disponíveis em cada zona. Para criar NLBs privados em diversas zonas, pelo menos uma VLAN privada deverá ter sub-redes portáteis disponíveis em cada zona. É possível incluir sub-redes seguindo as etapas em Configurando sub-redes para clusters.

• Assegure-se de ter a função de acesso de serviço Gravador ou Gerenciador do IBM Cloud IAM para o namespace default.

• Assegure-se de que você tenha o número necessário de nós do trabalhador:

  • Clusters clássicos: se você restringir o tráfego de rede aos nós do trabalhador de borda, assegure-se de que pelo menos dois nós do trabalhador de borda estejam ativados em cada zona para que o NLBs implemente uniformemente.

• Quando os nós do cluster são recarregados ou quando uma atualização principal de cluster inclui uma nova imagem keepalived, o IP virtual do balanceador de carga é movido para a interface de rede de um novo nó. Quando isso ocorrer, quaisquer conexões duradouras com o seu balanceador de carga deverão ser restabelecidas. Considere incluir uma lógica de repetição de tentativas em seu aplicativo, para que as tentativas de restabelecer a conexão sejam realizadas rapidamente.

Para configurar um NLB 2.0 em um cluster multizona:

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

2. Crie um serviço de balanceador de carga para o app que você deseja expor para a Internet pública ou uma rede privada.

   1. Crie um arquivo de configuração de serviço que seja chamado, por exemplo, de myloadbalancer.yaml.
   2. Defina um serviço de balanceador de carga para o app que você deseja expor. É possível especificar uma zona, uma VLAN e um endereço IP.

       apiVersion: v1
       kind: Service
       metadata:
         name: myloadbalancer
         annotations:
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
           service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
       spec:
         type: LoadBalancer
         selector:
           <selector_key>: <selector_value>
         ports:
          - protocol: TCP
            port: 8080
            targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
         loadBalancerIP: <IP_address>
         externalTrafficPolicy: Local
       ```
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
       :   Anotação para especificar um balanceador de carga `private` ou `public`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-zone`
       :   Anotação para especificar a zona na qual o serviço de balanceador de carga é implementado. Para ver zonas, execute `ibmcloud oc zone ls`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan`
       :   Anotação para especificar uma VLAN na qual o serviço de balanceador de carga é implementado. Para ver VLANs, execute `ibmcloud oc vlan ls --zone ZONE`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"`
       :   Anotação para especificar um balanceador de carga da versão 2.0.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler`
       :   Opcional: anotação para especificar o algoritmo de planejamento. Os valores aceitos são `"rr"` para o método round-robin (padrão) ou `"sh"` para o método Source Hashing. Para obter mais informações, consulte [2.0: planejando algoritmos](#scheduling).
   
       `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.
   
       `port`
       :   A porta na qual o serviço atende.
   
       `loadBalancerIP`
       :   Opcional: para criar um NLB privado ou para usar um endereço IP móvel específico para um NLB público, especifique o endereço IP que você deseja usar. O endereço IP deve estar na zona e na VLAN que você especificar nas anotações. Se você não especificar um endereço IP:
           :   Se o seu cluster estiver em uma VLAN pública, um endereço IP móvel público será usado. A maioria dos clusters está em uma VLAN pública.
           :   Se seu cluster estiver somente em uma VLAN privada, um endereço IP privado móvel será usado.
   
       `externalTrafficPolicy: Local`
       :   Configure para `Local`.
   
   
       Exemplo de arquivo de configuração para criar um serviço NLB 2.0 no `dal12` que utiliza o algoritmo de agendamento round-robin:
   
       ```yaml {: codeblock}
       apiVersion: v1
       kind: Service
       metadata:
         name: myloadbalancer
         annotations:
           service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "rr"
       spec:
         type: LoadBalancer
         selector:
           app: nginx
         ports:
          - protocol: TCP
            port: 8080
            targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
         externalTrafficPolicy: Local
       ```
   3. Opcional: Torne seu serviço NLB disponível apenas para um intervalo limitado de endereços IP, especificando os endereços IP no campo “ `spec.loadBalancerSourceRanges` ”. O recurso “ `loadBalancerSourceRanges` ” é implementado pelo “ `kube-proxy` ” em seu cluster por meio de regras do iptables nos nós de trabalho. Para obter mais informações, consulte a [Documentação do Kubernetes](https://kubernetes.io/docs/concepts/services-networking/){: external}.
   
   4. Crie o serviço em seu cluster.
   
   ```sh {: pre}
       oc apply -f myloadbalancer.yaml
       ```
   

3. Verifique se o serviço do NLB foi criado com êxito. Pode levar alguns minutos para que o serviço NLB seja criado corretamente e o app fique disponível.

   oc describe service myloadbalancer
   

   Saída de exemplo:

   NAME:                   myloadbalancer
   Namespace:              default
   Labels:                 <none>
   Selector:               app=liberty
   Type:                   LoadBalancer
   Zone:                   dal10
   IP:                     172.21.xxx.xxx
   LoadBalancer Ingress:   169.xx.xxx.xxx
   Port:                   <unset> 8080/TCP
   NodePort:               <unset> 32040/TCP
   Endpoints:              172.30.xxx.xxx:8080
   Session Affinity:       None
   Events:
       FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
       ---------    --------    -----    ----            -------------    ----     ------                      -------
       10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
       10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer
   

   O endereço IP do LoadBalancer Ingress é o endereço IP móvel que foi designado para o seu serviço do NLB.

4. Se você criou um NLB público, acesse o seu app por meio da Internet.

   1. Abra seu navegador da web preferencial.
   2. Insira o endereço IP público móvel do NLB e da porta.

       http://169.xx.xxx.xxx:8080
       ```
   

5. Para obter alta disponibilidade, repita as etapas 2 a 4 para adicionar um 2.0 NLB em cada zona onde houver instâncias do aplicativo.

6. Opcional: um serviço do NLB também torna o seu app disponível por meio dos NodePorts do serviço. NodePorts são acessíveis em cada endereço IP público e privado para cada nó dentro do cluster. Para bloquear o tráfego para NodePorts enquanto você estiver usando um serviço do NLB, consulte Controlando o tráfego de entrada para os serviços do balanceador de carga de rede (NLB) ou do NodePort.

Em seguida, é possível registrar um subdomínio do NLB.

Antes de Iniciar

Conclua os pré-requisitos do NLB 2.0 antes de continuar.

• Deve-se ter um endereço IP público ou privado móvel disponível para designar ao serviço NLB. Para obter mais informações, consulte Configurando sub-redes para clusters.

• Assegure-se de ter a função de acesso de serviço Gravador ou Gerenciador do IBM Cloud IAM para o namespace default.

• Quando os nós do cluster são recarregados ou quando uma atualização principal de cluster inclui uma nova imagem keepalived, o IP virtual do balanceador de carga é movido para a interface de rede de um novo nó. Quando isso ocorrer, quaisquer conexões duradouras com o seu balanceador de carga deverão ser restabelecidas. Considere incluir uma lógica de repetição de tentativas em seu aplicativo, para que as tentativas de restabelecer a conexão sejam realizadas rapidamente.

Para criar um serviço NLB 2.0 em um cluster de zona única:

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 serviço de balanceador de carga para o app que você deseja expor para a Internet pública ou uma rede privada.

   1. Crie um arquivo de configuração de serviço que seja chamado, por exemplo, de myloadbalancer.yaml.

   2. Defina um serviço de balanceador de carga 2.0 para o app que você deseja expor.

       apiVersion: v1
       kind: Service
       metadata:
         name: myloadbalancer
         annotations:
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
           service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
           service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
       spec:
         type: LoadBalancer
         selector:
           <selector_key>: <selector_value>
         ports:
          - protocol: TCP
            port: 8080
            targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
         loadBalancerIP: <IP_address>
         externalTrafficPolicy: Local
       ```
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
       :   Anotação para especificar um balanceador de carga `private` ou `public`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan`
       :   Opcional: anotação para especificar uma VLAN para a qual o serviço do balanceador de carga implementa. Para ver VLANs, execute `ibmcloud oc vlan ls --zone ZONE`.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"`
       :   Anotação para especificar um balanceador de carga 2.0.
   
       `service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler`
       :   Opcional: anotação para especificar um algoritmo de planejamento. Os valores aceitos são `"rr"` para o método round-robin (padrão) ou `"sh"` para o método Source Hashing. Para obter mais informações, consulte [2.0: planejando algoritmos](#scheduling).
   
   
       `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.
   
   
       `port`
       :   A porta na qual o serviço atende.
   
   
       `loadBalancerIP`
       :   Opcional: para criar um NLB privado ou para usar um endereço IP móvel específico para um NLB público, especifique o endereço IP que você deseja usar. O endereço IP deve estar na VLAN que você especifica nas anotações. Se você não especificar um endereço IP:
           - Se o seu cluster estiver em uma VLAN pública, um endereço IP móvel público será usado. A maioria dos clusters está em uma VLAN pública.
           - Se seu cluster estiver somente em uma VLAN privada, um endereço IP privado móvel será usado.
   
   
       `externalTrafficPolicy: Local`
       :   Configure para `Local`.
   
   3. Opcional: Torne seu serviço NLB disponível apenas para um intervalo limitado de endereços IP, especificando os endereços IP no campo “ `spec.loadBalancerSourceRanges` ”. O recurso “ `loadBalancerSourceRanges` ” é implementado pelo “ `kube-proxy` ” em seu cluster por meio de regras do iptables nos nós de trabalho. Para obter mais informações, consulte a [Documentação do Kubernetes](https://kubernetes.io/docs/concepts/services-networking/){: external}.
   
   4. Crie o serviço em seu cluster.
   
   ```sh {: pre}
       oc apply -f myloadbalancer.yaml
       ```
   

3. Verifique se o serviço do NLB foi criado com êxito. Pode levar alguns minutos para que o serviço seja criado e para que o app fique disponível.

   oc describe service myloadbalancer
   

   Saída de exemplo:

   NAME:                   myloadbalancer
   Namespace:              default
   Labels:                 <none>
   Selector:               app=liberty
   Type:                   LoadBalancer
   Location:               dal10
   IP:                     172.21.xxx.xxx
   LoadBalancer Ingress:   169.xx.xxx.xxx
   Port:                   <unset> 8080/TCP
   NodePort:               <unset> 32040/TCP
   Endpoints:              172.30.xxx.xxx:8080
   Session Affinity:       None
   Events:
       FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
       ---------    --------    -----    ----            -------------    ----     ------                      -------
       10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
       10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer
   

   O endereço IP do LoadBalancer Ingress é o endereço IP móvel que foi designado para o seu serviço do NLB.

4. Se você criou um NLB público, acesse o seu app por meio da Internet.

   1. Abra seu navegador da web preferencial.
   2. Insira o endereço IP público móvel do NLB e da porta.

       http://169.xx.xxx.xxx:8080
       ```
   

5. Opcional: um serviço do NLB também torna o seu app disponível por meio dos NodePorts do serviço. NodePorts são acessíveis em cada endereço IP público e privado para cada nó dentro do cluster. Para bloquear o tráfego para NodePorts enquanto você estiver usando um serviço do NLB, consulte Controlando o tráfego de entrada para os serviços do balanceador de carga de rede (NLB) ou do NodePort.

Em seguida, é possível registrar um subdomínio do NLB.

Algoritmos de planejamento suportados

Round Robin (rr)

Os ciclos NLB através da lista de pods do app ao roteirização de conexões com nós do trabalhador, tratando cada pod do app igualmente. round-robin é o algoritmo de agendamento padrão para a versão 2.0 NLBs.

Source Hashing (sh)

O NLB gera uma chave de hash com base no endereço IP de origem do pacote de solicitações do cliente. O NLB, em seguida, consulta a chave de hash em uma hashtable designada estaticamente e roteia a solicitação para o pod do app que manipula as hashes desse intervalo. Esse algoritmo assegura que as solicitações de um determinado cliente sejam sempre direcionadas para o mesmo pod do app. O Kubernetes usa regras do Iptables que fazem com que as solicitações sejam enviadas para um pod aleatório no trabalhador. Para usar esse algoritmo de planejamento, deve-se assegurar que não mais que um pod de seu app seja implementado por nó do trabalhador. Por exemplo, se cada pod tiver o rótulo run=<app_name>, inclua a regra de antiafinidade a seguir na seção spec da sua implementação do app:

spec:
  affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: run
            operator: In
            values:
            - <APP_NAME>
        topologyKey: kubernetes.io/hostname

Algoritmos de planejamento não suportados

Destination Hashing (dh)

O destino do pacote, que é o endereço IP e a porta do NLB, é usado para determinar qual nó do trabalhador manipula a solicitação recebida. No entanto, o endereço IP e a porta para NLBs no Red Hat OpenShift on IBM Cloud não mudam. O NLB é forçado a manter a solicitação dentro do mesmo nó do trabalhador no qual ele está, portanto, apenas pods de app que estão em um único trabalhador manipulam todas as solicitações recebidas.

Algoritmos de contagem de conexão dinâmica

Os algoritmos a seguir dependem da contagem dinâmica de conexões entre clientes e NLBs. No entanto, como o retorno de serviço direto (DSR) evita que os pods NLB 2.0 fiquem no caminho do pacote de devolução, os NLBs não rastreiam conexões estabelecidas.

• Least Connection (lc)
• Locality-Based Least Connection (lblc)
• Locality-Based Least Connection with Replication (lblcr)
• Never Queue (nq)
• Shortest Expected Delay (seq)

Algoritmos de pod ponderados

Os algoritmos a seguir dependem de pods de app ponderados. No entanto, no Red Hat OpenShift on IBM Cloud, todos os pods de app são designados a igual peso para balanceamento de carga.

• Weighted Least Connection (wlc)
• Round-robin ponderado (wrr)