<p>In the Kubernetes docs, in the <a href="https://kubernetes.io/docs/concepts/configuration/overview/#using-labels" rel="nofollow noreferrer">Using Labels</a> section it says:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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:</p>
<pre class="lang-sh prettyprint-override"><code>kubectl apply -f service.yaml

</code></pre>

<p>A service points to a set of endpoints (pods) determined by its label selector.</p>
<p>Let's take an example of a service that has the label selector</p>
<pre class="lang-yaml prettyprint-override"><code>app: api
version: v1
</code></pre>
<p>It will point to all pods that have these two labels (may have more).</p>
<p>If you deploy a new version, with label <code>version: v2</code> the existing service will NOT point to these pods since the label selector no longer matches the pods labels.</p>
<p>On the other hand, if you omit <code>version: v1</code> from the label selector of the service and leave only <code>app: api</code>, the service will point to any pod that has the <code>app: api</code> 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.</p>
<p>This way you can update the service pods without updating the service itself - you can do that only by deploying your new api version.</p>
