Updating Multiple Objects

The use of selector labels#

Even though most of the time we send requests to specific objects, almost everything is happening using selector labels. When we updated the Deployments, they looked for matching selectors to choose which ReplicaSets to create and scale. They, in turn, created or terminated Pods also using the matching selectors.

Almost everything in Kubernetes is operated using label selectors. It’s just that sometimes that is obscured from us.

We do not have to update an object only by specifying its name or the YAML file where its definition resides. We can also use labels to decide which object should be updated. That opens some interesting possibilities since the selectors might match multiple objects.

Defining the deployment#

Imagine that we are running several Deployments with Mongo databases and that the time has come to update them all to a newer release. Before we explore how we could do that, we’ll create another Deployment so that we have at least two with the database Pods.

Let us first take a look at the definition of different-app-db.

When compared with the go-demo-2-db Deployment, the only difference is in the service label. Both have the type set to db.

Creating the deployment#

Let’s create the deployment.

Now that we have two deployments with the mongo:3.3 Pods, we can try to update them both at the same time.

The trick is to find a label (or a set of labels) that uniquely identifies all the Deployments we want to update.

Let’s take a look at the list of Deployments with their labels.

The output is as follows.

We want to update mongo Pods created using different-app-db and go-demo-2-db Deployments. Both are uniquely identified with the labels type=db and vendor=MongoLabs. Let’s test that.

The output is as follows.

Updating the deployments#

We can see that filtering with those two labels worked. We retrieved only the Deployments we want to update, so let’s proceed and roll out the new release.

The output is as follows.

Finally, before we move into the next subject, we should validate that the image indeed changed to mongo:3.4.

The output, limited to the relevant parts, is as follows.

As we can see, the update was indeed successful, at least with that Deployment. Feel free to describe the Deployment defined in different-app-db.yml. You should see that its image was also updated to the newer version.

Try it yourself#

A list of all the commands used in the lesson is given below.