The kinds of Service

ClusterIP, NodePort, LoadBalancer.

Services come in a few types, and the difference is simply who needs to reach your app: only other things inside the cluster, or people out on the internet. Picking the right type — ClusterIP, NodePort, or LoadBalancer — is mostly about internal versus external access.

ClusterIP, NodePort, LoadBalancer

ClusterIP is the default and the most common: it gives your Service a stable address reachable only from inside the cluster — perfect for internal communication, like your web app talking to its backend API or database. Most Services are ClusterIP. NodePort opens a specific port on every node so the Service can be reached from outside using a node’s address and that port — a simple way to expose something externally, though the high port numbers and per-node access make it crude for real use. LoadBalancer asks your cloud provider to create an external load balancer with its own public address pointing at the Service — the standard way to expose an app to the internet when running on a cloud. So the mental ladder is: ClusterIP for internal-only (the default and most frequent), LoadBalancer for public access on a cloud, and NodePort as a basic exposure option often used in learning or bare-metal setups.

spec:
  type: ClusterIP        # DEFAULT — internal only (most Services)
  # type: NodePort       # opens a port on every node — basic external access
  # type: LoadBalancer   # cloud provisions a public load balancer — standard external
  selector: { app: hello }
  ports: [{ port: 80, targetPort: 8080 }]
 
kubectl get svc          # EXTERNAL-IP: <none> for ClusterIP; an address for LoadBalancer

How you really expose web apps

There is an important practical wrinkle: giving every public web service its own LoadBalancer gets expensive and clumsy, because each one is a separate cloud load balancer. So for HTTP/HTTPS apps, the usual pattern is to keep your Services as internal ClusterIP and put a single Ingress in front of them (the next lesson) — one entry point that routes to many internal Services by hostname and path, and handles TLS. That way you pay for and manage one front door instead of dozens. There is also a fourth flavor worth knowing by name: a "headless" Service (for cases where clients need to reach individual pods directly, used by things like databases), which you will meet later. But for fundamentals, the decision is refreshingly simple: default to ClusterIP for anything internal; use LoadBalancer (or, more often, an Ingress in front of ClusterIP Services) to reach the internet. Choosing the type is really just answering "who needs to connect to this?" — and most of the time the answer is "only other things in the cluster", which means ClusterIP.