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

Version 1.15 

• Le plus récent
• Version 1.16
• Versions antérieures (non compatibles)

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 paramètres de configuration.

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

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 découvrir une alternative, consultez la page 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 celui 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 doit être celui du cluster. La valeur de 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 et à pile unique IPv4 avec BGP. Pour découvrir d'autres configurations, consultez la section 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 sessions et 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 de pods à allouer aux nœuds de manière dynamique. L'interface CNI utilise les plages CIDR de pods allouées sur un nœud pour allouer des adresses IP à chacun des pods exécutés sur le nœud. La clé ClusterCIDRConfig est également utilisée 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 page 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 section Présentation de la création de clusters.

   Si votre environnement est compatible avec le protocole 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 utilisant MP-BGP, consultez 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 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 mises à jour ultérieures aux ressources liées à BGP (NetworkGatewayGroup, FlatIPMode et BGPPeer). Le cluster d'administrateur rapproche ensuite les modifications sur le cluster d'utilisateur. Si vous modifiez ces ressources directement sur le cluster d'utilisateur, le cluster d'administrateur écrasera 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 non 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 permettant de configurer 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 permettant de configurer 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 (IPv4 dynamique Flat IP, adresse IPv6 dynamique Flat)

L'exemple de fichier de configuration de cluster suivant montre les paramètres de configuration d'un cluster à double pile 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 comprend 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 défini à 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. Récupérez les ressources BGPAdvertisedRoute pour voir 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 d'itinéraires 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.