¿Qué es un Istio ServiceEntry?
Istio ServiceEntry es la forma de definir un punto final que no pertenece al Registro de Servicios de Istio. Una vez que el ServiceEntry es parte del registro, puede definir reglas e imponer políticas como si pertenecieran a la malla.
Istio Service Entry responde a la pregunta que probablemente te has hecho varias veces al usar una Malla de Servicios. ¿Cómo puedo hacer la misma magia con puntos finales externos que puedo hacer cuando todo está bajo el alcance de mi malla de servicios? Y los objetos Istio Service Entry proporcionan precisamente eso:
Una forma de tener una malla extendida gestionando otro tipo de carga de trabajo o, aún mejor, en palabras del propio Istio:
ServiceEntry permite agregar entradas adicionales en el registro de servicios interno de Istio para que los servicios auto-descubiertos en la malla puedan acceder/rutear a estos servicios especificados manualmente.
Estos servicios podrían ser externos a la malla (por ejemplo, APIs web) o servicios internos de la malla que no son parte del registro de servicios de la plataforma (por ejemplo, un conjunto de VMs comunicándose con servicios en Kubernetes).
¿Cuáles son las principales capacidades de Istio ServiceEntry?
Aquí puedes ver un ejemplo de la definición YAML de un Service Entry:
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: external-svc-redirect
spec:
hosts:
- wikipedia.org
- "*.wikipedia.org"
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: TLS
resolution: NONE
En este caso, tenemos un objeto external-svc-redirectServiceEntry que está manejando todas las llamadas que van a wikipedia.org, y definimos el puerto y el protocolo a utilizar (TLS – 443) y clasificamos este servicio como externo a la malla (MESH_EXTERNAL) ya que es una página web externa.
También puedes especificar más detalles dentro de la configuración de ServiceEntry, para que puedas, por ejemplo, definir un nombre de host o IP y traducirlo a un nombre de host y puerto diferentes porque también puedes especificar el modo de resolución que deseas usar para este Service Entry específico. Si ves el fragmento anterior, encontrarás un campo resolution con el valor NONE que indica que no hará ninguna resolución particular. Pero otros valores válidos son los siguientes:
- NONE: Asume que las conexiones entrantes ya han sido resueltas (a una dirección IP de destino específica).
- STATIC: Usa las direcciones IP estáticas especificadas en los puntos finales como las instancias de respaldo asociadas con el servicio.
- DNS: Intenta resolver la dirección IP consultando el DNS ambiental de manera asincrónica.
- DNSROUNDROBIN: Intenta resolver la dirección IP consultando el DNS ambiental de manera asincrónica. A diferencia de DNS, DNSROUNDROBIN solo usa la primera dirección IP devuelta cuando se necesita iniciar una nueva conexión sin depender de los resultados completos de la resolución DNS, y las referencias hechas a los hosts se mantendrán incluso si los registros DNS cambian con frecuencia, eliminando el drenaje de grupos de conexiones y el ciclo de conexiones.
Para definir el objetivo del ServiceEntry, necesitas especificar sus puntos finales utilizando un objeto WorkloadEntry. Para hacerlo, necesitas proporcionar los siguientes datos:
- address: Dirección asociada con el punto final de la red sin el puerto.
- ports: Conjunto de puertos asociados con el punto final
- weight: El peso de balanceo de carga asociado con el punto final.
- locality: La localidad asociada con el punto final. Una localidad corresponde a un dominio de falla (por ejemplo, país/región/zona).
- network: La red permite a Istio agrupar puntos finales residentes en el mismo dominio/red L3.
¿Qué puedes hacer con Istio ServiceEntry?
El número de casos de uso es enorme. Una vez que un ServiceEntry es similar a lo que tienes definido un Servicio Virtual, puedes aplicar cualquier regla de destino a ellos para hacer un balanceador de carga, un cambio de protocolo, o cualquier lógica que se pueda hacer con el objeto DestinationRule. Lo mismo se aplica al resto de los CRD de Istio, como RequestAuthentication y PeerAuthorization, entre otros.
También puedes tener una representación gráfica del ServiceEntry dentro de Kiali, una representación visual para la Malla de Servicios de Istio, como puedes ver en la imagen a continuación:
Como puedes definir, una malla extendida con puntos finales fuera del clúster de Kubernetes es algo que se está volviendo más común con la explosión de clústeres disponibles y los entornos híbridos cuando necesitas gestionar clústeres de diferentes topologías y no perder la gestión centralizada basada en políticas de red que la Malla de Servicios de Istio proporciona a tu plataforma.