Información acerca de la dirección de servicio


Descripción general

Puedes controlar cómo fluye el 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 en 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 forma general en las siguientes categorías:

  • Firewalls para la seguridad
  • Proxys para controlar el acceso
  • Aceleración de WAN para mejorar la velocidad
  • Inspección profunda de paquetes (DPI) para analizar contenido
  • Intercepción legal (LI) para la vigilancia y la investigación
  • Traducción de direcciones de red (NAT) para direcciones IP públicas y privadas
  • HTTP para el enriquecimiento de encabezados
  • Balanceadores de cargas para distribuir el tráfico de manera eficiente

Entre las terminologías alternativas para las funciones de servicio, se incluyen las siguientes:

  • Electrodomésticos de contenedores
  • Aparatos virtuales
  • Funciones de red virtualizadas (NFV)
  • Funciones de red en contenedores (CNF)
  • Funciones de red nativas de la nube (CNF)

En la dirección de servicios, un objeto Service representa una función de servicio (SF).

Cadena de funciones de servicio (SFC)

La cadena de funciones de servicio (SFC) es una serie de funciones de servicio, como firewalls, proxies o balanceadores de cargas, vinculados 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 en 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 servicios (SC).

En la dirección del servicio, el objeto ServiceFunctionChain representa una cadena de funciones de servicio (SFC).

Una función de servicio funciona independientemente 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 que es completamente transparente para la fuente y el destino. A veces, este concepto se conoce como "enrutamiento basado en políticas", "redirección de tráfico" o "reenvío de funciones de servicio". La dirección de servicio logra el enrutamiento transparente con el encapsulamiento de Geneve + NSH (consulta RFC 8926, RFC 8300 y Geneve + NSH IETF Draft).

Estas son algunas de las características importantes de la dirección de servicios:

  • Balanceo de cargas entre los Pods de backend de una función de servicio: Las funciones de servicio a menudo se ejecutan en varios Pods para lograr escalabilidad y confiabilidad. La dirección del servicio distribuye el tráfico de red entrante de manera uniforme entre estos Pods para evitar que se sobrecarguen.
  • 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 según la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el protocolo. La dirección del servicio garantiza que todos los paquetes dentro del mismo flujo se dirijan de manera coherente al mismo conjunto de funciones de servicio (saltos).
  • Habilita 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. La dirección 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 esté controlando por 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 encuentra automáticamente una forma de regresar 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 en la cadena atrae el tráfico de vuelta a sí misma mediante 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). La dirección de servicio garantiza que el tráfico se enrute a través de estos CNF antes de llegar a su destino previsto, lo que proporciona una capa de protección y control.

Proveedores de seguridad administrados (MSP):

Los MSPs pueden usar la dirección del servicio de GKE para enrutar el 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 funciones de puertas de enlace web seguras (SWG), SASE (perímetro de servicio de acceso seguro) y SD-WAN (red de área extensa definida por software).

Telecomunicaciones y redes 5G:

La dirección de servicio administra los flujos de tráfico de 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 varios componentes de la dirección de servicios.

Función de servicio

  1. 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.

  2. Garantiza la afinidad del flujo: La dirección del servicio garantiza la afinidad del flujo dirigiendo todos los paquetes con el mismo ID de flujo a través de la misma ruta de funciones de servicio (SF).

  3. 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, NAT cambia la dirección IP de origen, lo que crea un flujo nuevo.

  4. Selecciona el tráfico para 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 Functions restantes, lo que podría tomar una ruta diferente a la del flujo original.

  5. 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: de la fuente al proxy/NAT y del proxy/NAT al destino. La dirección de servicios no garantiza la misma ruta para estos dos flujos.

  6. 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 está dirigido por la dirección de servicio. Si una función de servicio genera un flujo nuevo con una dirección IP de origen que no coincide, se descartan esos paquetes, a menos que se permita de forma explícita.

  7. 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 la función de servicio no lo saben. Los paquetes se descapsulan antes de ingresar al Pod, lo que simplifica el desarrollo de la función de servicio.

Conexiones existentes

Cuando creas un TrafficSelector, la dirección del servicio lo aplica automáticamente a cualquier conexión existente que coincida con los criterios del selector. Redirecciona los paquetes de estas conexiones a las funciones de servicio adecuadas. La función de servicio es responsable de administrar estas conexiones durante el vuelo. Un enfoque común es descartar los paquetes y depender del cliente para iniciar 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 borrarse. No hay webhooks ni finalizadores que impidan o retrasen la eliminación de recursos.

Tráfico de Pod a servicio

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 servicios 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 forzosa 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 reenviadores de paquetes.

Beneficios

La adopción de la dirección de servicio de GKE, junto con la transición a tecnologías nativas de la nube, tiene los siguientes beneficios:

  • Oferta del mercado: Los terceros pueden ofrecer su producto en contenedor 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. Esto significa que, para un flujo determinado, la ruta de retorno es simétrica a la ruta de reenvío. 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 la misma réplica del conjunto 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 dirección de servicios de GKE incluye la integración con varias redes en Pods. Con esto, un usuario puede crear una dirección de servicio en una red de pods específica.
  • Entrega de paquetes sin procesar a la aplicación: La orientación de servicios de GKE encapsula el paquete original y lo entrega directamente al Pod. De esta manera, no tienes que hacer ninguna decapsulación y tu aplicación puede actuar directamente en el paquete original.

¿Qué sigue?