Skip to main content
In this lesson, you’ll learn how Kubernetes implements stable service discovery for your applications. We’ll demonstrate two primary mechanisms:
  1. Environment Variables injected into pods at launch
  2. Cluster DNS names resolving service endpoints
Throughout this guide, we’ll use an nginx-service deployed in the default namespace as our example.

​
Service Overview

First, confirm that the nginx-service exists in the default namespace:
Expected output:

​
1. Environment Variable–Based Discovery

When a pod starts, the kubelet injects environment variables for each Service in the same namespace. Let’s verify this with a temporary pod:
Inside the pod shell, list variables related to nginx-service:
You should see:
Use these variables to curl the service:
You’ll receive the standard NGINX welcome page HTML.

​
1.1 Limitations Across Namespaces

Environment variables are only injected into pods in the same namespace as the Service.
To see this in action, launch a pod in the kube-system namespace:
No output appears, since nginx-service resides in default.

​
2. Cluster DNS–Based Discovery

Kubernetes also runs a DNS server (CoreDNS or kube-dns) that resolves Service names cluster-wide. Pods automatically get DNS settings in /etc/resolv.conf:
Typical output:

​
2.1 Verifying DNS Resolution

Install DNS utilities and lookup the Service FQDN:
Expected response:
You can curl using the full DNS name:

​
2.2 Shortened DNS Names

Since svc.cluster.local is in your search domains, you can use a shorter name:
Both will resolve to 10.103.206.194.

​
Comparison of Discovery Methods

​
Summary

  • Environment Variables
    Injected per namespace by the kubelet. Simple but limited to in-namespace communication.
  • Cluster DNS
    Provides cross-namespace, cluster-wide name resolution. Requires CoreDNS or kube-dns running.

Watch Video

Practice Lab