Configura una puerta de enlace NAT de salida

10

Con los clústeres de Anthos alojados en VMware (GKE On-Prem), puedes configurar la traducción de direcciones de red de origen (SNAT) para que cierto tráfico de salida del 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.

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.

Una limitación en los clústeres de Anthos alojados en VMware para esta versión es que solo se concilia la NetworkGatewayGroup que tiene el nombre default en el espacio de nombres kube-system para asignaciones de IP flotantes. Además, solo NetworkGatewayGroup predeterminado informa el estado de asignación de todas las direcciones IP flotantes.

Por lo tanto, cuando crees varios objetos NetworkGatewayGroup, debes asegurarte de que las direcciones IP en los objetos no predeterminados también se especifiquen en el manifiesto de NetworkGatewayGroup predeterminado. De lo contrario, no se asignarán como IP flotantes y, por lo tanto, el objeto EgressNATPolicies no podrá usarlas.

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

  1. Verifica el objeto NetworkGatewayGroup predeterminado (name: default) con kubectl para obtener el estado de asignación de las direcciones IP flotantes:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkgatewaygroup --name default --output 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:
      ...
      floatingIPs:
        192.168.1.100: worker1
        192.168.1.101: worker2
        192.168.1.102: worker1
    
  2. Después de verificar el estado del NetworkGatewayGroup predeterminado, crea objetos NetworkGatewayGroup adicionales en el espacio de nombres kube-system para “hacer un seguimiento” de cada IP flotante.

    Ten en cuenta que estos objetos nuevos no informan el estado de la asignación, que se encuentra en el NetworkGatewayGroup default.

    kind: NetworkGatewayGroup
    apiVersion: networking.gke.io/v1
    metadata:
      namespace: kube-system
      name: gateway1
    spec:
      floatingIPs:
      — 192.168.1.100
    ---
    kind: NetworkGatewayGroup
    apiVersion: networking.gke.io/v1
    metadata:
      namespace: kube-system
      name: gateway2
    spec:
      floatingIPs:
      — 192.168.1.101
    ---
    kind: NetworkGatewayGroup
    apiVersion: networking.gke.io/v1
    metadata:
      namespace: kube-system
      name: gateway3
    spec:
      floatingIPs:
      — 192.168.1.102
    
  3. Crea varias políticas que hagan referencia a los objetos NetworkGatewayGroup “secundarios”, 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