How do the UI, backend, and database pods talk to each other? Why do we need Services? And what role does Ingress play?

To answer these questions, I built a small three-tier demo app:

• A UI pod (frontend)

• A Business Service (BS) pod (backend API)

• A Database (Postgres) pod (storage)

The goal was simple → make them talk to each other inside Minikube, and expose the UI through an Ingress so I can open it in my browser.

This blog is my step-by-step journey, written in beginner-friendly language.

🛠 Prerequisites

I used Ubuntu WSL with Minikube. The setup steps:

# Start Minikube
minikube start --cpus=4 --memory=6g --driver=docker

# Enable ingress controller
minikube addons enable ingress

# Create namespace for this demo
kubectl create ns demo

🎨 UI Component

This is the frontend web app that users see.

ConfigMap (ui-configmap.yaml)

Stores the backend API URL:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ui-config
data:
  API_URL: "http://bs:5000"

👉 UI and BS are connected via environment URLs to make API requests.

Deployment (ui-deployment.yaml)

Runs the UI container:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ui
  template:
    metadata:
      labels:
        app: ui
    spec:
      containers:
      - name: ui
        image: ghcr.io/benc-uk/k8s-demo-ui:latest
        ports:
        - containerPort: 80
        envFrom:
        - configMapRef:
            name: ui-config

The image already has the code and listens on port 80 (default HTTP).

Service (ui-service.yaml)

Creates a stable DNS name:

apiVersion: v1
kind: Service
metadata:
  name: ui
spec:
  selector:
    app: ui
  ports:
  - port: 80
    targetPort: 80

👉 Pods have changing IPs. A Service acts like a permanent contact number (DNS) that always points to the right pod.

⚙️ Business Service (BS)

This is the backend API that the UI calls.

ConfigMap (bs-configmap.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: bs-config
data:
  DB_HOST: "db"
  DB_PORT: "5432"
  DB_NAME: "postgres"
  DB_USER: "postgres"
  DB_PASS: "postgres"

👉 BS uses DB connection details via environment variables.

Deployment (bs-deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bs
  template:
    metadata:
      labels:
        app: bs
    spec:
      containers:
      - name: bs
        image: ghcr.io/benc-uk/k8s-demo-api:latest
        ports:
        - containerPort: 5000
        envFrom:
        - configMapRef:
            name: bs-config

👉 Port 5000 is the BS app’s listening port.

Service (bs-service.yaml)

apiVersion: v1
kind: Service
metadata:
  name: bs
spec:
  selector:
    app: bs
  ports:
  - port: 5000
    targetPort: 5000

Now the UI can call http://bs:5000/api/... reliably.

🗄 Database (Postgres)

The storage layer of the app.

Deployment (db-deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db
spec:
  replicas: 1
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
      - name: db
        image: postgres:15
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_PASSWORD
          value: postgres
        volumeMounts:
        - name: db-data
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: db-data
        persistentVolumeClaim:
          claimName: db-pvc

👉 5432 is the default PostgreSQL port.
👉 /var/lib/postgresql/data is Postgres’s default data directory (set by the official image).

PVC (db-pvc.yaml)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard

👉 PVC is just a YAML request; Kubernetes binds it to a PV (the real disk).

Now the DB data survives pod restarts ✅

Service (db-service.yaml)

apiVersion: v1
kind: Service
metadata:
  name: db
spec:
  selector:
    app: db
  ports:
  - port: 5432
    targetPort: 5432

The BS connects to db:5432.

🌐 Ingress (ingress.yaml)

Finally, I needed a way to reach the UI from my browser.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
spec:
  rules:
  - host: app.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: ui
            port:
              number: 80

👉 Ingress is like a receptionist — it decides which internal Service should handle your request from outside.

🔄 End-to-End Flow

When I open http://app.local:8080, here’s what happens:

1. Browser → request goes to 127.0.0.1:8080 with Host app.local.

2. Port-forward → tunnels to Ingress Service inside Minikube.

3. Ingress Controller (NGINX) sees host app.local, matches rule → sends to UI Service.

4. UI Service → forwards to UI Pod.

5. UI Pod → frontend makes API call /api/health.

6. Ingress → forwards to BS Service.

7. BS Service → forwards to BS Pod.

8. BS Pod → connects to DB Service (db:5432).

9. DB Pod → returns data → BS → UI → Browser.

✅ All three tiers are talking inside Kubernetes.

📊 Diagram

This picture helped me the most to understand the flow:

📌 Key Takeaways

• Pods are temporary → use Services for stable connectivity.

• ConfigMaps → inject configs like API_URL or DB_HOST.

• Postgres defaults → port 5432, data at /var/lib/postgresql/data.

• PVCs → make DB data persistent across restarts.

• Ingress → routes external requests into cluster, like a receptionist.

🎯 Conclusion

This small hands-on activity cleared up a lot of my confusion as a fresher in DevOps.
Now I understand how UI, backend, and DB pods communicate inside Kubernetes, and how an Ingress routes external requests.

Next, I want to try writing Helm charts for these manifests and then explore ArgoCD GitOps.

If you’re also learning Kubernetes — I recommend setting up this three-tier demo. It’s the best way to actually see networking in action.