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 en términos generales de la siguiente manera:
- 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 el contenido
- Interceptación legal (LI) para la vigilancia y la 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
Entre las terminologías alternativas para las funciones de servicio, se incluyen las siguientes:
- Dispositivos de contenedor
- Dispositivos 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 servicio, 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, vinculadas 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 específica 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 la dirección de servicio, 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 el origen y el destino. A veces, este concepto se denomina "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 mediante el encapsulamiento de Geneve + NSH (consulta RFC 8926, RFC 8300, Geneve + NSH IETF Draft).
Algunas de las características importantes de la dirección de servicio incluyen las siguientes:
- Balanceo de cargas en los Pods de backend de una función de servicio: Las funciones de servicio suelen ejecutarse en varios Pods para lograr escalabilidad y confiabilidad. La dirección de servicio distribuye el tráfico de red entrante de manera uniforme en estos Pods para evitar que un solo Pod se sobrecargue.
- 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 una transmisión específica 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. La dirección de servicio ayuda a garantizar que todos los paquetes dentro del mismo flujo se dirijan de manera coherente al mismo conjunto de funciones de servicio (saltos).
- Habilitación de 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 al origen que el tráfico de solicitud original. La dirección de servicio ayuda a garantizar esta simetría, que es importante para algunos protocolos y aplicaciones de red.
Para cualquier tráfico de red determinado que se dirija al 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 ruta de regreso a través de la misma cadena de servicio. Si el tráfico original está fuera del clúster, la función de servicio final de la cadena atrae el tráfico de regreso 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 ayuda a garantizar 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 administrados (MSP):
Los MSP pueden utilizar la dirección de servicio de GKE para enrutar tu tráfico a través de sus cadenas de servicio de seguridad basadas en la nube. Esto les permite ofrecer soluciones de seguridad integrales, incluidas las 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 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 la dirección de servicio.
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.
Ayuda a garantizar la afinidad de flujo: La dirección de servicio ayuda a garantizar la afinidad de 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 cualquiera 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.
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 las
Service Functionsrestantes, lo que podría tomar 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: origen a proxy/NAT y proxy/NAT a destino. La dirección de servicio no garantiza la misma ruta para estos dos flujos.
Valida la dirección de origen: Las SF siempre están sujetas a la validación de la dirección de origen, incluso para el tráfico que no dirige la dirección de servicio. 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 función de servicio no lo saben. 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, la dirección de servicio lo aplica automáticamente a cualquier conexión existente que coincida con los criterios del selector. Redirige los paquetes de estas conexiones a las funciones de servicio adecuadas. La función de servicio en sí es responsable de administrar estas conexiones en tránsito. Un enfoque común es descartar los paquetes y depender del cliente para iniciar una conexión nueva, que luego se integra sin problemas en la cadena de servicio desde el principio.
Ciclo de vida de los recursos
Los recursos TrafficSelector y ServiceFunctionChain se borran de inmediato después de que se marcan para su eliminación. No hay webhooks ni finalizadores que impidan o retrasen la eliminación 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 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 de Marketplace: Los terceros pueden ofrecer su producto en contenedores en Google Cloud Marketplace y usar las APIs de dirección de servicio. 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 datos de retorno es simétrica a la ruta de datos de ida. 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 dirección de servicio 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 dirección de servicio 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 en el paquete original.