En este documento, se describe cómo configurar una puerta de enlace NAT de salida para clústeres de Anthos en equipos físicos. Esta puerta de enlace proporciona enrutamiento persistente y determinista para el tráfico de salida desde tus clústeres. Cuando ejecutas cargas de trabajo que tienen tráfico de usuario 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 la inclusión de políticas de listas de entidades permitidas. No se aplican cargos por usar esta función mientras está en vista previa.
La puerta de enlace NAT de salida se habilita mediante dos recursos personalizados. Para un espacio de nombres determinado, el recurso personalizado AnthosNetworkGateway 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 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.
Cómo funciona la puerta de enlace NAT de salida
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, consideremos el flujo del 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.
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.1en un nodo con la dirección IP192.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.100especificada en el recurso personalizadoEgressNATPolicy.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.1se trata como tráfico en el clúster, enrutado al nodo original y entregado al Pod original.
Configura direcciones IP flotantes para el tráfico de nodos
El controlador de puerta de enlace de red de Anthos es un componente empaquetado de los clústeres de Anthos en equipos físicos. El controlador 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. La puerta de enlace de red de Anthos pone a disposición una dirección IP flotante en todo momento según el criterio del mejor esfuerzo. Si un nodo que usa una dirección IP flotante falla, la red de puerta de enlace de Anthos 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 la puerta de enlace de red de Anthos (anotación y especificaciones) en el archivo de configuración del clúster cuando crees un clúster nuevo 1.8.0.
Crea el recurso personalizado AnthosNetworkGateway
Puedes habilitar la puerta de enlace de red de Anthos mediante la anotación baremetal.cluster.gke.io/enable-anthos-network-gateway en el archivo de configuración del clúster cuando creas un clúster. Configura la anotación como true, como se muestra en el siguiente ejemplo:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
annotations:
baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
name: cluster1
namespace: cluster-cluster1
Cuando crees el recurso AnthosNetworkGateway 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: AnthosNetworkGateway
apiVersion: networking.gke.io/v1alpha1
metadata:
namespace: cluster-cluster1
name: default
spec:
floatingIPs:
- 192.168.1.100
- 192.168.1.101
- 192.168.1.102
La cantidad de direcciones IP flotantes que especifiques afecta la confiabilidad de tu clúster. Por ejemplo, una puerta de enlace NAT de salida funcionará con solo una dirección IP flotante especificada, pero una falla de nodo puede provocar interrupciones de tráfico. Si agregas más direcciones IP flotantes, AnthosNetworkGateway las asigna y las mueve según sea necesario. Te recomendamos que proporciones al menos dos direcciones IP flotantes por el dominio L2 que se usan en el clúster.
El controlador asigna las IP flotantes a los nodos según los siguientes criterios:
- Subred del nodo: la dirección IP flotante debe coincidir con la subred del nodo.
- Función de nodo (principal, trabajador): los nodos trabajadores tienen prioridad sobre los nodos principales cuando asignan direcciones IP flotantes.
- Si un nodo tiene una dirección IP flotante, el controlador prioriza las asignaciones a los nodos que aún no tienen una IP flotante asignada.
La asignación de dirección/nodo se puede encontrar en la sección status cuando obtienes el objeto AnthosNetworkGateway. Ten en cuenta que el objeto AnthosNetworkGateway está en el espacio de nombres del sistema de Kubernetes. Si un nodo de puerta de enlace está inactivo, el controlador de AnthosNetworkGateway 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
AnthosNetworkGatewayy ver cómo se asignan las direcciones IP flotantes:kubectl -n kube-system get anthosnetworkgateway.networking.gke.io default -oyamlLa respuesta de un clúster con dos nodos,
worker1yworker2podría tener el siguiente aspecto: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 status: nodes: worker1: Up worker2: Up // Or Down floatingIPs: 192.168.1.100: worker1 192.168.1.101: worker2 192.168.1.102: worker1Usa el siguiente comando a fin de recuperar el estado de
AnthosNetworkGatewayy la asignación de dirección para un nodo específico.kubectl -n kube-system get anthosnetworkgatewaynode.networking.gke.io NODE_NAME -oyamlReemplaza NODE_NAME por el nombre del nodo o la máquina específicos que deseas inspeccionar.
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 determinista para el tráfico de salida que sale del clúster.
Cuando especificas el CR, egress (con al menos una regla), destinationCIDRs y egressSourceIP son obligatorios.
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
podSelectory unanamespaceSelector. - 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.
- Cada regla consta de una
Especifica las direcciones de destino permitidas en la sección
destinationCIDRs.destinationCIDRstoma 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: aliceouser: paul. - El Pod se comunica con las direcciones IP en el rango
8.8.8.0/24.
kind: EgressNATPolicy
apiVersion: networking.gke.io/v1alpha1
metadata:
name: egress
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
Para obtener más información sobre el uso de etiquetas, consulta Etiquetas y selectores en la documentación de Kubernetes.
Especifica una dirección IP de origen para el tráfico de salida
Especifica la dirección IP de origen que deseas usar en el campo egressSourceIP.
La dirección IP de origen debe coincidir con una de las direcciones IP flotantes especificadas en el recurso AnthosNetworkGateway personalizado.
En el ejemplo de EgressNATPolicy de la sección anterior, si se cumplen los criterios de dirección IP de destino y selección de Pods, el tráfico de salida del pod se traduce a 192.168.1.100 mediante SNAT.
Para que la ruta se acepte, la dirección egressSourceIP debe estar en la misma subred que la IP del nodo de la puerta de enlace. Si la dirección egressSourceIP es desconocida (no está asignada) al nodo de puerta de enlace, la solicitud de ruta no se puede completar. En este caso, recibirás un error UnknownEgressIP en los eventos de Kubernetes.
Usa el siguiente comando de kubectl para imprimir los eventos del objeto EgressNATPolicy:
kubectl describe EgressNATPolicy egressSi hay varios CR EgressNATPolicy, cada uno debe tener una dirección egressSourceIP diferente. Para evitar conflictos, coordina con el equipo de desarrollo.
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.
Para esta vista previa, las direcciones IP de salida deben estar en el mismo dominio L2 con direcciones IP de nodo.
Las actualizaciones no son compatibles con clústeres que se configuraron para usar la vista previa de la puerta de enlace NAT de salida.