Configura una puerta de enlace NAT de salida

Con Google Distributed Cloud, puedes configurar la traducción de direcciones de red de origen (SNAT) para que cierto tráfico de salida de tu clúster de usuario tenga una dirección IP de origen predecible.

En este documento, se muestra cómo configurar una puerta de enlace NAT de salida para un clúster de usuario.

Precaución: No puedes actualizar ningún clúster de versión 1.8.x o 1.9.x que tenga Anthos Network Gateway habilitada a ninguna versión posterior. Por ejemplo, no puedes actualizar un clúster de la versión 1.9.0 que tenga habilitado Anthos Network Gateway a la versión 1.9.x, ni puedes actualizarlo a la versión 1.10. Solo puedes actualizar los clústeres que tengan habilitado Anthos Network Gateway si se crearon en la versión 1.10 o posterior. Puedes borrar un clúster de versión 1.8.x o 1.9.x y, luego, volver a crearlo según las instrucciones de este documento.

Introducción

A veces, tienes Pods en ejecución en un clúster de usuario que necesitan enviar paquetes a los componentes que se ejecutan en tu organización, pero fuera del clúster. Te recomendamos diseñar esos componentes externos para que filtren el tráfico de red entrante en función de un conjunto de direcciones IP de origen conocidas.

A continuación, se describen algunas situaciones:

• Tienes un firewall frente a una base de datos que solo permite el acceso por dirección IP. El equipo que administra el firewall de la base de datos es diferente del que administra el clúster de usuario.

• Las cargas de trabajo en tu clúster de usuarios deben acceder a una API de terceros a través de Internet. Por motivos de seguridad, el proveedor de la API autentica y autoriza el tráfico mediante la dirección IP como la identidad.

Con una puerta de enlace NAT de salida, puedes tener un control detallado sobre las direcciones IP de origen que se usan para el tráfico de red que sale de un clúster.

Precios

No se aplican cargos por usar esta función durante la vista previa.

Cómo funciona una puerta de enlace NAT de salida

Por lo general, cuando un pod envía un paquete fuera del clúster, el paquete se traduce con SNAT, con la dirección IP del nodo en el que se ejecuta el pod.

Cuando se establece una puerta de enlace NAT de salida, puedes especificar que ciertos paquetes salientes se envíen primero a un nodo dedicado de puerta de enlace. La interfaz de red en el nodo de la puerta de enlace se configura con dos direcciones IP: la principal y la de origen de salida.

Cuando se selecciona un paquete que usa la puerta de enlace NAT de salida, el paquete abandona el clúster del nodo de puerta de enlace y se traduce con SNAT con la dirección IP de origen de salida configurada en la interfaz de red.

En el siguiente diagrama, se ilustra el flujo de paquetes:

En el diagrama anterior, puedes ver el flujo de un paquete que se envía desde el pod.

1. En un nodo con dirección IP 192.168.1.1, un Pod con dirección IP 10.10.10.1 genera un paquete saliente.

2. El paquete coincide con una regla de salida, por lo que se reenvía al nodo de puerta de enlace.

3. El nodo de la puerta de enlace cambia la dirección IP de origen a 192.168.1.100 y envía el paquete fuera del clúster.

4. El tráfico de retorno regresa al nodo de la puerta de enlace con el destino 192.168.1.100.

5. El nodo de puerta de enlace usa conntrack para modificar la dirección IP de destino a 10.10.10.1.

6. El paquete se trata como tráfico en el clúster, se reenvía al nodo original y se devuelve al Pod original.

Personas

En este tema, se hace referencia a dos perfiles:

• Administrador del clúster Esta persona crea un clúster de usuario y especifica las direcciones IP flotantes que usará la puerta de enlace de red de Anthos.

• Desarrollador: Este perfil ejecuta cargas de trabajo en el clúster de usuario y crea políticas de salida.

Habilita la puerta de enlace NAT de salida

Esta sección está destinada a los administradores de clústeres.

Para configurar una puerta de enlace NAT de salida, usa los campos enableDataplaneV2 y advancedNetworking en el archivo de configuración del clúster de usuario y crea uno o más objetos NetworkGatewayGroup.

En el archivo de configuración del clúster, establece estos campos como true:

enableDataplaneV2: true
...
advancedNetworking: true

Crea el clúster de usuario

Especifica direcciones IP flotantes

Esta sección está destinada a los administradores de clústeres.

Elige un conjunto de direcciones IP que deseas usar como direcciones de origen de salida. Estas se denominan direcciones IP flotantes, porque la puerta de enlace de red de Anthos las asigna, según sea necesario, a las interfaces de red de los nodos que elige como puertas de enlace de salida.

Las direcciones IP flotantes deben estar en la misma subred que las direcciones IP del nodo.

Tu conjunto de direcciones IP flotantes no debe superponerse con el conjunto de direcciones IP que especificaste para tus nodos.

Por ejemplo, supongamos que una subred tiene el rango de direcciones 192.168.1.0/24. Y supongamos que elegiste usar desde la 192.168.1.1 hasta la 192.168.1.99 para los nodos. Luego, puedes usar desde la 192.168.1.100 hasta la 192.168.1.104 como direcciones IP flotantes.

Crea un objeto NetworkGatewayGroup

Esta sección está destinada a los administradores de clústeres.

Este es un ejemplo de un manifiesto para un objeto NetworkGatewayGroup:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: kube-system
  name: default
spec
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  - 192.168.1.103
  - 192.168.1.104

Reemplaza el array floatingIPs por tus direcciones IP flotantes y guarda el manifiesto en un archivo llamado my-ngg.yaml.

Crea el objeto NetworkGatewayGroup:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ngg.yaml

Ejemplo de una política NAT de salida

Esta sección está destinada a los desarrolladores.

A continuación, se muestra un ejemplo de un recurso personalizado EgressNatPolicy:

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: alice-paul
spec:
  sources:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  action: SNAT
  destinations:
  - cidr: 8.8.8.0/24
  gatewayRef:
    name: default
    namespace: kube-system

En el manifiesto anterior, se observa lo siguiente:

• Un pod es candidato para NAT de salida si cumple con una de las siguientes condiciones:

  • El pod tiene la etiqueta role: frontend y el pod está en un espacio de nombres que tiene la etiqueta user: alice.

  • El pod tiene la etiqueta role: frontend y el pod está en un espacio de nombres que tiene la etiqueta user: paul.

• El tráfico de un Pod candidato a una dirección en el rango 8.8.8.0/24 se envía a la puerta de enlace NAT de salida.

• En la sección gatewayRef, se determina la dirección IP de origen de salida. El recurso personalizado EgressNATPolicy usa los valores gatewayRef.name y gatewayRef.namespace para encontrar un objeto NetworkGatewayGroup. La política usa una de las direcciones IP flotantes de NetworkGatewayGroup como la dirección IP de origen para el tráfico de salida. Si hay varias direcciones IP flotantes en el NetworkGatewayGroup coincidente, la política usa la primera dirección IP de la lista floatingIPs e ignora cualquier otra dirección IP. Si hay campos no válidos en la sección gatewayRef, se producirá un error cuando se aplique el objeto EgressNATPolicy.

Crea un objeto EgressNATPolicy

Crea tu propio manifiesto de OutputNATPolicy. Establece metadata.name en "my-policy". Guarda tu manifiesto en un archivo llamado my-policy.yaml.

Crea el objeto EgressNatPolicy:

kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f my-policy.yaml

Visualiza la información sobre tu política NAT de salida

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get egressnatpolicy my-policy --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --namespace kube-system --output yaml

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe egressnatpolicy my-policy

Orden de las operaciones

La política de NAT de salida es compatible con las API de política de red. La política de red se evalúa antes de la política de NAT de salida. Si una política de red indica que se descarta un paquete, este se descarta sin importar la política de NAT de salida.

Varias políticas de salida

Como se describió antes, cada EgressNATPolicy usa la primera dirección IP en la lista floatingIPs de NetworkGatewayGroup que coincide con gatewayRef.name y gatewayRef.namespace. Si creas varias políticas y deseas usar diferentes direcciones IP, debes crear varios objetos NetworkGatewayGroup y hacer referencia a ellos, respectivamente. Si creas varias políticas, el objeto gatewayRef debe ser único para cada política.

Cada recurso NetworkGatewayGroup debe contener direcciones IP flotantes únicas. Si quieres configurar varios objetos EgressNATPolicy para que usen la misma dirección IP, usa los mismos gatewayRef.name y gatewayRef.namespace en ambos.

Nota: La puerta de enlace de red de Anthos no te permite crear objetos de puerta de enlace nuevos que contengan direcciones IP en spec.floatingIPs que ya se usen en objetos de puerta de enlace existentes. Un webhook en Google Distributed Cloud versión 1.15.0 y versiones posteriores aplica esta regla.

Para configurar varias políticas de salida y varios objetos de puerta de enlace, sigue estos pasos:

1. Crea objetos de puerta de enlace en el espacio de nombres kube-system para administrar cada dirección IP flotante. Por lo general, cada política de salida debe tener un objeto de puerta de enlace correspondiente para garantizar que se asigne la dirección IP correcta.

   Luego, verifica cada objeto de puerta de enlace con kubectl para obtener el estado de asignación de las direcciones IP flotantes:

   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway1
   spec:
     floatingIPs:
     - 192.168.1.100
   status:
     ...
     floatingIPs:
       192.168.1.100: worker1
   ---
   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway2
   spec:
     floatingIPs:
     - 192.168.1.101
   status:
     ...
     floatingIPs:
       192.168.1.101: worker2
   ---
   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway3
   spec:
     floatingIPs:
     - 192.168.1.102
   status:
     ...
     floatingIPs:
       192.168.1.102: worker1
   

2. Crea varias políticas que hagan referencia a los objetos de puerta de enlace, como gateway1 creado en el paso anterior:

   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy1
   spec:
     ...
     gatewayRef:
       name: gateway1
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy2
   spec:
     ...
     gatewayRef:
       name: gateway2
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egresspolicy3
   spec:
     ...
     gatewayRef:
       name: gateway3
       namespace: kube-system
   

Especifica nodos en los que se ubicarán direcciones IP flotantes (opcional)

Los recursos NetworkGatewayGroup admiten selectores de nodos. Si deseas especificar un subconjunto de nodos que se consideran para alojar una dirección IP flotante, puedes agregar el selector de nodos al objeto NetworkGatewayGroup, como se muestra en el siguiente ejemplo:

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  nodeSelector:
    node-type: "egressNat"

El selector de nodos coincide con los nodos que tienen la etiqueta especificada, y solo estos nodos se consideran para alojar una dirección IP flotante. Si especificas varios selectores, su lógica es aditiva, por lo que un nodo debe coincidir con cada etiqueta para que se considere para alojar una dirección IP flotante. Si no hay muchos nodos con etiquetas que coincidan, un selector de nodos puede reducir las cualidades de alta disponibilidad (HA) de la ubicación de las direcciones IP flotantes.