DEV Community

Dev Cookies
Dev Cookies

Posted on

🛰️ How Services Communicate in Kubernetes Using Namespaces and DNS

🚀 Introduction

In a Kubernetes cluster, microservices are often deployed as individual Pods and exposed via Services. For your application to work seamlessly, these services must communicate with each other reliably.

One of the most common questions developers and DevOps engineers ask is:

🧠 "How can services in the same Kubernetes cluster but different namespaces talk to each other?"

This blog will walk you through how Kubernetes service discovery works using DNS, and how to leverage namespaces and FQDN for seamless service-to-service communication.

📦 What Is a Kubernetes Service?

A Service in Kubernetes is an abstraction that defines a logical set of Pods and a policy by which to access them. Services enable loose coupling between dependent microservices.

🌐 Kubernetes DNS and Service Discovery

Kubernetes comes with a built-in DNS service (kube-dns or CoreDNS) that automatically creates DNS entries for Services and Pods. This allows services to talk to each other using names instead of IPs.

✅ Services get DNS names like:

<service-name>.<namespace>.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

This is called a Fully Qualified Domain Name (FQDN) in Kubernetes.

🧭 Service Communication Scenarios

Let's walk through different scenarios of service-to-service communication in Kubernetes:

🔸 1. Same Namespace Communication

If service-a and service-b are in the same namespace, they can communicate using just the service name:

http://service-b
Enter fullscreen mode Exit fullscreen mode

Kubernetes DNS resolves it automatically to the correct ClusterIP.

🔸 2. Cross-Namespace Communication

If service-a is in namespace team-a and wants to access service-b in namespace team-b, it should use the FQDN:

http://service-b.team-b.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

This tells Kubernetes to look for service-b in the team-b namespace.

✅ Shorter version (works too):

http://service-b.team-b
Enter fullscreen mode Exit fullscreen mode

🌍 DNS Hierarchy in Kubernetes

When resolving a service, Kubernetes DNS tries names in this order:

  1. service-name
  2. service-name.namespace
  3. service-name.namespace.svc
  4. service-name.namespace.svc.cluster.local

So, if you’re in namespace-a and want to reach service-x in namespace-b, you can use:

curl http://service-x.namespace-b
Enter fullscreen mode Exit fullscreen mode

Kubernetes will resolve it to the full FQDN internally.

📁 Real-World Example

Let’s assume you have the following setup:

  • Frontend service: frontend-service in namespace frontend
  • Backend service: backend-service in namespace backend

For frontend-service to call backend-service, the frontend code or config should use:

http://backend-service.backend.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

✅ Or just:

http://backend-service.backend
Enter fullscreen mode Exit fullscreen mode

🔐 Bonus: Security Consideration

You can apply NetworkPolicies to control which namespaces or services can talk to each other.

For example, to restrict frontend namespace to access only backend, you'd define a NetworkPolicy that allows ingress from frontend.

🛠️ Best Practices

✅ Good Practice 🚫 Bad Practice
Use DNS names for service discovery Hardcoding Pod IPs
Use FQDN across namespaces Skipping namespace leads to failure
Rely on Service objects, not Pods Talking directly to Pods can break scaling

📌 Summary

Scenario How to Reach the Service
Same namespace http://service-name
Different namespaces http://service-name.namespace or service-name.namespace.svc.cluster.local

🧪 Sample YAML for Testing 

# backend-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: backend-service
  namespace: backend
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
Enter fullscreen mode Exit fullscreen mode 
# frontend-deployment.yaml
# frontend can use ENV or curl to hit: http://backend-service.backend
Enter fullscreen mode Exit fullscreen mode

🧠 Final Thoughts

Using Kubernetes DNS and FQDNs makes service-to-service communication simple and powerful. It supports scaling, abstraction, and cross-namespace microservice architectures without manual IP management.

Next time you build a distributed system on Kubernetes, remember:

🧩 Use service-name.namespace — it just works.

📚 Related Reads

Top comments (0)