Minimal objects to expose a stateless app

WHAT THIS TESTS This checks whether you can translate a plain requirement into the right minimal Kubernetes objects and explain each one's purpose.

A GOOD ANSWER COVERS For a stateless web server you need two things. A Deployment runs the Pods, maintains the desired replica count, and recreates Pods that die or get rescheduled, so you never manage Pods directly. A Service gives those Pods a single stable endpoint and load-balances traffic across them, which matters because Pod IPs are ephemeral and change on restart. To make it reachable from outside the cluster, choose the Service type: LoadBalancer provisions an external load balancer on a cloud provider, NodePort opens a port on every node for simpler or on-prem setups, and for HTTP you often add an Ingress plus an ingress controller to route by host or path over a single external address. A StatefulSet is unnecessary because there is no persistent per-Pod identity or storage.

COMMON WRONG ANSWERS Exposing a single bare Pod and pointing clients at its IP. Using a StatefulSet for a stateless workload. Forgetting the Service and trying to reach Pods directly. Assuming ClusterIP is externally reachable.

LIKELY FOLLOW-UPS What is the difference between ClusterIP, NodePort, and LoadBalancer? Why not use a Pod IP directly? When do you add an Ingress? How does the Service find its Pods?

ONE CONCRETE EXAMPLE You create a Deployment with three replicas of the web image. You create a Service of type LoadBalancer with a selector matching the Deployment's Pod labels; the cloud provisions an external IP that forwards to the Pods and load-balances across them. If a Pod crashes, the Deployment replaces it and the Service automatically routes only to healthy endpoints, all without clients ever knowing individual Pod IPs.