How can we use Envoy & Consul to route & register micro-services?

In Gojek we widely used Envoy & Consul in our microservices architecture.
Let’s understand these terms one by one and how they communicate with each other

Envoy : Envoy is an open-source L7 proxy and communication bus Originally built at Lyft to move their architecture away from a monolith. Now you want to know What the heck is L7 proxy ?

So, let me explain this L7 — > Layer 7 is related to seventh layer of the OSI model: application level.
For example: HTTP, FTP, SMTP, DNS protocols are application level.
A layer 7 load-balancer takes routing decision based on IPs, TCP or UDP ports or any information it can get from the application protocol (mainly HTTP).
The layer 7 load-balancer acts as a proxy, which means it maintains two TCP connections: one with the client and one with the server.

Consul : We can use Consul for service discovery and health checking in our micro-services architecture. All our services k8s pods and VM’s register themselves on consul.

consul-envoy-xds : It’s an open source in-house product of gojek. It’s act as a bridge b/w Envoy & Consul in simple terms for communication. It will push all information like this : Consul → consul-envoy-xds → Envoy

Kubernetes Pods are running inside a physical instance and one or more instances create a K8s Cluster.In Every Node of K8s Cluster we have consul agent and consul servers running.

Clients can be micro-services, third party apps from which request is coming and routed to Envoy. Envoy will help this request on which Kubernetes Pod it should route to. Whenever there is new deployment in K8S Cluster then news pods will get created and their new IP addresses will be register by Consul and with the help of consul-envoy-xds new pods IP addresses will push to Envoy.