Configura gateway connettività di rete

Questo documento mostra come configurare Network Connectivity Gateway per un cluster in Google Distributed Cloud.

A volte hai pod in esecuzione in un cluster che deve comunicare con carichi di lavoro in esecuzione in un Virtual Private Cloud (VPC). Questa comunicazione deve essere sicura. E forse hai bisogno di questa comunicazione su una rete piatta senza usare un server proxy. Network Connectivity Gateway consente questo tipo di comunicazione.

Network Connectivity Gateway viene eseguito come pod nel cluster. Come mostrato nel seguente diagramma, questa soluzione fornisce i tunnel IPsec per il traffico dai pod nel tuo cluster alle VM in un VPC. Quando il pod gateway riceve prefissi per le subnet VPC in una sessione BGP (Border Gateway Protocol), configura l'inoltro utilizzando Dataplane V2. Quando altri pod inviano il traffico a un indirizzo con uno di questi prefissi, il traffico viene indirizzato al pod del gateway. Quindi il pod del gateway instrada il traffico su un tunnel IPsec verso Google Cloud.

Diagramma Network Connectivity Gateway per Google Distributed Cloud

Network Connectivity Gateway non supporta le seguenti caratteristiche e funzionalità:

  • IPv6 per VPN ad alta disponibilità (e BGP)
  • MD5 per BGP
  • Rilevamento bidirezionale del forwarding (BFD) per BGP

Creazione di risorse Google Cloud

Prima di abilitare Network Connectivity Gateway in un cluster, devi disporre delle seguenti risorse Google Cloud:

  • Un router Cloud

  • Un gateway VPN ad alta disponibilità

  • Un gateway VPN peer: un'interfaccia

  • Due tunnel VPN

  • Due sessioni BGP: una per ciascuno dei tuoi tunnel VPN

Per informazioni su come creare e configurare queste risorse, consulta Creazione di un gateway VPN ad alta disponibilità connesso a un gateway VPN peer.

Durante la creazione di queste risorse, raccogli le seguenti informazioni e fai in modo che siano disponibili per un secondo momento:

  • I due indirizzi IP esterni che Google Cloud ha assegnato al gateway VPN ad alta disponibilità.

  • L'indirizzo IP pubblico per il traffico IPsec/VPN che lascia la tua organizzazione. Questo indirizzo potrebbe essere il risultato di una Network Address Translation (NAT).

  • La tua chiave precondivisa.

  • Il numero di sistema autonomo (ASN) che hai assegnato al tuo router Cloud per le sessioni BGP.

  • L'ASN che hai scelto di utilizzare nel cluster on-premise per le sessioni BGP.

  • Per ogni sessione BGP, l'indirizzo locale rispetto al collegamento, ad esempio 169.254.1.1, che deve essere utilizzato dal router Cloud e l'indirizzo locale rispetto al collegamento da utilizzare nel cluster on-premise.

Per informazioni su come trovare i dettagli della configurazione della sessione BGP, consulta Visualizzare la configurazione delle sessioni BGP.

Requisiti per i cluster

Il download dello strumento a riga di comando di Network Connectivity Gateway, ncgctl-v1.12.0-linux-amd64.tar.gz, è compatibile solo con la versione 1.12 di Google Distributed Cloud. Se stai creando un nuovo cluster della versione 1.12.0, abiliti Network Connectivity Gateway con un'annotazione nel file di configurazione del cluster.

Per abilitare Network Connectivity Gateway durante la creazione del cluster:

  1. Nel file di configurazione del cluster, aggiungi l'annotazione 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. Usa bmctl create per creare il cluster:

    bmctl create cluster -c CLUSTER_NAME
    

    Sostituisci CLUSTER_NAME con il nome specificato al momento della creazione del file di configurazione del cluster. Per ulteriori informazioni sulla creazione dei cluster, consulta Panoramica della creazione dei cluster.

Scarica

Per scaricare ncgctl, lo strumento a riga di comando di Network Connectivity Gateway, segui questi passaggi:

  1. Scarica i componenti di Network Connectivity Gateway e le definizioni di risorse personalizzate:

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

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

Installa

Per installare ncgctl, segui questi passaggi:

  1. Esegui controlli preflight per assicurarti che il cluster soddisfi i preflight. Ad esempio, assicurati che Dataplane V2 sia abilitato.

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

    Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster.

  2. Installa Gateway di connettività di rete.

    ./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
    
  3. Se disponi di un cluster versione 1.12.0 esistente, puoi utilizzare il seguente comando ncgctl per abilitare Network Connectivity Gateway:

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

    Il comando ncgctl accetta -e come versione abbreviata del flag di abilitazione.

  4. Per visualizzare ulteriori scorciatoie e altri comandi della guida, usa il seguente comando:

    ./bin/ncgctl --help
    

Crea un secret per la tua chiave precondivisa

I gateway alle due estremità dei tunnel IPsec utilizzano un secret contenente la tua chiave precondivisa per l'autenticazione.

Per creare il secret:

  1. Crea un file denominato psk-secret.yaml con i seguenti dettagli del manifest del secret:

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

    Sostituisci PRE_SHARED_KEY con una chiave precondivisa codificata in Base64. Se hai una chiave in testo non crittografato, codificala in formato base64 prima di creare questo secret. Ad esempio, se la console Google Cloud ha generato una chiave per te, è in testo non crittografato e devi codificarla. Per codificare una chiave in Base64:

    echo -n PLAINTEXT_KEY | base64
    
  2. Crea il secret:

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

Crea due risorse personalizzate OverlayVPNTunnel

Per avviare due sessioni IPsec, crea due risorse personalizzate OverlayVPNTunnel.

  1. Crea un file denominato overlay-vpn-tunnels.yaml con i seguenti dettagli del file manifest 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
    

    Sostituisci quanto segue:

    • TUNNEL_NAME_1: un nome a tua scelta per il primo OverlayVPNTunnel.

    • TUNNEL_NAME_2: un nome a tua scelta per il secondo OverlayVPNTunnel.

    • PEER_PUBLIC_IP_1: l'indirizzo IP pubblico di un'interfaccia sul gateway VPN ad alta disponibilità. Hai specificato questa interfaccia quando hai creato il tuo primo tunnel VPN.

    • PEER_PUBLIC_IP_2: l'indirizzo IP pubblico dell'altra interfaccia sul gateway VPN ad alta disponibilità. Hai specificato questa interfaccia quando hai creato il secondo tunnel VPN.

    • SELF_LOCAL_TUNNEL_IP_1: l'indirizzo locale rispetto al collegamento da utilizzare nel cluster per le sessioni BGP sul primo tunnel.

    • SELF_LOCAL_TUNNEL_IP_2: l'indirizzo locale rispetto al collegamento da utilizzare nel cluster per le sessioni BGP sul secondo tunnel.

    • SELF_PUBLIC_IP: l'indirizzo IP pubblico per il traffico IPsec/VPN che lascia l'organizzazione. Questo indirizzo potrebbe essere il risultato di una Network Address Translation (NAT).

  2. Crea i due OverlayVPNTunnels:

    kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-vpn-tunnels.yaml
    
  3. Controlla lo stato dei tunnel:

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

Crea due risorse personalizzate OverlayBGPPeer

Per avviare una sessione BGP su ciascuno dei tunnel, crea due OverlayBGPPeer risorse personalizzate.

  1. Crea un file denominato overlay-bgp-peers.yaml con i seguenti dettagli del manifest 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
    

    Sostituisci quanto segue:

    • BGP_PEER_1_NAME: un nome a tua scelta per il primo OverlayBGPPeer.

    • BGP_PEER_2_NAME: un nome a tua scelta per il secondo OverlayBGPPeer.

    • LOCAL_ASN: l'ASN da usare nel cluster per le sessioni BGP.

    • LOCAL_IP: l'indirizzo IP pubblico per il traffico IPsec/VPN che lascia la tua organizzazione. Questo indirizzo potrebbe essere il risultato di una Network Address Translation (NAT).

    • PEER_IP_1: l'indirizzo IP pubblico di un'interfaccia sul gateway VPN ad alta disponibilità. Hai specificato questa interfaccia quando hai creato il tuo primo tunnel VPN.

    • PEER_IP_2: l'indirizzo IP pubblico dell'altra interfaccia sul gateway VPN ad alta disponibilità. Hai specificato questa interfaccia quando hai creato il secondo tunnel VPN.

    • PEER_ASN: l'ASN assegnato al router Cloud per le sessioni BGP.

    • TUNNEL_1_NAME: il nome del primo OverlayVPNTunnel creato in precedenza.

    • TUNNEL_2_NAME: il nome del secondo OverlayVPNTunnel creato in precedenza.

  2. Crea le OverlayBGPPeer risorse personalizzate:

    kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f overlay-bgp-peers.yaml
    
  3. Controlla lo stato delle sessioni BGP:

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

Controlla lo stato del Network Connectivity Gateway

L'installazione ha creato una risorsa personalizzata NetworkConnectivityGateway.

  • Visualizza la risorsa personalizzata NetworkConnectivityGateway:

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

    L'output è simile al seguente. Verifica che Status: Healthy sia visualizzato:

    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
    

Controllare i log di Network Connectivity Gateway

Il pod del gateway appartiene a un DaemonSet denominato ncgd, quindi il nome del pod inizia con ncgd.

Per visualizzare i log di Network Connectivity Gateway, segui questi passaggi:

  1. Trova il nome del pod del gateway:

    kubectl --kubeconfig CLUSTER_KUBECONFIG pods --namespace kube-system | grep ncgd
    
  2. Visualizza i log del pod del gateway:

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

    Sostituisci GATEWAY_POD con il nome del pod gateway.

Disinstalla

Per disinstallare Network Connectivity Gateway da un cluster:

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

Risoluzione dei problemi

Per suggerimenti sulla risoluzione dei problemi relativi al Network Connectivity Gateway, consulta Risoluzione dei problemi relativi al gateway di connettività di rete.