Kubernetes, an open-source platform for automating the deployment, scaling, and management of containerized applications, uses concepts like Pods, Services, and Endpoints to ensure that applications can communicate reliably and efficiently, even in dynamic environments. One of the key functionalities Kubernetes provides is service discovery. This article explores how Kubernetes pods discover each other within a cluster, which is vital for building scalable and reliable applications.

Kubernetes Networking Basics

Before diving into pod discovery, it's essential to understand Kubernetes's networking model. In Kubernetes, each Pod is assigned its own IP address, and Pods can communicate with each other across nodes without the need for network address translation (NAT). The Kubernetes networking model emphasizes simplicity and ensures that:

• All Pods can communicate with all other Pods in different nodes without NAT.
• All nodes can communicate with all Pods without NAT.
• The IP that a Pod sees for itself is the same IP that others see.

To support dynamic application deployments, Kubernetes employs two main methods for service discovery:

1. Environment Variables
2. DNS-based Service Discovery

Environment Variables

When a Pod is launched, Kubernetes can inject environment variables into it. These environment variables are defined based on the Services running in the cluster at the time of Pod creation. Each service gets environment variables with the ```<SERVICE_NAME>``_SERVICE_HOST` and ```<SERVICE_NAME>``_SERVICE_PORT`, which hold the Cluster IP and port of the service, respectively.

Example:
If a service named `myservice` has a Cluster IP of `10.3.240.203` and exposes port `80`, the corresponding environment variables might look like this:

• `MYSERVICE_SERVICE_HOST=10.3.240.203`
• `MYSERVICE_SERVICE_PORT=80`

However, this method has a limitation in dynamic scaling scenarios. If a service is updated or new services are added after a Pod's creation, the environment variables inside the existing Pods won't be updated.

DNS-based Service Discovery

The preferred and more dynamic method for service discovery in Kubernetes is DNS-based. Kubernetes includes an internal DNS server that automatically assigns DNS names to services. With DNS-based service discovery, you do not need to manage environment variables manually. Kubernetes automatically updates DNS records as you add or remove services or endpoints.

Example:
If you have a service named `frontend`, Kubernetes automatically registers it in the DNS with a record like `frontend.default.svc.cluster.local`. Pods within the same namespace (`default` in this case) can simply use `frontend` to resolve the IP address.

Cluster DNS

Kubernetes typically deploys an add-on like `CoreDNS` to handle cluster DNS. CoreDNS manages domain names and their corresponding IP addresses inside the Kubernetes cluster, offering not just simple DNS records but also capability for conditional forwarding and rewriting DNS entries.

Example of a DNS request in a Kubernetes cluster:

• ClusterIP: The default type, which exposes the service on a cluster-internal IP. Choosing this type makes the service only reachable from within the cluster.
• NodePort: Exposes the service on each Node's IP at a static port (the NodePort). A ClusterIP service, to which the NodePort service routes, is automatically created.
• LoadBalancer: Exposes the service externally using a cloud provider's load balancer. NodePort and ClusterIP services, to which the external load balancer routes, are automatically created.