Clássico: configurando o balanceamento de carga básico com um NLB 1.0

Os NLBs da versão 1.0 podem ser criados apenas em clusters clássicos e não podem ser criados em clusters de VPC. Para balancear a carga em clusters VPC, consulte Expondo apps com balanceadores de carga para VPC.

Exponha uma porta e use um endereço IP móvel para um balanceador de carga de rede da camada 4 (NLB) para expor um app conteinerizado. Para obter informações sobre os NLBs versão 1.0, consulte Componentes e arquitetura de um NLB 1.0.

Configurando um NLB 1.0 em um cluster multizona

Antes de Iniciar

Para criar balanceadores de carga de rede (NLBs) pública 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.
Ative um Virtual Router Function (VRF) para a sua conta de infraestrutura do IBM Cloud. Para ativar o VRF, consulte Ativando o VRF. Para verificar se um VRF já está ativado, use o comando ibmcloud account show. Se não puder ou não quiser ativar a VRF, ative a Ampliação de VLAN. Quando um VRF ou um VLAN Spanning é ativado, o NLB 1.0 pode rotear pacotes para diversas sub-redes na conta.
Verifique se você tem a função de acesso de serviço Gravador ou Gerenciador do IBM CloudIAM 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 feitas rapidamente.

Para configurar um serviço NLB 1.0 em um cluster multizona:

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.

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

Crie um arquivo de configuração de serviço que seja chamado, por exemplo, de myloadbalancer.yaml.
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>"
    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>
    ```

    `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
    :   Anotação para especificar um balanceador de carga `private` ou `public`. Se essa anotação não for especificada e os nós do trabalhador forem conectados a VLANs públicas, um serviço público `LoadBalancer` será criado. Se seus nós do trabalhador estiverem conectados a VLANs privadas somente, um serviço `LoadBalancer` privado será criado.

    `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 ks 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 ks vlan ls --zone <zone>`.

    `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 balanceador de carga privado ou para usar um endereço IP móvel específico para um balanceador de carga público, especifique o endereço IP que você deseja usar. O endereço IP deve estar na VLAN e na zona 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.

    Exemplo de arquivo de configuração para criar um serviço NLB 1.0 privado que usa um endereço IP especificado na VLAN privada `2234945` em `dal12`:

    ```yaml {: codeblock}
    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
        service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
    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.
      loadBalancerIP: 172.21.xxx.xxx
    ```
3. Opcional: Torne seu serviço NLB disponível apenas para um intervalo limitado de endereços IP, especificando os endereços no campo “ `spec.loadBalancerSourceRanges` ”. A restrição de endereços de origem ( `loadBalancerSourceRanges` ) é implementada por meio da restrição de endereços de origem ( `kube-proxy` ) em seu cluster, utilizando 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}
    kubectl apply -f myloadbalancer.yaml
    ```

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.

kubectl 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

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
    ```
```
Repita as etapas 2 a 4 para adicionar um NLB do tipo “ 1.0 ” em cada zona.
Se você escolher ativar a preservação de IP de origem para um NLB 1.0, assegure-se de que os pods do app sejam planejados nos nós do trabalhador de borda incluindo a afinidade do nó de borda em pods do app. Os pods do app devem ser planejados nos nós de borda para obter solicitações recebidas.
Opcional: um serviço do balanceador de carga também disponibiliza o seu app sobre as 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.

Configurando um NLB 1.0 em um cluster de zona única

Antes de Iniciar

Deve-se ter um endereço IP público ou privado móvel disponível para designar ao serviço de balanceador de carga de rede (NLB). Para obter mais informações, consulte Configurando sub-redes para clusters.
Verifique se você tem a função de acesso de serviço Gravador ou Gerenciador do IBM CloudIAM 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 feitas rapidamente.

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

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.

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

Crie um arquivo de configuração de serviço que seja chamado, por exemplo, de myloadbalancer.yaml.
Defina um serviço de balanceador de carga 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>"
    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>
    ```
    `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`
    :   Anotação para especificar uma VLAN na qual o serviço de balanceador de carga é implementado. Para ver VLANs, execute `ibmcloud ks vlan ls --zone <zone>`.

    `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 balanceador de carga privado ou para usar um endereço IP móvel específico para um balanceador de carga 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.

    Exemplo de arquivo de configuração para criar um serviço NLB 1.0 privado que usa um endereço IP especificado na VLAN privada `2234945`:

    ```yaml {: codeblock}
    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
    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.
      loadBalancerIP: 172.21.xxx.xxx
    ```
3. Opcional: Torne seu serviço NLB disponível apenas para um intervalo limitado de endereços IP, especificando os endereços no campo “ `spec.loadBalancerSourceRanges` ”. A restrição de endereços de origem ( `loadBalancerSourceRanges` ) é implementada por meio da restrição de endereços de origem ( `kube-proxy` ) em seu cluster, utilizando 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}
    kubectl apply -f myloadbalancer.yaml
    ```

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.

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

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
    ```
```
Se você escolher ativar a preservação de IP de origem para um NLB 1.0, assegure-se de que os pods do app sejam planejados nos nós do trabalhador de borda incluindo a afinidade do nó de borda em pods do app. Os pods do app devem ser planejados nos nós de borda para obter solicitações recebidas.
Opcional: um serviço do balanceador de carga também disponibiliza o seu app sobre as 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.

Ativando a preservação de IP de origem

Esse recurso destina-se somente a balanceadores de carga de rede (NLBs) da versão 1.0. O endereço IP de origem de solicitações do cliente é preservado por padrão em NLBs da versão 2.0.

Quando uma solicitação do cliente para seu app é enviada para seu cluster, um pod de serviço de balanceador de carga recebe a solicitação. Se nenhum pod de app existir no mesmo nó do trabalhador que o pod de serviço do balanceador de carga, o NLB encaminhará a solicitação para um nó do trabalhador diferente. O endereço IP de origem da solicitação é alterado para o endereço IP público do nó de trabalho no qual o pod do serviço de balanceador de carga é executado.

Para preservar o endereço IP de origem original da solicitação do cliente, é possível ativar o IP de origem para serviços de balanceador de carga. A conexão TCP continua todo o caminho para os pods de app para que o app possa ver o endereço IP de origem real do inicializador. Preservar o IP do cliente é útil, por exemplo, quando os servidores de app precisam aplicar as políticas de segurança e de controle de acesso.

Após a ativação do IP de origem, os pods do serviço de balanceador de carga devem encaminhar solicitações para pods do app que são implementados no mesmo nó do trabalhador somente. Geralmente, os pods de serviço de balanceador de carga também são implementados para os nós do trabalhador nos quais os pods de app são implementados. No entanto, existem algumas situações em que os pods do balanceador de carga e os pods do app podem não ser planejados no mesmo nó do trabalhador:

Você tem nós de borda que estão contaminados para que somente pods do serviço de balanceador de carga possam ser implementados neles. Pods do app não podem ser implementados nesses nós.
O seu cluster está conectado a diversas VLANs públicas ou privadas e os pods de seu app podem ser implementados em nós do trabalhador conectados apenas a uma VLAN. Os pods de serviço do balanceador de carga podem não ser implementados nesses nós do trabalhador porque o endereço IP do NLB está conectado a uma VLAN diferente do que os nós do trabalhador.

Para forçar seu app a ser implementado em nós do trabalhador específicos nos quais os pods de serviço de balanceador de carga também podem ser implementados, deve-se incluir regras de afinidade e tolerâncias em sua implementação do app.

Incluindo regras de afinidade e tolerâncias de nó de borda

Ao rotular nós do trabalhador como nós de borda e também contaminar os nós de borda, os pods do serviço de balanceador de carga implementam somente nesses nós de borda e os pods de app não podem implementar em nós de borda. Quando o IP de origem é ativado para o serviço NLB, os pods do balanceador de carga nos nós de borda não podem encaminhar as solicitações recebidas para os pods de app em outros nós do trabalhador.

Para forçar os pods do app a implementar em nós de borda, inclua uma regra de afinidade e uma tolerância na implementação do app.

Exemplo de arquivo YAML de implementação com afinidade de nó de borda e tolerância do nó de borda:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  selector:
    matchLabels:
      <label_name>: <label_value>
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: dedicated
                operator: In
                values:
                - edge
      tolerations:
        - key: dedicated
          value: edge
...

As seções affinity e tolerations têm, ambas, dedicated como key e edge como value.

Incluindo regras de afinidade para diversas VLANs públicas ou privadas

Quando o cluster está conectado a diversas VLANs públicas ou privadas, os pods do app podem ser implementados nos nós do trabalhador que são conectados apenas a uma VLAN. Se o endereço IP do NLB estiver conectado a uma VLAN diferente do que esses nós do trabalhador, os pods do serviço do balanceador de carga não serão implementados nesses nós do trabalhador.

Quando o IP de origem estiver ativado, planeje os pods de app em nós do trabalhador que estejam na mesma VLAN que o endereço IP do NLB incluindo uma regra de afinidade na implementação do app.

Antes de Iniciar:

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Obtenha o endereço IP do serviço NLB. Procure o endereço IP no campo Ingress do LoadBalancer.
```
kubectl describe service <loadbalancer_service_name>
```

Recupere o ID da VLAN à qual seu serviço NLB está conectado.

Liste as VLANs públicas móveis para seu cluster.

    ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources
    ```
    Saída de exemplo
    ```sh {: screen}
    ...
    Subnet VLANs
    VLAN ID   Subnet CIDR       Public   User-managed
    2234947   10.xxx.xx.xxx/29  false    false
    2234945   169.36.5.xxx/29   true     false
    ```
2. Na saída em **VLANs de sub-rede**, procure o CIDR de sub-rede que corresponda ao endereço IP do NLB recuperado anteriormente e anote o ID da VLAN.

    Por exemplo, se o endereço IP do serviço NLB for `169.36.5.xxx`, a sub-rede correspondente na saída de exemplo da etapa anterior será `169.36.5.xxx/29`. O ID da VLAN ao qual a sub-rede está conectada é `2234945`.

Inclua uma regra de afinidade na implementação do app para o ID de VLAN observado na etapa anterior.

Por exemplo, se você tiver diversas VLANs, mas quiser que os pods de seu app sejam implementados nos nós do trabalhador somente na VLAN pública 2234945:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  selector:
    matchLabels:
      <label_name>: <label_value>
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: publicVLAN
                operator: In
                values:
                - "2234945"
...

No YAML de exemplo, a seção affinity tem publicVLAN como key e "2234945" como value.

Aplique o arquivo de configuração de implementação atualizado.
```
kubectl apply -f with-node-affinity.yaml
```

Verifique se os pods do app implementados nos nós do trabalhador estão conectados à VLAN designada.

Liste os pods em seu cluster. Substitua <selector> pelo rótulo usado para o app.

    kubectl get pods -o wide app=<selector>
    ```
    Saída de exemplo
    ```sh {: screen}
    NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
    cf-py-d7b7d94db-vp8pq  1/1       Running             0          10d       172.30.xxx.xxx   10.176.48.78
    ```
2. Na saída, identifique um pod para seu app. Observe o ID de **NÓ** do nó do trabalhador no qual o pod está.

    Na saída de exemplo da etapa anterior, o pod de app `cf-py-d7b7d94db-vp8pq` está no nó do trabalhador `10.176.48.78`.

3. Liste os detalhes para o nó do trabalhador.

```sh {: pre}
    kubectl describe node <worker_node_ID>
    ```
    Saída de exemplo

    ```sh {: screen}
    NAME:                   10.xxx.xx.xxx
    Role:
    Labels:                 arch=amd64
    beta.kubernetes.io/arch=amd64
    beta.kubernetes.io/os=linux
    failure-domain.beta.kubernetes.io/region=us-south
    failure-domain.beta.kubernetes.io/zone=dal10
    ibm-cloud.kubernetes.io/encrypted-docker-data=true
    kubernetes.io/hostname=10.xxx.xx.xxx
    privateVLAN=2234945
    publicVLAN=2234967
    ...
    ```
4. Na seção **Rótulos** da saída, verifique se a VLAN pública ou privada é a VLAN que você designou nas etapas anteriores.