Configurar balanceadores de carga em pacote com o BGP

Version 1.15 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

Neste documento, descrevemos como configurar e usar balanceadores de carga agrupados com o protocolo de gateway de borda (BGP, na sigla em inglês) para o GKE 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ão compatíveis apenas 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 opera 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 NetworkGatewayGroup.
• 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 é 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 GKE em nós do plano de controle bare metal fazem peering com o respectivo TOR.

Observação: o diagrama ilustra apenas um exemplo. Os peerings não precisam estar na mesma sub-rede. Ativamos o BGP de vários saltos por padrão.

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 não são iniciadas diretamente dos endereços IP do nó do cluster. Em vez disso, elas usam endereços IP flutuantes.

Observação: o balanceamento de carga de serviço ou do plano de dados não se aplica aos clusters de administrador. Se você incluir informações de configuração da sessão do BGP no plano de dados do cluster de administrador, a configuração será ignorada.

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) NetworkGatewayGroup, 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 NetworkGatewayGroup 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

No balanceamento de carga do plano de dados, é possível usar os mesmos pares externos especificados para o peering do plano de controle na seção loadBalancer.controlPlaneBGP do arquivo de configuração do cluster. Também é possível especificar diferentes pares de BGP.

Se você quiser especificar diferentes pares de BGP para o peering de plano de dados, anexe as especificações de recursos BGPLoadBalancer e BGPPeer ao arquivo de configuração do cluster. Quando você não especifica esses recursos personalizados, os pares do plano de controle são usados automaticamente no plano de dados.

É possível especificar os pares externos usados em sessões de peering com os endereços IP flutuantes no recurso personalizado BGPPeer, que você adiciona ao arquivo de configuração do cluster. O recurso BGPPeer inclui um rótulo para ser identificado pelo recurso personalizado BGPLoadBalancer correspondente. Especifique o rótulo correspondente no campo peerSelector no recurso personalizado BGPLoadBalancer para selecionar o BGPPeer para uso.

O controlador de gateway de rede do Anthos tenta estabelecer sessões (o número de sessões é configurável) para cada par externo a partir do conjunto de endereços IP flutuantes reservados. Recomendamos especificar pelo menos dois pares externos para garantir alta disponibilidade nas sessões do BGP. Cada par 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 NetworkGatewayGroup.

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.

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. No arquivo de configuração do cluster, ative a rede avançada e atualize a seção loadBalancer. Além disso, anexe as especificações aos três recursos personalizados a seguir:

• NetworkGatewayGroup: especifica endereços IP flutuantes usados em sessões de peering do BGP do serviço.

• BGPLoadBalancer: especifica, usando seletores de identificador, quais pares são usados para o balanceamento de carga do BGP.

• BGPPeer: especifica pares individuais, incluindo um rótulo de seleção, para sessões de peering do BGP.

Veja nas instruções a seguir como configurar o cluster e os três recursos personalizados para configurar o balanceamento de carga em pacote com o BGP.

1. Adicione o campo advancedNetworking ao arquivo de configuração do cluster na seção clusterNetwork e defina como true.

   Esse campo ativa a capacidade avançada de rede, especificamente o recurso de grupo de gateway de rede.

   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: bm
     namespace: CLUSTER_NAMESPACE
   spec:
   ...
     clusterNetwork:
       advancedNetworking: true
   

   Substitua CLUSTER_NAMESPACE pelo namespace do cluster. Por padrão, os namespaces de cluster para GKE em Bare Metal são os nomes do cluster precedidos por cluster-. Por exemplo, se você der o nome de test ao cluster, o namespace será cluster-test.

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.

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

   Observação: quando você usa o balanceamento de carga em pacote baseado em BGP (mode: bundled e type: bgp), os VIPs especificados não podem vir da mesma sub-rede que um dos nós do cluster.

   ...
     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 NetworkGatewayGroup:

   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/v1
   kind: NetworkGatewayGroup
   metadata:
     name: default
     namespace: CLUSTER_NAMESPACE
   spec:
     floatingIPs:
     - FLOATING_IP
   ...
   

   Substitua:

   • CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces de cluster do GKE em Bare Metal são os nomes do cluster precedidos por cluster-. Por exemplo, se você der o nome de test ao cluster, 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.

   Verifique se o recurso personalizado NetworkGatewayGroup tem o nome de default e usa o namespace do cluster. Confira um exemplo da especificação de recurso personalizado NetworkGatewayGroup em Exemplos de configurações.

7. (Opcional) Para especificar os pares que serão usados no balanceamento de carga do plano de dados, configure o recurso personalizado BGPLoadBalancer:

   ...
   ---
   apiVersion: networking.gke.io/v1
   kind: BGPLoadBalancer
   metadata:
     name: default
     namespace: CLUSTER_NAMESPACE
   spec:
     peerSelector:
       PEER_LABEL: "true"
   ...
   

   Substitua:

   • CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces de cluster do GKE em Bare Metal são os nomes do cluster precedidos por cluster-. Por exemplo, se você der o nome de test ao cluster, o namespace será cluster-test.
   • PEER_LABEL: o rótulo usado para identificar os pares a serem usados no balanceamento de carga. Qualquer recurso personalizado BGPPeer com um rótulo correspondente especifica os detalhes de cada par.

   Verifique se o recurso personalizado BGPLoadBalancer tem o nome de default e usa o namespace do cluster. Se você não especificar um recurso personalizado BGPLoadBalancer, os pares do plano de controle serão usados automaticamente no balanceamento de carga do plano de dados. Para conferir exemplos detalhados, consulte Exemplos de configurações.

8. (Opcional) Especifique os pares externos do plano de dados configurando um ou mais recursos personalizados BGPPeer:

   ...
   ---
   apiVersion: networking.gke.io/v1
   kind: BGPPeer
   metadata:
     name: BGP_PEER_NAME
     namespace: CLUSTER_NAMESPACE
     labels:
       PEER_LABEL: "true"
   spec:
     localASN: CLUSTER_ASN
     peerASN: PEER_ASN
     peerIP: PEER_IP
     sessions: SESSION_QTY
     ...
   

   Substitua:

   • BGP_PEER_NAME: o nome do par.
   • CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces de cluster do GKE em Bare Metal são os nomes do cluster precedidos por cluster-. Por exemplo, se você der o nome de test ao cluster, o namespace será cluster-test.
   • PEER_LABEL: o rótulo usado para identificar os pares a serem usados no balanceamento de carga. Esse rótulo precisa ser igual ao rótulo especificado no recurso personalizado BGPLoadBalancer.
   • 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. Recomendamos especificar pelo menos dois pares externos, mas é necessário especificar um, no mínimo.
   • PEER_ASN: o número do sistema autônomo da rede que contém o dispositivo de peering externo.
   • SESSION_QTY: o número de sessões a serem criadas para esse par. Recomendamos criar pelo menos duas sessões para garantir a conexão com o par caso um dos seus nós fique inativo.

   É possível especificar vários pares externos. Para isso, crie outros recursos personalizados BGPPeer. Recomendamos que você especifique pelo menos dois pares externos (dois recursos personalizados) para garantir alta disponibilidade nas sessões do BGP. Se você não especificar um recurso personalizado BGPPeer, os pares do plano de controle serão usados automaticamente no balanceamento de carga do plano de dados.

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

   Em caso de sucesso, os recursos de balanceamento de carga do BGP adicionados (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer) entram no cluster de administrador no namespace do cluster de usuário. Use o arquivo kubeconfig do cluster de administrador ao fazer atualizações para esses recursos. Em seguida, o cluster de administrador reconcilia as alterações no cluster de usuário. Se você editar esses recursos diretamente no cluster de usuário, o cluster de administrador substituirá as alterações nas reconciliações subsequentes.

Como divulgar vários próximos saltos por sessão com o recurso ADD-PATH do BGP

Recomendamos usar o recurso ADD-PATH do BGP nas 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 GKE 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

Os clusters do GKE 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 GKE 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.

Configurar o balanceamento de carga do BGP com rede de pilha dupla

A partir da versão 1.14.0 do GKE em bare metal, o balanceador de carga em pacote baseado no BGP oferece suporte a IPv6. Com a introdução da compatibilidade com IPv6, é possível configurar os serviços LoadBalancer de IPv6 e de pilha dupla em um cluster configurado para uma rede de pilha dupla. Nesta seção, descrevemos as alterações necessárias para configurar o balanceamento de carga em pacote de pilha dupla com o BGP.

Para ativar os serviços LoadBalancer de pilha dupla, as seguintes alterações de configuração são necessárias:

• O cluster precisa ser configurado para rede de pilha dupla:

  • Especifique os CIDRs de serviço IPv4 e IPv6 no arquivo de configuração do cluster em spec.clusterNetwork.services.cidrBlocks.

  • Defina recursos ClusterCIDRConfig apropriados para especificar intervalos CIDR IPv4 e IPv6 para pods.

  Para mais informações sobre como configurar um cluster para rede de pilha dupla, consulte Redes de pilha dupla de IPv4/IPv6.

• Especifique um pool de endereços IPv6 no arquivo de configuração do cluster em spec.loadBalancer.addressPools. Para que o MetalLB aloque endereços IP para um serviço de pilha dupla, é necessário que haja pelo menos um pool de endereços com endereços do formato IPv4 e IPv6.

O exemplo de configuração a seguir destaca as alterações necessárias para o balanceamento de carga em pacote de pilha dupla com o BGP:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  clusterNetwork:
  services:
      cidrBlocks:
      # Dual-stack Service IP addresses must be provided
      - 10.96.0.0/16
      - fd00::/112
...
  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

    addressPools:
    - name: pool1
      addresses:
      # Each address must be either in the CIDR form (1.2.3.0/24)
      # or range form (1.2.3.1-1.2.3.5).
      - "203.0.113.1-203.0.113.20"
      - "2001:db8::1-2001:db8::20"  # Note the additional IPv6 range

... # Other cluster config info omitted
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2001:db8:1::/112"
    perNodeMaskSize: 120

Limitações para balanceamento de carga em pacote de pilha dupla com BGP

Ao configurar seu cluster para usar o balanceamento de carga em pacote de pilha dupla com o BGP, observe as seguintes limitações:

• O balanceamento de carga do plano de controle IPv6 não é compatível.

• As sessões IPv6 do BGP não são compatíveis, mas as rotas IPv6 podem ser exibidas nas sessões IPv4 usando o BGP multiprotocolo.

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

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 NetworkGatewayGroup. Neste exemplo, como nenhum BGPLoadBalancer é especificado, os pares do plano de controle são usados automaticamente nas sessões do BGP do plano de dados.

Observação :as seções de configuração do cluster que não se aplicam a essa configuração de balanceamento de carga com base no BGP foram removidas para facilitar a leitura da amostra.

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/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

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.

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 NetworkGatewayGroup. Neste exemplo, como nenhum BGPLoadBalancer é especificado, os pares do plano de controle são usados automaticamente nas sessões do BGP do plano de dados.

Observação :as seções de configuração do cluster que não se aplicam a essa configuração de balanceamento de carga com base no BGP foram removidas para facilitar a leitura da amostra.

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/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

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.11) 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.

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

Para configurar o balanceamento de carga do plano de dados:

• Especifique o peering externo para o plano de dados no recurso BGPPeer e adicione um identificador para usar na seleção do peering, como cluster.baremetal.gke.io/default-peer: "true".

• Especifique o rótulo correspondente para o campo peerSelector no recurso BGPLoadBalancer.

Observação :as seções de configuração de cluster que não se aplicam a essa configuração de balanceamento de carga com base em BGP foi removida para facilitar a leitura do exemplo.

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/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

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.

Use o arquivo kubeconfig do cluster de administrador ao fazer atualizações subsequentes nos recursos relacionados ao BGP (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer). Em seguida, o cluster de administrador reconcilia as alterações no cluster de usuário. Se você editar esses recursos diretamente no cluster de usuário, o cluster de administrador substituirá as alterações nas reconciliações subsequentes.

Plano de controle

As informações de peering do BGP do plano de controle podem ser atualizadas no recurso Cluster. É possível adicionar ou remover pares especificados na seção de balanceamento de carga do plano de controle.

Aviso: tenha cuidado ao atualizar as informações de peering do BGP do plano de controle, especialmente em clusters autogerenciados (clusters do tipo administrador, híbrido ou independente). Os planos de controle VIP e do Kubernetes ficam inacessíveis de fora do cluster se ele não puder divulgar o plano de controle VIP a algum dos pares. Por exemplo, o acesso é perdido se a configuração de peering não se refere a um peering válido ou se o cluster não pode se conectar ao par devido a problemas de configuração ou de rede. Saiba como recuperar o acesso em Como recuperar o acesso ao VIP do plano de controle em clusters autogerenciados.

As seções a seguir descrevem as práticas recomendadas para atualizar as informações de peering do BGP do plano de controle.

Verificar o status dos pares antes da atualização

Para minimizar o risco de configurar os pares incorretamente, verifique se as sessões de peering do BGP do plano de controle estão no estado esperado antes de fazer alterações. Por exemplo, se você espera que todas as sessões de peering do BGP estejam ativas no momento, verifique se todos os pods bgp-advertiser informam ready, indicando que as sessões estão ativas. Se o status atual não corresponde ao esperado, corrija o problema antes de atualizar a configuração de peering.

Para saber como recuperar detalhes da sessão do BGP do plano de controle, consulte Sessões do BGP do plano de controle.

Atualizar pares de maneira controlada

Se possível, atualize um par de cada vez para isolar possíveis problemas:

1. Adicione ou atualize um único peering.
2. Aguarde a configuração ser corrigida.
3. Verifique se o cluster pode se conectar ao par novo ou atualizado.
4. Remova os pares antigos ou desnecessários.

Serviços

Para atualizar os pools de endereços e as configurações de nó do balanceador de carga, edite nodePoolSpec no recurso Cluster.

Aviso: tenha cuidado ao atualizar as informações de peering para serviços do plano de dados. Quando as informações de peering estão configuradas incorretamente, e o cluster não pode estabelecer sessões do BGP para os pares e divulgar os VIPs, não é possível acessar os serviços com os VIPs do LoadBalancer. Recomendamos que você atualize sua configuração um par de cada vez, conforme descrito na seção anterior, para minimizar o risco de configurações incorretas.

Para modificar a configuração de peering do BGP após a criação do cluster, edite os recursos personalizados NetworkGatewayGroup e BGPLoadBalancer. Qualquer alteração das informações de peering nessas respostas personalizadas é 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.

Solução de 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

Observação: a condição de prontidão dos pods bgpadvertiser do plano de controle está vinculada ao status das sessões do BGP. Isso significa que um pod é declarado como "Pronto" somente quando todas as sessões do BGP estão ativas. Quando uma das sessões do BGP do pod fica inativa, a condição "Pronto" do pod muda para "Falso".

Quando os pods estão funcionando corretamente, a resposta é semelhante a 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                 LOCAL ASN   PEER ASN   LOCAL IP     PEER IP      STATE            LAST REPORT
10.0.1.254-node-01   65500       65000      10.0.1.178   10.0.1.254   Established      2s
10.0.1.254-node-02   65500       65000      10.0.3.212   10.0.1.254   Established      2s
10.0.3.254-node-01   65500       65000      10.0.1.178   10.0.3.254   Established      2s
10.0.3.254-node-02   65500       65000      10.0.3.212   10.0.3.254   Established      2s

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/v1
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                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

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

Como recuperar o acesso ao VIP do plano de controle em clusters autogerenciados

Para recuperar o acesso ao VIP do plano de controle em um cluster de administrador, híbrido ou independente, é necessário atualizar a configuração do BGP no cluster. Como mostrado no exemplo de comando a seguir, use SSH para se conectar ao nó e, em seguida, kubectl para abrir o recurso do cluster para edição.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

Substitua:

• IDENTITY_FILE: o nome do arquivo de identidade SSH que contém a chave de identidade para autenticação de chave pública;
• CLUSTER_NODE_IP: o endereço IP do nó do cluster;
• CLUSTER_NAMESPACE: o namespace do cluster.
• CLUSTER_NAME: o nome do cluster.

Modifique a configuração de peering do BGP no objeto de cluster. Depois de salvar a nova configuração do cluster, monitore a integridade dos pods bgpadvertiser. Se a configuração funcionar, os pods serão reiniciados e se tornarão íntegros quando se conectarem aos pares.

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 VIP do plano de controle. 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 na configuração dos clusters do GKE em 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.