Configurar una pasarela de NAT de salida

Con Google Distributed Cloud, puedes configurar la traducción de direcciones de red de origen (SNAT) para que determinado 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 pasarela de NAT de salida para un clúster de usuario.

Precaución: No puedes actualizar a una versión posterior ningún clúster de la versión 1.8.x o 1.9.x que tenga habilitado Anthos Network Gateway. 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 a la versión 1.10. Solo puedes actualizar los clústeres que tengan habilitada la puerta de enlace de red de Anthos si se crearon en la versión 1.10 o posterior. Puedes eliminar un clúster de la versión 1.8.x o 1.9.x y, a continuación, volver a crearlo siguiendo las instrucciones de este documento.

Introducción

A veces, tienes pods que se ejecutan en un clúster de usuarios que necesitan enviar paquetes a componentes que se ejecutan en tu organización, pero fuera del clúster. Puede que le interese diseñar esos componentes externos de forma que filtren el tráfico de red entrante según un conjunto de direcciones IP de origen conocidas.

A continuación, te indicamos algunas situaciones:

• Tienes un cortafuegos delante de una base de datos que solo permite el acceso por dirección IP. Además, el equipo que gestiona el cortafuegos de la base de datos es diferente del que gestiona el clúster de usuarios.

• Las cargas de trabajo de tu clúster de usuarios tienen que 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 identidad.

Con una pasarela de salida NAT, puedes controlar de forma granular las direcciones IP de origen que se utilizan para el tráfico de red que sale de un clúster.

Precios

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

Cómo funciona una pasarela de NAT de salida

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

Cuando hay una pasarela de NAT de salida, puedes especificar que determinados paquetes salientes se envíen primero a un nodo de pasarela dedicado. La interfaz de red del nodo de pasarela se configura con dos direcciones IP: la dirección IP principal y una dirección IP de origen de salida.

Cuando se selecciona un paquete para usar la pasarela de NAT de salida, el paquete sale del clúster desde el nodo de la pasarela y se traduce con SNAT con la dirección IP de origen de salida que se ha configurado en la interfaz de red.

En el siguiente diagrama se muestra 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 la dirección IP 192.168.1.1, un pod con la 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 la pasarela.

3. El nodo de pasarela 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 vuelve al nodo de la pasarela con el destino 192.168.1.100.

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

6. El paquete se trata como tráfico dentro del clúster y se reenvía al nodo original, y se devuelve al pod original.

Perfiles ficticios

En este tema se hace referencia a dos perfiles:

• Administrador de clústeres. Esta persona crea un clúster de usuario y especifica las direcciones IP flotantes que usará Anthos Network Gateway.

• Desarrollador. Esta persona ejecuta cargas de trabajo en el clúster de usuario y crea políticas de salida.

Habilitar la pasarela de NAT de salida

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

Para configurar una pasarela NAT de salida, usa los campos enableDataplaneV2 y advancedNetworking del archivo de configuración del clúster de usuario y crea uno o varios objetos NetworkGatewayGroup.

En el archivo de configuración del clúster, asigna el valor true a estos campos:

enableDataplaneV2: true
...
advancedNetworking: true

Crea el clúster de usuarios.

Especificar direcciones IP flotantes

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

Elige un conjunto de direcciones IP que quieras usar como direcciones de origen de salida. Se denominan direcciones IP flotantes porque Network Gateway Group las asigna, según sea necesario, a las interfaces de red de los nodos que elige como pasarelas de salida.

Las direcciones IP flotantes deben estar en la misma subred que las direcciones IP de los nodos.

El conjunto de direcciones IP flotantes no debe solaparse con el conjunto de direcciones IP que hayas especificado para tus nodos.

Por ejemplo, supongamos que una subred tiene el intervalo de direcciones 192.168.1.0/24. Supongamos que has elegido usar las direcciones de 192.168.1.1 a 192.168.1.99 para los nodos. Después, podrías usar las direcciones IP de 192.168.1.100 a 192.168.1.104 como direcciones IP flotantes.

Crear un objeto NetworkGatewayGroup

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

A continuación, se muestra un ejemplo de manifiesto de 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

Sustituye la matriz 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 de NAT de salida

Esta sección está dirigida a desarrolladores.

A continuación, se muestra un ejemplo de 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, vemos lo siguiente:

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

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

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

• El tráfico de un pod candidato a una dirección del intervalo 8.8.8.0/24 se envía a la pasarela NAT de salida.

• La sección gatewayRef 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 dirección IP de origen del 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 las demás. Si hay campos no válidos en la sección gatewayRef, no se podrá aplicar el objeto EgressNATPolicy.

Crea un objeto EgressNATPolicy

Crea tu propio manifiesto de EgressNATPolicy. Asigna el valor "my-policy" a metadata.name. Guarda el manifiesto en un archivo llamado my-policy.yaml.

Crea el objeto EgressNatPolicy:

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

Ver información sobre tu política de 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 APIs de políticas de red. La política de red se evalúa antes que la política de NAT de salida. Si una política de red indica que se debe descartar un paquete, se descartará independientemente de la política de NAT de salida.

Varias políticas de salida

Como se ha descrito anteriormente, cada EgressNATPolicy usa la primera dirección IP de la lista floatingIPs del NetworkGatewayGroup que coincida con gatewayRef.name y gatewayRef.namespace. Si crea varias políticas y tiene previsto usar diferentes direcciones IP, debe crear varios objetos NetworkGatewayGroup y hacer referencia a ellos respectivamente. Si crea varias políticas, el objeto gatewayRef debe ser único para cada política.

Cada recurso NetworkGatewayGroup debe contener direcciones IP flotantes únicas. Para configurar varios objetos EgressNATPolicy de forma que usen la misma dirección IP, utiliza el mismo gatewayRef.name y gatewayRef.namespace para ambos.

Nota: Anthos Network Gateway no permite crear objetos de pasarela que contengan direcciones IP en spec.floatingIPs que ya se utilicen en objetos de pasarela. Esta regla se aplica mediante un webhook en Google Distributed Cloud versión 1.15.0 y posteriores.

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

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

   A continuación, verifica cada objeto de pasarela 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 la pasarela, como gateway1, que se ha 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
   

(Opcional) Especificar los nodos en los que se colocarán las direcciones IP flotantes

NetworkGatewayGroup recursos admiten selectores de nodos. Para especificar un subconjunto de nodos que se tienen en cuenta para alojar una dirección IP flotante, puedes añadir el selector de nodos al objeto NetworkGatewayGroup, tal 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 se tienen en cuenta estos nodos 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 tenga en cuenta a la hora de alojar una dirección IP flotante. Si no hay muchos nodos con etiquetas coincidentes, un selector de nodos puede reducir las cualidades de alta disponibilidad (HA) de la colocación de direcciones IP flotantes.