In the Kubernetes docs, in the Using Labels section it says:
A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. When you need to update a running service without downtime, use a Deployment.
I don’t understand how this can be achieved by a Deployment? When we want to update a service shouldn’t it happen separately (on its own), separate from any Deployments? Like:
kubectl apply -f service.yaml
>Solution :
A service points to a set of endpoints (pods) determined by its label selector.
let’s take an example of a service that has the label selector
app: api
version: v1
it will point to all pods that has these two labels (may have more)
if you deploy a new version, with label version: v2 the existing service will NOT point to these pods since the label selector no longer matches the pods labels
on the other hand, if you omit version: v1 from the label selector of the service and leave only app: api, the service will point to any pod that has the app: api label, meaning when you deploy a new version, even if the version label has a new value, the service will still point to these pods
this way you can update the service pods without updating the service itself – you can do that only by deploying your new api version.