Configurer des équilibreurs de charge groupés avec BGP

Ce document explique comment configurer et utiliser des équilibreurs de charge groupés avec le protocole BGP (Border Gateway Protocol) pour Google Distributed Cloud. Ce mode d'équilibrage de charge est compatible avec l'annonce d'adresses IP virtuelles ServiceType LoadBalancer via le protocole eBGP (external Border Gateway Protocol) pour vos clusters. Dans ce scénario, votre réseau de clusters est un système autonome, qui établit une interconnexion avec un autre système autonome, un réseau externe, via l'appairage.

Les équilibreurs de charge groupés dotés de la fonctionnalité BGP s'appliquent à tous les types de clusters, mais les clusters d'administrateur ne sont compatibles qu'avec la partie d'équilibrage de charge du plan de contrôle.

L'utilisation des équilibreurs de charge groupés avec la fonctionnalité BGP offre les avantages suivants :

  • Elle utilise la fonctionnalité d'équilibrage de charge actif/actif N-directionnel, permettant un basculement plus rapide et une utilisation plus efficace de la bande passante disponible.
  • Il est compatible avec le protocole de couche 3 qui fonctionne avec des commutateurs et des routeurs haut de gamme tiers compatibles avec eBGP.
  • Elle permet aux centres de données qui exécutent une pile de réseau défini par logiciel avancée de transférer la limite de couche 3 jusqu'aux clusters.

Fonctionnement de l'équilibrage de charge groupé avec BGP

Les sections suivantes fournissent un résumé rapide du fonctionnement des équilibreurs de charge groupés avec BGP.

Appairage BGP

Les équilibreurs de charge groupés avec la fonctionnalité BGP démarrent plusieurs connexions BGP à votre infrastructure. BGP a les exigences techniques suivantes :

  • Les sessions d'appairage sont distinctes pour les adresses IP virtuelles du plan de contrôle et pour les adresses IP virtuelles de service.
  • Les sessions d'appairage de plans de contrôle sont lancées à partir des adresses IP des nœuds du plan de contrôle.
  • Les sessions d'appairage de services sont lancées à partir d'adresses IP flottantes que vous spécifiez dans la ressource personnalisée NetworkGatewayGroup.
  • La passerelle réseau du contrôleur GDC gère les adresses IP flottantes.
  • L'équilibrage de charge groupé basé sur BGP n'accepte que l'appairage eBGP.
  • L'appairage multi-saut est compatible par défaut.
  • Les mots de passe MD5 sur les sessions BGP ne sont pas acceptés.
  • Les sessions d'appairage basées sur IPv6 ne sont pas acceptées.
  • Les routes annoncées à un pair doivent être redistribuées sur le réseau et accessibles depuis n'importe quel autre emplacement du cluster.
  • L'utilisation de la fonctionnalité BGP ADD-PATH en mode de réception est recommandée pour les sessions d'appairage.
  • L'annonce de plusieurs chemins à partir de chaque pair entraîne un équilibrage de charge actif/actif.
  • Le routage ECMP (Equal-Cost Multi-Path) doit être activé pour votre réseau afin que plusieurs chemins puissent être utilisés pour répartir le trafic sur un ensemble de nœuds d'équilibreur de charge.

Équilibrage de charge du plan de contrôle

Chaque nœud de plan de contrôle de votre cluster établit des sessions BGP avec un ou plusieurs pairs dans votre infrastructure. Chaque nœud de plan de contrôle doit posséder au moins un pair. Dans le fichier de configuration du cluster, vous pouvez configurer quels nœuds du plan de contrôle se connectent à quels pairs externes.

Le schéma suivant montre un exemple d'appairage de plan de contrôle. Le cluster comporte deux nœuds de plan de contrôle dans un sous-réseau et un dans un autre. Il existe un pair externe (TOR) dans chaque sous-réseau, et les nœuds du plan de contrôle Google Distributed Cloud sont appairés à leur TOR.

Équilibrage de charge de service avec appairage BGP

Équilibrage de charge de service

En plus des sessions d'appairage lancées à partir de chaque nœud du plan de contrôle pour l'appairage du plan de contrôle, des sessions d'appairage supplémentaires sont lancées pour les services LoadBalancer. Ces sessions d'appairage ne sont pas lancées directement à partir des adresses IP des nœuds du cluster, mais utilisent des adresses IP flottantes à la place.

Les services avec une règle de réseau externalTrafficPolicy=Local sont compatibles. Toutefois, le paramètre externalTrafficPolicy=Local dépend de la charge de travail et entraîne la mise à jour des routes chaque fois qu'un pod supportant le service est ajouté ou supprimé complètement d'un nœud. Ce comportement de mise à jour de route peut entraîner la modification des flux de trafic par le routage ECMP (Equal Cost Multi-Path), ce qui peut entraîner des baisses de trafic.

Adresses IP flottantes

L'équilibrage de charge de service nécessite de réserver des adresses IP flottantes dans les sous-réseaux de nœud de cluster à utiliser pour l'appairage BGP. Au moins une adresse IP flottante est requise pour le cluster, mais nous vous recommandons de réserver au moins deux adresses afin de garantir une haute disponibilité pour les sessions BGP. Les adresses IP flottantes sont spécifiées dans la ressource personnalisée NetworkGatewayGroup, qui peut être incluse dans le fichier de configuration du cluster.

Avec les adresses IP flottantes, vous n'avez plus à vous soucier du mappage des adresses IP des enceintes BGP avec les nœuds. La passerelle réseau du contrôleur GDC se charge d'attribuer NetworkGatewayGroup aux nœuds et gère également les adresses IP flottantes. Si un nœud tombe en panne, la passerelle réseau du contrôleur GDC réattribue les adresses IP flottantes pour s'assurer que les pairs externes disposent d'une adresse IP déterministe à appairer.

Pairs externes

Pour l'équilibrage de charge du plan de données, vous pouvez utiliser les mêmes pairs externes que ceux spécifiés pour l'appairage des plans de contrôle dans la section loadBalancer.controlPlaneBGP du fichier de configuration du cluster. Vous pouvez également spécifier différents pairs BGP.

Si vous souhaitez spécifier différents pairs BGP pour l'appairage de plans de données, ajoutez les spécifications de ressource BGPLoadBalancer et BGPPeer au fichier de configuration du cluster. Si vous ne spécifiez pas ces ressources personnalisées, les pairs du plan de contrôle sont utilisés automatiquement pour le plan de données.

Vous spécifiez les pairs externes utilisés pour les sessions d'appairage avec les adresses IP flottantes dans la ressource personnalisée BGPPeer, que vous ajoutez au fichier de configuration du cluster. La ressource BGPPeer inclut un libellé d'identification utilisé par la ressource personnalisée BGPLoadBalancer correspondante. Spécifiez le libellé correspondant dans le champ peerSelector de la ressource personnalisée BGPLoadBalancer pour sélectionner le pair BGPPeer à utiliser.

La passerelle réseau pour le contrôleur GDC tente d'établir des sessions (le nombre de sessions est configurable) avec chaque pair externe à partir de l'ensemble d'adresses IP flottantes réservées. Nous vous recommandons de spécifier au moins deux pairs externes afin de garantir une haute disponibilité pour les sessions BGP. Chaque pair externe désigné pour l'équilibrage de charge des services doit être configuré pour être appairé à chaque adresse IP flottante spécifiée dans la ressource personnalisée NetworkGatewayGroup.

Nœuds d'équilibrage de charge

Un sous-ensemble de nœuds du cluster est utilisé pour l'équilibrage de charge, ce qui signifie qu'il s'agit des nœuds annoncés pour accepter le trafic entrant pour l'équilibrage de charge. Cet ensemble de nœuds est défini par défaut sur le pool de nœuds du plan de contrôle, mais vous pouvez spécifier un autre pool de nœuds dans la section loadBalancer du fichier de configuration du cluster. Si vous spécifiez un pool de nœuds, il est utilisé pour les nœuds de l'équilibreur de charge, au lieu du pool de nœuds du plan de contrôle.

Les adresses IP flottantes, qui fonctionnent comme des speakers BGP, peuvent ou non s'exécuter sur les nœuds de l'équilibreur de charge. Les adresses IP flottantes sont attribuées à un nœud du même sous-réseau et l'appairage est déclenché à partir de ce nœud, qu'il s'agisse ou non d'un nœud d'équilibreur de charge. Toutefois, les sauts suivants annoncés sur BGP sont toujours les nœuds de l'équilibreur de charge.

Exemple de topologie d'appairage

Le schéma suivant montre un exemple d'équilibrage de charge de service avec appairage BGP. Deux adresses IP flottantes sont attribuées aux nœuds de leurs sous-réseaux respectifs. Deux pairs externes sont définis. Chaque adresse IP flottante est appairée aux deux pairs externes.

Équilibrage de charge de service avec appairage BGP

Configurer l'équilibreur de charge BGP

Les sections suivantes décrivent comment configurer vos clusters et votre réseau externe pour utiliser l'équilibreur de charge groupé avec BGP.

Planifier votre intégration avec une infrastructure externe

Pour utiliser l'équilibreur de charge groupé avec BGP, vous devez configurer l'infrastructure externe:

  • L'infrastructure externe doit être configurée pour être appairée à chacun des nœuds de plan de contrôle du cluster afin de configurer la communication du plan de contrôle. Ces sessions d'appairage permettent d'annoncer les adresses IP virtuelles du plan de contrôle Kubernetes.

  • L'infrastructure externe doit être configurée pour être appairée à un ensemble d'adresses IP flottantes réservées pour la communication du plan de données. Les adresses IP flottantes sont utilisées pour l'appairage BGP pour les adresses IP virtuelles de service. Nous vous recommandons d'utiliser deux adresses IP flottantes et deux pairs pour garantir une haute disponibilité pour les sessions BGP. Le processus de réservation d'une adresse IP flottante est décrit dans le cadre de la configuration de votre cluster pour l'équilibrage de charge groupé avec BGP.

Une fois l'infrastructure configurée, ajoutez les informations d'appairage BGP au fichier de configuration du cluster. Le cluster que vous créez peut lancer des sessions d'appairage avec l'infrastructure externe.

Configurer votre cluster pour l'équilibrage de charge groupé avec BGP

Vous activez et configurez l'équilibrage de charge groupé avec BGP dans le fichier de configuration du cluster lorsque vous créez un cluster. Dans le fichier de configuration du cluster, vous activez la mise en réseau avancée et mettez à jour la section loadBalancer. Vous pouvez également ajouter des spécifications pour les trois ressources personnalisées suivantes :

  • NetworkGatewayGroup : spécifie les adresses IP flottantes utilisées pour les sessions d'appairage BGP des services.

  • BGPLoadBalancer: spécifie, avec les sélecteurs d'étiquettes, les pairs utilisés pour l'équilibrage de charge BGP.

  • BGPPeer : spécifie les pairs individuels, y compris un libellé à des fins de sélection, pour les sessions d'appairage BGP.

Les instructions suivantes décrivent comment configurer votre cluster et les trois ressources personnalisées pour configurer l'équilibrage de charge groupé avec BGP.

  1. Ajoutez le champ advancedNetworking au fichier de configuration du cluster dans la section clusterNetwork et définissez-le sur true.

    Ce champ active la fonctionnalité de mise en réseau avancée, en particulier la ressource Network Gateway Group.

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

    Remplacez CLUSTER_NAMESPACE par l'espace de noms du cluster. Par défaut, les espaces de noms de cluster pour Google Distributed Cloud correspondent au nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms est cluster-test.

  2. Dans la section loadBalancer du fichier de configuration du cluster, définissez mode sur bundled et ajoutez un champ type avec la valeur bgp.

    Ces valeurs de champ activent l'équilibrage de charge groupé basé sur BGP.

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. Pour spécifier les informations d'appairage BGP pour le plan de contrôle, ajoutez les champs suivants à la section 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
...

    Remplacez les éléments suivants :

    • CLUSTER_ASN: numéro de système autonome du cluster en cours de création.
    • PEER_IP : adresse IP de l'appareil pair externe.
    • PEER_ASN : numéro de système autonome du réseau qui contient l'appareil pair externe.
    • CP_NODE_IP : (facultatif) adresse IP du nœud de plan de contrôle qui se connecte au pair externe. Si vous ne spécifiez aucun nœud de plan de contrôle, tous les nœuds de plan de contrôle peuvent se connecter au pair externe. Si vous spécifiez une ou plusieurs adresses IP, seuls les nœuds spécifiés participent aux sessions d'appairage.

    Vous pouvez spécifier plusieurs pairs externes ; bgpPeers accepte une liste de mappages. Nous vous recommandons de spécifier au moins deux pairs externes pour la haute disponibilité pour les sessions BGP. Pour obtenir un exemple avec plusieurs pairs, consultez la section Exemples de configurations.

  4. Définissez les champs loadBalancer.ports, loadBalancer.vips et loadBalancer.addressPools (valeurs par défaut affichées).

    ...
  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. Spécifiez le nœud de cluster à utiliser pour l'équilibrage de charge du plan de données.

    Cette étape est facultative. Si vous n'annulez pas la mise en commentaire dans la section nodePoolSpec, les nœuds du plan de contrôle sont utilisés pour l'équilibrage de charge du plan de données.

    ...
  # 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. Réservez des adresses IP flottantes en configurant la ressource personnalisée NetworkGatewayGroup :

    Les adresses IP flottantes sont utilisées dans les sessions d'appairage pour l'équilibrage de charge du plan de données.

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

    Remplacez les éléments suivants :

    • CLUSTER_NAMESPACE: espace de noms du cluster. Par défaut, les espaces de noms de cluster pour Google Distributed Cloud correspondent au nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms est cluster-test.
    • FLOATING_IP: adresse IP de l'un des sous-réseaux du cluster. Vous devez spécifier au moins une adresse IP, mais nous vous recommandons de spécifier au moins deux adresses IP.
    • NODE_SELECTOR (facultatif) : sélecteur d'étiquettes permettant d'identifier les nœuds pour l'instanciation de sessions d'appairage avec des pairs externes, tels que des commutateurs top-of-rack (ToR). Si ce n'est pas nécessaire, supprimez ce champ.

    Assurez-vous que la ressource personnalisée NetworkGatewayGroup est nommée default et utilise l'espace de noms du cluster. Pour obtenir un exemple de spécification de ressource personnalisée NetworkGatewayGroup, consultez la section Exemples de configurations.

  7. (Facultatif) Spécifiez les pairs à utiliser pour l'équilibrage de charge du plan de données en configurant la ressource personnalisée BGPLoadBalancer:

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

    Remplacez les éléments suivants :

    • CLUSTER_NAMESPACE : espace de noms du cluster. Par défaut, les espaces de noms de cluster pour Google Distributed Cloud correspondent au nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms est cluster-test.
    • PEER_LABEL : libellé utilisé pour identifier les pairs à utiliser pour l'équilibrage de charge. Toute ressource personnalisée BGPPeer associée à un libellé spécifie les détails de chaque pair.

    Assurez-vous que la ressource personnalisée BGPLoadBalancer est nommée default et utilise l'espace de noms du cluster. Si vous ne spécifiez pas de ressource personnalisée BGPLoadBalancer, les pairs du plan de contrôle sont automatiquement utilisés pour l'équilibrage de charge du plan de données. Pour obtenir des exemples complets, consultez la section Exemples de configurations.

  8. (Facultatif) Spécifiez les pairs externes du plan de données en configurant une ou plusieurs ressources personnalisées BGPPeer :

    ...
---
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
  ...

    Remplacez les éléments suivants :

    • BGP_PEER_NAME : nom du pair.
    • CLUSTER_NAMESPACE: espace de noms du cluster. Par défaut, les espaces de noms de cluster pour Google Distributed Cloud correspondent au nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms est cluster-test.
    • PEER_LABEL : libellé utilisé pour identifier les pairs à utiliser pour l'équilibrage de charge. Ce libellé doit correspondre au libellé spécifié dans la ressource personnalisée BGPLoadBalancer.
    • CLUSTER_ASN: numéro de système autonome du cluster en cours de création.
    • PEER_IP : adresse IP de l'appareil pair externe. Nous vous recommandons de spécifier au moins deux pairs externes, mais vous devez en spécifier au moins un.
    • PEER_ASN : numéro de système autonome du réseau qui contient l'appareil pair externe.
    • SESSION_QTY : nombre de sessions à établir pour ce pair. Nous vous recommandons d'établir au moins deux sessions pour vous assurer de maintenir une connexion au pair en cas d'interruption de l'un de vos nœuds.
    • GATEWAY_REF: (facultatif) nom d'une ressource NetworkGatewayGroup à utiliser pour l'appairage. Si cette règle n'est pas configurée, tout ou partie des ressources de passerelle peuvent être utilisées. Utilisez ce paramètre conjointement avec le champ nodeSelector de la ressource NetworkGatewayGroups afin de sélectionner les nœuds à utiliser pour l'appairage avec un pair externe spécifique, tel qu'un commutateur ToR. Si vous le souhaitez, cette opération peut nécessiter plusieurs entrées pour sélectionner plusieurs objets NetworkGatewayGroups au format d'une passerelle par ligne.

    Vous pouvez spécifier plusieurs pairs externes en créant des ressources personnalisées BGPPeer supplémentaires. Nous vous recommandons de spécifier au moins deux pairs externes (deux ressources personnalisées) pour la haute disponibilité des sessions BGP. Si vous ne spécifiez pas de ressource personnalisée BGPPeer, les pairs du plan de contrôle sont automatiquement utilisés pour l'équilibrage de charge du plan de données.

  9. Lorsque vous exécutez bmctl cluster create pour créer votre cluster, les vérifications préliminaires s'exécutent. Entre autres vérifications, les vérifications préliminaires valident la configuration d'appairage BGP du plan de contrôle et signalent les problèmes éventuels directement au poste de travail administrateur avant la création du cluster.

    En cas de réussite, les ressources d'équilibrage de charge BGP ajoutées (NetworkGatewayGroup, BGPLoadBalancer et BGPPeer) sont transmises au cluster d'administrateur situé dans l'espace de noms du cluster d'utilisateur. Utilisez le fichier kubeconfig du cluster d'administrateur lorsque vous effectuez les mises à jour ultérieures de ces ressources. 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.

Nous vous recommandons d'utiliser la fonctionnalité BGP ADD-PATH pour les sessions d'appairage, comme spécifié dans le document RFC 7911. Par défaut, le protocole BGP ne permet d'annoncer qu'un seul saut suivant aux pairs pour un seul préfixe. La fonctionnalité BGP ADD-PATH permet d'annoncer plusieurs sauts suivants pour le même préfixe. Lorsque ADD-PATH est utilisé avec l'équilibrage de charge groupé basé sur BGP, le cluster peut annoncer plusieurs nœuds de cluster en tant que nœuds frontend (sauts suivants) pour un service d'équilibreur de charge (préfixe). Activez ECMP sur le réseau afin que le trafic puisse être réparti sur plusieurs chemins. La possibilité de distribuer le trafic en annonçant plusieurs nœuds de cluster en tant que sauts suivants améliore le scaling de la capacité d'équilibrage de charge du plan de données.

Si votre appareil de pairs externe, tel qu'un commutateur ou un routeur ToR, est compatible avec BGP ADD-PATH, il suffit d'activer l'extension de réception seulement. L'équilibrage de charge groupé avec BGP fonctionne sans la fonctionnalité ADD-PATH, mais la restriction de l'annonce d'un seul nœud d'équilibrage de charge par session d'appairage limite la capacité du plan de données de l'équilibreur de charge. Sans ADD-PATH, Google Distributed Cloud choisit les nœuds à annoncer à partir du pool de nœuds de l'équilibreur de charge et tente de répartir les sauts suivants pour différentes adresses IP virtuelles sur différents nœuds.

Restreindre l'appairage BGP aux nœuds de l'équilibreur de charge

Google Distributed Cloud attribue automatiquement des adresses IP flottantes à tout nœud du même sous-réseau que l'adresse IP flottante. Les sessions BGP sont lancées à partir de ces adresses IP, même si elles ne se trouvent pas sur les nœuds de l'équilibreur de charge. Ce comportement est intentionnel, car nous avons découplé le plan de contrôle (BGP) du plan de données (pools de nœuds LB).

Si vous souhaitez limiter l'ensemble de nœuds pouvant être utilisés pour l'appairage BGP, vous pouvez désigner un sous-réseau à n'utiliser que pour les nœuds d'équilibreur de charge. Autrement dit, vous pouvez configurer tous les nœuds de ce sous-réseau pour qu'ils se trouvent dans le pool de nœuds de l'équilibreur de charge. Ensuite, lorsque vous configurez des adresses IP flottantes qui sont utilisées pour l'appairage BGP, assurez-vous qu'elles proviennent de ce même sous-réseau. Google Distributed Cloud garantit que les attributions d'adresses IP flottantes et l'appairage BGP ont uniquement lieu à partir des nœuds de l'équilibreur de charge.

Configurer l'équilibrage de charge BGP avec une mise en réseau à double pile

À partir de la version 1.14.0 de Google Distributed Cloud, l'équilibreur de charge groupé basé sur BGP est compatible avec IPv6. Grâce à la compatibilité avec IPv6, vous pouvez configurer des services LoadBalancer à double pile et IPv6 sur un cluster configuré pour une mise en réseau à double pile. Cette section décrit les modifications requises pour configurer l'équilibrage de charge groupé à double pile avec BGP.

Pour activer les services LoadBalancer à double pile, les modifications de configuration suivantes sont requises:

  • Le cluster sous-jacent doit être configuré pour la mise en réseau à double pile:

    • Spécifiez les CIDR de services IPv4 et IPv6 dans le fichier de configuration du cluster sous spec.clusterNetwork.services.cidrBlocks.

    • Définissez les ressources ClusterCIDRConfig appropriées pour spécifier les plages CIDR IPv4 et IPv6 pour les pods.

    Pour en savoir plus sur la configuration d'un cluster pour la mise en réseau à double pile, consultez la page Mise en réseau à double pile IPv4/IPv6.

  • Spécifiez un pool d'adresses IPv6 dans le fichier de configuration du cluster sous spec.loadBalancer.addressPools. Pour que MetalLB puisse allouer des adresses IP à un service à double pile, au moins un pool d'adresses doit disposer d'adresses aux formats IPv4 et IPv6.

L'exemple de configuration suivant met en évidence les modifications nécessaires à l'équilibrage de charge groupé à double pile avec 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

Limites de l'équilibrage de charge groupé à double pile avec BGP

Lorsque vous configurez votre cluster pour utiliser l'équilibrage de charge groupé à double pile avec BGP, tenez compte des limites suivantes:

  • L'équilibrage de charge du plan de contrôle IPv6 n'est pas compatible.

  • Les sessions BGP IPv6 ne sont pas acceptées, mais les routes IPv6 peuvent être annoncées sur des sessions IPv4 à l'aide de BGP multiprotocole.

Exemples de configurations

Les sections suivantes expliquent comment configurer l'équilibrage de charge basé sur BGP pour différentes options et différents comportements.

Configurer tous les nœuds pour qu'ils utilisent les mêmes pairs

Comme le montre le schéma suivant, cette configuration génère un ensemble de pairs externes (10.8.0.10 et 10.8.0.11) qui sont accessibles par tous les nœuds. Les nœuds du plan de contrôle (10.0.1.10, 10.0.1.11 et 10.0.2.10) et les adresses IP flottantes (10.0.1.100 et 10.0.2.100) attribuées aux nœuds du plan de données atteignent tous les pairs.

Les mêmes pairs externes sont tous deux accessibles par l'une des adresses IP flottantes (10.0.1.100 ou 10.0.2.100) qui sont réservées à l'appairage de services loadBalancer. Les adresses IP flottantes peuvent être attribuées à des nœuds qui se trouvent dans le même sous-réseau.

Équilibrage de charge BGP avec tous les nœuds qui utilisent les mêmes pairs

Comme illustré dans l'exemple de configuration de cluster suivant, vous configurez les pairs pour les nœuds du plan de contrôle, bgpPeers, sans spécifier controlPlaneNodes. Lorsqu'aucun nœud n'est spécifié pour les pairs, tous les nœuds du plan de contrôle se connectent à tous les pairs.

Vous spécifiez les adresses IP flottantes à utiliser pour les sessions d'appairage de l'équilibrage de charge de services dans la ressource personnalisée NetworkGatewayGroup. Dans cet exemple, étant donné qu'aucun équilibreur de charge BGPLoadBalancer n'est spécifié, les pairs du plan de contrôle sont utilisés automatiquement pour les sessions BGP du plan de données.

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

Configurer des nœuds de plan de contrôle spécifiques pour les appairer à des pairs externes spécifiques

Comme le montre le schéma suivant, cette configuration génère deux nœuds de plan de contrôle (10.0.1.10 et 10.0.1.11) qui sont appairés à un seul pair externe (10.0.1.254). Le troisième nœud de plan de contrôle (10.0.2.10) est appairé à un autre pair externe (10.0.2.254). Cette configuration est utile lorsque vous ne souhaitez pas que tous les nœuds se connectent à tous les pairs. Par exemple, vous souhaiterez peut-être que les nœuds du plan de contrôle ne s'appairent qu'avec leurs commutateurs ToR correspondants.

Les mêmes pairs externes sont tous deux accessibles par l'une des adresses IP flottantes (10.0.1.100 ou 10.0.2.100) qui sont réservées aux sessions d'appairage d'équilibrage de charge de services. Les adresses IP flottantes peuvent être attribuées à des nœuds qui se trouvent dans le même sous-réseau.

Équilibrage de charge BGP avec mappage explicite des nœuds du plan de contrôle aux pairs

Comme illustré dans l'exemple de configuration de cluster suivant, vous limitez les nœuds du plan de contrôle pouvant se connecter à un pair donné en spécifiant leurs adresses IP dans le champ controlPlaneNodes du pair dans la section bgpPeers.

Vous spécifiez les adresses IP flottantes à utiliser pour les sessions d'appairage de l'équilibrage de charge de services dans la ressource personnalisée NetworkGatewayGroup. Dans cet exemple, étant donné qu'aucun équilibreur de charge BGPLoadBalancer n'est spécifié, les pairs du plan de contrôle sont utilisés automatiquement pour les sessions BGP du plan de données.

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

Configurer le plan de contrôle et le plan de données séparément

Comme le montre le schéma suivant, cette configuration génère deux nœuds de plan de contrôle (10.0.1.10 et 10.0.1.11) qui sont appairés à un seul pair externe (10.0.1.254), et le troisième nœud de plan de contrôle (10.0.2.11) qui est appairé à un autre pair externe (10.0.2.254).

Un troisième pair externe (10.0.3.254) est accessible par l'une des adresses IP flottantes (10.0.3.100 ou 10.0.3.101) qui sont réservées aux sessions d'appairage d'équilibrage de charge de services. Les adresses IP flottantes peuvent être attribuées à des nœuds qui se trouvent dans le même sous-réseau.

Équilibrage de charge BGP avec une configuration distincte pour le plan de contrôle et le plan de données

Comme illustré dans l'exemple de configuration de cluster suivant, vous limitez les nœuds du plan de contrôle pouvant se connecter à un pair donné en spécifiant leurs adresses IP dans le champ controlPlaneNodes du pair dans la section bgpPeers.

Vous spécifiez les adresses IP flottantes à utiliser pour les sessions d'appairage de l'équilibrage de charge de services dans la ressource personnalisée NetworkGatewayGroup.

Pour configurer l'équilibrage de charge du plan de données, procédez comme suit :

  • Spécifiez le pair externe pour le plan de données dans la ressource BGPPeer et ajoutez une étiquette à utiliser pour la sélection du pair, telle que cluster.baremetal.gke.io/default-peer: "true".

  • Spécifiez le libellé correspondant au champ peerSelector dans la ressource 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

Modifier la configuration de votre équilibrage de charge basé sur BGP

Une fois que vous avez créé votre cluster configuré pour utiliser l'équilibrage de charge groupé avec BGP, certains paramètres de configuration peuvent être mis à jour, mais certains ne peuvent pas être mis à jour après la création du cluster.

Utilisez le fichier kubeconfig du cluster d'administrateur lorsque vous effectuez des mises à jour ultérieures des ressources liées à BGP (NetworkGatewayGroup, BGPLoadBalancer 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.

Plan de contrôle

Les informations d'appairage BGP du plan de contrôle peuvent être mises à jour dans la ressource Cluster. Vous pouvez ajouter ou supprimer des pairs spécifiés dans la section sur l'équilibrage de charge du plan de contrôle.

Les sections suivantes décrivent les bonnes pratiques pour mettre à jour les informations d'appairage BGP du plan de contrôle.

Vérifier l'état du pair avant la mise à jour

Pour réduire le risque de mauvaise configuration des pairs, vérifiez que les sessions d'appairage BGP du plan de contrôle sont à l'état attendu avant d'apporter des modifications. Par exemple, si vous pensez que toutes les sessions d'appairage BGP sont actuellement actives, vérifiez que tous les pods bgp-advertiser sont à l'état ready, indiquant que les sessions sont opérationnelles. Si l'état actuel ne correspond pas à vos attentes, corrigez le problème avant de mettre à jour la configuration d'un pair.

Pour en savoir plus sur la récupération des informations sur la session BGP du plan de contrôle, consultez la section Sessions BGP du plan de contrôle.

Mettre à jour les pairs de manière contrôlée

Si possible, mettez à jour un pair à la fois, pour isoler les problèmes possibles :

  1. Ajoutez ou mettez à jour un seul pair.
  2. Attendez que la configuration soit rattachée.
  3. Vérifiez que le cluster peut se connecter au pair nouveau ou mis à jour.
  4. Supprimez les anciens pairs ou les pairs inutiles.

Services

Pour mettre à jour les pools d'adresses et les nœuds de l'équilibreur de charge, modifiez nodePoolSpec dans la ressource Cluster.

Pour modifier la configuration de l'appairage BGP après la création du cluster, modifiez les ressources personnalisées NetworkGatewayGroup et BGPLoadBalancer. Toute modification apportée aux informations d'appairage dans ces ressources personnalisées est reflétée dans la configuration de la solution d'équilibrage de charge dans le cluster cible.

N'effectuez des mises à jour dans les ressources sources de l'espace de noms du cluster que dans le cluster d'administrateur. Toutes les modifications apportées aux ressources du cluster cible (utilisateur) sont écrasées.

Dépannage

Les sections suivantes expliquent comment accéder aux informations de dépannage pour l'équilibrage de charge groupé avec BGP.

Sessions BGP du plan de contrôle

La configuration d'appairage BGP du plan de contrôle est validée avec des vérifications préliminaires lors de la création du cluster. Les vérifications préliminaires tentent d'effectuer les actions suivantes :

  • Établir une connexion BGP avec chaque pair.
  • Annoncer l'adresse IP virtuelle du plan de contrôle.
  • Vérifier que le nœud du plan de contrôle est accessible via l'adresse IP virtuelle.

Si la création de votre cluster échoue aux vérifications préliminaires, consultez les journaux de vérification préliminaire pour rechercher les erreurs. Les fichiers journaux horodatés des vérifications préliminaires se trouvent dans le répertoire baremetal/bmctl-workspace/CLUSTER_NAME/log.

Au moment de l'exécution, les speakers BGP du plan de contrôle s'exécutent en tant que pods statiques sur chaque nœud du plan de contrôle et écrivent les informations sur les événements dans les journaux. Le nom de ces pods statiques inclut "bgpadvertiser". Utilisez donc la commande kubectl get pods suivante pour afficher l'état des pods du speaker BGP :

kubectl -n kube-system get pods | grep bgpadvertiser

Lorsque les pods fonctionnent correctement, la réponse se présente comme suit :

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

Exécutez la commande suivante pour afficher les journaux du pod bgpadvertiser-node-01 :

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

Sessions BGP des services

La ressource BGPSession fournit des informations sur les sessions BGP en cours. Pour obtenir des informations sur les sessions, commencez par récupérer les sessions en cours, puis récupérez la ressource BGPSession de l'une des sessions.

Utilisez la commande kubectl get suivante pour lister les sessions en cours :

kubectl -n kube-system get bgpsessions

La commande renvoie la liste des sessions comme dans l'exemple suivant :

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

Utilisez la commande kubectl describe suivante pour obtenir la ressource BGPSession pour la session BGP 10.0.1.254-node-01 :

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

La ressource BGPSession renvoyée doit ressembler à l'exemple suivant :

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

Exécutez la commande kubectl get pour obtenir les ressources BGPAdvertisedRoute :

kubectl -n kube-system get bgpadvertisedroutes

La réponse, qui doit ressembler à l'exemple suivant, affiche les routes actuellement annoncées :

NAME                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

Utilisez kubectl describe pour afficher les détails des sauts suivants annoncés par chaque route.

Récupérer l'accès à l'adresse IP virtuelle du plan de contrôle pour les clusters autogérés

Pour récupérer l'accès à l'adresse IP virtuelle du plan de contrôle sur un cluster d'administrateur, hybride ou autonome, vous devez mettre à jour la configuration BGP sur le cluster. Comme indiqué dans l'exemple de commande suivant, utilisez SSH pour vous connecter au nœud, puis utilisez kubectl pour ouvrir la ressource du cluster afin de la modifier.

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

Remplacez les éléments suivants :

  • IDENTITY_FILE : nom du fichier d'identité SSH contenant la clé d'identité pour l'authentification par clé publique.
  • CLUSTER_NODE_IP : adresse IP du nœud du cluster.
  • CLUSTER_NAMESPACE : espace de noms du cluster
  • CLUSTER_NAME : nom du cluster.

Modifiez la configuration de l'appairage BGP dans l'objet du cluster. Après avoir enregistré la nouvelle configuration de cluster, surveillez l'état des pods bgpadvertiser. Si la configuration fonctionne, les pods redémarrent et deviennent opérationnels une fois connectés à leurs pairs.

Validation BGP manuelle

Cette section contient des instructions pour vérifier manuellement votre configuration BGP. La procédure configure une connexion BGP de longue durée afin que vous puissiez déboguer davantage la configuration BGP avec votre équipe réseau. Cette procédure vous permet de vérifier votre configuration avant de créer un cluster ou de l'utiliser en cas d'échec des vérifications préliminaires liées à BGP.

Les vérifications préliminaires automatisent les tâches de validation BGP suivantes :

  • Configurer une connexion BGP à un pair.
  • Annoncer l'adresse IP virtuelle du plan de contrôle.
  • Vérifier que le trafic envoyé depuis tous les autres nœuds de cluster vers l'adresse IP virtuelle atteint le nœud d'équilibreur de charge actuel.

Ces tâches sont exécutées pour chaque pair BGP sur chaque nœud du plan de contrôle. Ces vérifications sont essentielles lors de la création d'un cluster. Toutefois, les vérifications préliminaires ne créent pas de connexions de longue durée. Il est donc difficile de déboguer un échec.

Les sections suivantes fournissent des instructions pour configurer une connexion BGP et annoncer une route d'une seule machine de cluster vers un pair. Pour tester plusieurs machines et plusieurs pairs, répétez les instructions en utilisant une combinaison de machine et de pair différente.

N'oubliez pas que les connexions BGP sont établies à partir des nœuds du plan de contrôle. Veillez donc à tester cette procédure à partir de l'un des nœuds de votre plan de contrôle planifié.

Obtenir le binaire du programme de test BGP

Suivez les étapes décrites dans cette section sur votre poste de travail administrateur. Ces étapes permettent d'obtenir le programme bgpadvertiser utilisé pour tester les connexions BGP et de le copier sur les nœuds du plan de contrôle pour lesquels vous souhaitez effectuer le test.

  1. Récupérez l'image Docker ansible-runner.

    Sans miroir de registre

    Si vous n'utilisez pas de miroir de registre, exécutez les commandes suivantes pour extraire l'image Docker Ansible-runner:

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Avec miroir de registre

    Si vous utilisez un miroir de registre, exécutez les commandes suivantes pour extraire l'image Docker ansible-runner :

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Remplacez REGISTRY_HOST par le nom de votre serveur de miroir de registre.

  2. Pour extraire le binaire bgpadvertiser.

    Sans miroir de registre

    Pour extraire le binaire bgpadvertiser, exécutez la commande suivante :

    docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

    Avec miroir de registre

    Pour extraire le binaire bgpadvertiser, exécutez la commande suivante :

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

  3. Pour copier le binaire bgpadvertiser sur le nœud du plan de contrôle que vous souhaitez tester, exécutez la commande suivante :

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Remplacez les éléments suivants :

    • USERNAME : nom d'utilisateur que vous utilisez pour accéder au nœud de plan de contrôle.

    • CP_NODE_IP : adresse IP du nœud de plan de contrôle.

Configurer une connexion BGP

Exécutez les étapes de cette section sur un nœud de plan de contrôle.

  1. Créez un fichier de configuration sur le nœud à l'adresse /tmp/bgpadvertiser.conf qui se présente comme suit :

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

    Remplacez les éléments suivants :

    • NODE_IP : adresse IP du nœud de plan de contrôle sur lequel vous vous trouvez.
    • CLUSTER_ASN : numéro de système autonome utilisé par le cluster.
    • PEER_IP : adresse IP de l'un des pairs externes que vous souhaitez tester.
    • PEER_ASN : numéro de système autonome du réseau qui contient l'appareil pair externe.

  2. Exécutez le daemon bgpadvertiser en remplaçant l'adresse IP virtuelle de plan de contrôle dans la commande suivante :

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

    Remplacez CONTROL_PLANE_VIP par l'adresse IP que vous allez utiliser pour l'adresse IP virtuelle de votre plan de contrôle. Cette commande force l'annonceur BGP à annoncer cette adresse au pair.

  3. Consultez les résultats du programme.

    À ce stade, le daemon bgpadvertiser démarre, tente de se connecter au pair et annonce l'adresse IP virtuelle. Le programme imprime régulièrement des messages (consultez l'exemple de résultat suivant) qui incluent BGP_FSM_ESTABLISHED lorsque la connexion BGP est établie.

    {"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}"

Si vous ne voyez pas ces messages, vérifiez à nouveau les paramètres de configuration BGP dans le fichier de configuration et consultez l'administrateur réseau. Vous disposez maintenant d'une connexion BGP. Vous pouvez vérifier auprès de l'administrateur réseau qu'il voit bien la connexion établie de son côté ainsi que la route qui lui est annoncée.

Test du trafic

Pour vérifier que le réseau peut transférer du trafic vers l'adresse IP virtuelle, vous devez ajouter l'adresse IP virtuelle à votre nœud de plan de contrôle qui exécute bgpadvertiser. Exécutez la commande suivante dans un autre terminal pour pouvoir laisser bgpadvertiser en cours d'exécution :

  1. Ajoutez l'adresse IP virtuelle à votre nœud de plan de contrôle :

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    Remplacez les éléments suivants :

    • CONTROL_PLANE_VIP: argument --advertise-ip VIP de bgpadvertiser.
    • INTF_NAME: interface Kubernetes sur le nœud. c'est-à-dire l'interface possédant l'adresse IP que vous avez indiquée dans la configuration Google Distributed Cloud pour loadBalancer.bgpPeers.controlPlaneNodes.

  2. Émettez un ping vers l'adresse IP virtuelle depuis un autre nœud:

    ping CONTROL_PLANE_VIP

    Si le ping n'aboutit pas, il peut y avoir un problème avec la configuration BGP sur l'appareil réseau. Contactez votre administrateur réseau pour vérifier la configuration et résoudre le problème.

Effectuer un nettoyage

Assurez-vous de suivre ces étapes pour réinitialiser le nœud après avoir vérifié manuellement que le protocole BGP fonctionne. Si vous ne réinitialisez pas correctement le nœud, la configuration manuelle peut interférer avec la vérification préliminaire ou la création du cluster par la suite.

  1. Supprimez l'adresse IP virtuelle du nœud de plan de contrôle si vous l'avez ajoutée pour le test de trafic :

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. Sur le nœud du plan de contrôle, appuyez sur Ctrl+C dans le terminal bgpadvertiser pour arrêter l'annonceur bgpadvertiser.

  3. Vérifiez qu'aucun processus bgpadvertiser n'est en cours d'exécution :

    ps -ef | grep bgpadvertiser

  4. Si vous voyez des processus en cours d'exécution, arrêtez-les en utilisant la commande kill.