Out of the box, Kubernetes has a high-level functional service mesh that provides service discovery for the necessary pods/containers and enables round-robin network requests for service versioning. There are no retries, timeouts, or any other features that the service mesh typically provides and can handle for a microservice.  

The functional capability of a service registry is to keep track of all service pods and virtual machines for the designated application. With support from Istio, Kubernetes allows all new instances of a service, such as a new version, to be automatically registered within the service registry. For example, services without connections to pods are dead services and those services hide from discovery. 

In Istio, the pilot consumes service configurations from the service registry and provides a platform-agnostic service discovery interface. The sidecar proxy is configured for service discovery and dynamically updates the load balancing weight pools for every service. This can be seen in the following diagram:

In the preceding diagram, all of the network traffic that's bound to a microservice is rerouted through the sidecar proxy. By enabling a load balancer within the cluster, the sidecar proxy can distribute traffic requests across any service instance. The sidecar proxy, that is, Envoy, supports a long list of load balancing algorithms. Within Istio and its latest version, Envoy is certified against three specific modules, such as weighted request, round-robin, and random percentage assignment.

Pilot has an abstract model for services that external platform services can fill to register external services. Galley can function for configuration management for external services. Pilot takes the metadata from microservices deployed in the Kubernetes API server and pushes updated pod configurations to sidecar proxies. It also abstracts service discovery so that sidecars can consume it as a standard format. Pilot receives user-defined policies, which are then pushed to the sidecar proxies to enforce policy-based rules. 

Now that we understand Istio-enabled service discovery, we will learn how to implement traffic management policies using Istio-defined primitives.