Configurar balanceadores de carga em pacote com o BGP

Neste documento, você verá como configurar e usar balanceadores de carga com o protocolo de gateway de borda (BGP, na sigla em inglês) em clusters para Anthos em bare metal. Esse modo de balanceamento de carga é compatível com a divulgação de endereços IP virtuais (VIPs, na sigla em inglês) para o ServiceType LoadBalancer usando o protocolo de gateway de borda externo (eBGP, na sigla em inglês) para seus clusters. Nesse cenário, a rede de clusters é um sistema autônomo, que se interconecta com outro sistema autônomo, uma rede externa, por peering.

Os balanceadores de carga em pacote com o recurso BGP se aplicam a todos os tipos de clusters, mas os clusters de administrador só são compatíveis com a parte do balanceamento de carga do plano de controle desse recurso.

O uso dos balanceadores de carga em pacote com o recurso BGP oferece os seguintes benefícios:

  • Usa o recurso de balanceamento de carga ativo/ativo N-way, com failover mais rápido e uso mais eficiente da largura de banda disponível.
  • É compatível com o protocolo de camada 3, que interopera com roteadores e switches de topo de rack (ToR, na sigla em inglês) de terceiros compatíveis com o eBGP.
  • Permite que data centers que executam uma pilha avançada de rede definida por software (SDN, na sigla em inglês) excedam o limite da camada 3 até os clusters.

Como funciona o balanceamento de carga em pacote com o BGP

Nas seções a seguir, você verá um breve resumo de como funcionam os balanceadores de carga em pacote com o BGP.

Peering do BGP

O recurso de balanceadores de carga em pacote com o BGP inicia várias conexões BGP com a infraestrutura. O BGP tem os seguintes requisitos técnicos:

  • As sessões de peering são separadas entre VIPs do plano de controle e VIPs de serviço.
  • As sessões de peering do plano de controle são iniciadas a partir dos endereços IP dos nós do plano de controle.
  • As sessões de peering de serviço são iniciadas a partir de endereços IP flutuantes especificados no recurso personalizado AnthosNetworkGateway.
  • O controlador do gateway de rede do Anthos gerencia os endereços IP flutuantes.
  • O balanceamento de carga em pacote baseado em BGP é compatível apenas com peering eBGP.
  • O peering de vários saltos é aceito por padrão.
  • As senhas MD5 nas sessões do BGP não são suportadas.
  • As sessões de peering baseadas em IPv6 não são suportadas.
  • Rotas anunciadas para qualquer peering devem ser redistribuídas em toda a rede e acessíveis em qualquer outro ponto do cluster.
  • O uso do recurso ADD-PATH do BGP no modo de recebimento é altamente recomendado para sessões de peering.
  • Anunciar vários caminhos de cada peering resulta no balanceamento de carga ativo/ativo.
  • O roteamento de vários caminhos de custo igual (ECMP, na sigla em inglês) precisa estar ativado na rede. Assim, vários caminhos podem ser usados na distribuição do tráfego por um conjunto de nós do balanceador de carga.

Balanceamento de carga do plano de controle

Cada nó do plano de controle no cluster estabelece sessões do BGP com um ou mais peerings na infraestrutura. É preciso que cada nó do plano de controle tenha pelo menos um peering. No arquivo de configuração do cluster, é possível definir quais nós do plano de controle se conectam a quais peerings externos.

O diagrama a seguir mostra um exemplo de peering do plano de controle. O cluster tem dois nós do plano de controle em uma sub-rede e um nó em outra. Há um peering externo (TOR) em cada sub-rede e os clusters do Anthos em nós do plano de controle bare metal fazem peering com o respectivo TOR.

Balanceamento de carga de serviço com peering do BGP

Balanceamento de carga de serviço

Além das sessões de peering iniciadas a partir de cada nó do plano de controle para o peering do plano de controle, outras sessões de peering são iniciadas para os serviços de LoadBalancer. Essas sessões de peering não são iniciadas diretamente dos IPs de nós do cluster, mas usam IPs flutuantes.

Os serviços que têm uma política de rede externalTrafficPolicy=Local não são compatíveis.

Endereços de IP flutuantes

O balanceamento de carga de serviço exige a reserva de endereços IP flutuantes nas sub-redes de nós do cluster para uso no peering do BGP. É necessário pelo menos um endereço IP flutuante para o cluster, mas recomendamos reservar, no mínimo, dois endereços a fim de garantir alta disponibilidade nas sessões do BGP. Os endereços IP flutuantes são especificados no recurso personalizado (CR, na sigla em inglês) AnthosNetworkGateway, que pode ser incluído no arquivo de configuração do cluster.

Com os endereços IP flutuantes, você não precisa se preocupar com o mapeamento de endereços IP do locutor do BGP para os nós. O controlador do gateway de rede do Anthos se encarrega da atribuição de AnthosNetworkGateway aos nós e também gerencia os endereços IP flutuantes. Se um nó ficar inativo, o controlador do gateway de rede do Anthos atribuirá novamente os endereços IP flutuantes para garantir que os peerings externos tenham um endereço IP determinista para fazer peering.

Peerings externos

É possível especificar os peerings externos usados em sessões de peering com os endereços IP flutuantes no recurso personalizado BGPLoadBalancer, que você adiciona ao arquivo de configuração do cluster. Os peerings externos podem ser os mesmos especificados para o peering do plano de controle na seção loadBalancer.controlPlaneBGP do arquivo de configuração do cluster, mas também é possível especificar peerings diferentes.

O controlador do gateway de rede do Anthos tenta estabelecer duas sessões para cada peering externo a partir do conjunto de endereços IP flutuantes reservados. Recomendamos especificar pelo menos dois peerings externos para garantir alta disponibilidade nas sessões do BGP. Cada peering externo designado para o balanceamento de carga de serviço precisa ser configurado para fazer peering com cada endereço IP flutuante especificado no recurso personalizado AnthosNetworkGateway.

Nós do balanceador de carga

Um subconjunto de nós do cluster é usado no balanceamento de carga, o que significa que eles são os nós divulgados para aceitar o tráfego de entrada do balanceamento de carga. Esse conjunto de nós assume como padrão o pool de nós do plano de controle, mas é possível especificar outro pool de nós na seção loadBalancer do arquivo de configuração do cluster. Se você especificar um pool de nós, ele será usado para os nós do balanceador de carga, e não o pool de nós do plano de controle.

Os endereços IP flutuantes, que funcionam como locutores do BGP, podem ou não ser executados nos nós do balanceador de carga. Os endereços IP flutuantes são atribuídos a um nó na mesma sub-rede. Nele, o peering é iniciado, independentemente de ser um nó de balanceador de carga. No entanto, os próximos saltos divulgados no BGP são sempre os nós do balanceador de carga.

Exemplo de topologia de peering

O diagrama a seguir mostra um exemplo de balanceamento de carga de serviço com peering do BGP. Há dois endereços IP flutuantes atribuídos aos nós nas respectivas sub-redes. Há dois peerings externos definidos. Cada IP flutuante faz peering com ambos os peerings externos.

Balanceamento de carga de serviço com peering do BGP

Configurar o balanceador de carga do BGP

As seções a seguir explicam como configurar os clusters e a rede externa para usar o balanceador de carga em pacote com o BGP.

Planejar a integração com a infraestrutura externa

Para usar o balanceador de carga em pacote com o BGP, configure a infraestrutura externa:

  • A infraestrutura externa deve ser configurada para fazer peering com cada nó do plano de controle no cluster para definir a comunicação do plano de controle. Essas sessões de peering são usadas para divulgar os VIPs do plano de controle do Kubernetes.

  • A infraestrutura externa deve ser configurada para fazer peering com um conjunto de endereços IP flutuantes reservados para a comunicação do plano de dados. Os endereços IP flutuantes são usados para o peering do BGP com os VIPs de serviço. Recomendamos usar dois endereços IP flutuantes e dois peerings para garantir alta disponibilidade nas sessões do BGP. O processo de reserva de IP flutuante é descrito como parte da configuração do cluster para balanceamento de carga em pacote com o BGP.

Depois de configurar a infraestrutura, adicione as informações de peering do BGP ao arquivo de configuração do cluster. O cluster criado pode iniciar sessões de peering com a infraestrutura externa.

Configurar o cluster para balanceamento de carga em pacote com o BGP

Ao criar um cluster, você deve ativar e configurar o balanceamento de carga em pacote com o BGP no arquivo de configuração do cluster.

  1. Adicione a anotação baremetal.cluster.gke.io/enable-anthos-network-gateway ao arquivo de configuração do cluster e defina-a como true.

    Essa anotação ativa o controlador do gateway de rede do Anthos.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
  # This annotation is required for BGP load balancer
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
spec:
...

  2. Na seção loadBalancer do arquivo de configuração do cluster, defina mode como bundled e adicione um campo type com um valor de bgp.

    Esses valores de campo permitem o balanceamento de carga em pacote baseado em BGP.

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. Para especificar as informações de peering do BGP para o plano de controle, adicione os seguintes campos à seção loadBalancer:

        ...
    # AS number for the cluster
    localASN: CLUSTER_ASN

    # List of BGP peers used for the control plane peering sessions.
    bgpPeers:
    - ip: PEER_IP
      asn: PEER_ASN
      # optional; if not specified, all CP nodes connect to all peers.
      controlPlaneNodes:   # optional
      - CP_NODE_IP
...

    Substitua:

    • CLUSTER_ASN: o número do sistema autônomo para o cluster que está sendo criado.
    • PEER_IP: o endereço IP do dispositivo de peering externo.
    • PEER_ASN: o número do sistema autônomo da rede que contém o dispositivo de peering externo.
    • CP_NODE_IP (opcional): o endereço IP do nó do plano de controle que se conecta ao peering externo. Se você não especificar nenhum nó do plano de controle, todos os nós do plano de controle poderão se conectar ao peering externo. Se você especificar um ou mais endereços IP, apenas os nós especificados participarão das sessões de peering.

    Você pode especificar vários peerings externos, bgpPeers recebe uma lista de mapeamentos. Recomendamos especificar pelo menos dois peerings externos para alta disponibilidade nas sessões do BGP. Veja um exemplo com vários peerings em Configurações de exemplo.

    Essa configuração de peering do BGP para o plano de controle não pode ser atualizada após a criação do cluster.

  4. Defina os campos loadBalancer.ports, loadBalancer.vips e loadBalancer.addressPools (valores padrão exibidos).

    ...
  loadBalancer:
  ...
    # Other existing load balancer options remain the same
    ports:
      controlPlaneLBPort: 443
    # When type=bgp, the VIPs are advertised over BGP
    vips:
      controlPlaneVIP: 10.0.0.8
      ingressVIP: 10.0.0.1

    addressPools:
    - name: pool1
      addresses:
      - 10.0.0.1-10.0.0.4
...

  5. Especifique o nó do cluster a ser usado no balanceamento de carga do plano de dados.

    Este passo é opcional. Se você não remover a marca de comentário da seção nodePoolSpec, os nós do plano de controle serão usados para o balanceamento de carga do plano de dados.

    ...
  # Node pool used for load balancing data plane (nodes where incoming traffic
  # arrives. If not specified, this defaults to the control plane node pool.
  # nodePoolSpec:
  #   nodes:
  #   - address: <Machine 1 IP>
...

  6. Reserve endereços IP flutuantes configurando o recurso personalizado AnthosNetworkGateway:

    Os endereços IP flutuantes são usados em sessões de peering para o balanceamento de carga do plano de dados.

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
...

    Substitua:

    • CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces do cluster para os clusters do Anthos em bare metal são o nome do cluster precedido por cluster-. Por exemplo, se você chamar seu cluster de test, o namespace será cluster-test.
    • FLOATING_IP: um endereço IP de uma das sub-redes do cluster. É preciso especificar pelo menos um endereço IP, mas recomendamos que você especifique pelo menos dois endereços IP.

    Veja um exemplo da especificação de recurso personalizado AnthosNetworkGateway em Configurações de exemplo.

  7. Especifique as informações de peering do BGP para o plano de dados configurando o recurso personalizado BGPLoadBalancer:

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: CLUSTER_NAMESPACE
spec:
  localASN: CLUSTER_ASN
  peers:
  - peerIP: PEER_IP
    peerASN: PEER_ASN
    ...

    Substitua:

    • CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces do cluster para os clusters do Anthos em bare metal são o nome do cluster precedido por cluster-. Por exemplo, se você chamar seu cluster de test, o namespace será cluster-test.
    • CLUSTER_ASN: o número do sistema autônomo para o cluster que está sendo criado.
    • PEER_IP: o endereço IP do dispositivo de peering externo. Ainda que o mínimo seja um peering externo, recomendamos especificar pelo menos dois peerings. Você pode usar os mesmos peerings especificados no plano de controle.
    • PEER_ASN: o número do sistema autônomo da rede que contém o dispositivo de peering externo.

    Você pode especificar vários peerings externos, peers recebe uma lista de pares de mapeamento. Recomendamos especificar pelo menos dois peerings externos para alta disponibilidade nas sessões do BGP. Veja um exemplo com vários peerings em Configurações de exemplo.

  8. Quando você executa bmctl cluster create para criar o cluster, as verificações de simulação são executadas. Entre outras verificações, as verificações de simulação validam a configuração de peering do BGP para o plano de controle e comunicam problemas diretamente à estação de trabalho de administrador antes de criar o cluster.

Recomendamos usar o recurso ADD-PATH do BGP para sessões de peering, conforme especificado na RFC 7911. Por padrão, o protocolo do BGP permite que apenas um próximo salto seja divulgado aos peerings para um único prefixo. O ADD-PATH do BGP permite divulgar vários próximos saltos do mesmo prefixo. Quando ADD-PATH é usado com o balanceamento de carga em pacote baseado em BGP, o cluster pode divulgar vários nós de cluster como nós de front-end (próximos saltos) de um serviço de balanceador de carga (prefixo). Ative o ECMP na rede para que o tráfego possa ser distribuído por vários caminhos. A capacidade de distribuir o tráfego divulgando vários nós de cluster como próximos saltos fornece um escalonamento aprimorado da capacidade do plano de dados para balanceamento de carga.

Se o dispositivo de peering externo, como um roteador ou switch de topo de rack (ToR) for compatível com o ADD-PATH do BGP, basta ativar a extensão de recebimento. O balanceamento de carga em pacote com o BGP funciona sem o recurso ADD-PATH, mas a restrição de divulgar um único nó de balanceamento de carga por sessão de peering limita a capacidade do plano de dados do balanceador de carga. Sem ADD-PATH, os clusters do Anthos em bare metal escolhem nós no pool de nós do balanceador de carga para divulgar e tentam distribuir os próximos saltos para diferentes VIPs nos vários nós.

Restringir o peering do BGP aos nós do balanceador de carga

Na versão de visualização desse recurso, os clusters do Anthos em bare metal atribuem automaticamente endereços IP flutuantes em qualquer nó na mesma sub-rede que o endereço IP flutuante. As sessões do BGP são iniciadas por esses endereços IP mesmo que não fiquem nos nós do balanceador de carga. Esse comportamento é padrão, porque separamos o plano de controle (BGP) do plano de dados (pools de nós do balanceador de carga).

Se você quiser restringir o conjunto de nós que podem ser usados para o peering do BGP, designe uma sub-rede a ser usada apenas para nós do balanceador de carga. Isso significa que você pode configurar todos os nós dessa sub-rede para ficar no pool de nós do balanceador de carga. Em seguida, ao configurar endereços IP flutuantes que são usados para o peering do BGP, certifique-se de que sejam dessa mesma sub-rede. Os clusters do Anthos em bare metal fazem com que as atribuições de endereços IP flutuantes e o peering do BGP ocorram apenas a partir dos nós do balanceador de carga.

Exemplos de configurações

As seções a seguir explicam como configurar o balanceamento de carga baseado em BGP para diferentes opções ou comportamentos.

Configurar para que todos os nós que usem os mesmos peerings

Conforme mostrado no diagrama a seguir, essa configuração resulta em um conjunto de peerings externos (10.8.0.10 e 10.8.0.11) que podem ser acessados por todos os nós. Os nós do plano de controle (10.0.1.10, 10.0.1.11 e 10.0.2.10) e os endereços IP flutuantes (10.0.1.100 e 10.0.2.100) atribuídos aos nós do plano de dados alcançam todos os peerings.

Os mesmos peerings externos podem ser acessados por um dos endereços IP flutuantes (10.0.1.100 ou 10.0.2.100) reservados para o peering de serviços de loadBalancer. Os endereços IP flutuantes podem ser atribuídos a nós que estão na mesma sub-rede.

Balanceamento de carga do BGP em que todos os nós usam os mesmos peerings

Conforme mostrado nesta amostra de configuração de clusterm configure os peerings para os nós do plano de controle, bgpPeers, sem especificar controlPlaneNodes. Quando nenhum nó é especificado para os peerings, todos os nós do plano de controle se conectam a todos os peerings.

Especifique os endereços IP flutuantes a serem usados para sessões de peering de balanceamento de carga de serviço no recurso personalizado AnthosNetworkGateway. Especifique os peerings externos correspondentes no recurso BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.8.0.10
    peerASN: 65002
  - peerIP: 10.8.0.11
    peerASN: 65002

Configurar nós específicos do plano de controle para fazer peering com peerings externos específicos

Conforme mostrado no diagrama a seguir, essa configuração resulta em dois nós do plano de controle (10.0.1.10 e 10.0.1.11) com um peering externo (10.0.1.254). O terceiro nó do plano de controle (10.0.2.10) faz peering com outro peering externo (10.0.2.254). Essa configuração é útil quando você não quer que todos os nós se conectem a todos os peerings. Por exemplo, você pode querer que os nós de plano de controle façam peering apenas com os switches de topo de rack (ToR) correspondentes.

Os mesmos peerings externos podem ser acessados por um dos endereços IP flutuantes (10.0.1.100 ou 10.0.2.100) reservados para sessões de peering do balanceamento de carga de serviço. Os endereços IP flutuantes podem ser atribuídos a nós que estejam na mesma sub-rede.

Balanceamento de carga do BGP com mapeamento explícito dos nós do plano de controle para peerings

Conforme mostrado na amostra de configuração de cluster a seguir, você restringe quais nós do plano de controle podem se conectar a um determinado peering especificando os endereços IP no campo controlPlaneNodes para o peering na seção bgpPeers.

Especifique os endereços IP flutuantes a serem usados para sessões de peering de balanceamento de carga de serviço no recurso personalizado AnthosNetworkGateway. Especifique os peerings externos correspondentes no recurso BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.0.1.254
    peerASN: 65002
  - peerIP: 10.0.2.254
    peerASN: 65002

Configurar o plano de controle e o plano de dados separadamente

Conforme mostrado no diagrama a seguir, essa configuração resulta em dois nós do plano de controle (10.0.1.10 e 10.0.1.11) fazendo peering com um peering externo (10.0.1.254). O terceiro nó do plano de controle (10.0.2.10) faz peering com outro peering externo (10.0.2.254).

Um terceiro peering externo (10.0.3.254) pode ser acessado por um dos endereços IP flutuantes (10.0.3.100 ou 10.0.3.101) reservados para sessões de peering de balanceamento de carga de serviço. Os endereços IP flutuantes podem ser atribuídos a nós que estejam na mesma sub-rede.

Balanceamento de carga do BGP com configuração separada para o plano de controle e o plano de dados

Conforme mostrado na amostra de configuração de cluster a seguir, você restringe quais nós do plano de controle podem se conectar a um determinado peering especificando os endereços IP no campo controlPlaneNodes para o peering na seção bgpPeers.

Especifique os endereços IP flutuantes a serem usados para sessões de peering de balanceamento de carga de serviço no recurso personalizado AnthosNetworkGateway. Especifique os peerings externos correspondentes no recurso BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.11

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
  name: bgplb
  namespace: cluster-bm
spec:
  bgp:
    localASN: 65001
    peers:
    - peerIP: 10.0.3.254
      peerASN: 65002

Alterar a configuração de balanceamento de carga baseada em BGP

Depois de criar o cluster para usar o balanceamento de carga em pacote com o BGP, algumas configurações podem ser atualizadas. Outras, no entanto, não podem ser atualizadas após a criação do cluster.

Plano de controle

As alterações na configuração do balanceamento de carga do plano de controle não são compatíveis durante a visualização.

Serviços

É possível alterar a configuração de peering do BGP após a criação do cluster editando a resposta automática AnthosNetworkGateway e a resposta automática BGPLoadBalancer. Qualquer alteração nas informações de peering nessas respostas automáticas é refletida na configuração da solução de balanceamento de carga no cluster de destino.

Faça atualizações nos recursos de origem no namespace do cluster somente no cluster de administrador. Todas as alterações feitas nos recursos no cluster de destino (usuário) são substituídas.

Resolver problemas

As seções a seguir explicam como acessar informações de solução de problemas para o balanceamento de carga em pacote com o BGP.

Sessões do BGP do plano de controle

A configuração de peering do BGP do plano de controle é validada com verificações de simulação durante a criação do cluster. As verificações de simulação tentam:

  • estabelecer uma conexão do BGP com cada peering;
  • divulgar o VIP do plano de controle;
  • verificar se o nó do plano de controle pode ser acessado usando o VIP.

Se a criação do cluster falhar nas verificações de simulação, veja se há erros nos registros de verificação de simulação. Os arquivos de registro de verificação de simulação com datas estão localizados no diretório baremetal/bmctl-workspace/CLUSTER_NAME/log.

No ambiente de execução, os locutores do BGP do plano de controle são executados como pods estáticos em cada nó do plano de controle e gravam informações de evento nos registros. Esses pods estáticos incluem "bgpadvertiser" no nome. Portanto, use o seguinte comando kubectl get pods para ver o status dos pods de locutores do BGP:

kubectl -n kube-system  get pods | grep bgpadvertiser

Se os pods estiverem funcionando corretamente, a resposta será parecida com esta:

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

Use o seguinte comando para visualizar os registros do pod bgpadvertiser-node-01:

kubectl -n kube-system  logs bgpadvertiser-node-01

Sessões do BGP de serviço

O recurso BGPSession fornece informações sobre as sessões atuais do BGP. Para receber informações da sessão, verifique primeiro as sessões atuais e, em seguida, recupere o recurso BGPSession de uma das sessões.

Use o seguinte comando kubectl get para listar as sessões atuais:

kubectl -n kube-system get bgpsessions

O comando retorna uma lista de sessões como este exemplo:

NAME                            AGE
10.0.1.254-node-01              170m
10.0.1.254-node-05              170m
10.0.3.254-node-01              170m
10.0.3.254-node-05              170m

Use o seguinte comando kubectl describe para conseguir o recurso BGPSession para a sessão 10.0.1.254-node-01 do BGP:

kubectl -n kube-system describe bgpsession 10.0.1.254-node-01

O recurso BGPSession retornado deve ser semelhante ao seguinte exemplo:

Name:         10.0.1.254-node-01
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1alpha1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

Use o comando kubectl get para conseguir os recursos BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

A resposta, que precisa ser parecida com exemplo a seguir, mostra as rotas que estão sendo divulgadas:

NAME                                  AGE
bgplb-default-load-balancer-example   5d5h
bgplb-gke-system-istio-ingress        6d

Use kubectl describe para visualizar detalhes sobre os próximos saltos que cada rota está divulgando.

Verificação manual do BGP

Nesta seção, você verá instruções para verificar manualmente a configuração do BGP. O procedimento define uma conexão do BGP de longa duração para você depurar a configuração do BGP com a equipe de rede. Use este procedimento para verificar sua configuração antes de criar um cluster ou use-o se as verificações de simulação relacionadas ao BGP falharem.

As verificações de simulação automatizam as seguintes tarefas de verificação do BGP:

  • Configure uma conexão do BGP com um peering.
  • Divulgar o VIP do plano de controle;
  • Verifique se o tráfego enviado de todos os outros nós do cluster para o VIP alcança o nó do balanceador de carga atual.

Essas tarefas são executadas para cada peering do BGP em cada nó do plano de controle. Transmitir essas verificações é fundamental ao criar um cluster. No entanto, as verificações de simulação não criam conexões de longa duração. Portanto, é difícil depurar falhas.

As seções a seguir fornecem instruções para configurar uma conexão do BGP e anunciar uma rota de uma única máquina de cluster para um peering. Para testar várias máquinas e vários pares, repita as instruções usando uma combinação diferente de máquina e peering.

Lembre-se de que as conexões BGP são estabelecidas a partir dos nós do plano de controle. Portanto, tente este procedimento em um dos nós do plano de controle planejados.

Receber o binário do programa de teste do BGP

Siga as etapas desta seção na estação de trabalho do administrador. Estas etapas recebem o programa bgpadvertiser usado para testar as conexões do BGP e o copiam para os nós do plano de controle em que você quer testar.

  1. Extraia a imagem do docker do ansible-runner.

    Sem espelho do registro

    Se você não usar um espelho de registro, execute os seguintes comandos para extrair a imagem do Docker do ansible-runner:

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Com espelho de registro

    Se você usar um espelho de registro, execute os seguintes comandos para extrair a imagem do Docker do ansible-runner:

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Substitua REGISTRY_HOST pelo nome do servidor espelhado do registro.

  2. Extrair o binário bgpadvertiser.

    Sem espelho do registro

    Para extrair o binário bgpadvertiser, execute o seguinte comando:

    docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

    Com espelho de registro

    Para extrair o binário bgpadvertiser, execute o seguinte comando:

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

  3. Para copiar o binário bgpadvertiser para o nó do plano de controle que você quer testar, execute o seguinte comando:

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Substitua:

    • USERNAME: o nome de usuário usado para acessar o nó do plano de controle.

    • CP_NODE_IP: o endereço IP do nó do plano de controle.

Configurar uma conexão do BGP

Execute as etapas desta seção em um nó do plano de controle.

  1. Crie um arquivo de configuração no nó em /tmp/bgpadvertiser.conf que tenha a seguinte aparência:

    localIP: NODE_IP
localASN: CLUSTER_ASN
peers:
- peerIP: PEER_IP
  peerASN: PEER_ASN

    Substitua:

    • NODE_IP: endereço IP do nó do plano de controle em que você está.
    • CLUSTER_ASN: o número do sistema autônomo usado pelo cluster.
    • PEER_IP: o endereço IP de um dos pares externos que você quer testar.
    • PEER_ASN: o número do sistema autônomo da rede que contém o dispositivo de peering externo.

  2. Execute o daemon bgpadvertiser, substituindo o plano de controle VIP no seguinte comando:

    /tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP

    Substitua CONTROL_PLANE_VIP pelo endereço IP que você usará para o plano de controle VIP. Esse comando faz com que o anunciante do BGP anuncie esse endereço em apps semelhantes.

  3. Veja a saída do programa.

    Nesse ponto, o daemon bgpadvertiser é iniciado, tenta se conectar ao peering e anuncia o VIP. O programa exibe periodicamente mensagens (veja o exemplo de saída a seguir) que incluem BGP_FSM_ESTABLISHED quando a conexão do BGP é estabelecida.

    {"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"}
{"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"}
I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started.
I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080".
INFO[0000] Add a peer configuration for:21.0.101.80      Topic=Peer
{"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"}
DEBU[0000] IdleHoldTimer expired                         Duration=0 Key=21.0.101.80 Topic=Peer
I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80}
DEBU[0000] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired
DEBU[0000] create Destination                            Nlri=10.0.0.1/32 Topic=Table
{"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}}
I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 }
I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving...
DEBU[0005] try to connect                                Key=21.0.101.80 Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received
INFO[0005] Peer Up                                       Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated
DEBU[0005] sent update                                   Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] received update                               Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] create Destination                            Nlri=10.0.0.1/32 Topic=Table
DEBU[0035] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
DEBU[0065] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"

Se você não vir essas mensagens, verifique novamente os parâmetros de configuração do BGP no arquivo de configuração e confirme com o administrador da rede. Agora você tem uma conexão do BGP configurada. Você pode verificar com o administrador da rede se vê a conexão estabelecida no lado dele e se vê a rota anunciada para ele.

Teste de tráfego

Para testar se a rede pode encaminhar tráfego para o VIP, adicione o VIP ao nó do plano de controle que está executando bgpadvertiser. Execute o seguinte comando em um terminal diferente para deixar bgpadvertiser em execução:

  1. Adicione o VIP ao nó do plano de controle:

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    Substitua:

    • CONTROL_PLANE_VIP: o argumento --advertise-ip do VIP do bgpadvertiser.
    • INTF_NAME: a interface do Kubernetes no nó. Ou seja, a interface que tem o endereço IP que você colocou nos clusters do Anthos na configuração bare metal para loadBalancer.bgpPeers.controlPlaneNodes.

  2. Dê um ping no VIP a partir de um nó diferente:

    ping CONTROL_PLANE_VIP

    Se o ping não funcionar, pode haver um problema com a configuração do BGP no dispositivo de rede. Trabalhe com seu administrador de rede para verificar a configuração e resolver o problema.

Limpar

Siga estas etapas para redefinir o nó depois de verificar manualmente se o BGP está funcionando. Se você não redefinir o nó corretamente, a configuração manual poderá interferir na verificação de simulação ou na criação do cluster subsequente.

  1. Remova o VIP do nó do plano de controle se você o tiver adicionado para o teste de tráfego:

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. No nó do plano de controle, pressione Ctrl+C no terminal bgpadvertiser para interromper o bgpadvertiser.

  3. Verifique se nenhum processo bgpadvertiser está em execução:

    ps -ef | grep bgpadvertiser

  4. Se houver processos em execução, interrompa-os usando o comando kill.