'How a shared service can be updated by a deployment?

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 1:[1]

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

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 anarxz