We have seen pods come and go. And we can’t rely on their names (or IP addresses) to be stable. You have probably noticed that when we run port-forward, we always need to make sure that we have the correct pod name, as they will change. For example, this is important when we scale a Deployment up and down.

Let’s first clarify some of the problems we have with our current setup:

We are using port-forward to redirect traffic from our local machine to a pod, so a user that doesn’t have access to our Kubernetes cluster is not able to access this application.

If we have more than one application running in the cluster, they don’t have a reliable way to talk to each other. We could hardcode the pod IP address to be able to reach it, but as the pod is re-created, the IP will change and that will stop working.

We are always sending requests to a single pod, even if we have a Deployment that is creating several replicas for us. If we have 10 replicas of our application running, it is only logical that we would want requests to be distributed across all of these pods instead of going to one pod while the others are idle.

A Service is another Kubernetes resource that lets us provide a stable endpoint for our pods. It’s something that sits in front of the pods and takes care of receiving requests and delivering them to all the pods that are behind it.