Configurar una pasarela de NAT de salidas

En este documento se describe cómo configurar una pasarela de NAT de salida para Google Distributed Cloud. Esta pasarela proporciona direcciones IP de SNAT persistentes y deterministas para el tráfico de salida de tus clústeres. Cuando ejecutas cargas de trabajo que tienen tráfico de usuarios de salida (fuera de tus clústeres), tus clientes quieren identificar este tráfico mediante algunas direcciones IP deterministas. Esto permite a tus clientes establecer medidas de seguridad basadas en IP, como políticas de listas de permitidos.

Esta página está dirigida a especialistas en redes que diseñan y desarrollan la red de su organización, así como instalan, configuran y ofrecen asistencia para los equipos de red. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas de usuario habituales de GKE.

La pasarela de NAT de salida se habilita mediante dos recursos personalizados. En un espacio de nombres determinado, el recurso personalizado NetworkGatewayGroup especifica las direcciones IP flotantes que se pueden configurar en la interfaz de red de un nodo que se elija para actuar como pasarela. El recurso personalizado EgressNatPolicy te permite especificar políticas de enrutamiento de salida para controlar el tráfico en la puerta de enlace de salida.

Si no configuras una pasarela NAT de salida o si el tráfico de salida no cumple las reglas de selección de tráfico, el tráfico de salida de un pod determinado a un destino fuera del clúster se enmascarará con la dirección IP del nodo en el que se esté ejecutando el pod. En este caso, no hay ninguna garantía de que todo el tráfico de salida de un pod concreto tenga la misma dirección IP de origen o se enmascare con la misma dirección IP de nodo.

La pasarela de NAT de salida es una oferta de redes avanzada basada en Dataplane V2.

Cómo funciona la pasarela de NAT de salida

La lógica de selección del tráfico de salida se basa en un selector de espacio de nombres, un selector de pods y un conjunto de intervalos de direcciones IP de destino en notación de bloque CIDR. Para ilustrar cómo funciona la pasarela de NAT de salida, vamos a analizar el flujo de un paquete de un pod a un consumidor externo y la respuesta correspondiente. Supongamos que la subred de nodos tiene direcciones IP en el bloque CIDR 192.168.1.0/24.

En el siguiente diagrama se muestra la arquitectura de red del tráfico de salida a través de un nodo de pasarela.

Diagrama de la pasarela de NAT de salida de Google Distributed Cloud

El flujo de paquetes a través de la pasarela de NAT de salida podría ser el siguiente:

  1. El tráfico de salida se genera desde un pod con la dirección IP 10.10.10.1 en un nodo con la dirección IP 192.168.1.1.

    La dirección de destino del tráfico es un endpoint fuera del clúster.

  2. Si el tráfico coincide con una regla de salida, el programa eBPF lo dirige al nodo de la pasarela en lugar de enmascararlo directamente con la dirección IP del nodo.

  3. El nodo de la pasarela recibe el tráfico de salida.

  4. El nodo de la pasarela enmascara la dirección IP de origen del tráfico de origen, 10.10.10.1, con la dirección IP de salida de origen, 192.168.1.100, especificada en el recurso personalizado EgressNATPolicy.

  5. El tráfico de retorno vuelve al nodo de la pasarela con el destino 192.168.1.100.

  6. El nodo de la pasarela hace coincidir el conntrack del tráfico de retorno con el del tráfico de salida original y reescribe la dirección IP de destino como 10.10.10.1.

  7. 10.10.10.1 se trata como tráfico dentro del clúster, se dirige al nodo original y se devuelve al pod original.

Configurar direcciones IP flotantes para el tráfico de nodos

El recurso personalizado NetworkGatewayGroup es un componente incluido de Google Distributed Cloud. El recurso gestiona una lista de una o más direcciones IP flotantes que se usan para el tráfico de salida de los nodos de tu clúster. Los nodos participantes se determinan mediante el espacio de nombres especificado. El grupo de pasarelas de red hace que una dirección IP flotante esté disponible en todo momento con el mejor esfuerzo posible. Si un nodo que usa una dirección IP flotante deja de funcionar, el operador de red avanzado mueve la dirección IP asignada al siguiente nodo disponible. Todo el tráfico de salida de la carga de trabajo que utilice esa dirección IP también se moverá.

Incluya los detalles del grupo de pasarela de red (anotación y especificación) en el archivo de configuración del clúster al crear un clúster 1.34.0-gke.566.

Crea el recurso personalizado NetworkGatewayGroup.

Para habilitar Network Gateway Group, defina el campo spec.clusterNetwork.advancedNetworking en true en el archivo de configuración del clúster al crear un clúster, tal como se muestra en el siguiente ejemplo:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

Cuando cree el recurso personalizado NetworkGatewayGroup, defina su espacio de nombres como el espacio de nombres del clúster y especifique una lista de direcciones IP flotantes, 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

El operador de redes avanzadas asigna las IPs flotantes a los nodos en función de los siguientes criterios:

  • Subred de nodos: la dirección IP flotante debe coincidir con la subred del nodo.
  • Rol del nodo (plano de control o trabajador): los nodos de trabajador tienen prioridad sobre los nodos del plano de control a la hora de asignar direcciones IP flotantes.
  • Si un nodo tiene una dirección IP flotante, el operador prioriza las asignaciones a los nodos que aún no tienen una dirección IP flotante asignada.

La asignación de direcciones a nodos se encuentra en la sección status cuando obtienes el objeto NetworkGatewayGroup. Ten en cuenta que el objeto NetworkGatewayGroup está en el espacio de nombres kube-system. Si un nodo de pasarela no funciona, el operador de red avanzado asigna las direcciones IP flotantes al siguiente nodo disponible.

Verificar la configuración de la pasarela

Una vez que hayas aplicado los cambios en la configuración de la pasarela, puedes usar kubectl para comprobar el estado de la pasarela y recuperar las direcciones IP flotantes especificadas para la pasarela.

  1. Usa el siguiente comando para comprobar el estado de NetworkGatewayGroup y ver cómo se asignan las direcciones IP flotantes:

    kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

    La respuesta de un clúster con dos nodos, worker1 y worker2, podría tener este aspecto:

    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
status:
  nodes:
    worker1: Up
    worker2: Up // Or Down
  floatingIPs:
    192.168.1.100: worker1
    192.168.1.101: worker2
    192.168.1.102: worker1

Definir reglas de selección de tráfico

El recurso personalizado EgressNATPolicy especifica reglas de selección de tráfico y asigna una dirección IP determinista al tráfico de salida que abandona el clúster. Cuando especifique el recurso personalizado, deberá incluir egress (con al menos una regla), destinationCIDRs y egressSourceIP.

Usa kubectl apply para crear el EgressNATPolicy recurso personalizado. En las siguientes secciones se proporcionan detalles y ejemplos para definir la especificación.

Especificar reglas de enrutamiento de salida

El recurso personalizado EgressNatPolicy te permite especificar las siguientes reglas para el tráfico de salida:

  • Debe especificar una o varias reglas de selección de tráfico de salida en la sección egress.

    • Cada regla consta de un podSelector y un namespaceSelector.
    • La selección se basa en una etiqueta de espacio de nombres, namespaceSelector.matchLabels.user, y una etiqueta de pod, podSelector.matchLabels.role.
    • Si un pod coincide con alguna de las reglas (la coincidencia usa una relación OR), se selecciona para el tráfico de salida.

  • Especifique las direcciones de destino permitidas en la sección destinationCIDRs.

    • destinationCIDRs toma una lista de bloques CIDR.
    • Si el tráfico saliente de un pod tiene una dirección IP de destino que se encuentra dentro del intervalo de cualquiera de los bloques CIDR especificados, se selecciona para el tráfico de salida.

En el siguiente ejemplo, se permite el tráfico de salida de un pod cuando se cumplen los siguientes criterios:

  • El pod está etiquetado con role: frontend.
  • El pod está en un espacio de nombres etiquetado como user: alice o user: paul.
  • El pod se comunica con direcciones IP del bloque CIDR 8.8.8.0/24.
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
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

Para obtener más información sobre el uso de etiquetas, consulta el artículo Etiquetas y selectores de la documentación de Kubernetes.

Obtener una dirección IP de origen para el tráfico de salida

El recurso personalizado EgressNATPolicy (política) usa los valores gatewayRef.name y gatewayRef.namespace para encontrar un objeto NetworkGatewayGroup (gateway). La política usa una de las direcciones IP flotantes de la pasarela como dirección IP de origen del tráfico de salida. Si hay varias direcciones IP flotantes en la pasarela coincidente, la política utiliza la primera dirección IP de la lista floatingIPs e ignora las demás. En el caso de la pasarela de ejemplo, la primera dirección de la lista floatingIPs es 192.168.1.100. Si hay campos o valores no válidos en la sección gatewayRef, no se podrá aplicar el objeto de la política.

Varias políticas de salida y varios objetos de pasarela

Como se ha descrito en la sección anterior, cada objeto egressNATPolicy (política) usa la primera dirección IP de la lista floatingIPs del objeto de pasarela que coincida con gatewayRef.name y gatewayRef.namespace. Puede crear varias políticas y, si tiene intención de usar diferentes direcciones IP, debe crear varios objetos NetworkGatewayGroup y hacer referencia a ellos respectivamente.

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.

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: egress1
spec:
  ...
  gatewayRef:
    name: gateway1
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress2
spec:
  ...
  gatewayRef:
    name: gateway2
    namespace: kube-system
---
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress3
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.

Conmutación por error rápida para una pasarela de NAT de salida de alta disponibilidad

En los clústeres de la versión 1.34 y posteriores, puedes configurar la pasarela de NAT de salida con una conmutación por error rápida. Si tienes varias direcciones IP flotantes y configuras la conmutación por error rápida, se proporciona una salida de alta disponibilidad. Esta función proporciona una mejor distribución de la carga del tráfico de salida y una conmutación por error más rápida para minimizar el tiempo de inactividad. En lugar de depender de un solo nodo de pasarela a la vez (activo-inactivo), el clúster distribuye el tráfico saliente entre varios nodos de pasarela y todas las direcciones IP flotantes configuradas en un recurso NetworkGatewayGroup.

Este modelo activo-activo tiene las siguientes ventajas principales:

  • Distribución de la carga: el tráfico saliente de diferentes endpoints de origen, como los pods, se distribuye entre todos los nodos de pasarela disponibles, lo que reduce la carga de cualquier nodo y aumenta el ancho de banda de salida total disponible.

  • Conmutación por error rápida: si falla un nodo de la pasarela de salida, el tráfico se redirige automáticamente a los nodos en buen estado restantes. El objetivo es que el tráfico cambie rápidamente a la réplica de seguridad. Aunque se interrumpan las conexiones del nodo que ha fallado, se establecerán nuevas conexiones inmediatamente a través de otras pasarelas, lo que minimizará el tiempo de inactividad.

Diferencias principales

Configurar la pasarela de NAT de salida para que se produzca una conmutación por error rápida cambia el funcionamiento de la pasarela de NAT de salida:

Competencia Activo-en espera (predeterminado) Activo-activo (conmutación por error rápida)
Uso de IPs flotantes El EgressNATPolicy solo usa la primera dirección IP flotante del NetworkGatewayGroup. Todas las direcciones IP flotantes que se indican en el NetworkGatewayGroup distribuyen activamente el tráfico de salida.
Conmutación por error Si el nodo de la pasarela falla, la misma dirección IP flotante se mueve a otro nodo, lo que puede provocar una interrupción del tráfico. Si un nodo de la pasarela falla, el tráfico se redirige a otra dirección IP correcta de otro nodo. Las nuevas conexiones se enrutan inmediatamente a través de las pasarelas en buen estado, mientras que las conexiones con estado existentes en el nodo con errores se terminan.
Tráfico Todo el tráfico de una política determinada pasa por un único nodo de pasarela. El tráfico se distribuye entre varios nodos de puerta de enlace en función de un hash coherente del endpoint de origen, como un pod.

Configurar la conmutación por error rápida

Para configurar la función, debe seguir dos pasos principales:

  1. Especifica varias direcciones IP flotantes.

    Configure el NetworkGatewayGroup con un grupo de al menos dos direcciones IP flotantes para disfrutar de las ventajas de la alta disponibilidad y la distribución de carga. Usar más direcciones IP flotantes mejora la fiabilidad de salida y el rendimiento.

    Aquí tienes un ejemplo de configuración:

    apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: egress-gateways
  namespace: cluster-admin
spec:
  nodeSelector:
    # Selects nodes that are designated as egress gateways
    node-role.kubernetes.io/egress: ""
  floatingIPs:
  - "192.168.1.100"
  - "192.168.1.101"
  - "192.168.1.102"

  2. Para habilitar la conmutación por error rápida, añade la anotación networking.gke.io/egressnat-ha: "enable" al recurso personalizado EgressNATPolicy:

    kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
  annotations:
    networking.gke.io/egressnat-ha: "enable"
spec:
  ...

Reglas de selección de tráfico de salida y políticas de red

La pasarela de NAT de salida es compatible con las APIs de políticas de red. Las políticas de red se evalúan primero y tienen prioridad sobre las reglas de selección de tráfico de la pasarela de NAT de salida. Por ejemplo, si el tráfico de salida activa una política de red que provoca que se descarte el paquete, las reglas de la puerta de enlace de salida no comprobarán el paquete. Solo cuando la política de red permita que el paquete salga, se evaluarán las reglas de selección de tráfico de salida para decidir cómo se gestiona el tráfico, ya sea mediante la pasarela NAT de salida o mediante el enmascaramiento directo con la dirección IP del nodo en el que se ejecuta el pod.

Limitaciones

Estas son las limitaciones actuales de la pasarela de NAT de salida:

  • La pasarela NAT de salida solo está habilitada para el modo IPv4.

  • Las direcciones IP de salida deben estar en el mismo dominio de capa 2 que las direcciones IP de los nodos.