Ce document explique comment configurer la Network Connectivity Gateway pour un cluster dans Google Distributed Cloud.
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 des pods de votre cluster vers 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.
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 Google Distributed Cloud. 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
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 manifesteOverlayVPNTunnel
: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 ressourceOverlayVPNTunnel
.TUNNEL_NAME_2
: nom de votre choix pour la deuxième ressourceOverlayVPNTunnel
.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 manifesteOverlayBGPPeer
.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 ressourceOverlayBGPPeer
.BGP_PEER_2_NAME
: nom de votre choix pour la deuxième ressourceOverlayBGPPeer
.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.