Mise en œuvre d'un modèle de réseau en mode plat avec compatibilité BGP

Ce document explique comment mettre en œuvre un modèle de réseau en mode plat compatible avec le protocole BGP (Border Gateway Protocol). Lorsque vous mettez en œuvre un modèle de réseau compatible avec BGP, BGP garantit de manière dynamique que les pods de différents domaines de couche 2 peuvent communiquer entre eux. La mise en réseau en mode plat avec BGP est parfois appelée IP plat dynamique.

Pour en savoir plus sur les modèles de réseau en mode plat, consultez la section Modèles réseau en mode plat ou en mode île.

Comment mettre en œuvre un réseau en mode plat utilisant BGP

La mise en réseau en mode plat avec BGP est activée lorsque vous créez un cluster. Vous ne pouvez pas activer cette fonctionnalité pour un cluster existant. Une fois cette fonctionnalité activée, vous pouvez modifier certains des paramètres de configuration.

Pour implémenter un cluster sur un modèle de réseau en mode plat compatible avec BGP:

1. Modifiez le fichier de configuration du cluster:

   • Définissez le champ spec.clusterNetwork.advancedNetworking sur true.

   • Si vous souhaitez activer la mise en réseau en mode plat pour IPv4, définissez le champ spec.clusterNetwork.flatIPv4 sur true.

     Vous pouvez également consulter la section Cluster à double pile (île IPv4, adresse IP plat dynamique IPv6), qui configure votre cluster avec la mise en réseau en mode plat pour IPv6 uniquement.

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

   Lorsque spec.clusterNetwork.flatIPv4 est défini sur true, le champ spec.clusterNetwork.pods.cidrBlocks est ignoré et peut être omis. Toutefois, vous devez ajouter un fichier manifeste ClusterCIDRConfigs dans le fichier de configuration du cluster (par nœud, par pool de nœuds et/ou par cluster).

2. Ajoutez un fichier manifeste NetworkGatewayGroup au fichier de configuration du cluster:

   Spécifiez les adresses IP flottantes à utiliser pour l'appairage BGP. Assurez-vous que le nom de la ressource est default et que l'espace de noms est l'espace de noms du cluster.

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

   La ressource personnalisée NetworkGatewayGroup gère une liste d'une ou plusieurs adresses IP flottantes. Les sessions d'appairage BGP sont lancées à partir d'adresses IP flottantes que vous spécifiez dans la ressource personnalisée NetworkGatewayGroup.

3. Ajoutez un fichier manifeste FlatIPMode au fichier de configuration du cluster:

   Le nom de la ressource FlatIPMode doit être default, et l'espace de noms est l'espace de noms du cluster. La valeur flatip-peer: "true" de peerSelector correspond aux étiquettes des objets de pairs BGP bgppeer1 et bgppeer2 (définis à l'étape suivante), de sorte que les deux pairs sont utilisés pour la mise en réseau en mode plat.

   Le fichier manifeste FlatIPMode suivant est destiné à la mise en réseau IPv4 à pile unique et en mode plat avec BGP. Pour découvrir d'autres configurations, consultez les exemples de configuration.

   ---
   apiVersion: baremetal.cluster.gke.io/v1alpha1
   kind: FlatIPMode
   metadata:
     name: default
     namespace: cluster-bm
   spec:
     enableBGPIPv4: true
     enableBGPIPv6: false
     peerSelector:
       flatip-peer: "true"
   

4. Ajoutez un ou plusieurs fichiers manifestes BGPPeer au fichier de configuration du cluster:

   Vous choisissez les noms des ressources, mais toutes les ressources BGPPeer doivent se trouver dans l'espace de noms du cluster.

   Remarque :IPv6 n'est pas compatible avec les sessions et les pairs BGP. Vous ne pouvez configurer des pairs BGP qu'avec des adresses IPv4.

   ---
   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. Ajoutez un fichier manifeste ClusterCIDRConfig au fichier de configuration du cluster:

   La ressource CusterCIDRConfig doit également se trouver dans l'espace de noms du 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 est une ressource personnalisée qui spécifie les plages CIDR des pods à allouer aux nœuds de manière dynamique. L'interface CNI utilise les plages CIDR des pods allouées sur un nœud pour allouer des adresses IP aux pods individuels qui s'exécutent sur le nœud. ClusterCIDRConfig est également utilisé pour la mise en réseau à double pile. Pour plus d'informations sur la ressource personnalisée ClusterCIDRConfig, y compris des exemples d'utilisation, consultez la section Comprendre la ressource personnalisée ClusterCIDRConfig.

6. Créez le cluster :

   bmctl create cluster
   

   Pour en savoir plus sur la création de clusters, consultez la page Présentation de la création de clusters.

   Si votre environnement est compatible avec le protocole BGP multiprotocole (MP-BGP), des routes IPv4 et IPv6 peuvent être annoncées sur ces sessions IPv4. Pour obtenir des exemples de différentes configurations, y compris des exemples utilisant MP-BGP, consultez la section Exemples de configuration.

Modifier votre configuration réseau en mode plat basée sur BGP

Une fois que vous avez créé votre cluster configuré pour utiliser un modèle de réseau en mode plat avec BGP, certains paramètres de configuration peuvent être mis à jour. Utilisez le fichier kubeconfig du cluster d'administrateur lorsque vous effectuez des mises à jour ultérieures des ressources liées à BGP (NetworkGatewayGroup, FlatIPMode et BGPPeer). Le cluster d'administrateur rapproche ensuite les modifications apportées au cluster d'utilisateur. Si vous modifiez ces ressources directement sur le cluster d'utilisateur, le cluster d'administrateur écrase vos modifications lors des rapprochements ultérieurs.

Exemples de configurations

Les sections suivantes incluent des exemples de configuration de cluster pour différentes variantes du modèle de réseau en mode plat avec BGP. Les exemples de fichiers de configuration ne sont pas complets. La plupart des paramètres de cluster qui ne sont pas pertinents pour la mise en réseau en mode plat avec BGP ont été omis.

Attention :Les adresses IP qui apparaissent dans les exemples de configuration suivants ne sont fournies qu'à titre d'exemple. Remplacez les adresses IP par les vôtres.

Cluster IPv4 à pile unique

L'exemple de fichier de configuration de cluster suivant présente les paramètres de configuration d'un cluster IPv4 à pile unique avec mise en réseau en mode plat avec 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 à double pile (île IPv4, adresse IP plat dynamique IPv6)

L'exemple de fichier de configuration de cluster suivant montre les paramètres de configuration d'un cluster à double pile (IPv4/IPv6) avec une mise en réseau en mode plat avec BGP, uniquement pour IPv6:

Remarque :Le champ spec.flatIPv4 est défini par défaut sur false et peut être omis pour cette configuration. Nous avons inclus ce champ dans l'exemple suivant pour faciliter les comparaisons.

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 à double pile (adresse IP plat dynamique IPv4, adresse IP plat dynamique IPv6)

L'exemple de fichier de configuration de cluster suivant présente les paramètres de configuration d'un cluster à double pile avec mise en réseau en mode plat avec 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

Dépannage

Pour vous aider à résoudre les problèmes liés à la mise en réseau en mode plat avec BGP, cette section inclut des instructions permettant de vérifier votre configuration:

1. Vérifiez si un objet FlatIPModes est créé dans l'espace de noms du cluster d'administrateur:

   kubectl get flatipmodes -A --kubeconfig ADMIN_KUBECONFIG
   

   La réponse doit se présenter comme suit:

   NAMESPACE                 NAME      AGE
   cluster-bm                default   2d17h
   

2. Vérifiez si un objet flatipmodes.networking.gke.io est créé sur le cluster d'utilisateur:

   L'objet flatipmodes.networking.gke.io est à l'échelle d'un cluster.

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

   La réponse doit se présenter comme suit:

   NAME      AGE
   default   2d17h
   

3. Obtenez les ressources BGPSessions pour afficher les sessions en cours:

   kubectl get bgpsessions -A --kubeconfig USER_KUBECONFIG
   

   La réponse doit se présenter comme suit:

   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. Obtenez les ressources BGPAdvertisedRoute pour afficher les routes actuellement annoncées:

   kubectl get bgpadvertisedroutes -A --kubeconfig USER_KUBECONFIG
   

   La réponse doit ressembler à ceci:

   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   
   

   Les noms des routes indiquent le prochain saut. Par exemple, route-via-222-22-208-240 de l'exemple de réponse précédent indique que le saut suivant pour le préfixe annoncé 222.2.0.0/24 est 222.22.208.240.