Ingress vs LoadBalancer Service decision in Kubernetes - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

When to use Ingress over LoadBalancer Service?

You have a Kubernetes cluster hosting multiple web applications. You want to expose them externally with a single IP address and route traffic based on URL paths. Which option best explains when to use an Ingress instead of a LoadBalancer Service?

A Use LoadBalancer Service when you want to route traffic based on URL paths.

B Use LoadBalancer Service to expose multiple services under a single IP address.

C Use Ingress when you need a dedicated external IP per service without routing rules.

D Use Ingress when you want to expose multiple services under one IP with path-based routing.

💡 Hint

Think about how many IP addresses you want to manage and if you need routing rules.

Ingress allows exposing multiple services through one IP with routing rules like URL paths or hostnames. LoadBalancer Service creates a separate external IP per service without routing.

💻 Command Output

intermediate

Output of kubectl get svc with LoadBalancer type

You run kubectl get svc on a service defined as type LoadBalancer. What output will you see in the EXTERNAL-IP column once the cloud provider assigns an IP?

Kubernetes

kubectl get svc my-service

A

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
my-service   LoadBalancer   10.0.0.1        <pending>        80:30080/TCP  5m

B

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
my-service   LoadBalancer   10.0.0.1        34.68.123.45     80:30080/TCP  5m

C

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
my-service   ClusterIP      10.0.0.1        <none>           80:30080/TCP  5m

D

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
my-service   NodePort       10.0.0.1        <none>           80:30080/TCP  5m

💡 Hint

Check the service type and what EXTERNAL-IP shows when assigned.

A LoadBalancer service gets an external IP from the cloud provider, shown in the EXTERNAL-IP column. Before assignment, it shows <pending>.

🔀 Workflow

advanced

Steps to expose multiple services with one external IP using Ingress

Arrange the steps in the correct order to expose multiple Kubernetes services externally using a single IP with Ingress.

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 2,3,1,4

💡 Hint

Think about creating services first, then the controller, then the rules.

You first create services, then deploy the Ingress controller, define Ingress rules, and finally access apps via the Ingress IP.

❓ Troubleshoot

advanced

Why is my LoadBalancer service stuck in <pending> state?

You created a LoadBalancer service in your Kubernetes cluster on a cloud provider, but the EXTERNAL-IP remains <pending> indefinitely. What is the most likely cause?

A The cloud provider does not support automatic external IP provisioning for LoadBalancer services.

B The service selector labels do not match any pods.

C The Ingress controller is not deployed.

D The service type should be ClusterIP instead of LoadBalancer.

💡 Hint

Consider cloud provider support for LoadBalancer services.

If the cloud provider does not support LoadBalancer type services, Kubernetes cannot provision an external IP, so it stays <pending>.

✅ Best Practice

expert

Choosing between Ingress and LoadBalancer for cost and scalability

You manage a Kubernetes cluster on a cloud provider with limited IP addresses and want to minimize costs while exposing many services externally. Which approach is best?

A Deploy multiple Ingress controllers, each with its own external IP.

B Create a LoadBalancer service for each application to isolate traffic and IPs.

C Use one Ingress controller with multiple Ingress resources to share a single external IP.

D Use NodePort services and expose nodes directly to save IPs.

💡 Hint

Think about IP address usage and cost efficiency.

Using one Ingress controller with multiple Ingress resources allows sharing a single external IP, reducing IP usage and cost while supporting many services.