So let's say there are two pods. Right now, I'm accessing through port-forwarding a specific pod. If this pod dies, the link here will be broken, and I won't be able to access this pod anymore, which is where Kubernetes services come in. So instead of port-forwarding, we will deploy a Kubernetes service, which is all within our deployment. So there is our deployment, and a Kubernetes service will specify how we can connect to our deployments. And in that case, if one of these pods dies and a new pod has spun up, I will be automatically routed and forwarded to the other pod. If that pod dies, and then, at this point, the other one has hopefully spun up again, it will route me back to the other pod that's alive.
If both pods are alive, I will be routed to any pods or the pod with the least traffic, but that's an additional configuration that we don't have in place right now. So a Kubernetes service allows us to connect dynamically to the different pods. Now, let's assume we have our front end, and the front end has three different pods. Then we have our backends. The backend might also run several different pods, as in this case. So all the same pods, and then we have our database.
Now, these are all different pods with different endpoints. So once we spin up a new pod, it's assigned an endpoint, a pod endpoint, like an IP address of 0.1, and then the next one will have 0.2. So they all have different endpoints.
Now, if the pod dies, a new pod with a new endpoint is spun up, and this endpoint will be different. So we cannot assign the backend to talk to this endpoint directly because it will always change. That wouldn't work. It would break our flow. It would be tightly coupled between those different pods and endpoints, and we do not want that.
So what we do instead is spin up services between those different sections of our application, let's say. So we have here one service, and then we have here service for our front end, we have a service for our database. In this case, the service will be assigned a specific endpoint or a label to it. So we can tell the back end that this is the service that always has to communicate with the front end. And this is the service that the backend always has to communicate with the database. So we don't care anymore about the specific pods that are running. But instead, we care about the different services attached to the deployment.
So, there are separate deployments for the front-end, backend, and database in this case. So usually, for each deployment, you will have a specific service. This service allows you to communicate with your deployment, different pods within your deployment that are independent of the endpoints attached to your specific pods or independent of which node they're running in, and so on.