'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 |
