Configure balanceadores de carga incluídos com BGP

Este documento descreve como configurar e usar equilibradores de carga agrupados com o Protocolo de gateway de fronteira (BGP) para o Google Distributed Cloud. Este modo de equilíbrio de carga suporta o anúncio de ServiceType LoadBalancer endereços IP virtuais (VIPs) através do protocolo de gateway de fronteira (BGP) externo para os seus clusters. Neste cenário, a sua rede de cluster é um sistema autónomo que se interliga com outro sistema autónomo, uma rede externa, através da interligação.

Os balanceadores de carga incluídos com capacidade BGP aplicam-se a todos os tipos de clusters, mas os clusters de administrador só suportam a parte de balanceamento de carga do plano de controlo desta capacidade.

A utilização dos balanceadores de carga incluídos com a funcionalidade BGP oferece as seguintes vantagens:

  • Usa a capacidade de equilíbrio de carga ativo/ativo de N vias, o que proporciona uma comutação por falha mais rápida e uma utilização mais eficiente da largura de banda disponível.
  • Suporta o protocolo de camada 3 que funciona com comutadores e routers de topo de rack (ToR) de terceiros compatíveis com eBGP.
  • Permite que os centros de dados que executam uma pilha de rede definida por software (SDN) avançada enviem o limite da camada 3 até aos clusters.

Como funciona o equilíbrio de carga agrupado com BGP

As secções seguintes oferecem um breve resumo do funcionamento dos balanceadores de carga agrupados com BGP.

Intercâmbio BGP

Os equilibradores de carga incluídos com a funcionalidade BGP iniciam várias ligações BGP à sua infraestrutura. O BGP tem os seguintes requisitos técnicos:

  • As sessões de peering são separadas para o VIP do plano de controlo e para os VIPs de serviço.
  • As sessões de peering do painel de controlo são iniciadas a partir dos endereços IP dos nós do painel de controlo.
  • As sessões de peering de serviços são iniciadas a partir de endereços IP flutuantes que especifica no recurso personalizado NetworkGatewayGroup.
  • O gateway de rede para o controlador GDC gere os endereços IP flutuantes.
  • O equilíbrio de carga baseado em BGP agrupado só suporta a interligação eBGP.
  • O intercâmbio de vários saltos é suportado por predefinição.
  • As palavras-passe MD5 em sessões BGP não são suportadas.
  • As sessões de intercâmbio baseadas em IPv6 não são suportadas.
  • Espera-se que os caminhos anunciados a qualquer par sejam redistribuídos por toda a rede e acessíveis a partir de qualquer outro local no cluster.
  • Recomendamos a utilização da capacidade ADD-PATH de BGP no modo de receção para sessões de peering.
  • A publicidade de vários caminhos de cada par resulta no equilíbrio de carga ativo/ativo.
  • O encaminhamento de vários caminhos de custo igual (ECMP) deve estar ativado para a sua rede, para que seja possível usar vários caminhos para distribuir o tráfego por um conjunto de nós do equilibrador de carga.

Balanceamento de carga do plano de controlo

Cada nó do plano de controlo no seu cluster estabelece sessões BGP com um ou mais pares na sua infraestrutura. Exigimos que cada nó do plano de controlo tenha, pelo menos, um par. No ficheiro de configuração do cluster, pode configurar a que pares externos os nós do plano de controlo se ligam.

O diagrama seguinte mostra um exemplo de intercâmbio de planos de controlo. O cluster tem dois nós do plano de controlo numa sub-rede e um noutra. Existe um par externo (TOR) em cada sub-rede e os nós do plano de controlo do Google Distributed Cloud comunicam com o respetivo TOR.

Balanceamento de carga de serviços com peering BGP

Balanceamento de carga de serviços

Além das sessões de peering iniciadas a partir de cada nó do plano de controlo para o peering do plano de controlo, são iniciadas sessões de peering adicionais para os serviços LoadBalancer. Estas sessões de peering não são iniciadas diretamente a partir de endereços IP de nós do cluster, mas usam endereços IP flutuantes.

Os serviços com uma política de rede externalTrafficPolicy=Local são suportados. No entanto, a definição externalTrafficPolicy=Local depende da carga de trabalho e faz com que as rotas sejam atualizadas sempre que um pod que suporta o serviço é adicionado ou removido completamente de um nó. Este comportamento de atualização de rotas pode fazer com que o encaminhamento de vários caminhos de custo igual (ECMP) altere os fluxos de tráfego, o que pode resultar em quedas no tráfego.

Endereços IP flutuantes

O equilíbrio de carga do serviço requer que reserve endereços IP flutuantes nas sub-redes dos nós do cluster para usar para a interligação BGP. É necessário, pelo menos, um endereço IP flutuante para o cluster, mas recomendamos que reserve, pelo menos, dois endereços para garantir a elevada disponibilidade das sessões BGP. Os endereços IP flutuantes são especificados no recurso personalizado (CR) NetworkGatewayGroup, que pode ser incluído no ficheiro de configuração do cluster.

Os endereços IP flutuantes eliminam a preocupação com o mapeamento de endereços IP de altifalantes BGP para nós. O gateway de rede para o controlador do GDC encarrega-se de atribuir o NetworkGatewayGroup aos nós e também gere os endereços IP flutuantes. Se um nó ficar inativo, o gateway de rede para o controlador GDC reatribui endereços IP flutuantes para garantir que os pares externos têm um endereço IP determinístico com o qual estabelecer ligação ponto a ponto.

Pares externos

Para o equilíbrio de carga do plano de dados, pode usar os mesmos pares externos que foram especificados para a interligação do plano de controlo na secção loadBalancer.controlPlaneBGP do ficheiro de configuração do cluster. Em alternativa, pode especificar diferentes pares BGP.

Se quiser especificar diferentes pares BGP para a interligação do plano de dados, anexe as especificações de recursos BGPLoadBalancer e BGPPeer ao ficheiro de configuração do cluster. Se não especificar estes recursos personalizados, os pares do plano de controlo são usados automaticamente para o plano de dados.

Especifica os pares externos usados para sessões de peering com os endereços IP flutuantes no recurso personalizado BGPPeer, que adiciona ao ficheiro de configuração do cluster. O recurso BGPPeer inclui uma etiqueta para identificação pelo recurso personalizado BGPLoadBalancer correspondente. Especifica a etiqueta de correspondência no campo peerSelector no recurso personalizado BGPLoadBalancer para selecionar o BGPPeer para utilização.

O gateway de rede para o controlador GDC 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 que especifique, pelo menos, dois pares externos para garantir a elevada disponibilidade das sessões BGP. Cada par externo designado para o equilíbrio de carga dos serviços tem de ser configurado para estabelecer uma relação de pares com todos os endereços IP flutuantes especificados no recurso personalizado NetworkGatewayGroup.

Nós do balanceador de carga

É usado um subconjunto de nós do cluster para o equilíbrio de carga, o que significa que são os nós anunciados para poderem aceitar o tráfego de equilíbrio de carga recebido. Este conjunto de nós é predefinido para o node pool do plano de controlo, mas pode especificar um node pool diferente na secção loadBalancer do ficheiro de configuração do cluster. Se especificar um node pool, este é usado para os nós do balanceador de carga, em vez do node pool do plano de controlo.

Os endereços IP flutuantes, que funcionam como altifalantes 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 e a interligação é iniciada a partir daí, independentemente de ser um nó do balanceador de carga. No entanto, os próximos saltos anunciados através do BGP são sempre os nós do equilibrador de carga.

Exemplo de topologia de peering

O diagrama seguinte mostra um exemplo de balanceamento de carga de serviços com intercâmbio de tráfego BGP. Existem dois endereços IP flutuantes atribuídos a nós nas respetivas sub-redes. Existem dois pares externos definidos. Cada IP flutuante estabelece uma relação de pares com ambos os pares externos.

Balanceamento de carga de serviços com peering BGP

Configure o balanceador de carga BGP

As secções seguintes descrevem como configurar os clusters e a rede externa para usar o balanceador de carga integrado com o BGP.

Planeie a integração com a infraestrutura externa

Para usar o balanceador de carga integrado com o BGP, tem de configurar a infraestrutura externa:

  • A infraestrutura externa tem de ser configurada para estabelecer uma relação de interconexão com cada um dos nós do plano de controlo no cluster para configurar a comunicação do plano de controlo. Estas sessões de peering são usadas para anunciar os VIPs do plano de controlo do Kubernetes.

  • A infraestrutura externa tem de ser configurada para estabelecer uma relação de intercâmbio 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 a interligação BGP para os VIPs de serviço. Recomendamos que use dois endereços IP flutuantes e dois pares para garantir a elevada disponibilidade das sessões BGP. O processo de reserva de IPs flutuantes é descrito como parte da configuração do cluster para o equilíbrio de carga agrupado com BGP.

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

Configure o cluster para o balanceamento de carga agrupado com BGP

Ativa e configura o equilíbrio de carga agrupado com BGP no ficheiro de configuração do cluster quando cria um cluster. No ficheiro de configuração do cluster, ativa as redes avançadas e atualiza a secção loadBalancer. Também pode anexar especificações para os seguintes três recursos personalizados:

  • NetworkGatewayGroup: especifica endereços IP flutuantes que são usados para sessões de peering BGP de serviços.

  • BGPLoadBalancer: especifica com seletores de etiquetas que pares são usados para o balanceamento de carga do BGP.

  • BGPPeer: especifica pares individuais, incluindo uma etiqueta para fins de seleção, para sessões de peering de BGP.

As instruções seguintes descrevem como configurar o cluster e os três recursos personalizados para configurar o equilíbrio de carga agrupado com BGP.

  1. Adicione o campo advancedNetworking ao ficheiro de configuração do cluster na secção clusterNetwork e defina-o como true.

    Este campo ativa a capacidade de redes avançadas, especificamente o recurso Network Gateway Group.

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

    Substitua CLUSTER_NAMESPACE pelo espaço de nomes do cluster. Por predefinição, os espaços de nomes do cluster para o Google Distributed Cloud são o nome do cluster com o prefixo cluster-. Por exemplo, se atribuir o nome test ao cluster, o espaço de nomes é cluster-test.

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

    Estes valores de campo ativam o equilíbrio de carga agrupado baseado no 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 BGP para o plano de controlo, adicione os seguintes campos à secçã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 o seguinte:

    • CLUSTER_ASN: o número do sistema autónomo para o cluster que está a ser criado.
    • PEER_IP: o endereço IP do dispositivo externo.
    • PEER_ASN: o número do sistema autónomo da rede que contém o dispositivo de pares externo.
    • CP_NODE_IP: (opcional) o endereço IP do nó do plano de controlo que se liga ao par externo. Se não especificar nenhum nó do plano de controlo, todos os nós do plano de controlo podem estabelecer ligação ao par externo. Se especificar um ou mais endereços IP, apenas os nós especificados participam em sessões de peering.

    Pode especificar vários pares externos. bgpPeers usa uma lista de mapeamentos. Recomendamos que especifique, pelo menos, dois pares externos para a elevada disponibilidade das sessões BGP. Para ver um exemplo com vários pares, consulte as Configurações de exemplo.

  4. Defina os campos loadBalancer.ports, loadBalancer.vips e loadBalancer.addressPools (valores predefinidos apresentados).

    ...
  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 usar para o equilíbrio de carga do plano de dados.

    Este passo é opcional. Se não retirar o comentário da secção nodePoolSpec, os nós do plano de controlo são usados para o equilíbrio 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 NetworkGatewayGroup recurso personalizado:

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

    ...
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
  nodeSelector:    # optional
  - NODE_SELECTOR
...

    Substitua o seguinte:

    • CLUSTER_NAMESPACE: o espaço de nomes do cluster. Por predefinição, os espaços de nomes do cluster para o Google Distributed Cloud são o nome do cluster com o prefixo cluster-. Por exemplo, se der o nome test ao seu cluster, o espaço de nomes é cluster-test.
    • FLOATING_IP: um endereço IP de uma das sub-redes do cluster. Tem de especificar, pelo menos, um endereço IP, mas recomendamos que especifique, pelo menos, dois endereços IP.
    • NODE_SELECTOR: (Opcional) um seletor de etiquetas para identificar nós para instanciar sessões de peering com pares externos, como comutadores top-of-rack (ToR). Se não for necessário, remova este campo.

    Certifique-se de que o recurso personalizado NetworkGatewayGroup tem o nome default e usa o espaço de nomes do cluster. Para ver um exemplo do aspeto da especificação de recursos personalizados, consulte as configurações de exemplo.NetworkGatewayGroup

  7. (Opcional) Especifique os pares a usar para o equilíbrio de carga do plano de dados configurando o recurso personalizado BGPLoadBalancer:

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

    Substitua o seguinte:

    • CLUSTER_NAMESPACE: o espaço de nomes do cluster. Por predefinição, os espaços de nomes do cluster para o Google Distributed Cloud são o nome do cluster com o prefixo cluster-. Por exemplo, se der o nome test ao seu cluster, o espaço de nomes é cluster-test.
    • PEER_LABEL: a etiqueta usada para identificar que pares usar para o equilíbrio de carga. Qualquer recurso personalizado BGPPeer com uma etiqueta correspondente especifica os detalhes de cada par.

    Certifique-se de que o recurso personalizado BGPLoadBalancer tem o nome default e usa o espaço de nomes do cluster. Se não especificar um BGPLoadBalancerrecurso personalizado, os pares do plano de controlo são usados automaticamente para o equilíbrio de carga do plano de dados. Para ver exemplos abrangentes, consulte Exemplos de configurações.

  8. (Opcional) Especifique os pares externos para o plano de dados configurando um ou mais BGPPeerrecursos personalizados:

    ...
---
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
  selectors:   # Optional
    gatewayRefs:
    - GATEWAY_REF
  ...

    Substitua o seguinte:

    • BGP_PEER_NAME: o nome do par.
    • CLUSTER_NAMESPACE: o espaço de nomes do cluster. Por predefinição, os espaços de nomes do cluster para o Google Distributed Cloud são o nome do cluster com o prefixo cluster-. Por exemplo, se der o nome test ao seu cluster, o espaço de nomes é cluster-test.
    • PEER_LABEL: a etiqueta usada para identificar que pares usar para o equilíbrio de carga. Esta etiqueta deve corresponder à etiqueta especificada no recurso personalizado BGPLoadBalancer.
    • CLUSTER_ASN: o número do sistema autónomo para o cluster que está a ser criado.
    • PEER_IP: o endereço IP do dispositivo externo. Recomendamos que especifique, pelo menos, dois pares externos, mas tem de especificar, pelo menos, um.
    • PEER_ASN: o número do sistema autónomo da rede que contém o dispositivo de pares externo.
    • SESSION_QTY: o número de sessões a estabelecer para este par. Recomendamos que estabeleça, pelo menos, duas sessões para garantir que mantém uma ligação ao par caso um dos seus nós fique inativo.
    • GATEWAY_REF: (Opcional) o nome de um recurso NetworkGatewayGroup a usar para peering. Se não for definido, podem ser usados todos os recursos de gateway. Use esta definição juntamente com o campo nodeSelector no recurso NetworkGatewayGroups para selecionar que nós usar para a interligação com um par externo específico, como um comutador ToR. Pode introduzir várias entradas para selecionar vários NetworkGatewayGroups, se quiser, no formato de um gateway por linha.

    Pode especificar vários pares externos criando BGPPeerrecursos personalizados adicionais. Recomendamos que especifique, pelo menos, dois pares externos (dois recursos personalizados) para a alta disponibilidade das sessões BGP. Se não especificar um recurso personalizado, os pares do plano de controlo são usados automaticamente para o equilíbrio de carga do plano de dados.BGPPeer

  9. Quando executa bmctl cluster create para criar o cluster, são executadas verificações prévias. Entre outras verificações, as verificações pré-voo validam a configuração do peering BGP para o plano de controlo e comunicam quaisquer problemas diretamente à estação de trabalho do administrador antes de o cluster poder ser criado.

    Se tiver êxito, os recursos de equilíbrio de carga BGP adicionados (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer) são colocados no cluster de administrador no espaço de nomes do cluster de utilizador. Use o ficheiro kubeconfig do cluster de administrador quando fizer atualizações subsequentes a estes recursos. Em seguida, o cluster de administrador reconcilia as alterações ao cluster de utilizadores. Se editar estes recursos diretamente no cluster de utilizadores, o cluster de administrador substitui as suas alterações em reconciliações subsequentes.

Recomendamos que use a capacidade BGP ADD-PATH para sessões de peering, conforme especificado na RFC 7911. Por predefinição, o protocolo BGP permite que apenas um único salto seguinte seja anunciado aos pares para um único prefixo. O BGP ADD-PATH permite anunciar vários saltos seguintes para o mesmo prefixo. Quando ADD-PATH é usado com o equilíbrio de carga agrupado baseado em BGP, o cluster pode anunciar vários nós do cluster como nós de front-end (próximos saltos) para um serviço de equilibrador 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 anunciando vários nós de cluster como saltos seguintes, oferece uma melhor escalabilidade da capacidade do plano de dados para o equilíbrio de carga.

Se o seu dispositivo externo de pares, como um comutador ou um router de topo de rack (ToR), suportar o BGP ADD-PATH, basta ativar apenas a extensão de receção. O equilíbrio de carga agrupado com BGP funciona sem a capacidade ADD-PATH, mas a restrição de anunciar um único nó de equilíbrio de carga por sessão de peering limita a capacidade do plano de dados do equilibrador de carga. Sem ADD-PATH, o Google Distributed Cloud escolhe nós para anunciar a partir do conjunto de nós do balanceador de carga e tenta distribuir os próximos saltos para diferentes VIPs por diferentes nós.

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

O Google Distributed Cloud atribui automaticamente endereços IP flutuantes em qualquer nó na mesma sub-rede que o endereço IP flutuante. As sessões de BGP são iniciadas a partir destes endereços IP, mesmo que não sejam direcionadas para os nós do equilibrador de carga. Este comportamento é intencional, uma vez que desvinculámos o plano de controlo (BGP) do plano de dados (conjuntos de nós do LB).

Se quiser restringir o conjunto de nós que podem ser usados para o peering BGP, pode designar uma sub-rede para ser usada apenas para nós do equilibrador de carga. Ou seja, pode configurar todos os nós nessa sub-rede para estarem no conjunto de nós do balanceador de carga. Em seguida, quando configurar endereços IP flutuantes que são usados para a interligação BGP, certifique-se de que são da mesma sub-rede. O Google Distributed Cloud garante que as atribuições de endereços IP flutuantes e o peering BGP ocorrem apenas a partir de nós do balanceador de carga.

Configure o balanceamento de carga de BGP com redes de pilha dupla

A partir da versão 1.14.0 do Google Distributed Cloud, o balanceador de carga integrado baseado em BGP suporta IPv6. Com a introdução do suporte de IPv6, pode configurar serviços LoadBalancer de IPv6 e de pilha dupla num cluster configurado para redes de pilha dupla. Esta secção descreve as alterações necessárias para configurar o equilíbrio de carga de pilha dupla com BGP.

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

  • O cluster subjacente tem de estar configurado para redes de pilha dupla:

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

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

    Para mais informações sobre a configuração de um cluster para redes de pilha dupla, consulte o artigo Redes de pilha dupla IPv4/IPv6.

  • Especifique um conjunto de endereços IPv6 no ficheiro de configuração do cluster em spec.loadBalancer.addressPools. Para que o MetalLB atribua endereços IP a um serviço de pilha dupla, tem de existir, pelo menos, um conjunto de endereços com endereços no formato IPv4 e IPv6.

A configuração de exemplo seguinte realça as alterações necessárias para o equilíbrio de carga agrupado de pilha dupla com 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 do balanceamento de carga agrupado de pilha dupla com BGP

Quando configurar o cluster para usar o dual-stack, o equilíbrio de carga agrupado com BGP, tenha em atenção as seguintes limitações:

  • O equilíbrio de carga do plano de controlo IPv6 não é suportado.

  • As sessões de BGP IPv6 não são suportadas, mas as rotas IPv6 podem ser anunciadas através de sessões IPv4 com o BGP multiprotocolo.

Exemplos de configurações

As secções seguintes demonstram como configurar o equilíbrio de carga baseado em BGP para diferentes opções ou comportamentos.

Configurar todos os nós para usarem os mesmos pares

Conforme mostrado no diagrama seguinte, esta configuração resulta num conjunto de pares externos (10.8.0.10 e 10.8.0.11) acessíveis por todos os nós. Os nós do plano de controlo (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 pares.

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

Equilíbrio de carga BGP em que todos os nós usam os mesmos pares

Conforme mostrado no exemplo de configuração do cluster seguinte, configura os pares para os nós do plano de controlo, bgpPeers, sem especificar controlPlaneNodes. Quando não são especificados nós para os pares, todos os nós do plano de controlo estabelecem ligação a todos os pares.

Especifica os endereços IP flutuantes a usar para sessões de peering de balanceamento de carga dos serviços no recurso personalizado NetworkGatewayGroup. Neste exemplo, uma vez que não é especificado nenhum BGPLoadBalancer, os pares do plano de controlo são usados automaticamente para as sessões BGP do plano de dados.

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

Configure nós do plano de controlo específicos para estabelecer relações de pares com pares externos específicos

Conforme mostrado no diagrama seguinte, esta configuração resulta em dois nós do plano de controlo (10.0.1.10 e 10.0.1.11) com peering com um par externo (10.0.1.254). O terceiro nó do plano de controlo (10.0.2.10) tem peering com outro par externo (10.0.2.254). Esta configuração é útil quando não quer que todos os nós se liguem a todos os pares. Por exemplo, pode querer que os nós do plano de controlo interajam apenas com os comutadores de topo de rack (ToR) correspondentes.

Os mesmos pares externos são acessíveis através de qualquer um dos endereços IP flutuantes (10.0.1.100 ou 10.0.2.100) reservados para sessões de peering de balanceamento de carga de serviços. Os endereços IP flutuantes podem ser atribuídos a nós que estão na mesma sub-rede.

Balanceamento de carga BGP com mapeamento explícito de nós do plano de controlo para pares

Conforme mostrado no exemplo de configuração do cluster seguinte, restringe os nós do plano de controlo que podem estabelecer ligação a um determinado par especificando os respetivos endereços IP no campo controlPlaneNodes para o par na secção bgpPeers.

Especifica os endereços IP flutuantes a usar para sessões de peering de balanceamento de carga dos serviços no recurso personalizado NetworkGatewayGroup. Neste exemplo, uma vez que não é especificado nenhum BGPLoadBalancer, os pares do plano de controlo são usados automaticamente para as sessões BGP do plano de dados.

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

Configure o plano de controlo e o plano de dados separadamente

Conforme mostrado no diagrama seguinte, esta configuração resulta em dois nós do plano de controlo (10.0.1.10 e 10.0.1.11) com peering com um par externo (10.0.1.254) e o terceiro nó do plano de controlo (10.0.2.11) com peering com outro par externo (10.0.2.254).

Um terceiro ponto externo (10.0.3.254) é acessível através de qualquer 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ços. Os endereços IP flutuantes podem ser atribuídos a nós que estão na mesma sub-rede.

Equilíbrio de carga BGP com configuração separada para o plano de controlo e o plano de dados

Conforme mostrado no exemplo de configuração do cluster seguinte, restringe os nós do plano de controlo que podem estabelecer ligação a um determinado par especificando os respetivos endereços IP no campo controlPlaneNodes para o par na secção bgpPeers.

Especifica os endereços IP flutuantes a usar para sessões de peering de balanceamento de carga dos serviços no recurso personalizado NetworkGatewayGroup.

Para configurar o equilíbrio de carga do plano de dados:

  • Especifique o par externo para o plano de dados no recurso BGPPeer e adicione uma etiqueta a usar para a seleção de pares, como cluster.baremetal.gke.io/default-peer: "true".

  • Especifique a etiqueta correspondente para o campo peerSelector 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/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

Modifique a configuração do equilíbrio de carga baseado em BGP

Depois de criar o cluster configurado para usar o balanceamento de carga integrado com BGP, é possível atualizar algumas definições de configuração, mas não é possível atualizar outras depois de criar o cluster.

Use o ficheiro kubeconfig do cluster de administrador quando fizer atualizações subsequentes aos recursos relacionados com o BGP (NetworkGatewayGroup, BGPLoadBalancer e BGPPeer). Em seguida, o cluster de administrador reconcilia as alterações com o cluster de utilizador. Se editar estes recursos diretamente no cluster de utilizadores, o cluster de administrador substitui as suas alterações em reconciliações subsequentes.

Plano de controlo

As informações de peering BGP do plano de controlo podem ser atualizadas no recurso Cluster. Pode adicionar ou remover pares especificados na secção de equilíbrio de carga do plano de controlo.

As secções seguintes descrevem as práticas recomendadas para atualizar as informações de peering BGP do plano de controlo.

Verifique o estado do par antes de fazer a atualização

Para minimizar o risco de configurar incorretamente os pares, verifique se as sessões de peering BGP do plano de controlo estão no estado esperado antes de fazer alterações. Por exemplo, se esperar que todas as sessões de peering BGP estejam atualmente ativas, verifique se todos os bgp-advertiserpods comunicam ready, o que indica que as sessões estão ativas. Se o estado atual não corresponder ao esperado, corrija o problema antes de atualizar uma configuração de pares.

Para obter informações sobre como obter detalhes da sessão BGP do plano de controlo, consulte o artigo Sessões BGP do plano de controlo.

Atualize os pares de forma controlada

Atualize um par de cada vez, se possível, para ajudar a isolar possíveis problemas:

  1. Adicione ou atualize um único par.
  2. Aguarde pela conciliação da configuração.
  3. Verifique se o cluster consegue estabelecer ligação ao nó igual atualizado ou novo.
  4. Remova os pares antigos ou desnecessários.

Serviços

Para atualizar os conjuntos de endereços e as definições dos nós do equilibrador de carga, edite nodePoolSpec no recurso Cluster.

Para modificar a configuração da interligação BGP após a criação do cluster, edite os recursos personalizados NetworkGatewayGroup e BGPLoadBalancer. Todas as modificações às informações de peering nestes recursos personalizados refletem-se na configuração da solução de equilíbrio de carga no cluster de destino.

Faça atualizações nos recursos de origem no espaço de nomes do cluster apenas no cluster de administração. Todas as modificações feitas aos recursos no cluster de destino (utilizador) são substituídas.

Resolução de problemas

As secções seguintes descrevem como aceder às informações de resolução de problemas para o equilíbrio de carga agrupado com BGP.

Sessões de BGP do plano de controlo

A configuração de peering BGP do plano de controlo é validada com verificações de pré-voo durante a criação do cluster. As verificações prévias tentam:

  • Estabeleça uma ligação BGP com cada par.
  • Anuncie o VIP do plano de controlo.
  • Verifique se é possível alcançar o nó do plano de controlo através do VIP.

Se a criação do cluster falhar nas verificações prévias, reveja os registos das verificações prévias para ver se existem erros. Os ficheiros de registo da verificação prévia com indicação de data/hora estão localizados no diretório baremetal/bmctl-workspace/CLUSTER_NAME/log.

Em tempo de execução, os altifalantes BGP do plano de controlo são executados como pods estáticos em cada nó do plano de controlo e escrevem informações de eventos nos registos. Estes pods estáticos incluem "bgpadvertiser" no respetivo nome, por isso, use o seguinte comando kubectl get pods para ver o estado dos pods do altifalante BGP:

kubectl -n kube-system get pods | grep bgpadvertiser

Quando os Pods estão a funcionar corretamente, a resposta tem um aspeto semelhante ao seguinte:

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 ver os registos do pod bgpadvertiser-node-01:

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

Sessões de BGP de serviços

O recurso BGPSession fornece informações sobre as sessões de BGP atuais. Para obter informações da sessão, primeiro, obtenha as sessões atuais e, em seguida, obtenha o recurso BGPSession para uma das sessões.

Use o seguinte comando kubectl get para apresentar uma lista das sessões atuais:

kubectl -n kube-system get bgpsessions

O comando devolve uma lista de sessões, como no exemplo seguinte:

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 obter o recurso BGPSession para a sessão 10.0.1.254-node-01 BGP:

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

O recurso BGPSession devolvido deve ter um aspeto 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 obter os recursos BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

A resposta, que deve ter um aspeto semelhante ao exemplo seguinte, mostra as rotas atualmente anunciadas:

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 ver detalhes sobre os próximos saltos que cada trajeto está a anunciar.

Recuperar o acesso ao VIP do plano de controlo para clusters autogeridos

Para recuperar o acesso ao VIP do plano de controlo num cluster de administrador, híbrido ou autónomo, tem de atualizar a configuração do BGP no cluster. Conforme mostrado no exemplo de comando seguinte, use SSH para estabelecer ligação ao nó e, em seguida, use 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 o seguinte:

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

Modifique a configuração de peering BGP no objeto de cluster. Depois de guardar a nova configuração do cluster, monitorize o estado dos pods bgpadvertiser. Se a configuração funcionar, os pods são reiniciados e ficam em bom estado assim que se ligam aos respetivos pares.

Validação manual de BGP

Esta secção contém instruções para validar manualmente a configuração do BGP. O procedimento configura uma ligação BGP de longa duração para que possa depurar ainda mais a configuração de BGP com a sua equipa de rede. Use este procedimento para validar a sua configuração antes de criar um cluster ou usá-lo se as verificações prévias relacionadas com o BGP falharem.

As verificações pré-voo automatizam as seguintes tarefas de validação do BGP:

  • Configure uma ligação BGP a um par.
  • Anuncie o VIP do plano de controlo.
  • Verifique se o tráfego enviado de todos os outros nós do cluster para o VIP atinge o nó do balanceador de carga atual.

Estas tarefas são executadas para cada par BGP em cada nó do plano de controlo. A aprovação nestas verificações é fundamental quando cria um cluster. No entanto, as verificações prévias não criam ligações de longa duração, pelo que a depuração de uma falha é difícil.

As secções seguintes fornecem instruções para configurar uma ligação BGP e anunciar um trajeto de uma única máquina de cluster a um par. Para testar várias máquinas e vários pares, repita as instruções novamente com uma combinação de máquina e par diferente.

Lembre-se de que as ligações BGP são estabelecidas a partir dos nós do plano de controlo, por isso, certifique-se de que testa este procedimento a partir de um dos nós do plano de controlo planeados.

Obtenha o ficheiro binário do programa de teste BGP

Execute os passos nesta secção na sua estação de trabalho de administrador. Estes passos obtêm o programa bgpadvertiser que é usado para testar as ligações BGP e copiá-lo para os nós do plano de controlo onde quer testar.

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

    Sem o registo do espelho

    Se não usar um espelho do registo, 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 o Registry Mirror

    Se usar um espelho do registo, 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 de replicação do registo.

  2. Para extrair o ficheiro binário bgpadvertiser.

    Sem o registo do espelho

    Para extrair o ficheiro 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 o Registry Mirror

    Para extrair o ficheiro 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 ficheiro binário bgpadvertiser para o nó do plano de controlo com o qual quer fazer o teste, execute o seguinte comando:

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Substitua o seguinte:

    • USERNAME: o nome de utilizador que usa para aceder ao nó do plano de controlo.

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

Configure uma ligação BGP

Execute os passos nesta secção num nó do plano de controlo.

  1. Crie um ficheiro de configuração no nó em /tmp/bgpadvertiser.conf com o seguinte aspeto:

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

    Substitua o seguinte:

    • NODE_IP: endereço IP do nó do plano de controlo em que se encontra.
    • CLUSTER_ASN: o número do sistema autónomo usado pelo cluster.
    • PEER_IP: o endereço IP de um dos pares externos que quer testar.
    • PEER_ASN: o número do sistema autónomo da rede que contém o dispositivo de pares externo.

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

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

    Substitua CONTROL_PLANE_VIP pelo endereço IP que vai usar para o VIP do plano de controlo. Este comando faz com que o anunciante BGP anuncie este endereço ao par.

  3. Veja o resultado do programa.

    Neste ponto, o daemon bgpadvertiser é iniciado, tenta estabelecer ligação ao par e anuncia o VIP. O programa imprime periodicamente mensagens (consulte o exemplo de saída seguinte) que incluem BGP_FSM_ESTABLISHED quando a ligação 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 não vir estas mensagens, verifique novamente os parâmetros de configuração do BGP no ficheiro de configuração e valide-os junto do administrador de rede. Agora, tem uma ligação BGP configurada. Pode confirmar junto do administrador de rede que a ligação foi estabelecida do lado dele e que a rota lhe foi anunciada.

Teste de tráfego

Para testar se a rede consegue encaminhar tráfego para o VIP, tem de adicionar o VIP ao nó do plano de controlo que está a executar o bgpadvertiser. Execute o seguinte comando num terminal diferente para poder deixar o bgpadvertiser em execução:

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

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    Substitua o seguinte:

    • CONTROL_PLANE_VIP: o argumento VIP --advertise-ip de bgpadvertiser.
    • INTF_NAME: a interface do Kubernetes no nó. Ou seja, a interface que tem o endereço IP que introduziu na configuração do Google Distributed Cloud para loadBalancer.bgpPeers.controlPlaneNodes.

  2. Envie um ping para o VIP a partir de um nó diferente:

    ping CONTROL_PLANE_VIP

    Se o ping não for bem-sucedido, pode haver um problema com a configuração do BGP no dispositivo de rede. Trabalhe com o administrador de rede para validar a configuração e resolver o problema.

Limpar

Certifique-se de que segue estes passos para repor o nó depois de verificar manualmente que o BGP está a funcionar. Se não repuser o nó corretamente, a configuração manual pode interferir com a verificação prévia ou a criação de clusters subsequente.

  1. Remova o VIP do nó do plano de controlo se 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 controlo, prima Ctrl+C no terminal bgpadvertiser para parar o bgpadvertiser.

  3. Verifique se não existem processos bgpadvertiser em execução:

    ps -ef | grep bgpadvertiser

  4. Se vir processos em execução, pare-os com o comando kill.