Configurer Network Connectivity Gateway

Ce document explique comment configurer la Network Connectivity Gateway pour un cluster dans GKE sur 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 la Network Connectivity Gateway pour GKE sur une 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 la version 1.12 de GKE sur Bare Metal. 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 :

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

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 :

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

Extrayez l'archive :

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

Installer

Pour installer ncgctl, procédez comme suit :

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.
Installez Network Connectivity Gateway.
```
./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
```
Remarque : Si vous créez un cluster de version 1.12.0, vous pouvez ignorer les étapes suivantes. Lorsque vous créez des clusters, nous vous recommandons d'ajouter l'annotation baremetal.cluster.gke.io/enable-gng: "true" à votre fichier de configuration de cluster pour activer Network Connectivity Gateway. Pour en savoir plus, consultez la page Configuration requise pour les clusters.
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.
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 :

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

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.

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

Créez les deux ressources OverlayVPNTunnels :

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-vpn-tunnels.yaml

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.

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.

Créez les ressources personnalisées OverlayBGPPeer :

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-bgp-peers.yaml

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 :

Recherchez le nom du pod de la passerelle :

kubectl --kubeconfig CLUSTER_KUBECONFIG pods --namespace kube-system | grep ncgd

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.