Minimal objects to expose a stateless app

What's really being asked

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

The full answer

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.

The mistakes people make

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.

What usually comes next

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?

A 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.