Updating Deployment Replicas

The use of Deployments allows us to define a particular number of PODs that we would like to be running by adjusting the Replicas value within the Deployment.

Deployments make use of the ReplicaSet object to set the number of replicas of a POD that should be running. While it is technically possible to manually create a ReplicaSet to control the number of PODs this is not normally considered best pracice.

There are a number of ways of changing the number of replicas within a Deployment and this post will cover a few of them.

Create the Deployment

We'll create a simple deployment that will create an nginx POD.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-nginx
  name: test-nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: test-nginx
    spec:
      containers:
      - image: nginx:latest
        imagePullPolicy: Always
        name: nginx

We can then confirm the Deployment and it's single POD are running.

test-nginx

We'll expose the Deployment using a NodePort object to allow connection from outside the cluster.

kubectl expose deployment test-nginx --port=80 --type=NodePort

Expose-Test_Deployment

We're going to take a look at our initial deployment with the rollout history command and then get a bit more information by looking at the details of it's first revision.

kubectl rollout history deployment test-nginx 
kubectl rollout history deployment test-nginx --revision=1

Rollout_History1

Scale up Replicas using Scale Command

A simple way of scaling the number of running replicas is to simply increase the number using the scaling command.

kubectl scale deployment test-nginx --replicas=3 --record

The command will increase the number of replicas running to 3. The last part of the command --record will cause this command to become part of the history of the deployment.

ScaledUp

Scale up Replicas by Directly Editing the Deployment

It is also possible to directly edit the running deployment to make changes by running.

kubectl edit deployment test-nginx

This will open the running object within a text editor and allow changes to be made and then saved.

EditFile

This is a simple way of making changes 'on the fly' but does have the disadvantage of not having a means of keeping an audit of what was changed or having a simple way of rolling back.

This shows an edit that rolled back the running replicas to 1 but the history of the deployment still shows it having 3 replicas running.

Confirmingedit

Scale the Replicas by Updating Manifest File

The best way of changing the number of replicas is by making a change to the manifest YAML file and re-applying it. This has the advantage of being able to be tracked within the history of the deployment, which also allows an easy roll-back.

Another manifest file will be created to increase the running replicas to 4 and this is then applied. The history of the deployment will also be updated accordingly.

updateto4

Conclusions

It can be seen that scaling of an application is relatively straight forward and is done by controlling the number of replicas within the Deployment. This in turn will dictate the configuration of the associated ReplicaSet which is the actual object that is purely responsible to ensure the correct number is running within the cluster.

The use of a Deployment combined with a suitable service means that the number of PODs can be increased or decrease with ease. In essence the number of end-points associated with the service is being changed and the cluster is making use of the load sharing that comes with this.

While it is possible to make this change by manually changing the number of replias, either by using the scale command or editing the running Deployment it is better to modify the associated YAML manifest file.

This allows suitable tracking and auditing of the change, with the appropriate file being run whenever there is a need to update the number of running replicas.