🚀 Using ClusterIP, NodePort, and LoadBalancer in a Real-World Kubernetes Application

📖 Overview

Kubernetes provides multiple ways to expose your applications running inside Pods. The most commonly used Service types are:

• ClusterIP – internal communication
• NodePort – external access via node IP and port
• LoadBalancer – production-grade public access via cloud load balancer

In this blog, we’ll build a real-world E-commerce Web App with:

1. Frontend (ReactJS) → exposed via LoadBalancer
2. Backend (Spring Boot or FastAPI) → exposed via NodePort
3. Database (MySQL) → exposed via ClusterIP

🧩 Application Architecture

+------------------+       +------------------+       +------------------+
|  React Frontend  | <---> |  Backend (API)   | <---> |     MySQL DB     |
| (LoadBalancer)   |       |  (NodePort)      |       |  (ClusterIP)     |
+------------------+       +------------------+       +------------------+
       ↑
  Public Internet

⚙️ 1. MySQL Service (ClusterIP)

🔹 Why ClusterIP?

We don’t want the database to be accessible from outside. It should be reachable only by internal Pods like the backend.

🧾 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:5.7
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: password
          ports:
            - containerPort: 3306

🧾 Service

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  type: ClusterIP
  selector:
    app: mysql
  ports:
    - port: 3306
      targetPort: 3306

⚙️ 2. Backend API Service (NodePort)

🔹 Why NodePort?

For non-production use or internal teams, we may want to access the backend using the node’s external IP and a fixed port.

🧾 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: backend
          image: mycompany/backend:latest
          ports:
            - containerPort: 8080
          env:
            - name: DB_HOST
              value: "mysql"

🧾 Service

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: NodePort
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

📌 Access via http://<NodeIP>:30080

⚙️ 3. Frontend Service (LoadBalancer)

🔹 Why LoadBalancer?

This service needs to be accessed publicly by customers, so we use LoadBalancer to provision a cloud load balancer.

🧾 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: frontend
          image: mycompany/frontend:latest
          ports:
            - containerPort: 80

🧾 Service

apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  type: LoadBalancer
  selector:
    app: frontend
  ports:
    - port: 80
      targetPort: 80

☁️ Cloud providers like AWS, GCP, and Azure will assign a public IP to this service.

🔄 Application Flow

+---------------------------+
|    Public Internet        |
+------------+-------------+
             ↓
     [LoadBalancer Service]
             ↓
       [Frontend Pod]
             ↓
     [NodePort to Backend]
             ↓
     [ClusterIP to MySQL]

📌 Summary Table

✅ Best Practices

• Use ClusterIP for internal-only services (e.g., DBs, caches).
• Use NodePort sparingly—only for development, testing, or where cloud load balancer isn’t an option.
• Use LoadBalancer in production for services needing public access.
• Use Ingress Controllers and domain routing when dealing with multiple LoadBalancer services.
• Add liveness and readiness probes for all deployments.
• Parameterize all ports, replicas, and resource limits using Helm charts for reusability.

📦 Bonus: Ingress Alternative

If you want to expose multiple services under one domain, consider using an Ingress Controller instead of multiple LoadBalancers.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
spec:
  rules:
    - host: frontend.mysite.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 80

🎯 Conclusion

Understanding and using the right Kubernetes Service type is key to building scalable, secure, and manageable cloud-native apps.

Most tech companies — especially those building secure, scalable, cloud-native applications — follow this common architecture pattern when using Kubernetes:

✅ Industry-Standard Approach (Used by Most Tech Companies)

🔐 Backend = ClusterIP

• Not exposed to the public
• Only accessible internally by the frontend
• Protects business logic and APIs from direct attack
• Communication via internal DNS (e.g., http://backend:8080)

🌐 Frontend = LoadBalancer or Ingress

• Exposed to the public Internet
• Acts as the only entry point to the system
• Sends requests to backend over internal network

🗄️ Database = ClusterIP

• Always kept internal
• Accessed only by backend

🧠 Why This Architecture Is Preferred

🏢 Real-World Examples

🧾 Optional: Using an Ingress Controller

Most companies also place an Ingress controller (like NGINX, Traefik, or Istio Gateway) in front of the frontend to manage:

• SSL termination
• URL path routing
• Rate limiting
• Authentication

🔐 Pro Tip: Zero Trust Model

Larger orgs go a step further with:

• mTLS between services
• Network Policies to restrict pod communication
• Service Mesh (like Istio or Linkerd) for traffic control, observability, and security

✅ TL;DR: What Most Tech Companies Use

Would you like a production-grade setup with Helm, Ingress, TLS, and best practices bundled into one YAML or chart?