Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura una puerta de enlace NAT de salida

Una puerta de enlace de NAT de salida en Google Distributed Cloud te permite asignar direcciones IP de SNAT persistentes y determinísticas al tráfico saliente de tus clústeres. Con direcciones de origen predecibles, las redes externas pueden aplicar medidas de seguridad basadas en IP, como las políticas de listas de entidades permitidas. La puerta de enlace NAT de salida es una función de red avanzada compilada en Dataplane V2.

Cómo funciona la puerta de enlace NAT de salida

La puerta de enlace NAT de salida se habilita mediante dos recursos personalizados. Para 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 eligió como una puerta de enlace. 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 puerta de enlace de NAT de salida o si el tráfico de salida no cumple con 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 enmascara con la dirección IP del nodo en el que se ejecuta el Pod. En este caso, no hay garantía de que todo el tráfico de salida de un Pod en particular tenga la misma dirección IP de origen o se enmascare a la misma dirección IP del nodo.

La lógica de selección de tráfico de salida se basa en un selector de espacio de nombres, un selector de Pods y un conjunto de rangos de direcciones IP de destino en la notación de bloques CIDR. Para ilustrar cómo funciona la puerta de enlace NAT de salida, considera el flujo de un paquete de un Pod a un consumidor externo y la respuesta correspondiente. Supongamos que la subred de nodo tiene direcciones IP en el bloque CIDR 192.168.1.0/24.

En el siguiente diagrama, se muestra la arquitectura de red para el tráfico de salida a través de un nodo de puerta de enlace.

Diagrama de la puerta de enlace NAT de salida para Google Distributed Cloud

El flujo de paquetes a través de la puerta de enlace NAT de salida podría verse así:

El tráfico de salida se genera de 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 extremo fuera del clúster.
Si el tráfico coincide con una regla de salida, el programa de eBPF enruta el tráfico de salida al nodo de puerta de enlace, en lugar de enmascarar directamente con la dirección IP del nodo.
El nodo de puerta de enlace recibe el tráfico de salida.
El nodo de puerta de enlace 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.
El tráfico de retorno se dirige al nodo de la puerta de enlace con el destino 192.168.1.100.
El nodo de puerta de enlace coincide con 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.
10.10.10.1 se trata como tráfico en el clúster, enrutado al nodo original y entregado al Pod original.

Antes de comenzar

Si tus nodos ejecutan Ubuntu 18.04, el kernel de Linux debe ser la versión 5.4 o una posterior. Para obtener más información, consulta Configura Ubuntu.

Configura direcciones IP flotantes para el tráfico de nodos

El recurso personalizado Network Gateway Group es un componente empaquetado de Google Distributed Cloud. El recurso administra una lista de una o más direcciones IP flotantes para usar en el tráfico de salida de los nodos en el clúster. Los nodos participantes se determinan según el espacio de nombres especificado. Network Gateway Group hace que una dirección IP flotante esté disponible en todo momento según el criterio del mejor esfuerzo. Si un nodo que usa una dirección IP flotante falla, el operador avanzado de la red mueve la dirección IP asignada al siguiente nodo disponible. También se transferirá todo el tráfico de salida de carga de trabajo que use esa dirección IP.

Incluye los detalles de Network Gateway Group (anotaciones y especificaciones) en el archivo de configuración del clúster cuando crees un clúster 1.36.200-gke.118 nuevo.

Crea el recurso personalizado `NetworkGatewayGroup`

Para habilitar Network Gateway Group, establece el campo spec.clusterNetwork.advancedNetworking en true en el archivo de configuración del clúster cuando crees un clúster, 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 crees el recurso NetworkGatewayGroup personalizado, configura su espacio de nombres con el espacio de nombres del clúster y especifica una lista de direcciones IP flotantes, 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 red avanzado asigna las IP flotantes a los nodos en función de los siguientes criterios:

Subred del nodo: la dirección IP flotante debe coincidir con la subred del nodo.
Rol del nodo (plano de control, trabajador): Los nodos trabajadores tienen prioridad sobre los nodos del plano de control cuando se asignan 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 IP flotante asignada.

La asignación de dirección a nodo se puede encontrar 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 puerta de enlace está inactivo, el operador de red avanzado asigna las direcciones IP flotantes al siguiente nodo disponible.

Verifica la configuración de la puerta de enlace

Después de aplicar los cambios en la configuración de la puerta de enlace, puedes usar kubectl a fin de verificar el estado de la puerta de enlace y recuperar las direcciones IP flotantes especificadas para la puerta de enlace.

Usa el siguiente comando para verificar 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 el siguiente 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

Configura reglas de selección de tráfico

El recurso EgressNATPolicy personalizado especifica las reglas de selección de tráfico y asigna una dirección IP determinísticas para el tráfico de salida que sale del clúster. Cuando se especifica el recurso personalizado, se requieren egress (con al menos una regla), destinationCIDRs y egressSourceIP.

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

Especifica las reglas de enrutamiento de salida

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

Debes especificar una o más reglas de selección de tráfico de salida en la sección egress.
- Cada regla consta de una podSelector y una 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 cualquiera de las reglas (la coincidencia usa una relación OR), se selecciona para el tráfico de salida.
Especifica 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 rango 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 desde un Pod cuando se cumplen los siguientes criterios:

El Pod se etiqueta con role: frontend.
El Pod está en un espacio de nombres etiquetado como user: alice o user: paul.
El Pod se comunica con las direcciones IP en el 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 Etiquetas y selectores en la documentación de Kubernetes.

Obtén 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 (puerta de enlace). La política usa una de las direcciones IP flotantes de la puerta de enlace como la dirección IP de origen para el tráfico de salida. Si hay varias direcciones IP flotantes en la puerta de enlace coincidente, la política usa la primera dirección IP de la lista floatingIPs e ignora cualquier otra dirección IP. Para la puerta de enlace de ejemplo, la primera dirección en la lista floatingIPs es 192.168.1.100. Tener valores o campos no válidos en la sección gatewayRef hará que falle la aplicación del objeto de política.

Varias políticas de salida y varios objetos de puerta de enlace

Como se describió en la sección anterior, cada objeto egressNATPolicy (política) usa la primera dirección IP de la lista floatingIPs del objeto de puerta de enlace que coincida con gatewayRef.name y gatewayRef.namespace. Puedes crear varias políticas y, si planeas usar direcciones IP diferentes, debes 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 modo que usen la misma dirección IP, usa los mismos gatewayRef.name y gatewayRef.namespace para ambos.

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

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

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

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

Los recursos NetworkGatewayGroup admiten selectores de nodos. Para 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 la dirección IP flotante.

Conmutación por error rápida para una puerta de enlace NAT de salida con alta disponibilidad

Para los clústeres de la versión 1.34 y posteriores, puedes configurar la puerta de enlace NAT de salida con conmutación por error rápida. Cuando 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 para el 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 puerta de enlace a la vez (activo-en espera), el clúster distribuye el tráfico saliente entre varios nodos de puerta de enlace y todas las direcciones IP flotantes configuradas en un recurso NetworkGatewayGroup.

Este modelo activo-activo tiene los siguientes beneficios principales:

Distribución de carga: El tráfico saliente de diferentes extremos de origen, como los Pods, se distribuye en todos los nodos de puerta de enlace disponibles, lo que reduce la carga en cualquier nodo individual y aumenta el ancho de banda de salida total disponible.
Conmutación por error rápida: Si un nodo de puerta de enlace de salida falla, el tráfico se redirecciona automáticamente a los nodos restantes en buen estado. El objetivo es que la conmutación por error del tráfico se realice con rapidez. Mientras que las conexiones existentes en el nodo con errores se descartan, las conexiones nuevas se establecen de inmediato a través de otras puertas de enlace, lo que minimiza el tiempo de inactividad.

Diferencias clave

Configurar la puerta de enlace NAT de salida para la conmutación por error rápida cambia la forma en que funciona la puerta de enlace NAT de salida:

Función	Activa-En espera (predeterminado)	Activa-activa (conmutación por error rápida)
Uso de IP flotante	La `EgressNATPolicy` usa solo la primera dirección IP flotante en la `NetworkGatewayGroup`.	Todas las direcciones IP flotantes que se enumeran en el `NetworkGatewayGroup` distribuyen de forma activa el tráfico de salida.
Conmutación por error	Si el nodo de puerta de enlace falla, la misma dirección IP flotante se mueve a un nodo diferente, lo que puede causar una interrupción del tráfico.	Si un nodo de puerta de enlace falla, el tráfico se redirecciona a una dirección IP diferente y en buen estado en otro nodo. Las conexiones nuevas se enrutan de inmediato a través de las puertas de enlace en buen estado, mientras que las conexiones con estado existentes en el nodo con errores finalizan.
Tráfico	Todo el tráfico de una política determinada pasa por un solo nodo de puerta de enlace.	El tráfico se distribuye entre varios nodos de puerta de enlace según un hash coherente del extremo de origen, como un Pod.

Configura la conmutación por error rápida

La configuración de la función implica dos pasos principales:

Especifica varias direcciones IP flotantes.

Configura el NetworkGatewayGroup con un grupo de, al menos, dos direcciones IP flotantes para aprovechar los beneficios de la alta disponibilidad y la distribución de la carga. El uso de más direcciones IP flotantes mejora la confiabilidad y la capacidad de procesamiento de salida.

A continuación, se muestra 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"
```

Para habilitar la conmutación por error rápida, agrega 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 puerta de enlace NAT de salida es compatible con las API de la política 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 puerta de enlace NAT de salida. Por ejemplo, si el tráfico de salida activa una política de red que provoca que el paquete se descarte, las reglas de puerta de enlace de salida no comprobarán el paquete. Solo cuando la política de red permite la salida del paquete, se evaluarán las reglas de selección de tráfico de salida para decidir cómo se maneja el tráfico, ya sea mediante la puerta de enlace 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 puerta de enlace NAT de salida:

La puerta de enlace NAT de salida solo está habilitada para el modo IPv4.
Las direcciones IP de salida deben estar en el mismo dominio de capa 2 con direcciones IP de nodo.
Si configuras el balanceo de cargas de BGP estándar junto con la NAT de salida y usas la API de GKE On-Prem para administrar tus clústeres (con Terraform, la consola de Google Cloud o la CLI degcloud), no se admiten los selectores de pares de BGP. Esta falta de compatibilidad puede provocar que las sesiones de BGP usen IPs locales incorrectas de forma aleatoria para el intercambio de tráfico, lo que genera un error en el intercambio de tráfico de BGP. Para obtener una solución alternativa, consulta Configura balanceadores de cargas agrupados con BGP: Limitación del selector de BGP.