Day #20 - Service Discovery - Connecting services within the cluster

Service discovery in Kubernetes is a mechanism that allows applications to find and communicate with each other without needing to hard code IP addresses or endpoint configuration.

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.

What is Service Discovery?

Service discovery is a mechanism by which services discover each other dynamically without the need for hard coding IP addresses or endpoint configuration.

In modern cloud-native infrastructure such as Kubernetes, applications are designed using microservices. The different components need to communicate within a microservices architecture for applications to function, but individual IP addresses and endpoints change dynamically.

As a result, there is a need for service discovery so services can automatically discover each other.

Key Components of Service Discovery

Kubernetes provides built-in support for service discovery through the use of Services and DNS.

When a service is created, Kubernetes assigns it a stable DNS name and a virtual IP address (ClusterIP). This allows workloads to connect to the service using either its DNS name or IP address, even if the underlying pods' IPs change.

1. Services: Abstract a set of pods and provide a single point of access.Example types:ClusterIP: Internal access within the cluster.NodePort: Exposes the service on a static port on each node.LoadBalancer: Exposes the service externally using a cloud provider's load balancer.
2. Kube-DNS/ CoreDNS: Kubernetes automatically creates DNS records for services.Example: A service named my-service in the namespace default can be resolved as my-service.default.svc.cluster.local.
3. Endpoints: Tracks the IPs of the pods backing a service. Kubernetes automatically updates these endpoints as pods come and go.

How service discovery works in Kubernetes:

There are two different ways of Service discovery in Kubernetes:

? A.) for API-aware clients

An application deployment consists of set of pods. These pods are ephemeral, which means their IP addresses and ports are continually changing. In the Kubernetes, this 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.

The Kubernetes control plane ETCD serves as a service registry, where all endpoints are registered and kept up to date by Kubernetes.

? B.) Client having no API support:

Not all clients support APIs, Kubernetes supports service discovery in other methods also.

A Kubernetes service object is a persistent endpoint that points to a collection of pods depending on label selectors. It uses labels and selectors to route requests to the backend pods.

Because pods can come and leave dynamically in Kubernetes, a service object ensures that the endpoint or IP address that points to the list of operating pods never changes. If numerous pods are operating in the same application, the requests are also load-balanced across a group of pods.

Clients can utilize the Kubernetes service’s DNS name. Kubernetes’ internal DNS manages service mapping.

The usage of DNS for name-to-IP mapping is optional, and Kubernetes can do so with environment variables. The fundamental implementation of Kubernetes Service is handled by a kube-proxy instance running on each worker node.

Things to Consider

• Automatically generated service names: Kubernetes automatically generates service names that map to the Service's IP address.
• DNS configuration: Kubernetes modifies the DNS configuration of containers running on a Kubernetes node.?
• Local DNS resolver: When an application looks up a domain name, the local DNS resolver will first try to resolve the name in the local cluster.?
• Kube-proxy: A kube-proxy instance running on each worker node handles the underlying implementation of Kubernetes Service.
• Service manifest: Internal or external clients invoke a service with the help of a service manifest that contains selectors.?
• Pods: Any Pod whose label matches the required selector is discovered and allocated by the service.

Service discovery in Kubernetes makes it easier to manage, scale, and maintain applications.

Is it Possible to Connect Services Within the Cluster?

Yes, Kubernetes makes it straightforward to connect services within the cluster. Here’s how:

1. Using DNS Name: Services are assigned a DNS name by default, which can be used for inter-service communication. Example: A frontend service can communicate with a backend service by its name, like backend-service.default.svc.cluster.local.
2. Using ClusterIP: Services expose a stable IP address within the cluster that other services can use to connect.
3. Headless Services: For direct pod-to-pod communication (without a virtual IP), you can use headless services (spec.clusterIP: None). Pods discover each other using DNS SRV records.
4. Environment Variables: Kubernetes injects environment variables containing service-related information into pods at runtime. Example: SERVICE_HOST and SERVICE_PORT.
5. Network Policies: Kubernetes Network Policies control which services can communicate with each other, providing fine-grained access control.