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 les clusters Anthos sur Bare Metal. 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 avec la fonctionnalité BGP s'appliquent à tous les types de cluster, mais les clusters d'administrateur ne sont compatibles qu'avec la partie équilibrage de charge du plan de contrôle de cette fonctionnalité.

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.
  • Elle est compatible avec le protocole de couche 3 qui présente une interopérabilité avec les commutateurs et les routeurs de haut de rack (ToR, top-of-rack) tiers qui sont 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 AnthosNetworkGateway.
  • Le contrôleur Anthos Network Gateway 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 réception est fortement 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 de plan de contrôle des clusters Anthos sur Bare Metal 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 de plan de contrôle pour l'appairage de 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.

Les services avec une règle de réseau externalTrafficPolicy=Local ne sont pas compatibles.

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 pour garantir une haute disponibilité pour les sessions BGP. Les adresses IP flottantes sont spécifiées dans la ressource personnalisée AnthosNetworkGateway, qui peut être incluse dans le fichier de configuration du cluster.

Les adresses IP flottantes évitent de devoir mapper les adresses IP des speakers BGP aux nœuds. Le contrôleur Anthos Network Gateway se charge d'attribuer AnthosNetworkGateway aux nœuds et gère également les adresses IP flottantes. Si un nœud tombe en panne, le contrôleur Anthos Network Gateway réaffecte les adresses IP flottantes pour garantir que les pairs externes ont une adresse IP déterministe avec laquelle s'appairer.

Pairs externes

Vous spécifiez les pairs externes utilisés pour les sessions d'appairage avec les adresses IP flottantes dans la ressource personnalisée BGPLoadBalancer, que vous ajoutez au fichier de configuration de cluster. Les pairs externes peuvent être identiques à ceux spécifiés pour l'appairage de plan de contrôle dans la section loadBalancer.controlPlaneBGP du fichier de configuration de cluster, ou vous pouvez spécifier différents pairs.

Le contrôleur Anthos Network Gateway tente d'établir deux sessions pour 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 pour garantir la haute disponibilité des sessions BGP. Chaque pair externe désigné pour l'équilibrage de charge des services doit être configuré pour effectuer l'appairage avec chaque adresse IP flottante spécifiée dans la ressource personnalisée AnthosNetworkGateway.

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 du 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 la procédure de 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.

  1. Ajoutez l'annotation baremetal.cluster.gke.io/enable-anthos-network-gateway au fichier de configuration du cluster et définissez-la sur true.

    Cette annotation active le contrôleur Anthos Network Gateway.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
  # This annotation is required for BGP load balancer
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
spec:
...

  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é des sessions BGP. Pour obtenir un exemple avec plusieurs pairs, consultez la section Exemples de configurations.

    Cette configuration d'appairage BGP pour le plan de contrôle ne peut pas être mise à jour une fois le cluster créé.

  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 AnthosNetworkGateway :

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

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
...

    Remplacez les éléments suivants :

    • CLUSTER_NAMESPACE : espace de noms du cluster. Par défaut, les espaces de noms des clusters Anthos sur Bare Metal sont le nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms sera 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.

    Pour obtenir un exemple d'affichage de la spécification de ressource personnalisée AnthosNetworkGateway, consultez la section Exemples de configurations.

  7. Spécifiez les informations d'appairage BGP pour le plan de données en configurant la ressource personnalisée BGPLoadBalancer :

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: CLUSTER_NAMESPACE
spec:
  localASN: CLUSTER_ASN
  peers:
  - peerIP: PEER_IP
    peerASN: PEER_ASN
    ...

    Remplacez l'élément suivant :

    • CLUSTER_NAMESPACE : espace de noms du cluster. Par défaut, les espaces de noms des clusters Anthos sur Bare Metal sont le nom du cluster précédé de cluster-. Par exemple, si vous nommez votre cluster test, l'espace de noms sera cluster-test.
    • CLUSTER_ASN : numéro de système autonome du cluster en cours de création.
    • PEER_IP : adresse IP de l'appareil pair externe. Vous devez spécifier au moins un pair externe, mais nous vous recommandons de spécifier au moins deux pairs. Vous pouvez utiliser les mêmes pairs que ceux spécifiés dans le plan de contrôle.
    • PEER_ASN : numéro de système autonome du réseau qui contient l'appareil pair externe.

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

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

Annoncer plusieurs sauts suivants par session avec BGP ADD-PATH

Nous vous recommandons vivement 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, les clusters Anthos sur Bare Metal choisissent les nœuds à annoncer dans le pool de nœuds de l'équilibreur de charge et tentent 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

Dans la version Bêta de cette fonctionnalité, les clusters Anthos sur Bare Metal attribuent automatiquement des adresses IP flottantes à n'importe quel 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. Les clusters Anthos sur Bare Metal garantissent que les attributions d'adresses IP flottantes et l'appairage BGP ne sont effectués qu'à partir des nœuds d'équilibreur de charge.

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 de 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 AnthosNetworkGateway. Vous spécifiez les pairs externes correspondants 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.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.8.0.10
    peerASN: 65002
  - peerIP: 10.8.0.11
    peerASN: 65002

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 AnthosNetworkGateway. Vous spécifiez les pairs externes correspondants 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.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.0.1.254
    peerASN: 65002
  - peerIP: 10.0.2.254
    peerASN: 65002

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.10) 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 AnthosNetworkGateway. Vous spécifiez les pairs externes correspondants 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/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
  name: bgplb
  namespace: cluster-bm
spec:
  bgp:
    localASN: 65001
    peers:
    - peerIP: 10.0.3.254
      peerASN: 65002

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.

Plan de contrôle

Les modifications apportées à la configuration de l'équilibrage de charge du plan de contrôle ne sont pas acceptées lors de la version Bêta.

Services

Vous pouvez modifier la configuration de l'appairage BGP une fois le cluster créé en modifiant les ressources personnalisées AnthosNetworkGateway 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 doit ressembler à ceci :

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                            AGE
10.0.1.254-node-01              170m
10.0.1.254-node-05              170m
10.0.3.254-node-01              170m
10.0.3.254-node-05              170m

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/v1alpha1
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                                  AGE
bgplb-default-load-balancer-example   5d5h
bgplb-gke-system-istio-ingress        6d

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

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 comme 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 VIP --advertise-ip de bgpadvertiser.
    • INTF_NAME : interface Kubernetes sur le nœud. Autrement dit, l'interface associée à l'adresse IP que vous avez insérée dans la configuration des clusters Anthos sur solution Bare Metal 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.