The core component used for traffic management in Istio is Pilot, which manages and configures all the Envoy proxy instances deployed in a particular Istio service mesh. Pilot lets you specify what rules you want to use to route traffic between Envoy proxies, which run as sidecars to each service in the mesh.
Each service consists of any number of instances running on pods, containers, VMs, and so on. Each service can have any number of versions, or subsets. There can be distinct subsets of service instances running different variants of the app binary. These variants are not necessarily different API versions. They could be iterative changes to the same service, deployed in different environments (production, staging, development, and so on).
Pilot translates high-level rules into low-level configurations and distributes this configuration to Envoy instances. Pilot uses three types of configuration resources to manage traffic in its service mesh:
- Virtual services
- Destination rules
- Service entries
A VirtualService defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for traffic of a specific protocol. If the traffic is matched, it is sent to a named destination service (or subset or version of it) defined in the service registry.
A DestinationRule defines policies that apply to traffic that is intended for a service after routing has occurred. These rules specify configuration for load balancing, connection pool size from the sidecar, and outlier detection settings to detect and evict unhealthy hosts from the load balancing pool. Any destination host and subset referenced in a VirtualService rule must be defined in a corresponding DestinationRule.
A ServiceEntry configuration enables services in the mesh to access a service that is not necessarily managed by Istio. The rule describes the endpoints, ports, and protocols of a white-listed set of mesh-external domains and IP blocks that services in the mesh are allowed to access.