Configura gateway connettività di rete

Questo documento mostra come configurare Network Connettività Gateway per un cluster in Cluster Anthos su Bare Metal.

A volte hai pod in esecuzione in un cluster che deve comunicare con i carichi di lavoro in esecuzione in un virtual private cloud (VPC). Questa comunicazione deve essere sicura. Forse hai bisogno di questa comunicazione su una rete fissa senza utilizzare un server proxy. Questo gateway consente questo tipo di comunicazione.

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

Diagramma del gateway di connettività di rete per cluster Anthos su Bare Metal

Il gateway di rete non supporta le seguenti caratteristiche e funzionalità:

IPv6 per VPN ad alta disponibilità (e BGP)
MD5 per BGP
BiFD (Bidirectional Forwarding Detection) per BGP

Creare risorse Google Cloud

Prima di abilitare Network Connectivity Gateway in un cluster, devi avere le 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 tunnel VPN

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

Man mano che crei queste risorse, raccogli le seguenti informazioni e tienile a disposizione 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 l'organizzazione. Questo indirizzo potrebbe essere il risultato di una traduzione dell'indirizzo di rete (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 link-local, ad esempio 169.254.1.1, che deve essere utilizzato dal router Cloud e l'indirizzo link-local da utilizzare nel cluster on-premise.

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

Requisiti per i cluster

Il download dello strumento a riga di comando Gateway di connettività di rete, ncgctl-v1.12.0-linux-amd64.tar.gz è compatibile con la versione 1.12 dei cluster Anthos su Bare Metal. Se crei un nuovo cluster di versione 1.12.0, abiliti il gateway di connettività di rete con un'annotazione nel file di configurazione del cluster.

Per abilitare il gateway di connettività di rete durante la creazione del cluster:

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

Utilizza 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 la panoramica sulla creazione dei cluster.

Scarica

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

Scarica i componenti Network Connectivity Gateway e le definizioni di risorse personalizzate:
```
gsutil cp gs://ncg-release/anthos-baremetal/ncgctl-v1.12.0-linux-amd64.tar.gz .
```

Estrai l'archivio:

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

Installa

Per installare ncgctl, segui questi passaggi:

Esegui controlli preliminari per assicurarti che il cluster soddisfi i prerequisiti. Assicurati, ad esempio, che Dataplane V2 sia abilitato.
```
./bin/ncgctl --verify --kubeconfig CLUSTER_KUBECONFIG
```
Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster.
Installa il gateway di connettività di rete.
```
./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
```
Nota: se stai creando un nuovo cluster di versione 1.12.0, puoi saltare i seguenti passaggi. Quando crei cluster, ti consigliamo di aggiungere l'annotazione baremetal.cluster.gke.io/enable-gng: "true" al file di configurazione del cluster per abilitare il gateway di connettività di rete}. Per ulteriori informazioni, consulta i requisiti del cluster.
Se hai un cluster versione 1.12.0 esistente, puoi utilizzare il seguente comando ncgctl per abilitare il gateway di rete:
```
./bin/ncgctl --enable-ncg-on-existing-cluster
```
Il comando ncgctl accetta -e come versione abbreviata del flag di attivazione.
Per visualizzare altre scorciatoie e altri comandi per i comandi, utilizza il comando seguente:
```
./bin/ncgctl --help
```

Crea un Secret per la tua chiave precondivisa

I gateway a entrambe le estremità dei tunnel IPsec utilizzano un secret che contiene la tua chiave precondivisa per l'autenticazione.

Per creare il secret, segui questi passaggi:

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 con codifica Base64. Se hai una chiave in testo non crittografato, codificala con il formato base64 prima di creare questo secret. Ad esempio, se la console di Google Cloud ha generato una chiave per te, si trova in testo non crittografato e devi codificarla. Per codificare una chiave base64:
```
echo -n PLAINTEXT_KEY | base64
```

Crea il secret:

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

Crea due risorse personalizzate `OverlayVPNTunnel`

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

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 i primi 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 primo tunnel VPN.
- PEER_PUBLIC_IP_2: l'indirizzo IP pubblico dell'altra interfaccia del gateway VPN ad alta disponibilità. Hai specificato questa interfaccia durante la creazione del 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 link-local da utilizzare nel cluster per le sessioni BGP nel secondo tunnel.
- SELF_PUBLIC_IP: indirizzo IP pubblico del traffico IPsec/VPN che lascia l'organizzazione. Questo indirizzo potrebbe essere il risultato di una traduzione di indirizzo di rete (NAT).

Crea i due elementi OverlayVPNTunnels:

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

Verifica 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 risorse personalizzate OverlayBGPPeer.

Crea un file denominato overlay-bgp-peers.yaml con i seguenti dettagli del file 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 utilizzare nel cluster per le sessioni BGP.
- LOCAL_IP: l'indirizzo IP pubblico per il traffico IPsec/VPN che lascia l'organizzazione. Questo indirizzo potrebbe essere il risultato di una traduzione di indirizzo di rete (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 Tunnel OverlayVPN creato in precedenza.
- TUNNEL_2_NAME: il nome del secondo Tunnel OverlayVPN creato in precedenza.

Crea le risorse personalizzate OverlayBGPPeer:

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

Verifica lo stato delle sessioni BGP:

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

Verifica lo stato del gateway della rete

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 venga visualizzato Status: Healthy:

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 del gateway di connettività di rete

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

Per visualizzare i log del gateway di connettività di rete, segui questi passaggi:

Trova il nome del pod del gateway:

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

Visualizza i log dal pod gateway:

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

Sostituisci GATEWAY_POD con il nome del pod del gateway.

Disinstalla

Per disinstallare Network Connectivity Gateway da un cluster:

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

Risolvere i problemi

Per suggerimenti sulla risoluzione dei problemi relativi a Gateway di connettività di rete, consulta la sezione Risoluzione dei problemi di Gateway di connettività di rete.