Con Google Distributed Cloud, puedes configurar la traducción de direcciones de red de origen (SNAT) para que cierto 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 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 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
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 etiquetauser: alice
.El pod tiene la etiqueta
role: frontend
y 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.
En la sección
gatewayRef
, se determina la dirección IP de origen de salida. El recurso personalizado EgressNATPolicy usa los valoresgatewayRef.name
ygatewayRef.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 listafloatingIPs
e ignora cualquier otra dirección IP. Si hay campos no válidos en la seccióngatewayRef
, 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.
Cada recurso NetworkGatewayGroup
debe contener direcciones IP flotantes únicas.
Si quieres configurar varios objetos EgressNATPolicy
para que usen la misma dirección IP, usa los mismos gatewayRef.name
y gatewayRef.namespace
en 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: 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
Especifica nodos en los que se ubicarán direcciones IP flotantes (opcional)
Los recursos NetworkGatewayGroup
admiten selectores de nodos. Si deseas 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 las direcciones IP flotantes.