Comprendiendo Istio ServiceEntry: Cómo Extender tu Malla de Servicios a Puntos de Extremo Externos

por Alexandre Vazquez
2025-11-03

¿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:

Entendiendo Istio ServiceEntry: Cómo Extender Tu Malla de Servicios a Puntos Finales Externos

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.

Etiquetas:Service Mesh

Understanding Istio ServiceEntry: How to Extend Your Service Mesh to External Endpoints

por Alexandre Vazquez
2022-12-252024-09-29

What Is An Istio ServiceEntry?

Istio ServiceEntry is the way to define an endpoint that doesn’t belong to the Istio Service Registry. Once the ServiceEntry is part of the registry, it can define rules and enforce policies as if they belong to the mesh.

Istio Service Entry answers the question you probably have done several times when using a Service Mesh. How can I do the same magic with external endpoints that I can do when everything is under my service mesh scope? And Istio Service Entry objects provide precisely that:

A way to have an extended mesh managing another kind of workload or, even better, in Istio’s own words:

ServiceEntry enables adding additional entries into Istio’s internal service registry so that auto-discovered services in the mesh can access/route to these manually specified services.

These services could be external to the mesh (e.g., web APIs) or mesh-internal services that are not part of the platform’s service registry (e.g., a set of VMs talking to services in Kubernetes).

What are the main capabilities of Istio ServiceEntry?

Here you can see a sample of the YAML definition of a 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

In this case, we have an external-svc-redirectServiceEntry object that is handling all calls going to the wikipedia.org, and we define the port and protocol to be used (TLS – 443) and classify this service as external to the mesh (MESH_EXTERNAL) as this is an external Web page.

You can also specify more details inside the ServiceEntry configuration, so you can, for example, define a hostname or IP and translate that to a different hostname and port because you can also specify the resolution mode you want to use for this specific Service Entry. If you see the snippet above, you will find a resolution field with NONE value that says it will not make any particular resolution. But other values valid are the following ones:

NONE: Assume that incoming connections have already been resolved (to a specific destination IP address).
STATIC: Use the static IP addresses specified in endpoints as the backing instances associated with the service.
DNS: Attempt to resolve the IP address by querying the ambient DNS asynchronously.
DNSROUNDROBIN: Attempt to resolve the IP address by querying the ambient DNS asynchronously. Unlike DNS, DNSROUNDROBIN only uses the first IP address returned when a new connection needs to be initiated without relying on complete results of DNS resolution, and references made to hosts will be retained even if DNS records change frequently eliminating draining connection pools and connection cycling.

To define the target of the ServiceEntry, you need to specify its endpoints by using a WorkloadEntry object. To do that, you need to provide the following data:

address: Address associated with the network endpoint without the port.
ports: Set of ports associated with the endpoint
weight: The load balancing weight associated with the endpoint.
locality: The locality associated with the endpoint. A locality corresponds to a failure domain (e.g., country/region/zone).
network: Network enables Istio to group endpoints resident in the same L3 domain/network.

What Can You Do With Istio ServiceEntry?

The number of use cases is enormous. Once a ServiceEntry is similar to what you have a Virtual Service defined, you can apply any destination rule to them to do a load balancer, a protocol switch, or any logic that can be done with the DestinationRule object. The same applies to the rest of the Istio CRD, such as RequestAuthentication, and PeerAuthorization, among others.

You can also have a graphical representation of the ServiceEntry inside Kiali, a visual representation for the Istio Service Mesh, as you can see in the picture below:

Understanding Istio ServiceEntry: How to Extend Your Service Mesh to External Endpoints

As you can define, an extended mesh with endpoints outside the Kubernetes cluster is something that is becoming more usual with the explosion of clusters available and the hybrid environments when you need to manage clusters of different topologies and not lose the centralized policy-based network management that the Istio Service Mesh provides to your platform.

Etiquetas:Istio Service Mesh