Ingress vs LoadBalancer Service decision in Kubernetes - Hands-On Comparison

Ingress vs LoadBalancer Service Decision in Kubernetes

📖 Scenario: You are managing a Kubernetes cluster for a small company. You need to expose your web application to users outside the cluster. You want to decide whether to use an Ingress resource or a LoadBalancer service type to route external traffic to your application.

🎯 Goal: Build a simple Kubernetes configuration to understand the difference between using an Ingress and a LoadBalancer service. You will create a basic service and deployment, then add either a LoadBalancer service or an Ingress resource to expose the app externally. This will help you learn when to choose each option.

📋 What You'll Learn

Create a deployment named webapp with one replica running the nginx image

Create a service named webapp-service exposing port 80

Add a LoadBalancer service type to expose the app externally

Add an Ingress resource to route traffic to the service

Understand the difference in configuration and usage between LoadBalancer and Ingress

💡 Why This Matters

🌍 Real World

In real Kubernetes clusters, exposing applications to users outside the cluster is common. Choosing between LoadBalancer services and Ingress resources affects cost, flexibility, and features.

💼 Career

DevOps engineers and cloud administrators must understand how to expose services securely and efficiently. Knowing when to use LoadBalancer or Ingress is essential for managing Kubernetes networking.

1

Create a Deployment for the web application

Create a Kubernetes deployment named webapp with one replica running the nginx image. Use port 80 in the container spec.

Kubernetes

# Create a deployment named webapp with 1 replica running nginx on port 80
# Your code here

Hint

Use kind: Deployment and set replicas: 1. The container should use the nginx image and expose port 80.

2

Create a Service to expose the Deployment internally

Create a Kubernetes service named webapp-service that selects pods with label app: webapp. Expose port 80 and target port 80. Use service type ClusterIP.

Kubernetes

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

# Create a ClusterIP service named webapp-service exposing port 80
# Your code here

Hint

Use kind: Service with type: ClusterIP. Match pods with label app: webapp. Expose port 80.

3

Change the Service type to LoadBalancer to expose externally

Modify the webapp-service service to use type: LoadBalancer instead of ClusterIP. Keep all other settings the same.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  # Change service type to LoadBalancer below
  # Your code here

Hint

Change the type field in the service spec to LoadBalancer to expose the service externally.

4

Create an Ingress resource to route traffic to the Service

Create a Kubernetes Ingress resource named webapp-ingress that routes HTTP traffic from host example.com to the webapp-service on port 80. Use the nginx ingress class.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer

# Create an Ingress named webapp-ingress routing host example.com to webapp-service port 80
# Use nginx ingress class
# Your code here

Hint

Use kind: Ingress with annotation kubernetes.io/ingress.class: nginx. Route host example.com to service webapp-service on port 80.

Practice

1. Which Kubernetes service type should you choose if you want to expose a single application with its own external IP address?

easy

A. LoadBalancer Service

B. Ingress Controller

C. ClusterIP Service

D. NodePort Service

Solution

1. Step 1: Understand service types

   LoadBalancer Service exposes an app with its own external IP, making it directly accessible.

2. Step 2: Compare with Ingress

   Ingress routes multiple apps through one IP, so it's not for single app direct exposure.

3. Final Answer:

   LoadBalancer Service -> Option A

4. Quick Check:

   Single app direct IP = LoadBalancer Service [OK]

Hint: Single app direct IP? Use LoadBalancer Service [OK]

Common Mistakes:

• Confusing Ingress with LoadBalancer for single app
• Choosing ClusterIP which is internal only
• Selecting NodePort which exposes on node ports, not external IP

2. Which of the following is the correct way to define a LoadBalancer service in a Kubernetes YAML manifest?

easy

A. apiVersion: networking.k8s.io/v1\nkind: LoadBalancer\nmetadata:\n name: my-service\nspec:\n selector:\n app: my-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080

B. apiVersion: v1\nkind: Service\nmetadata:\n name: my-service\nspec:\n type: Ingress\n selector:\n app: my-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080

C. apiVersion: v1\nkind: Service\nmetadata:\n name: my-service\nspec:\n type: NodePort\n selector:\n app: my-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080

D. apiVersion: v1\nkind: Service\nmetadata:\n name: my-service\nspec:\n type: LoadBalancer\n selector:\n app: my-app\n ports:\n - protocol: TCP\n port: 80\n targetPort: 8080

Solution

1. Step 1: Check apiVersion and kind

   Service resources use apiVersion: v1 and kind: Service.

2. Step 2: Confirm service type

   LoadBalancer type is set under spec.type to expose external IP.

3. Final Answer:

   YAML with kind Service and type LoadBalancer -> Option D

4. Quick Check:

   LoadBalancer service YAML uses kind Service and type LoadBalancer [OK]

Hint: LoadBalancer service uses kind Service and type LoadBalancer [OK]

Common Mistakes:

• Using kind LoadBalancer instead of Service
• Setting type to Ingress which is invalid for Service
• Confusing NodePort with LoadBalancer

3. Given this scenario: You have two apps, app1 and app2, and want to expose both externally using one IP with different paths. Which Kubernetes resource will handle this correctly?

medium

A. Two LoadBalancer Services, one for each app

B. One Ingress resource with path rules for app1 and app2

C. Two NodePort Services with different ports

D. One ClusterIP Service with multiple selectors

Solution

1. Step 1: Understand routing multiple apps on one IP

   Ingress allows routing multiple apps through one IP using path or hostname rules.

2. Step 2: Compare with LoadBalancer and others

   LoadBalancer exposes one app per IP; NodePort uses node ports, not one IP; ClusterIP is internal only.

3. Final Answer:

   One Ingress resource with path rules -> Option B

4. Quick Check:

   Multiple apps, one IP = Ingress with path rules [OK]

Hint: Multiple apps, one IP? Use Ingress with paths [OK]

Common Mistakes:

• Using multiple LoadBalancers wasting IPs
• Choosing NodePort which needs manual port management
• Thinking ClusterIP exposes externally

4. You created a LoadBalancer service but it never gets an external IP assigned. What is the most likely cause?

medium

A. You forgot to set spec.type to ClusterIP

B. Ingress controller is missing

C. Your Kubernetes cluster is running on a platform without LoadBalancer support

D. You used NodePort instead of LoadBalancer

Solution

1. Step 1: Check platform support for LoadBalancer

   Some clusters (like bare metal) do not support automatic external IP assignment for LoadBalancer services.

2. Step 2: Verify service type and controller

   Spec.type must be LoadBalancer, not ClusterIP; Ingress controller is unrelated; NodePort is different service type.

3. Final Answer:

   Platform lacks LoadBalancer support -> Option C

4. Quick Check:

   No external IP = platform lacks LoadBalancer support [OK]

Hint: No external IP? Check platform LoadBalancer support [OK]

Common Mistakes:

• Confusing ClusterIP with LoadBalancer type
• Assuming Ingress controller assigns LoadBalancer IP
• Mixing NodePort with LoadBalancer service

5. You want to minimize cloud costs while exposing 5 different apps externally. Which approach is best?

hard

A. Use one Ingress resource to route all 5 apps through a single LoadBalancer IP

B. Use ClusterIP services and expose each with a separate external IP

C. Use 5 NodePort services and expose nodes directly

D. Create 5 LoadBalancer services, one per app

Solution

1. Step 1: Understand cost implications of LoadBalancer IPs

   Each LoadBalancer service usually gets a separate external IP, increasing cloud costs.

2. Step 2: Use Ingress for cost efficiency

   Ingress lets multiple apps share one external IP with routing rules, saving costs.

3. Final Answer:

   One Ingress resource with single LoadBalancer IP -> Option A

4. Quick Check:

   Multiple apps, minimize cost = Ingress with one LoadBalancer IP [OK]

Hint: Multiple apps, one IP saves cost: use Ingress [OK]

Common Mistakes:

• Creating multiple LoadBalancers wasting IPs and money
• Using NodePort exposes nodes, less secure and complex
• ClusterIP cannot expose apps externally