Configurer Network Connectivity Gateway

Ce document explique comment configurer Network Connectivity Gateway dans des clusters Anthos sur solution Bare Metal.

Parfois, des pods s'exécutent dans un cluster qui doit communiquer avec les charges de travail exécutées dans un cloud privé virtuel (VPC). Cette communication doit être sécurisée. Vous aurez peut-être besoin que cette communication se déroule sur un réseau plat sans utiliser de serveur proxy. Network Connectivity Gateway permet ce type de communication.

Network Connectivity Gateway s'exécute en tant que pod dans votre cluster. Comme le montre le schéma suivant, cette solution fournit des tunnels IPsec pour le trafic entre les pods de votre cluster et les VM d'un VPC. Lorsque le pod de la passerelle reçoit des préfixes pour les sous-réseaux VPC via une session BGP (Border Gateway Protocol), il configure le transfert à l'aide de Dataplane V2. Lorsque d'autres pods envoient du trafic à une adresse avec l'un de ces préfixes, le trafic est dirigé vers le pod de la passerelle. Le pod de la passerelle achemine ensuite le trafic via un tunnel IPsec vers Google Cloud.

Schéma de Network Connectivity Gateway pour les clusters Anthos sur solution Bare Metal

Network Connectivity Gateway n'est pas compatible avec les fonctionnalités suivantes :

  • IPv6 pour les VPN haute disponibilité (et BGP)
  • MD5 pour BGP
  • Protocole BFD (Bidirectional Forwarding Detection) pour BGP

Créer des ressources Google Cloud

Pour activer Network Connectivity Gateway dans un cluster, vous devez disposer des ressources Google Cloud suivantes :

  • Un routeur Cloud

  • Une passerelle VPN haute disponibilité

  • Une passerelle VPN de pairs : une interface

  • Deux tunnels VPN

  • Deux sessions BGP : une pour chaque tunnel VPN

Pour savoir comment créer et configurer ces ressources, consultez la page Créer une passerelle VPN haute disponibilité vers une passerelle VPN de pairs.

Lorsque vous créez ces ressources, munissez-vous des informations suivantes et gardez-les à disposition pour plus tard :

  • Les deux adresses IP externes attribuées par Google Cloud à votre passerelle VPN haute disponibilité.

  • L'adresse IP publique pour le trafic IPsec/VPN qui est transmis par votre organisation. Cette adresse peut être le résultat d'une traduction d'adresse réseau (NAT).

  • Votre clé pré-partagée.

  • Le numéro ASN (Autonomous System Number) que vous avez attribué à votre routeur Cloud pour les sessions BGP.

  • Le numéro ASN que vous avez choisi d'utiliser dans votre cluster sur site pour les sessions BGP.

  • Pour chaque session BGP, l'adresse de liaison locale (par exemple, 169.254.1.1) qui doit être utilisée par votre routeur Cloud et l'adresse de liaison locale à utiliser dans votre cluster sur site.

Pour savoir comment trouver les informations concernant la configuration de votre session BGP, consultez la section Afficher la configuration de la session BGP.

Configuration requise pour les clusters

Le téléchargement de l'outil de ligne de commande Network Connectivity Gateway (ncgctl-v1.12.0-linux-amd64.tar.gz) n'est compatible qu'avec les clusters Anthos sur solution Bare Metal version 1.12. Si vous créez un cluster de version 1.12.0, vous activez Network Connectivity Gateway avec une annotation dans le fichier de configuration du cluster.

Pour activer Network Connectivity Gateway lors de la création du cluster, procédez comme suit :

  1. Dans le fichier de configuration du cluster, ajoutez l'annotation baremetal.cluster.gke.io/enable-gng: "true".

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      annotations:
        baremetal.cluster.gke.io/enable-gng: "true"
      name: my-cluster
      namespace: cluster-my-cluster
    spec:
    ...
      anthosBareMetalVersion: 1.12.0
      ...
    
  2. Créez le cluster à l'aide de bmctl create :

    bmctl create cluster -c CLUSTER_NAME
    

    Remplacez CLUSTER_NAME par le nom que vous avez spécifié lors de la création du fichier de configuration du cluster. Pour en savoir plus sur la création de clusters, consultez la page Présentation de la création de clusters.

Télécharger

Pour télécharger ncgctl, l'outil de ligne de commande Network Connectivity Gateway, procédez comme suit :

  1. Téléchargez les composants de Network Connectivity Gateway et les définitions de ressources personnalisées :

    gsutil cp gs://ncg-release/anthos-baremetal/ncgctl-v1.12.0-linux-amd64.tar.gz .
    
  2. Extrayez l'archive :

    tar -xvzf ncgctl-v1.12.0-linux-amd64.tar.gz
    

Installer

Pour installer ncgctl, procédez comme suit :

  1. Exécutez des vérifications préliminaires pour vous assurer que le cluster remplit les conditions préalables. Par exemple, assurez-vous que Dataplane V2 est activé.

    ./bin/ncgctl --verify --kubeconfig CLUSTER_KUBECONFIG
    

    Remplacez CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster.

  2. Installez Network Connectivity Gateway.

    ./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
    
  3. Si vous disposez d'un cluster de version 1.12.0 existant, vous pouvez utiliser la commande ncgctl suivante pour activer Network Connectivity Gateway :

    ./bin/ncgctl --enable-ncg-on-existing-cluster
    

    La commande ncgctl accepte -e comme version abrégée de l'option d'activation.

  4. Pour afficher d'autres raccourcis et autres informations d'aide sur les commandes, exécutez la commande suivante :

    ./bin/ncgctl --help
    

Créer un secret pour la clé pré-partagée

Les passerelles situées à chaque extrémité des tunnels IPsec utilisent un secret contenant votre clé pré-partagée pour l'authentification.

Pour créer le secret, procédez comme suit :

  1. Créez un fichier nommé psk-secret.yaml contenant les informations suivantes du fichier manifeste du secret :

    apiVersion: v1
    kind: Secret
    metadata:
      name: "ike-key"
      namespace: "kube-system"
    data:
      psk: PRE_SHARED_KEY
    

    Remplacez PRE_SHARED_KEY par une clé pré-partagée encodée en base64. Si vous disposez d'une clé en texte brut, encodez-la au format base64 avant de créer ce secret. Par exemple, si la console Google Cloud a généré automatiquement une clé, elle est en texte brut et vous devez l'encoder. Pour encoder une clé en base64, procédez comme suit :

    echo -n PLAINTEXT_KEY | base64
    
  2. Créer le secret :

    kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f psk-secret.yaml
    

Créer deux ressources personnalisées OverlayVPNTunnel

Pour démarrer deux sessions IPsec, créez deux ressources personnalisées OverlayVPNTunnel.

  1. Créez un fichier nommé overlay-vpn-tunnels.yaml contenant les informations suivantes du fichier manifeste OverlayVPNTunnel :

    apiVersion: networking.gke.io/v1alpha1
    kind: OverlayVPNTunnel
    metadata:
      namespace: "kube-system"
      name: TUNNEL_1_NAME
    spec:
      ikeKey:
        name: "ike-key"
        namespace: "kube-system"
      peer:
        publicIP: PEER_PUBLIC_IP_1
      self:
        publicIP: SELF_PUBLIC_IP
      localTunnelIP: SELF_LOCAL_TUNNEL_IP_1
    ---
    apiVersion: networking.gke.io/v1alpha1
    kind: OverlayVPNTunnel
    metadata:
      namespace: "kube-system"
      name: TUNNEL_2_NAME
    spec:
      ikeKey:
        name: "ike-key"
        namespace: "kube-system"
      peer:
        publicIP: PEER_PUBLIC_IP_2
      self:
        publicIP: SELF_PUBLIC_IP
      localTunnelIP: SELF_LOCAL_TUNNEL_IP_2
    

    Remplacez les éléments suivants :

    • TUNNEL_NAME_1 : nom de votre choix pour la première ressource OverlayVPNTunnel.

    • TUNNEL_NAME_2 : nom de votre choix pour la deuxième ressource OverlayVPNTunnel.

    • PEER_PUBLIC_IP_1 : adresse IP publique d'une interface de votre passerelle VPN haute disponibilité. Vous avez spécifié cette interface lors de la création du premier tunnel VPN.

    • PEER_PUBLIC_IP_2 : adresse IP publique de l'autre interface de votre passerelle VPN haute disponibilité. Vous avez spécifié cette interface lors de la création du deuxième tunnel VPN.

    • SELF_LOCAL_TUNNEL_IP_1 : adresse de liaison locale à utiliser dans votre cluster pour les sessions BGP sur le premier tunnel.

    • SELF_LOCAL_TUNNEL_IP_2 : adresse de liaison locale à utiliser dans votre cluster pour les sessions BGP sur le deuxième tunnel.

    • SELF_PUBLIC_IP : adresse IP publique pour le trafic IPsec/VPN qui est transmis par votre organisation. Cette adresse peut être le résultat d'une traduction d'adresse réseau (NAT).

  2. Créez les deux ressources OverlayVPNTunnels :

    kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-vpn-tunnels.yaml
    
  3. Vérifiez l'état des tunnels :

    kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayVPNTunnel \
        --namespace kube-system --output yaml
    

Créer deux ressources personnalisées OverlayBGPPeer

Pour démarrer une session BGP sur chacun des tunnels, créez deux ressources personnalisées OverlayBGPPeer.

  1. Créez un fichier nommé overlay-bgp-peers.yaml contenant les informations suivantes du fichier manifeste OverlayBGPPeer.

    apiVersion: networking.gke.io/v1alpha1
    kind: OverlayBGPPeer
    metadata:
      namespace: "kube-system"
      name: BGP_PEER_1_NAME
    spec:
      localASN: LOCAL_ASN
      localIP: LOCAL_IP
      peerIP: PEER_IP_1
      peerASN: PEER_ASN
      vpnTunnel: TUNNEL_1_NAME
    ---
    apiVersion: networking.gke.io/v1alpha1
    kind: OverlayBGPPeer
    metadata:
      namespace: "kube-system"
      name: BGP_PEER_2_NAME
    spec:
      localASN: LOCAL_ASN
      localIP: LOCAL_IP
      peerIP: PEER_IP_2
      peerASN: PEER_ASN
      vpnTunnel: TUNNEL_2_NAME
    

    Remplacez les éléments suivants :

    • BGP_PEER_1_NAME : nom de votre choix pour la première ressource OverlayBGPPeer.

    • BGP_PEER_2_NAME : nom de votre choix pour la deuxième ressource OverlayBGPPeer.

    • LOCAL_ASN : numéro ASN à utiliser dans votre cluster pour les sessions BGP.

    • LOCAL_IP : adresse IP publique pour le trafic IPsec/VPN qui est transmis par votre organisation. Cette adresse peut être le résultat d'une traduction d'adresse réseau (NAT).

    • PEER_IP_1 : adresse IP publique d'une interface de votre passerelle VPN haute disponibilité. Vous avez spécifié cette interface lors de la création du premier tunnel VPN.

    • PEER_IP_2 : adresse IP publique de l'autre interface de votre passerelle VPN haute disponibilité. Vous avez spécifié cette interface lors de la création du deuxième tunnel VPN.

    • PEER_ASN : numéro ASN attribué à votre routeur Cloud pour les sessions BGP.

    • TUNNEL_1_NAME : nom de la première ressource OverlayVPNTunnel que vous avez créée précédemment.

    • TUNNEL_2_NAME : nom de la deuxième ressource OverlayVPNTunnel que vous avez créée précédemment.

  2. Créez les ressources personnalisées OverlayBGPPeer :

    kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-bgp-peers.yaml
    
  3. Vérifiez l'état des sessions BGP :

    kubectl --kubeconfig CLUSTER_KUBECONFIG get OverlayBGPPeer --namespace kube-system \
        --output yaml
    

Vérifier l'état de Network Connectivity Gateway

L'installation a créé une ressource personnalisée NetworkConnectivityGateway.

  • Affichez la ressource personnalisée NetworkConnectivityGateway :

    kubectl --kubeconfig CLUSTER_KUBECONFIG get NetworkConnectivityGateway --namespace kube-system \
        --output yaml
    

    Le résultat renvoyé ressemble à ceci : Vérifiez que Status: Healthy s'affiche :

    apiVersion: networking.gke.io/v1alpha1
    kind: NetworkConnectivityGateway
    metadata:
      namespace: kube-system
      name: default
    spec:
    status:
        CurrNode: worker1-node
        CreatedTime: 2021-09-07T03:18:15Z
        LastReportTime: 2021-09-21T23:57:54Z
        Status:  Healthy
    

Consulter les journaux Network Connectivity Gateway

Le pod de la passerelle appartient à un DaemonSet nommé ncgd. Le nom du pod commence donc par ncgd.

Pour afficher les journaux Network Connectivity Gateway, procédez comme suit :

  1. Recherchez le nom du pod de la passerelle :

    kubectl --kubeconfig CLUSTER_KUBECONFIG pods --namespace kube-system | grep ncgd
    
  2. Affichez les journaux du pod de la passerelle :

    kubectl --kubeconfig CLUSTER_KUBECONFIG logs GATEWAY_POD --namespace kube-system \
        --output yaml
    

    Remplacez GATEWAY_POD par le nom du pod de la passerelle.

Désinstaller

Pour désinstaller Network Connectivity Gateway d'un cluster, exécutez le code suivant :

./bin/ncgctl –-uninstall --kubeconfig CLUSTER_KUBECONFIG

Dépannage

Pour obtenir des conseils de dépannage concernant Network Connectivity Gateway, consultez la page Résoudre les problèmes liés à Network Connectivity Gateway.