DNS: The phonebook of the internet.

DNS: The phonebook of the internet.

Leader posted 3 min read

One‑line: DNS = the phonebook of the internet.

Two‑words: Name‑resolution.

Business analogy: Instead of memorizing everyone’s phone number, you look up their name in a directory — DNS is that directory for computers.

Mechanical definition (tight, clean)
DNS (Domain Name System) converts human‑friendly names into machine‑friendly IP addresses.

Examples:

google.com → 142.250.72.14
kafka.svc.cluster.local → the pod’s internal cluster IP
elasticsearch.default.svc.cluster.local → the StatefulSet’s service IP

You type the name → DNS returns the IP → your app connects.

Why it matters for Docker vs Kubernetes

Docker (single host)

Containers can cheat and use localhost
DNS barely matters because everything shares one machine

Kubernetes (multi‑node)

Pods move
IPs change
Nodes change
Restarts happen

So the only stable way to reach anything is through DNS names, not IPs or localhost.

Examples:

kafka:9092
zookeeper:2181
elasticsearch:9200

or in full cluster form:

kafka.svc.cluster.local:9092

The rule for distributed systems
If you can’t reach it by DNS, you don’t have a real distributed system yet.


One‑line: Here are the exact DNS names and the Docker‑side simulation.

Two‑words: Cluster realism.

Business analogy: Teach your app to use street addresses (DNS) even when it’s still living in your garage (Docker).

  1. Exact DNS Names for Kafka / ELK / MDM in Kubernetes
    These are the canonical, production‑safe names every pod should use.

Kafka

kafka.default.svc.cluster.local:9092

If using a dedicated namespace:

kafka.data.svc.cluster.local:9092

Zookeeper

zookeeper.default.svc.cluster.local:2181

Kafka Connect

connect.default.svc.cluster.local:8083

Elasticsearch

elasticsearch.default.svc.cluster.local:9200

If using a StatefulSet with headless service:

elasticsearch-0.elasticsearch.default.svc.cluster.local:9200

Kibana

kibana.default.svc.cluster.local:5601

MDM ETL Jobs
Jobs should reference Kafka and Elasticsearch via DNS:

kafka.default.svc.cluster.local:9092
elasticsearch.default.svc.cluster.local:9200
Bronze / Silver / Gold Storage
If using object storage:
minio.default.svc.cluster.local:9000
If using HDFS‑style:
namenode.default.svc.cluster.local:8020
2. How Docker Compose Can Simulate Kubernetes‑Style DNS
This is the trick that makes your local dev behave like a cluster.

Rule: Use service names, not localhost
Docker Compose automatically creates an internal DNS zone where each service name resolves like a Kubernetes Service.

Example docker‑compose.yml
yaml

services:

  kafka:
    image: confluentinc/cp-kafka
    ports:
      - "9092:9092"

  zookeeper:
    image: confluentinc/cp-zookeeper
    ports:
      - "2181:2181"

  connect:
    image: confluentinc/cp-kafka-connect
    depends_on:
      - kafka
      - zookeeper

Inside the network, these DNS names work:

kafka:9092
zookeeper:2181
connect:8083
elasticsearch:9200
kibana:5601

Exactly like Kubernetes:

kafka.default.svc.cluster.local:9092

3. The Golden Rule for Dev → CI/CD → Kubernetes

Never use localhost.
Always use service names.

Docker:

kafka:9092
elasticsearch:9200

Kubernetes:

kafka.default.svc.cluster.local:9092
elasticsearch.default.svc.cluster.local:9200

Your code never changes — only the environment does.


One‑line: Day zero.

Two‑words: DNS first.

Business analogy: If production uses street addresses, you don’t train your team on “my house, my room, my desk.”

Direct answer (tight, mechanical, architect‑grade)
Teams should switch to service‑style DNS from the very first local prototype, long before CI/CD or Kubernetes enter the picture.

Because the moment you allow localhost:9092 into the code path, you’ve already baked in a failure mode:

CI/CD → breaks

Multi‑node cluster → breaks

Sidecar networking → breaks

Jobs/CronJobs → break

Scaling → breaks

Canary deploys → break

Localhost is a lie in distributed systems.
It only works on a laptop because Docker Compose simulates a fake single‑machine universe.

The correct development sequence

1. Dev environment (Docker)

Use:

kafka:9092
elasticsearch:9200
zookeeper:2181

Never:

localhost:9092
127.0.0.1:9200

2. CI/CD

Use the same names:

kafka:9092
elasticsearch:9200

Your pipeline becomes cluster‑ready without changing a single line.

3. Kubernetes

DNS becomes:

kafka.svc.cluster.local:9092
elasticsearch.svc.cluster.local:9200
Same pattern, zero rewrites.

Why “DNS from day zero” is the only safe rule
Eliminates environment drift

Prevents pipeline failures

Makes ETL jobs portable

Avoids rewriting configs during migration

Forces distributed‑system thinking early

Protects MDM lineage and auditability

If you wait until Kubernetes to fix localhost assumptions, you’re already in trouble — because your entire pipeline has been trained to believe in a topology that doesn’t exist in production.

1 Comment

2 votes
1

More Posts

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelskiverified - Apr 23

The Audit Trail of Things: Using Hashgraph as a Digital Caliper for Provenance

Ken W. Algerverified - Apr 28

Docker‑to‑Kubernetes failure points: Where Docker Assumptions Break in Kubernetes

Dr. Usman Zafar - Feb 10

Merancang Backend Bisnis ISP: API Pelanggan, Paket Internet, Invoice, dan Tiket Support

Masbadar - Mar 13

The End of Data Export: Why the Cloud is a Compliance Trap

Pocket Portfolioverified - Apr 6
chevron_left

Related Jobs

View all jobs →

Commenters (This Week)

3 comments
1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!