The Istio Gateway service is a load balancer that will enable HTTP(S) traffic to your cluster. It will sit at the entry of the service mesh and listen to the external connection which will allow the external traffic into the mesh.
It will have details like
i) Hostnames that will route to services.
ii) Serve certificates for those hostnames.
iii) Port details.
The call from Gateway load balancer will be
intercepted by the Istio object “Gateway” pod which is an envoy proxy
(yes you are reading it correctly; Envoy acts as a sidecar and as well
as Gateway pod). The call from Gateway will be redirected to the
destination service based on the “VirtualService” routing
configuration.
VirtualServices configure how traffic flows to a service by defining a set of traffic rules for routing Envoy traffic inside service mesh. The traffic rules define what criteria to match before applying the rules on the call. That is, an Istio virtual service might match up with multiple kubernetes services based on various criteria.
DestinationRules will come in to play when routing is done to your application service subsets v1 and v2. That is, destination rules starts its work after the request already reaches your services. Say if you are introducing a new version of service or patch fixes to production, it is often desirable to move a controlled percentage of user traffic to a newer version of service in the process of phasing out the older version (Canary deployment). Basically it covers the basic configuration for load balancing, connection pool, circuit breaker, etc.
ServiceEntry: If you want to call external services outside your service mesh, We have
to create a service entry configuration for externally running business
components/ down streams.
No comments:
Post a Comment