Network Connectivity Gateway konfigurieren

In diesem Dokument wird gezeigt, wie Sie Network Connectivity Gateway für einen Cluster in Google Distributed Cloud konfigurieren.

Manchmal werden Pods in einem Cluster ausgeführt, die mit Arbeitslasten kommunizieren müssen, die in einer Virtual Private Cloud (VPC) ausgeführt werden. Diese Kommunikation muss sicher sein. Und vielleicht muss diese Kommunikation über ein flaches Netzwerk ohne Verwendung eines Proxyservers erfolgen. Network Connectivity Gateway ermöglicht diese Art der Kommunikation.

Das Network Connectivity Gateway wird als Pod in Ihrem Cluster ausgeführt. Wie im folgenden Diagramm dargestellt, stellt diese Lösung IPsec für Traffic von Pods in Ihrem Cluster zu VMs in einer VPC bereit. Wenn der Gateway-Pod Präfixe für VPC-Subnetze über eine Border Gateway Protocol-Sitzung (BGP) empfängt, richtet er die Weiterleitung mithilfe von Dataplane V2 ein. Wenn andere Pods Traffic an eine Adresse mit einem dieser Präfixe senden, wird der Traffic an den Gateway-Pod gesteuert. Anschließend leitet der Gateway-Pod den Traffic über einen IPsec-Tunnel an Google Cloud weiter.

Diagramm: Network Connectivity Gateway für Google Distributed Cloud

Das Network Connectivity Gateway unterstützt nicht die folgenden Funktionen:

IPv6 für HA VPN (und BGP)
MD5 für BGP
Bidirectional Forwarding Detection (BFD) für BGP

Google Cloud-Ressourcen erstellen

Bevor Sie das Network Connectivity Gateway in einem Cluster aktivieren, benötigen Sie die folgenden Google Cloud-Ressourcen:

Ein Cloud Router
Ein HA VPN-Gateway
Ein Peer-VPN-Gateway: eine Schnittstelle
Zwei VPN-Tunnel
Zwei BGP-Sitzungen: eine für jeden Ihrer VPN-Tunnel

Informationen zum Erstellen und Konfigurieren dieser Ressourcen finden Sie unter Gateway zwischen HA VPN und Peer-VPN erstellen.

Sammeln Sie beim Erstellen dieser Ressourcen die folgenden Informationen und halten Sie sie für später bereit:

Die beiden externen IP-Adressen, die Google Cloud Ihrem HA VPN-Gateway zugewiesen hat.
Die öffentliche IP-Adresse für IPsec-/VPN-Traffic, der Ihre Organisation verlässt. Diese Adresse kann das Ergebnis einer Netzwerkadressübersetzung (NAT) sein.
Ihr vorinstallierter Schlüssel.
Die Nummer des autonomen Systems (Autonomous System Number, ASN), die Sie Ihrem Cloud Router für BGP-Sitzungen zugewiesen haben.
Die ASN, die Sie in Ihrem lokalen Cluster für BGP-Sitzungen verwenden.
Für jede BGP-Sitzung die link-local Adresse, z. B. 169.254.1.1, die von Ihrem Cloud Router verwendet werden soll, und die link-local Adresse, die in Ihrer lokalen Umgebung verwendet werden soll.

Informationen zum Ermitteln der Details der BGP-Sitzungskonfiguration finden Sie unter BGP-Sitzungskonfiguration anzeigen.

Clusteranforderungen

Der Download des Network Connectivity Gateway-Befehlszeilentools (ncgctl-v1.12.0-linux-amd64.tar.gz) ist nur mit Version 1.12 von Google Distributed Cloud kompatibel. Wenn Sie einen neuen Cluster der Version 1.12.0 erstellen, aktivieren Sie das Network Connectivity Gateway mit einer Annotation in der Clusterkonfigurationsdatei.

So aktivieren Sie das Network Connectivity Gateway während der Clustererstellung:

Fügen Sie in der Clusterkonfigurationsdatei die Annotation baremetal.cluster.gke.io/enable-gng: "true" hinzu.

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

Verwenden Sie bmctl create, um den Cluster zu erstellen:
```
bmctl create cluster -c CLUSTER_NAME
```
Ersetzen Sie CLUSTER_NAME durch den Namen, den Sie beim Erstellen der Clusterkonfigurationsdatei angegeben haben. Weitere Informationen zum Erstellen von Clustern finden Sie unter Cluster erstellen.

Herunterladen

So laden Sie das Network Connectivity Gateway-Befehlszeilentool ncgctl herunter:

Laden Sie die Komponenten des Network Connectivity Gateway und die benutzerdefinierten Ressourcendefinitionen herunter:
```
gcloud storage cp gs://ncg-release/anthos-baremetal/ncgctl-v1.12.0-linux-amd64.tar.gz .
```

Extrahieren Sie das Archiv:

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

Installieren

Führen Sie zur Installation von ncgctl die folgenden Schritte aus:

Führen Sie Preflight-Prüfungen aus, um zu gewährleisten, dass der Cluster die Voraussetzungen erfüllt. Achten Sie beispielsweise darauf, dass Dataplane V2 aktiviert ist.
```
./bin/ncgctl --verify --kubeconfig CLUSTER_KUBECONFIG
```
Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Clusters.
Installieren Sie das Network Connectivity Gateway.
```
./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
```
Hinweis: Wenn Sie einen neuen Cluster der Version 1.12.0 erstellen, können Sie die folgenden Schritte überspringen. Wenn Sie Cluster erstellen, sollten Sie die Annotation baremetal.cluster.gke.io/enable-gng: "true" zu Ihrer Clusterkonfigurationsdatei hinzufügen, um das Network Connectivity Gateway zu aktivieren. Weitere Informationen finden Sie unter Clusteranforderungen.
Wenn Sie bereits einen Cluster der Version 1.12.0 haben, können Sie den folgenden ncgctl-Befehl verwenden, um das Network Connectivity Gateway zu aktivieren:
```
./bin/ncgctl --enable-ncg-on-existing-cluster
```
Der Befehl ncgctl akzeptiert -e als verkürzte Version des Aktivierungs-Flags.
Verwenden Sie den folgenden Befehl, um zusätzliche Tastenkombinationen und andere Befehlshilfen anzuzeigen:
```
./bin/ncgctl --help
```

Secret für den vorinstallierten Schlüssel erstellen

Die Gateways an beiden Enden der IPsec-Tunnel verwenden ein Secret mit Ihrem vorinstallierten Schlüssel für die Authentifizierung.

So erstellen Sie das Secret:

Erstellen Sie eine Datei mit dem Namen psk-secret.yaml und den folgenden Details des Secret-Manifests:
```
apiVersion: v1
kind: Secret
metadata:
  name: "ike-key"
  namespace: "kube-system"
data:
  psk: PRE_SHARED_KEY
```
Ersetzen Sie PRE_SHARED_KEY durch einen base64-codierten vorinstallierten Schlüssel. Wenn Sie einen Schlüssel im Klartext haben, codieren Sie den Schlüssel im base64-Format, bevor Sie dieses Secret erstellen. Wenn die Google Cloud Console beispielsweise einen Schlüssel für Sie generiert hat, befindet er sich in Klartext und muss codiert werden. So codieren Sie einen Schlüssel mit base64:
```
echo -n PLAINTEXT_KEY | base64
```

Secret erstellen:

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

Zwei benutzerdefinierte `OverlayVPNTunnel`-Ressourcen erstellen

Zum Starten von zwei IPsec-Sitzungen erstellen Sie zwei benutzerdefinierte OverlayVPNTunnel-Ressourcen.

Erstellen Sie eine Datei mit dem Namen overlay-vpn-tunnels.yaml und den folgenden OverlayVPNTunnel-Manifestdetails:
```
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
```
Dabei gilt:
- TUNNEL_NAME_1: ein Name Ihrer Wahl für den ersten OverlayVPNTunnel.
- TUNNEL_NAME_2: ein Name Ihrer Wahl für den zweiten OverlayVPNTunnel.
- PEER_PUBLIC_IP_1: die öffentliche IP-Adresse einer Schnittstelle auf Ihrem HA VPN-Gateway Sie haben diese Schnittstelle beim Erstellen Ihres ersten VPN-Tunnels angegeben.
- PEER_PUBLIC_IP_2: die öffentliche IP-Adresse der anderen Schnittstelle auf Ihrem HA VPN-Gateway Sie haben diese Schnittstelle beim Erstellen Ihres zweiten VPN-Tunnels angegeben.
- SELF_LOCAL_TUNNEL_IP_1: die link-local-Adresse, die in Ihrem Cluster für BGP-Sitzungen über den ersten Tunnel verwendet werden soll.
- SELF_LOCAL_TUNNEL_IP_2: die link-local-Adresse, die in Ihrem Cluster für BGP-Sitzungen über den zweiten Tunnel verwendet werden soll.
- SELF_PUBLIC_IP: die öffentliche IP-Adresse für IPsec-/VPN-Traffic, der Ihre Organisation verlässt. Diese Adresse kann das Ergebnis einer Netzwerkadressübersetzung (NAT) sein.

Erstellen Sie die beiden OverlayVPNTunnels:

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

Prüfen Sie den Status der Tunnel:

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

Zwei benutzerdefinierte `OverlayBGPPeer`-Ressourcen erstellen

Zum Starten einer BGP-Sitzung über jeden Tunnel erstellen Sie zwei benutzerdefinierte OverlayBGPPeer-Ressourcen.

Erstellen Sie eine Datei mit dem Namen overlay-bgp-peers.yaml und den folgenden OverlayBGPPeer-Manifestdetails.
```
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
```
Dabei gilt:
- BGP_PEER_1_NAME: ein Name Ihrer Wahl für den ersten OverlayBGPPeer.
- BGP_PEER_2_NAME: ein Name Ihrer Wahl für den zweiten OverlayBGPPeer.
- LOCAL_ASN: Die ASN, die in Ihrem Cluster für BGP-Sitzungen verwendet werden soll.
- LOCAL_IP: die öffentliche IP-Adresse für IPsec-/VPN-Traffic, der Ihre Organisation verlässt. Diese Adresse kann das Ergebnis einer Netzwerkadressübersetzung (NAT) sein.
- PEER_IP_1: die öffentliche IP-Adresse einer Schnittstelle auf Ihrem HA VPN-Gateway Diese Schnittstelle haben Sie beim Erstellen Ihres ersten VPN-Tunnels angegeben.
- PEER_IP_2: die öffentliche IP-Adresse der anderen Schnittstelle auf Ihrem VPN-Gateway Sie haben diese Schnittstelle beim Erstellen Ihres zweiten VPN-Tunnels angegeben.
- PEER_ASN: die ASN, die Ihrem Cloud Router für BGP-Sitzungen zugewiesen ist.
- TUNNEL_1_NAME: Name des ersten OverlayVPNTunnels, den Sie zuvor erstellt haben.
- TUNNEL_2_NAME: Name des zweiten OverlayVPNTunnels, den Sie zuvor erstellt haben.

Erstellen Sie die benutzerdefinierten Ressourcen OverlayBGPPeer:

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

Überprüfen Sie den Status der BGP-Sitzungen:

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

Status des Network Connectivity Gateways prüfen

Bei der Installation wurde eine benutzerdefinierte NetworkConnectivityGateway-Ressource erstellt.

Sehen Sie sich die benutzerdefinierte Ressource NetworkConnectivityGateway an:

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

Die entsprechende Ausgabe sieht etwa so aus: Prüfen Sie, ob Status: Healthy angezeigt wird:

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

Logs des Network Connectivity Gateways prüfen

Der Gateway-Pod gehört zu einem DaemonSet mit dem Namen ncgd. Der Pod-Name beginnt also mit ncgd.

Führen Sie die folgenden Schritte aus, um die Logs des Network Connectivity Gateways aufzurufen:

Suchen Sie den Namen des Gateway-Pods:

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

So rufen Sie die Logs aus dem Gateway-Pod auf:

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

Ersetzen Sie GATEWAY_POD durch den Namen des Gateway-Pods.

Deinstallieren

So deinstallieren Sie Network Connectivity Gateway aus einem Cluster:

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

Fehlerbehebung

Tipps zur Fehlerbehebung im Zusammenhang mit dem Network Connectivity Gateway finden Sie unter Fehlerbehebung beim Network Connectivity Gateway.