Configura Network Connectivity Gateway

En este documento, se muestra cómo configurar Network Connectivity Gateway para un clúster de los clústeres de Anthos en equipos físicos.

A veces, tienes Pods en ejecución en un clúster que debe comunicarse con cargas de trabajo que se ejecutan en una nube privada virtual (VPC). Esta comunicación debe ser segura. Tal vez necesites que esta comunicación se realice en una red plana sin usar un servidor proxy. Network Connectivity Gateway habilita este tipo de comunicación.

Network Connectivity Gateway se ejecuta como un Pod en tu clúster. Como se muestra en el siguiente diagrama, esta solución proporciona túneles IPsec para el tráfico de los Pods en tu clúster a las VM en una VPC. Cuando el Pod de la puerta de enlace recibe prefijos para las subredes de VPC a través de una sesión del Protocolo de puerta de enlace fronteriza (BGP), configura el reenvío mediante Dataplane V2. Cuando otros Pods envían tráfico a una dirección con uno de esos prefijos, el tráfico se dirige al Pod de la puerta de enlace. Luego, el Pod de la puerta de enlace enruta el tráfico a través de un túnel IPsec hacia Google Cloud.

Diagrama de Network Connectivity Gateway para clústeres de Anthos en equipos físicos

Network Connectivity Gateway no admite las siguientes características y capacidades:

IPv6 para VPN con alta disponibilidad (y BGP)
MD5 para BGP
Detección de reenvío bidireccional (BFD) para BGP

Crea recursos de Google Cloud

Antes de habilitar Network Connectivity Gateway en un clúster, debes tener los siguientes recursos de Google Cloud:

Un Cloud Router
Una puerta de enlace de VPN con alta disponibilidad
Una puerta de enlace de VPN de intercambio de tráfico: una interfaz
Dos túneles VPN
Dos sesiones de BGP: una para cada uno de tus túneles VPN

Para obtener información sobre cómo crear y configurar estos recursos, consulta Crea una puerta de enlace de VPN con alta disponibilidad a una puerta de enlace VPN de intercambio de tráfico.

A medida que crees estos recursos, recopila la siguiente información y tenla disponible para más adelante:

Las dos direcciones IP externas que Google Cloud asignó a tu puerta de enlace de VPN con alta disponibilidad.
La dirección IP pública del tráfico IPsec/VPN que sale de tu organización. Esta dirección puede ser el resultado de una traducción de direcciones de red (NAT).
Tu clave precompartida.
El número de sistema autónomo (ASN) que asignaste a tu Cloud Router para las sesiones de BGP.
El ASN que elegiste usar en tu clúster local para las sesiones de BGP.
Para cada sesión de BGP, la dirección de vínculo local, como 169.254.1.1, que usará tu Cloud Router y la dirección de vínculo local que se usará en tu clúster local.

Para obtener información sobre cómo encontrar los detalles de la configuración de tu sesión de BGP, consulta Ve la configuración de la sesión de BGP.

Requisitos del clúster

La descarga de la herramienta de línea de comandos de Network Connectivity Gateway, ncgctl-v1.12.0-linux-amd64.tar.gz, solo es compatible con la versión 1.12 de los clústeres de Anthos alojados en Bare Metal. Si creas un clúster nuevo de versión 1.12.0, debes habilitar Network Connectivity Gateway con una anotación en el archivo de configuración del clúster.

Para habilitar Network Connectivity Gateway durante la creación del clúster, haz lo siguiente:

En el archivo de configuración del clúster, agrega la anotación 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 para crear el clúster:
```
bmctl create cluster -c CLUSTER_NAME
```
Reemplaza CLUSTER_NAME por el nombre que especificaste cuando creaste el archivo de configuración del clúster. Para obtener más información sobre la creación de clústeres, consulta Descripción general de la creación de clústeres.

Descargar

Para descargar ncgctl, la herramienta de línea de comandos de Network Connectivity Gateway, sigue estos pasos:

Descarga los componentes de Network Connectivity Gateway y las definiciones de recursos personalizados:
```
gsutil cp gs://ncg-release/anthos-baremetal/ncgctl-v1.12.0-linux-amd64.tar.gz .
```

Extrae el archivo:

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

Instalar

Para instalar ncgctl, sigue estos pasos:

Ejecuta comprobaciones previas para asegurarte de que el clúster cumpla con los requisitos previos. Por ejemplo, asegúrate de que Dataplane V2 esté habilitado.
```
./bin/ncgctl --verify --kubeconfig CLUSTER_KUBECONFIG
```
Reemplaza CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de administrador.
Instala Network Connectivity Gateway.
```
./bin/ncgctl --install --kubeconfig CLUSTER_KUBECONFIG
```
Nota: Si creas un clúster nuevo de versión 1.12.0, puedes omitir los siguientes pasos. Cuando crees clústeres, te recomendamos que agregues la anotación baremetal.cluster.gke.io/enable-gng: "true" al archivo de configuración del clúster para habilitar Network Connectivity Gateway. Para obtener más información, consulta Requisitos del clúster.
Si tienes un clúster de versión 1.12.0, puedes usar el siguiente comando de ncgctl para habilitar Network Connectivity Gateway:
```
./bin/ncgctl --enable-ncg-on-existing-cluster
```
El comando ncgctl acepta -e como una versión abreviada de la marca de habilitación.
Para ver combinaciones de teclas adicionales y más ayuda sobre los comandos, usa el siguiente comando:
```
./bin/ncgctl --help
```

Crea un Secret para tu clave precompartida

Las puertas de enlace en cada extremo de los túneles IPsec usan un Secret que contiene tu clave precompartida para la autenticación.

Para crear el Secret, sigue estos pasos:

Crea un archivo llamado psk-secret.yaml con los siguientes detalles del manifiesto de Secret:
```
apiVersion: v1
kind: Secret
metadata:
  name: "ike-key"
  namespace: "kube-system"
data:
  psk: PRE_SHARED_KEY
```
Reemplaza PRE_SHARED_KEY por una clave precompartida codificada en base64. Si tienes una clave en texto simple, codifica la clave en formato base64 antes de crear este Secret. Por ejemplo, si la consola de Google Cloud generó una clave para ti, está en texto simple y debes codificarla. Para codificar una clave en Base64, haz lo siguiente:
```
echo -n PLAINTEXT_KEY | base64
```

Crea el Secreto

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

Crea dos recursos `OverlayVPNTunnel` personalizados

Para iniciar dos sesiones de IPsec, crea dos recursos OverlayVPNTunnel personalizados.

Crea un archivo llamado overlay-vpn-tunnels.yaml con los siguientes detalles del manifiesto 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
```
Reemplaza lo siguiente:
- TUNNEL_NAME_1: El nombre que elijas para el primer OverlayVPNTunnel.
- TUNNEL_NAME_2: El nombre que elijas para el segundo OverlayVPNTunnel.
- PEER_PUBLIC_IP_1: Es la dirección IP pública de una interfaz en la puerta de enlace de VPN con alta disponibilidad. Especificaste esta interfaz cuando creaste tu primer túnel VPN.
- PEER_PUBLIC_IP_2: Es la dirección IP pública de la otra interfaz en la puerta de enlace de VPN con alta disponibilidad. Especificaste esta interfaz cuando creaste tu segundo túnel VPN.
- SELF_LOCAL_TUNNEL_IP_1: Es la dirección de vínculo local que se usará en tu clúster para las sesiones de BGP en el primer túnel.
- SELF_LOCAL_TUNNEL_IP_2: Es la dirección de vínculo local que se usará en tu clúster para las sesiones de BGP en el segundo túnel.
- SELF_PUBLIC_IP: Es la dirección IP pública para el tráfico de IPsec/VPN que sale de la organización. Esta dirección puede ser el resultado de una traducción de direcciones de red (NAT).

Crea los dos OverlayVPNTunnels:

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

Comprueba el estado de los túneles:

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

Crea dos recursos `OverlayBGPPeer` personalizados

Para iniciar una sesión de BGP en cada uno de los túneles, crea dos recursos OverlayBGPPeer personalizados.

Crea un archivo llamado overlay-bgp-peers.yaml con los siguientes detalles del manifiesto 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
```
Reemplaza lo siguiente:
- BGP_PEER_1_NAME: El nombre que elijas para el primer OverlayBGPPeer.
- BGP_PEER_2_NAME: El nombre que elijas para el segundo OverlayBGPPeer.
- LOCAL_ASN: El ASN que se usará en tu clúster para las sesiones de BGP.
- LOCAL_IP: Es la dirección IP pública para el tráfico de IPsec/VPN que sale de la organización. Esta dirección puede ser el resultado de una traducción de direcciones de red (NAT).
- PEER_IP_1: Es la dirección IP pública de una interfaz en la puerta de enlace de VPN con alta disponibilidad. Especificaste esta interfaz cuando creaste tu primer túnel VPN.
- PEER_IP_2: Es la dirección IP pública de la otra interfaz en la puerta de enlace de VPN con alta disponibilidad. Especificaste esta interfaz cuando creaste tu segundo túnel VPN.
- PEER_ASN: Es el ASN asignado a tu Cloud Router para las sesiones de BGP.
- TUNNEL_1_NAME: Es el nombre del primer OverlayVPNTunnel que creaste antes.
- TUNNEL_2_NAME: Es el nombre del segundo OverlayVPNTunnel que creaste antes.

Crea los recursos personalizados de OverlayBGPPeer:

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

Verifica el estado de las sesiones de BGP:

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

Verifica el estado de Network Connectivity Gateway

La instalación creó un recurso personalizado NetworkConnectivityGateway.

Visualiza el recurso NetworkConnectivityGateway personalizado:

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

El resultado es similar al siguiente. Verifica que veas 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

Verifica los registros de Network Connectivity Gateway

El Pod de la puerta de enlace pertenece a un DaemonSet llamado ncgd, por lo que el nombre del Pod comienza con ncgd.

Para ver los registros de Network Connectivity Gateway, sigue estos pasos:

Busca el nombre del Pod de la puerta de enlace:

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

Ve los registros del Pod de la puerta de enlace:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG logs GATEWAY_POD --namespace kube-system \
    --output yaml
```
Reemplaza GATEWAY_POD por el nombre del Pod de la puerta de enlace.

Desinstalar

Para desinstalar Network Connectivity Gateway, haz lo siguiente:

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

Soluciona problemas

Para obtener sugerencias sobre cómo solucionar problemas relacionados con Network Connectivity Gateway, consulta Solución de problemas de Network Connectivity Gateway.