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 adresse IP plate 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 mettre en œuvre un cluster sur un modèle de réseau en mode plat compatible avec BGP, procédez comme suit:

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.

     Pour une autre option, consultez la section Cluster à double pile (île IPv4, adresse IP plate dynamique IPv6), qui configure votre cluster avec une 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 ressource est default et que l'espace de noms est bien 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 peerSelector flatip-peer: "true" correspond aux étiquettes des objets BGPPeer bgppeer1 et bgppeer2 (définis à l'étape suivante). Les deux pairs sont donc utilisés pour la mise en réseau en mode plat.

   Le fichier manifeste FlatIPMode suivant est destiné à la mise en réseau en mode plat à pile unique IPv4 avec BGP. Pour découvrir d'autres configurations, consultez la page 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 : Le protocole IPv6 n'est pas compatible avec les pairs et les sessions BGP. Vous pouvez configurer des pairs BGP avec des adresses IPv4 uniquement.

   ---
   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 de manière dynamique aux nœuds. L'interface CNI utilise les plages CIDR des pods allouées sur un nœud pour allouer des adresses IP aux pods individuels exécutés sur le nœud. ClusterCIDRConfig est également utilisé pour la mise en réseau à double pile. Pour en savoir plus 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 BGP multiprotocole (MP-BGP), les routes IPv4 et IPv6 peuvent être annoncées sur ces sessions IPv4. Pour obtenir des exemples de différentes configurations, y compris des exemples qui utilisent MP-BGP, consultez la section Exemples de configuration.

Modifier la configuration de votre mise en 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 apportez des modifications ultérieures aux ressources liées à BGP (NetworkGatewayGroup, FlatIPMode et BGPPeer). Le cluster d'administrateur réconcilie ensuite les modifications apportées au cluster utilisateur. Si vous modifiez directement ces ressources sur le cluster d'utilisateur, le cluster d'administrateur écrase vos modifications dans les rapprochements suivants.

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 que des exemples. Remplacez les adresses IP par les vôtres.

Cluster IPv4 à pile unique

L'exemple de fichier de configuration de cluster suivant montre les paramètres de configuration d'un cluster IPv4 à pile unique avec une 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 plate 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 pour IPv6 uniquement:

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 plate dynamique IPv4, adresse IP plate dynamique IPv6)

L'exemple de fichier de configuration de cluster suivant montre les paramètres de configuration d'un cluster à deux piles avec une 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 vous permettant de vérifier votre configuration:

1. Vérifiez si un objet FlatIPModes est créé dans l'espace de noms du cluster sur le cluster 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 se présenter comme suit :

   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, la valeur route-via-222-22-208-240 de l'exemple de réponse précédent indique que le prochain saut pour le préfixe annoncé 222.2.0.0/24 est 222.22.208.240.