Descripción general
Puedes controlar el flujo de tráfico de red dentro de tu clúster de GKE con la dirección de servicio de GKE. Puedes definir reglas para dirigir tipos específicos de tráfico a las funciones de red que implementaste en tu clúster. La dirección de servicio de GKE es similar al enrutamiento basado en políticas, en el que anulas la ruta normal del tráfico de red.
Terminología y conceptos
En esta página, se usan los siguientes conceptos:
Función de servicio (SF)
Una función de servicio es un componente de software que funciona con los paquetes de datos recibidos. Una capa de servicio puede operar en cualquier capa del modelo OSI a partir de la capa 2 (capa de vínculo de datos).
Las funciones de servicio se pueden clasificar de manera general en las siguientes categorías:
- Firewalls para la seguridad
- Proxies para controlar el acceso
- Aceleración de WAN para mejorar la velocidad
- Inspección profunda de paquetes (DPI) para analizar contenido
- Interceptación legal (LI) para vigilancia e investigación
- Traductor de direcciones de red (NAT) para direcciones IP privadas y públicas
- HTTP para el enriquecimiento de encabezados
- Balanceadores de cargas para distribuir el tráfico de manera eficiente
Las terminologías alternativas para las funciones de servicio incluyen las siguientes:
- Electrodomésticos en contenedores
- Dispositivos virtuales
- Funciones de red virtualizadas (NFV)
- Funciones de red en contenedores (CNF)
- Funciones de red nativas de la nube (CNF)
En Service Steering, un objeto Service representa una función de servicio (SF).
Cadena de funciones de servicio (SFC)
Una cadena de funciones de servicio (SFC) es una serie de funciones de servicio, como firewalls, proxies o balanceadores de cargas, que se vinculan para procesar el tráfico de red en un orden específico. Esta cadena actúa como una canalización, en la que cada función de servicio realiza una tarea particular en el tráfico antes de pasarlo a la siguiente función.
La cadena de funciones de servicio (SFC) también se denomina cadena de servicio (SC).
En Service Steering, el objeto ServiceFunctionChain representa una cadena de funciones de servicio (SFC).
Una función de servicio opera de forma independiente de cualquier cadena de funciones de servicio. Por lo general, la función de servicio no sabe de qué cadenas de funciones de servicio forma parte.
Dirección de servicio
La dirección de servicio enruta los paquetes a la función de servicio seleccionada de una manera completamente transparente para la fuente y el destino. A veces, este concepto se conoce como "enrutamiento basado en políticas", "redireccionamiento de tráfico" o "reenvío de funciones de servicio". La dirección de servicio logra el enrutamiento transparente con la encapsulación de Geneve + NSH (consulta RFC 8926, RFC 8300 y el borrador de IETF de Geneve + NSH).
Estas son algunas de las características importantes de Service Steering:
- Balanceo de cargas en los Pods de backend de una función de servicio: Las funciones de servicio suelen ejecutarse en varios Pods para garantizar la escalabilidad y la confiabilidad. Service Steering distribuye el tráfico de red entrante de manera uniforme entre estos Pods para evitar que se sobrecargue alguno de ellos.
- Compatibilidad con la afinidad de flujo de 5 tuplas (todos los saltos intermedios deben ser estables para un flujo determinado): Un flujo de 5 tuplas es una forma de identificar un flujo específico de tráfico de red en función de la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el protocolo. El direccionamiento de servicios garantiza que todos los paquetes dentro del mismo flujo se dirijan de manera coherente al mismo conjunto de funciones de servicio (saltos).
- Habilitar una ruta de datos de retorno simétrica: Una ruta de datos de retorno simétrica significa que el tráfico de respuesta sigue la misma ruta de regreso a la fuente que el tráfico de solicitud original. El redireccionamiento de servicios garantiza esta simetría, que es importante para algunos protocolos y aplicaciones de red.
Para cualquier tráfico de red determinado que se dirija a un servicio, los Pods de función de servicio intermedios controlan todos los paquetes de ese tráfico de red en particular, lo que garantiza saltos intermedios coherentes y una ruta predecible. Los mismos pods de función de servicio reciben el tráfico de retorno para garantizar un flujo de tráfico simétrico. Si el tráfico original se envía a un destino dentro del mismo clúster, el tráfico de retorno automáticamente encuentra un camino de regreso a través de la misma cadena de servicios. Si el tráfico original está fuera del clúster, la función de servicio final de la cadena atrae el tráfico hacia sí misma con la traducción de la dirección de red de origen (SNAT) o un proxy, que actúa como intermediario.
Casos de uso
La dirección de servicio de GKE integra el enrutamiento basado en políticas en tus clústeres. Esto permite los siguientes casos de uso principales:
Servicios de seguridad autoadministrados:
Las organizaciones pueden crear su propia infraestructura de seguridad con funciones de red alojadas en contenedores (CNF), como firewalls virtuales (vFW), firewalls virtuales de nueva generación (vNG-FW) y sistemas de detección de intrusiones virtuales (vIDS). El Enrutamiento de servicios garantiza que el tráfico se enrute a través de estas CNF antes de llegar a su destino previsto, lo que proporciona una capa de protección y control.
Proveedores de seguridad administrada (MSP):
Los MSP pueden usar la dirección del servicio de GKE para enrutar tu tráfico a través de sus cadenas de servicios de seguridad basadas en la nube. Esto les permite ofrecer soluciones de seguridad integrales, incluidas las funcionalidades de Secure Web Gateways (SWG), SASE (Secure Access Service Edge) y SD-WAN (Software-Defined Wide Area Network).
Telecomunicaciones y redes 5G:
Service Steering administra los flujos de tráfico para varias funciones de red dentro de las infraestructuras de telecomunicaciones y 5G. Puedes organizar routers virtuales (vRouters), controladores de borde de sesión virtual (vSBC) y funciones de red principal 5G para garantizar una administración eficiente del tráfico, un balanceo de cargas y la aplicación de políticas específicas de seguridad o calidad del servicio.
Cómo funciona la dirección de servicio
En esta sección, se describe cómo funcionan los distintos componentes de Service Steering.
Función de servicio
Identifica el flujo de tráfico de red: La dirección de servicios de GKE identifica cada conexión de red con un ID de flujo único, un hash de 5 tuplas de la dirección IP de origen del paquete, el puerto de origen, la dirección IP de destino, el puerto de destino y el protocolo.
Garantiza la afinidad del flujo: La dirección de servicios garantiza la afinidad del flujo dirigiendo todos los paquetes con el mismo ID de flujo a través de la misma ruta de las funciones de servicio (SF).
Modifica paquetes para crear flujos nuevos: Si una función de servicio modifica alguno de los campos de 5 tuplas en un paquete. Por ejemplo, si la NAT cambia la dirección IP de origen, se crea un flujo nuevo.
Selecciona el tráfico para los flujos nuevos: El proceso de selección de tráfico evalúa el flujo nuevo para determinar su ruta a través de los
Service Functionsrestantes, lo que podría generar una ruta diferente a la del flujo original.Controla los proxies y las NAT como dos flujos: El tráfico a través de proxies o NAT se considera como dos flujos separados: desde la fuente al proxy o a la NAT, y desde el proxy o la NAT al destino. El Enrutamiento de servicios no garantiza la misma ruta para estos dos flujos.
Valida la dirección de origen: Los SF siempre están sujetos a la validación de la dirección de origen, incluso para el tráfico que no se dirige con la Dirección de servicios. Si una función de servicio origina un flujo nuevo con una dirección IP de origen que no coincide, esos paquetes se descartan, a menos que se permitan de forma explícita.
Mantiene la transparencia del encapsulamiento: La dirección de servicio usa el encapsulamiento de Geneve para el tráfico entre las SF, pero los Pods de las funciones de servicio no lo conocen. Los paquetes se desencapsulan antes de ingresar al Pod, lo que simplifica el desarrollo de la función de servicio.
Conexiones existentes
Cuando creas un TrafficSelector, Service Steering lo aplica automáticamente a las conexiones existentes que coincidan con los criterios del selector. Redirecciona los paquetes de estas conexiones a las funciones de servicio adecuadas. La función de servicio en sí es responsable de administrar estas conexiones durante el vuelo. Un enfoque común es descartar los paquetes y confiar en que el cliente inicie una nueva conexión, que luego se integra sin problemas en la cadena de servicios desde el principio.
Ciclo de vida de los recursos
Los recursos TrafficSelector y ServiceFunctionChain se borran inmediatamente después de que se marcan para su eliminación. No hay webhooks ni finalizadores que impidan o retrasen el borrado de recursos.
Tráfico de Pod a Service
La dirección de servicio realiza la selección de tráfico después de resolver la dirección IP virtual del servicio. El tráfico dirigido a un servicio con su ClusterIP se puede seleccionar para la dirección de servicio si la dirección IP del Pod de destino se encuentra dentro del CIDR especificado en el campo .egress.to.ipBlock después de que se resuelve la dirección IP virtual.
Aplicación de NetworkPolicy
La dirección de servicio no omite NetworkPolicy. La política de salida en el Pod de origen y la política de entrada en el Pod de destino aún se aplican al tráfico seleccionado para la dirección de servicio. Sin embargo, no está sujeto a la aplicación de NetworkPolicy en la entrada o salida de una función de servicio. Esto se debe a que las reglas de entrada o salida de NetworkPolicy están bien definidas para los Pods de origen y destino, pero no para los retransmisores de paquetes.
Beneficios
La adopción de la dirección del servicio de GKE, junto con la transición a tecnologías nativas de la nube, tiene los siguientes beneficios:
- Oferta de Marketplace: Los terceros pueden ofrecer su producto en contenedores en Google Cloud Marketplace y usar las APIs de Service Steering. Pueden proporcionar una guía de implementación basada en la API integrada de Kubernetes que proporciona y administra GKE.
- Nivel de detalle de Kubernetes: Puedes controlar el tráfico dentro de tu clúster de Kubernetes. Puedes clasificar el tráfico que deseas dirigir. Puedes seleccionar las cargas de trabajo en las que deseas que se aplique la dirección de servicio de forma selectiva.
- Bidireccionalidad: La dirección de servicio de GKE es bidireccional por naturaleza. Esto significa que, para un flujo determinado, la ruta de retorno es simétrica a la ruta de avance. Esto es importante cuando las funciones de servicio (SF) se implementan como un grupo de réplicas. Asegúrate de que el mismo flujo pase por el mismo conjunto de réplicas para mantener el estado.
- Compatibilidad con varias redes: La mayoría de las funciones de servicio requieren varias interfaces de Pod para separar el plano de datos del plano de control y administración. Algunas funciones de servicio tienen varias interfaces como parte de su arquitectura. La función Service Steering de GKE incluye la integración con Multi-Network en Pods. Con esto, un usuario puede crear una Service Steering en una Pod-Network específica.
- Entrega de paquetes sin procesar a la aplicación: La función Service Steering de GKE encapsula el paquete original y lo entrega directamente al Pod. De esta manera, no tienes que realizar ninguna desencapsulación y tu aplicación puede actuar directamente sobre el paquete original.