Implementar um modelo de rede no modo plano com suporte do BGP

Neste documento, descrevemos como implementar um modelo de rede no modo plano com suporte do Border Gateway Protocol (BGP). Quando você implementa um modelo de rede com o suporte do BGP, o BGP garante dinamicamente que os pods em diferentes domínios da camada 2 possam se comunicar uns com os outros. A rede de modo simples com BGP às vezes é chamada de IP plano dinâmico.

Para mais informações sobre modelos de rede no modo plano, consulte Modelos de rede no modo plano x ilha.

Como implementar uma rede de modo plano que usa o BGP

A rede de modo plano com BGP é ativada quando você cria um novo cluster. Não é possível ativar esse recurso para um cluster. Depois que esse recurso for ativado, será possível fazer alterações em algumas das definições de configuração.

Para implementar um cluster em um modelo de rede de modo plano compatível com BGP:

  1. Edite o arquivo de configuração do cluster:

    • Defina o campo spec.clusterNetwork.advancedNetworking como true
    • Se você quiser ativar a rede de modo plano para IPv4, defina o campo spec.clusterNetwork.flatIPv4 como true.

      Como alternativa, consulte Cluster de pilha dupla (Ilha IPv4, IP dinâmico dinâmico IPv6), que configura o cluster com rede de modo plano somente para IPv6.

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: bm
      namespace: cluster-bm
    spec:
      type: user
      ...
      clusterNetwork:
        advancedNetworking: true
        flatIPv4: true
      ...
    

    Quando spec.clusterNetwork.flatIPv4 for definido como true, o campo spec.clusterNetwork.pods.cidrBlocks será ignorado e poderá ser omitido. No entanto, você precisa adicionar um manifesto ClusterCIDRConfigs ao arquivo de configuração do cluster (por nó, por pool de nós e/ou por cluster).

  2. Anexe um manifesto NetworkGatewayGroup ao arquivo de configuração do cluster.

    Especifique os IPs flutuantes a serem usados para o peering do BGP. Verifique se o nome do recurso é default e se o namespace é o namespace do cluster.

    ---
    apiVersion: networking.gke.io/v1
    kind: NetworkGatewayGroup
    metadata:
      name: default
      namespace: cluster-bm
    spec:
      floatingIPs:
      - 10.0.1.100
      - 10.0.2.100
    

    O recurso personalizado NetworkGatewayGroup gerencia uma lista de um ou mais endereços IP flutuantes. As sessões de peering do BGP são iniciadas a partir de endereços IP flutuantes que você especifica no recurso personalizado NetworkGatewayGroup.

  3. Anexe um manifesto FlatIPMode ao arquivo de configuração do cluster.

    O nome do recurso FlatIPMode precisa ser default e o namespace é o namespace do cluster. O valor peerSelector flatip-peer: "true" corresponde aos rótulos nos objetos BGPPeer bgppeer1 e bgppeer2 (definidos na etapa a seguir), portanto, ambos os pares são usados para rede de modo plano.

    O manifesto FlatIPMode a seguir é para rede de pilha simples de modo plano IPv4 com BGP. Para ver configurações alternativas, consulte Exemplos de configuração.

    ---
    apiVersion: baremetal.cluster.gke.io/v1alpha1
    kind: FlatIPMode
    metadata:
      name: default
      namespace: cluster-bm
    spec:
      enableBGPIPv4: true
      enableBGPIPv6: false
      peerSelector:
        flatip-peer: "true"
    
  4. Anexe um ou mais manifestos BGPPeer ao arquivo de configuração do cluster:

    Você escolhe os nomes dos recursos, mas todos os recursos BGPPeer precisam estar no namespace do cluster.

    ---
    apiVersion: networking.gke.io/v1
    kind: BGPPeer
    metadata:
      name: bgppeer1
      namespace: cluster-bm
      labels:
        flatip-peer: "true"
    spec:
      localASN: 65001
      peerASN: 65000
      peerIP: 10.0.1.254
      sessions: 2
    ---
    apiVersion: networking.gke.io/v1
    kind: BGPPeer
    metadata:
      name: bgppeer2
      namespace: cluster-bm
      labels:
        flatip-peer: "true"
    spec:
      localASN: 65001
      peerASN: 65000
      peerIP: 10.0.2.254
      sessions: 2
    
  5. Anexe um manifesto ClusterCIDRConfig ao arquivo de configuração do cluster.

    O recurso CusterCIDRConfig também precisa estar no namespace do cluster.

    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
    

    ClusterCIDRConfig é um recurso personalizado que especifica os intervalos CIDR de pod a serem alocados aos nós dinamicamente. A CNI usa os intervalos de CIDR de pod alocados em um nó para alocar endereços IP aos pods individuais em execução no nó. O ClusterCIDRConfig também é usado para rede em pilha dupla. Para mais informações sobre o recurso personalizado ClusterCIDRConfig, incluindo exemplos de uso, consulte Como entender o recurso personalizado ClusterCIDRConfig.

  6. Crie o cluster:

    bmctl create cluster
    

    Para mais informações sobre como criar clusters, consulte Visão geral da criação de clusters.

    Se o ambiente for compatível com BGP de vários protocolos (MP-BGP, na sigla em inglês), será possível divulgar rotas IPv4 e IPv6 nessas sessões IPv4. Para exemplos de diferentes configurações, incluindo exemplos que usam MP-BGP, consulte Exemplos de configuração.

Modificar a configuração de rede de modo plano baseada no BGP

Depois de criar o cluster configurado para usar um modelo de rede de modo simples com o BGP, algumas definições de configuração poderão ser atualizadas. Use o arquivo kubeconfig do cluster de administrador quando você fizer atualizações subsequentes nos recursos relacionados ao BGP (NetworkGatewayGroup, FlatIPMode 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.

Exemplos de configurações

As seções a seguir incluem exemplos de configuração de cluster para diferentes variações do modelo de rede de modo plano com o BGP. Os arquivos de configuração de amostra não estão completos. A maioria das configurações de cluster que não são relevantes para a rede de modo plano com BGP foi omitida.

Cluster IPv4 de pilha única

Veja na amostra de arquivo de configuração de cluster a seguir as configurações para configurar um cluster IPv4 de pilha única com rede de modo plano com BGP:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
  ...
  clusterNetwork:
    advancedNetworking: true
    flatIPv4: true
    services:
      cidrBlocks:
      - 10.96.0.0/12
  ...
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm          # Must match the cluster namespace
spec:
  ipv4:
    cidr: "222.2.0.0/16"
    perNodeMaskSize: 24
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm           # Must match the cluster namespace
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.3.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: FlatIPMode
metadata:
  name: default
  namespace: cluster-bm            # Must match the cluster namespace
spec:
  enableBGPIPv4: true
  enableBGPIPv6: false
  peerSelector:
    flatipmode-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.1.254
  sessions: 2
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer2
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Cluster de pilha dupla (Ilha IPv4, IP dinâmico dinâmico IPv6)

Veja na amostra de arquivo de configuração de cluster a seguir as configurações para configurar um cluster de pilha dupla (IPv4/IPv6) com rede de modo plano com BGP para apenas IPv6:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
  ...
  clusterNetwork:
    advancedNetworking: true
    flatIPv4: false
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/12
      # Additional IPv6 CIDR block determines if the cluster is dual-stack
      - 2620:0:1000:2630:5:2::/112
  ...
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm          # Must match the cluster namespace
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2222:3::/112"
    perNodeMaskSize: 120
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm           # Must match the cluster namespace
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.3.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: FlatIPMode
metadata:
  name: default
  namespace: cluster-bm            # Must match the cluster namespace
spec:
  enableBGPIPv4: false
  enableBGPIPv6: true
  peerSelector:
    flatipmode-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.1.254
  sessions: 2
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer2
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Cluster de pilha dupla (IP dinâmico dinâmico IPv4, IP dinâmico dinâmico IPv6)

Veja na amostra de arquivo de configuração de cluster a seguir as configurações para configurar um cluster de pilha dupla com rede de modo plano com BGP:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
  ...
  clusterNetwork:
    advancedNetworking: true
    flatIPv4: true
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/12
      # Additional IPv6 CIDR block determines if the cluster is dual-stack
      - 2620:0:1000:2630:5:2::/112
  ...
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm          # Must match the cluster namespace
spec:
  ipv4:
    cidr: "222.2.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2222:3::/112"
    perNodeMaskSize: 120
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm           # Must match the cluster namespace
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.3.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: FlatIPMode
metadata:
  name: default
  namespace: cluster-bm            # Must match the cluster namespace
spec:
  enableBGPIPv4: true
  enableBGPIPv6: true
  peerSelector:
    flatipmode-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.1.254
  sessions: 2
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer2
  namespace: cluster-bm            # Must match the cluster namespace
  labels:
    flatipmode-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Solução de problemas

Nesta seção, há instruções para verificar a configuração que ajuda você a resolver problemas relacionados à rede de modo plano com o BGP:

  1. Verifique se um objeto FlatIPModes foi criado no namespace do cluster do administrador:

    kubectl get flatipmodes -A --kubeconfig ADMIN_KUBECONFIG
    

    A resposta deverá ser parecida com esta:

    NAMESPACE                 NAME      AGE
    cluster-bm                default   2d17h
    
  2. Verifique se um objeto flatipmodes.networking.gke.io foi criado no cluster de usuário:

    O objeto flatipmodes.networking.gke.io tem escopo de cluster.

    kubectl get flatipmodes.networking.gke.io --kubeconfig USER_KUBECONFIG
    

    A resposta deverá ser parecida com esta:

    NAME      AGE
    default   2d17h
    
  3. Acesse os recursos do BGPSessions para ver as sessões atuais:

    kubectl get bgpsessions -A --kubeconfig USER_KUBECONFIG
    

    A resposta deverá ser parecida com esta:

    NAMESPACE     NAME                LOCAL ASN   PEER ASN   LOCAL IP       PEER IP        STATE            LAST REPORT
    kube-system   10.0.1.254-node-01  65500       65000      10.0.1.100     10.0.1.254     Established      2s
    kube-system   10.0.1.254-node-02  65500       65000      10.0.3.100     10.0.1.254     NotEstablished   2s
    kube-system   10.0.3.254-node-01  65500       65000      10.0.1.100     10.0.3.254     NotEstablished   2s
    kube-system   10.0.3.254-node-02  65500       65000      10.0.3.100     10.0.3.254     Established      2s
    
  4. Acesse os recursos BGPAdvertisedRoute para ver as rotas divulgadas atualmente:

    kubectl get bgpadvertisedroutes -A --kubeconfig USER_KUBECONFIG
    

    A resposta será parecida com esta:

    NAMESPACE     NAME                     PREFIX         METRIC
    kube-system   route-via-222-22-208-240   222.2.0.0/24
    kube-system   route-via-222-22-209-240   222.2.1.0/24
    

    Os nomes das rotas indicam o próximo salto. Por exemplo, route-via-222-22-208-240 da resposta do exemplo anterior indica que o próximo salto para o prefixo anunciado 222.2.0.0/24 é 222.22.208.240.