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.
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.
El paquete coincide con una regla de salida, por lo que se reenvía al nodo de puerta de enlace.
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.
El tráfico de retorno regresa al nodo de la puerta de enlace con el destino 192.168.1.100.
El nodo de puerta de enlace usa conntrack para modificar la dirección IP de destino a 10.10.10.1.
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 de red de Anthos
Esta sección está destinada a los administradores de clústeres.
Crea un clúster de usuario nuevo con la puerta de enlace de red de Anthos habilitada.
En el archivo de configuración del clúster de usuario, configura enableDataplaneV2 y enableAnthosNetworkGateway como true.
enableDataplaneV2: true ... enableAnthosNetworkGateway: true
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 AnthosNetworkGateway
Esta sección está destinada a los administradores de clústeres.
Este es un ejemplo de un manifiesto para un objeto AnthosNetworkGateway:
kind: AnthosNetworkGateway apiVersion: networking.gke.io/v1alpha1 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-ang.yaml.
Crea el objeto AnthosNetworkGateway:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-ang.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
metadata:
name: alice-paul
spec:
egress:
- namespaceSelector:
matchLabels:
user: alice
podSelector:
matchLabels:
role: frontend
- namespaceSelector:
matchLabels:
user: paul
podSelector:
matchLabels:
role: frontend
destinationCIDRs:
- 8.8.8.0/24
egressSourceIP: 192.168.1.100
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: frontendy el pod está en un espacio de nombres que tiene la etiquetauser: alice.El pod tiene la etiqueta
role: frontendy el pod está en un espacio de nombres que tiene la etiquetauser: 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.
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 anthosnetworkgateway --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.
Problemas conocidos
Direcciones egressSourceIP duplicadas
Cuando creas un objeto OutputNATGateway, puedes especificar una dirección egressSourceIP que ya esté en uso para otro objeto EgressNATPolicy. Esto causará conflictos de enrutamiento de tráfico de salida. Coordina con tu equipo de desarrollo para determinar qué direcciones IP flotantes están disponibles antes de especificar la dirección egressSourceIP.
Cambios en los recursos personalizados
Los cambios en los recursos personalizados de EgresNATPolicy no se propagan a los recursos personalizados de Cilium.