Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

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 carichi di lavoro in esecuzione in un Virtual Private Cloud (VPC). Questa comunicazione deve essere sicura. E magari avete bisogno di questa comunicazione su una rete piatta senza utilizzare un server proxy. Network Connectivity Gateway abilita questo tipo di comunicazione.

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

Diagramma di 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
Bidirectional Forwarding Detection (BFD) per BGP

Creazione di risorse Google Cloud

Prima di abilitare Network Connectivity Gateway in un cluster, devi disporre di quanto segue 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 ogni 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 disponibili per un secondo momento:

I due indirizzi IP esterni che Google Cloud ha assegnato al tuo un 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.
L'ASN (Autonomous System Number) 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, come 169.254.1.1, da utilizzare dal router Cloud e l'indirizzo link-local 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 crei un nuovo cluster della versione 1.12.0, si abilita il Network Connectivity Gateway con un'annotazione di configurazione del cluster.

Per abilitare Network Connectivity Gateway durante la creazione del cluster:

Nel file di configurazione del cluster, aggiungi 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
  ...

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 di cluster, consulta la panoramica della creazione di cluster.

Scarica

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

Scarica i componenti di Network Connectivity Gateway e le definizioni delle risorse personalizzate:
```
gcloud storage 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 i controlli preflight per assicurarti che il cluster soddisfi i prerequisiti. 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.
Installa Gateway di connettività di rete.
```
./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
```
Nota: se stai creando un nuovo cluster della versione 1.12.0, puoi saltare il passaggio i seguenti passaggi. Quando crei i cluster, ti consigliamo di aggiungere l'annotazione baremetal.cluster.gke.io/enable-gng: "true" al file di configurazione del cluster per attivare Network Connectivity Gateway. Per ulteriori informazioni, vedi Requisiti dei cluster.
Se hai già un cluster della versione 1.12.0, puoi utilizzare il seguente comando ncgctl per attivare Network Connectivity Gateway:
```
./bin/ncgctl --enable-ncg-on-existing-cluster
```
Il comando ncgctl accetta -e come versione abbreviata del flag di abilitazione.
Per visualizzare altre scorciatoie e la guida di altri comandi, utilizza il seguente comando:
```
./bin/ncgctl --help
```

Crea un segreto per la chiave precondivisa

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

Per creare il secret:

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 in formato base64 prima di crea questo secret. Ad esempio, se la console Google Cloud ha generato una chiave per te, questa è in testo non cifrato e devi codificarla. Per codificare in Base64 chiave:
```
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 risorse personalizzate OverlayVPNTunnel.

Crea un file denominato overlay-vpn-tunnels.yaml con i seguenti dettagli del 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 del tuo scelta per i primi OverlayVPNTunnel.
- TUNNEL_NAME_2: un nome del tuo per il secondo OverlayVPNTunnel.
- PEER_PUBLIC_IP_1: l'indirizzo IP pubblico di un'interfaccia sul gateway VPN ad alta disponibilità. Tu 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 sopra il primo tunnel.
- SELF_LOCAL_TUNNEL_IP_2: l'indirizzo link-local da utilizzare nel cluster per le sessioni BGP tramite il secondo tunnel.
- SELF_PUBLIC_IP: l'IP pubblico per il traffico IPsec/VPN che lascia la tua organizzazione. Questo indirizzo potrebbe essere il risultato di una Network Address Translation (NAT).

Crea i due OverlayVPNTunnels:

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

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 ogni tunnel, crea due risorse personalizzate OverlayBGPPeer.

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 scelto da te per il primo OverlayBGPPeer.
- BGP_PEER_2_NAME: il nome di a tua scelta per il secondo OverlayBGPPeer.
- LOCAL_ASN: l'ASN da utilizzare nel tuo cluster per le sessioni BGP.
- LOCAL_IP: l'indirizzo IP pubblico per 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 una interfaccia sul gateway VPN ad alta disponibilità. Hai specificato questa interface quando hai creato il primo tunnel VPN.
- PEER_IP_2: l'indirizzo IP pubblico dell'altra interfaccia del gateway VPN ad alta disponibilità. Hai specificato a questa interfaccia quando hai creato il secondo tunnel VPN.
- PEER_ASN: l'ASN assegnato al tuo router Cloud per le sessioni BGP.
- TUNNEL_1_NAME: il nome del il primo OverlayVPNTunnel creato in precedenza.
- TUNNEL_2_NAME: il nome del secondo tunnel VPN overlay creato in precedenza.

Crea le risorse personalizzate OverlayBGPPeer:

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

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 gateway appartiene a un DaemonSet denominato ncgd, pertanto il nome del pod inizia con ncgd.

Per visualizzare i log di Network Connectivity Gateway:

Trova il nome del pod del gateway:

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

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 a Network Connectivity Gateway, consulta Risoluzione dei problemi di Network Connectivity Gateway.