Skip to content

Quiz: Kubernetes Services & Ingress

← Back to quiz index

7 questions

L1 (4 questions)

1. How does a Kubernetes Service route traffic to pods?

Show answer Service selector matches pod labels. kube-proxy maintains iptables/IPVS rules that NAT traffic to pod IPs. If selector doesn't match pod labels, no endpoints = no traffic.

2. You create a ClusterIP Service but pods cannot reach it. kubectl get endpoints shows no endpoints. What are the most likely causes?

Show answer 1. Label selector mismatch between Service and Pod.
2. Pods are not in Ready state (failed readiness probe).
3. Pods are in a different namespace than the Service (and selector does not cross namespaces).
4. No pods matching the selector exist at all. Check: kubectl describe svc for selector, kubectl get pods -l to verify matches. *Common mistake:* The Service needs a LoadBalancer type to work — ClusterIP is the default and works for in-cluster communication.

3. What is the difference between a NodePort, ClusterIP, and LoadBalancer Service type, and when would you use each?

Show answer ClusterIP (default): internal-only, reachable within the cluster. NodePort: exposes on a static port (30000-32767) on every node — useful for on-prem without a cloud LB. LoadBalancer: provisions an external cloud load balancer that routes to NodePorts. Use ClusterIP for internal services, LoadBalancer for production external traffic, NodePort for dev/on-prem. *Common mistake:* ExternalName is the type for external traffic — ExternalName is actually a DNS CNAME alias, not a load-balancing mechanism.

4. How does kube-proxy implement ClusterIP Services using iptables mode?

Show answer kube-proxy creates iptables rules that DNAT (destination NAT) traffic sent to the ClusterIP:port to one of the backend pod IPs. It uses probability-based rules for load distribution (each endpoint gets 1/N probability). Rules are in the nat table, KUBE-SERVICES and KUBE-SVC-* chains. Changes to endpoints trigger iptables rule regeneration. *Common mistake:* kube-proxy runs as a reverse proxy accepting connections — that is the legacy userspace mode, not the default iptables mode.

L2 (3 questions)

1. You are running an Ingress controller and notice 502 errors during pod rolling updates. What is happening and how do you fix it?

Show answer The Ingress controller routes to pods that are terminating but still in the endpoints list. Fix:
1. Add a preStop hook with sleep (5-10s) to give the endpoints controller time to deregister the pod.
2. Ensure readiness probes fail fast on shutdown.
3. Set terminationGracePeriodSeconds high enough for in-flight requests to drain. *Common mistake:* Increase the Ingress controller replica count — more replicas do not solve the pod deregistration race.

2. What is the difference between Ingress and Gateway API in Kubernetes, and why was Gateway API created?

Show answer Ingress is a simple L7 routing resource (host/path → Service) but lacks standardized support for TCP/UDP, header-based routing, traffic splitting, and multi-tenancy. Gateway API introduces separate resources (Gateway, HTTPRoute, GRPCRoute) with role-based ownership (infra admin manages Gateway, app teams manage Routes). It is more expressive and portable across implementations. *Common mistake:* Gateway API replaces Services entirely — it only replaces Ingress resources; Services still exist for L4 routing.

3. When should you use headless Services (clusterIP: None) instead of regular ClusterIP Services?

Show answer Use headless Services when clients need to discover individual pod IPs (e.g., StatefulSets with stable DNS names, databases needing direct connections). DNS returns A records for each pod instead of one virtual IP. Headless Services are also used by StatefulSet for stable pod DNS ({pod}.{svc}.{ns}.svc.cluster.local) and by clients implementing their own load balancing. *Common mistake:* Headless Services skip kube-proxy entirely for better performance — the primary purpose is DNS-based pod discovery, not performance.