ServiceEntry vs Service and Endpoints

Question

What are the key benefits of using ServiceEntry when I can simply create Service(and if this service is a set of external IPs then define Endpoints instead of selector). In which cases I can't rely on Service?

Answer 1

I would say key benefits are mentioned in the documentation, you can configure the traffic route, define retry, timeouts, fault injection etc.

A service entry describes the properties of a service (DNS name, VIPs, ports, protocols, endpoints). 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).

---

You use a service entry to add an entry to the service registry that Istio maintains internally. After you add the service entry, the Envoy proxies can send traffic to the service as if it was a service in your mesh. Configuring service entries allows you to manage traffic for services running outside of the mesh, including the following tasks:

• Redirect and forward traffic for external destinations, such as APIs consumed from the web, or traffic to services in legacy infrastructure.
• Define retry, timeout, and fault injection policies for external destinations.
• Run a mesh service in a Virtual Machine (VM) by adding VMs to your mesh.
• Logically add services from a different cluster to the mesh to configure a multicluster Istio mesh on Kubernetes.

You don’t need to add a service entry for every external service that you want your mesh services to use. By default, Istio configures the Envoy proxies to passthrough requests to unknown services. However, you can’t use Istio features to control the traffic to destinations that aren’t registered in the mesh.

The following example mesh-external service entry adds the ext-svc.example.com external dependency to Istio’s service registry:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

You specify the external resource using the hosts field. You can qualify it fully or use a wildcard prefixed domain name.

You can configure virtual services and destination rules to control traffic to a service entry in a more granular way, in the same way you configure traffic for any other service in the mesh. For example, the following destination rule configures the traffic route to use mutual TLS to secure the connection to the ext-svc.example.com external service that we configured using the service entry:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

See the Service Entry reference for more possible configuration options.

Answer 2

As long, as I worked with Istio, I realized that the most benefit of ServiceEntry from Service+Endpoints is that I can specify labels on endpoints in ServceEntry and build subsets upon it.

Answer 3

ServiceEntry is the API object used to define services in Istio with a set of endpoints. ServiceEntry can describe a service deployed across several clusters, services outside of the service mesh(e.g., 3rd party 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).

ServiceEntry endpoints can be IP addresses or DNS names. Each endpoint can be individually labeled and tagged with a network, locality, and weight and allows ServiceEntrys to describe various network topologies.

In comparison with K8s Services, in particular, Service type ExternalName you won't have Istio features(retry, timeout, fault injection policies, traffic control/load balancing with egress gateway, etc) to properly control the traffic to destinations that aren’t registered in the mesh.

Istio integration with Kubernetes uses the K8s SDK to watch the API server for service creation and service endpoint update events. By using this data, Istio creates a ServiceEntry object(Kubernetes CRDs), and this ServiceEntry is used to update Istio internal model and generate updated configuration for the data plane(Envoy), specifically, ServiceEntrys create Envoy clusters and populate their endpoints.

Relevant excerpts from the official Istio docs:

To populate its own service registry, Istio connects to a service discovery system. For example, if you’ve installed Istio on a Kubernetes cluster, then Istio automatically detects the services and endpoints in that cluster. Istio maintains an internal service registry containing the set of services, and their corresponding service endpoints, running in a service mesh. Istio uses the service registry to generate Envoy configuration.

Istio does not provide service discovery, although most services are automatically added to the registry by Pilot adapters that reflect the discovered services of the underlying platform (Kubernetes, Consul, plain DNS). Additional services can also be registered manually using a ServiceEntry configuration.