Microservices or containers are used to execute modern cloud-native apps. Microservices must communicate dynamically in these contexts, with no manual configuration. This is made possible by service discovery.
In this blog, we’ll look in depth at service discovery and how it works in Kubernetes.
What is Service Discovery?
Service discovery is a method that allows services to discover one other in real-time without the need for hard coding IP addresses or endpoint setup.
Microservices are used to create applications with modern cloud-native infrastructure such as Kubernetes. For applications to work, the many components inside a microservices architecture must connect, but individual IP addresses and endpoints vary dynamically.
As a result, service discovery is required so that services may automatically discover each other.
Types of service discovery
There are numerous types of service discovery. Let us look at the most popular ones.
Server-side service discovery
In order to identify server-side services, a load balancer (LB) is placed in front of the service and allowed to connect to service instances. This procedure removes client-side complexity. The client simply points to the load balance’s IP or DNS name.
This method facilitates client service discovery, but the LB becomes a single point of failure and bottleneck. Furthermore, the LB must implement service discovery logic in order to point to the proper instances of pods that are operating at any given time.
Service registry
Another way to service discovery is to eliminate the LB component and implement service discovery on the client side through the use of a centralized service registry.
The service registry stores details about service endpoints to which clients can send requests.
When compared to a server-side method, the key advantage of a service registry is that there is one fewer component to manage (no LB) and no bottleneck.
A service registry, on the other hand, complicates client-side reasoning. The client must provide logic to maintain the registry up to current in order for it to contain the most up-to-date information about the backend pods/containers.
Kubernetes Service Discovery
Now that we’ve covered the basics of service discovery, let’s dive into the intricacies of Kubernetes service discovery.
Kubernetes service discovery for API-aware clients
An application deployment in Kubernetes consists of a pod or set of pods. These pods are ephemeral, which means their IP addresses and ports are continually changing. In the Kubernetes world, this continual change makes service discovery a huge difficulty.
Kubernetes’ endpoints API is one method it supports service discovery. Client applications can use the endpoints API to discover the IP addresses and ports of pods in an application.
In the following example, the Kubernetes control plane ETCD serves as a service registry, where all endpoints are registered and kept up to date by Kubernetes. A service mesh, for example, can incorporate logic to leverage an API for service discovery. Kubernetes’ native service discovery is responsible for this procedure.
Add pic here
The post Kubernetes Service Discovery appeared first on Cloud Training Program.