Kubernetes: Basic Deployments

By Alwyn Botha, Alibaba Cloud Tech Share Author. Tech Share is Alibaba Cloud’s incentive program to encourage the sharing of technical knowledge and best practices within the cloud community.

We use Deployments to define how many replicas of a Pod we want to be running. Kubernetes then continuously drives the state of running Pods to match our desired number of replicas.

If one of those Pods get deleted by accident, Kubernetes will automatically create a new one to replace it.

Deployments have other features as well:

  • Deployments can be scaled up or down ( running more or less replicas )
  • Deployments can be paused and resumed
  • Deployments can be rolled back to a previous Deployment
  • We can precisely control the maximum number of Pods that we allow to be unavailable during the update process.
  • We can use several commands to show the status of a Deployment currently in progress.

This tutorial will cover the following topics:

  • Basic Deployment Example
  • terminationGracePeriodSeconds: 0
  • Updating the image in a Pod
  • maxUnavailable and maxSurge
  • maxSurge: 5 maxUnavailable: 5
  • maxSurge: 10 maxUnavailable: 10

1) Basic Deployment Example

template defines the Pod we want

replicas defines we want 10 identical copies running

strategy type: RollingUpdate — we will see how updates work later. ( RollingUpdate is the default value )

Note the second line above kind: Deployment

Create the Deployment

We use the following command to show the status of our Deployment :

All 10 replicas we requested are created simultaneously.

We’ll be using Busybox as our Linux operating system as it is small (only 2MB) and suitable for our applications.

To create a container in a Pod running busybox is very fast. If you took 10 seconds to cut and paste the previous command all you may see is the final success line.

Alternative command to get information about our Deployment status.

kubectl rollout status shows detail per Pod — one line per Pod

kubectl get deploy shows overall summary status — compressed in one summary line.

Over time you will realize when to use which one.

Get as much detail as we can about our Deployment:

Note the useful Replicas: 10 desired | 10 updated | 10 total | 10 available | 0 unavailable line.

Show details about individual running Pods:

Show a history of this Deployment, right now just one revision. Later in this tutorial we will have and use more revisions.

This is our first revision: there is no CHANGE-CAUSE. More about this later.

The purpose of this part of tutorial was to create one basic Deployment and introduce you to several commands that enable you to get details out your Deployments.

This Deployment served its purpose, delete the Deployment

Show status of Pods during the delete phase:

… several seconds later …

… several seconds later …

… several annoying seconds later …

… several seconds later …

terminationGracePeriodSeconds default value for Pods is 30 seconds. That is why termination takes so long.

We will do several Deployment demos and such a long delay every time is too long.

We will set terminationGracePeriodSeconds to 0 seconds : kill Pod immediately. VERY BAD during production but enables quick experiments during development.

2) terminationGracePeriodSeconds: 0

Note last line in Pod spec.

Create the Deployment

Show details while Deployment is in progress.

Note several Pods already running ( since creation is so quick ). All other needed Pods are created simultaneously ( ContainerCreating )

Deployment complete in around 10 seconds.

Now the test for terminationGracePeriodSeconds: 0

One second later:

All Pods for this Deployment got deleted immediately.

Note that our previous example also had — force — grace-period=0 at the end.

That got ignored — each Pod still took 30 seconds to terminate.

Why? We have that — force flag on a delete command line for a Deployment. Deployments do not have a grace period so it got ignored.

The Deployment manages a ReplicaSet that manages our 10 Pods. The — force does not get passed from the Deployment on to the ReplicaSet. ReplicaSets do not have a — force option.

So when ReplicaSets command the Pods to terminate, no — force flag is sent to them.

It would have been better if kubectl delete showed a warning when you add — force — grace-period=0 when deleting a Deployment.

… Warning : Deployments do not support — force — grace-period=0, flags ignored.

3) Updating the Image in a Pod

In this section we will update our Pod to use a different busybox image.

terminationGracePeriodSeconds is 10 seconds — otherwise things happen too fast to learn what is happening.

Create the Deployment .

Repeatedly run command below until all 10 replicas are available.

Currently our busybox is using version 1.30 — the latest version.

Let’s assume we now need to run version 1.29.3.

We use the following command to update our Deployment to use busybox image 1.29.3

Note the — record at the end. This adds an annotation to the Deployment

Show ongoing status of Deployment …

busybox-deployment-6b48b9cb8f is the prefix of our old Pods

Several of them are terminating — making place for new Pods with busybox 1.29.3

Several of them are still running — making it possible for our old Pods to still do work during the rollover update

busybox-deployment-8866dfbb4 is the prefix of our new Pods — busybox 1.29.3

There is already several new Pods running

There are 2 in ContainerCreating status — busy being created

2 Pods are in Pending status … in a queue … waiting to be created

… several seconds later …

All old Pods are terminating.

All new Pods are running or being created: ContainerCreating

… several seconds later …

All new Pods are running.

If you do one more kubectl get pods — show-labels a few seconds later you will see all old Pods deleted.

Delete Pod.

4) maxUnavailable and maxSurge

Two critical settings control how a RollingUpdate works

Summary:

  • maxUnavailable … the maximum number of Pods that can be unavailable during the update process.
  • maxSurge … the maximum number of Pods that can be created IN ADDITION TO the desired number of Pods.

We are going to do several exercises so that you can become familiar with how this works.

These settings are easy to understand and they do work.

Unfortunately once a complex update is underway, it is difficult to PRECISELY see those settings are being observed 100% accurately. After these few exercises you will at least get the feeling it works as expected.

Both these fields are optional, since both have a default value of 25%.

We are going to set those fields to drastically different values so you can see the effect.

This exercise:

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods.
  • maxUnavailable: 5 Pods can be unavailable DURING the update process.

Create the Deployment

Show Deployment in progress.

  • maxUnavailable: 5 Pods can be unavailable DURING the update process. WORKS AS EXPECTED.

Right at top. 5 Pods are right now Terminating = unavailable DURING the update process

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods. WORKS AS EXPECTED.

All lines near bottom: 4 Pods are ContainerCreating = created IN ADDITION TO the desired number of Pods

In theory that should have been 5, but 4 is precise enough.

Several seconds later:

All old Pods are Terminating since we specified: maxUnavailable: 5 Pods can be unavailable DURING the update process. WORKS AS EXPECTED.

Only one Pod in ContainerCreating — all Pods at bottom are new ( only running for 8 seconds )

Several seconds later:

ALL old Pods are Terminating They are taking their time since we specified: terminationGracePeriodSeconds: 10

All 10 Pods at bottom are new.

Deployment complete.

Delete Deployment .

5) maxSurge: 5 maxUnavailable: 5

This exercise:

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods.
  • maxUnavailable: ONLY ONE Pods can be unavailable DURING the update process.

Create the Deployment .

Wait 10 seconds for this Deployment to complete.

Submit command to change image the container uses to busybox:1.29.3

VERY QUICKLY afterwards run this:

  • maxUnavailable: ONLY ONE Pods can be unavailable DURING the update process.

Perfect: we see only ONE Terminating Pod.

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods.

Since one Pod is terminating this 1 plus these 5 can be created: ContainerCreating = 6 Pods.

No need to view further details — we saw those 2 settings work as expected.

Delete Deployment .

6) maxSurge: 10 maxUnavailable: 10

This exercise:

  • maxSurge: 10 Pods can be created IN ADDITION TO the desired number of Pods.
  • maxUnavailable: ALL 10 Pods can be unavailable DURING the update process.

Create the Deployment

Immediately afterwards:

  • maxUnavailable: ALL 10 Pods can be unavailable DURING the update process.

ALL 10 old Pods are Terminating — as expected.

  • maxSurge: 10 Pods can be created IN ADDITION TO the desired number of Pods.

Bottom 10 Pods are the new ones. Only 3 ContainerCreating … NOT AS EXPECTED

I expected ALL 10 new Pods to be created at same time. ZERO Pending ones expected.

3 seconds later … all new Pods still not ContainerCreating … unexplained.

Demo complete. maxUnavailable works 100% as expected.

Delete Deployment

Conclusion

Now that you have seen demos of different maxSurge and maxUnavailable settings, do this one on your own.

First consider what you learnt about maxSurge and maxUnavailable.

Then predict what you expect will happen. Then run the exercise to confirm your predictions.

Delete Deployment when done

  • Deployments can be scaled up or down ( running more or less replicas )
  • Deployments can be paused and resumed
  • Deployments can be rolled back to a previous Deployment
  • We can precisely control the maximum number of Pods that we allow to be unavailable during the update process.
  • We can use several commands to show the status of a Deployment currently in progress.

This tutorial will cover the following topics:

  • Basic Deployment Example
  • terminationGracePeriodSeconds: 0
  • Updating the image in a Pod
  • maxUnavailable and maxSurge
  • maxSurge: 5 maxUnavailable: 5
  • maxSurge: 10 maxUnavailable: 10

1) Basic Deployment Example

template defines the Pod we want

replicas defines we want 10 identical copies running

strategy type: RollingUpdate - we will see how updates work later. ( RollingUpdate is the default value )

Note the second line above kind: Deployment

Create the Deployment

We use the following command to show the status of our Deployment :

All 10 replicas we requested are created simultaneously.

We'll be using Busybox as our Linux operating system as it is small (only 2MB) and suitable for our applications.

To create a container in a Pod running busybox is very fast. If you took 10 seconds to cut and paste the previous command all you may see is the final success line.

Alternative command to get information about our Deployment status.

kubectl rollout status shows detail per Pod - one line per Pod

kubectl get deploy shows overall summary status - compressed in one summary line.

Over time you will realize when to use which one.

Get as much detail as we can about our Deployment:

Note the useful Replicas: 10 desired | 10 updated | 10 total | 10 available | 0 unavailable line.

Show details about individual running Pods:

Show a history of this Deployment, right now just one revision. Later in this tutorial we will have and use more revisions.

This is our first revision: there is no CHANGE-CAUSE. More about this later.

The purpose of this part of tutorial was to create one basic Deployment and introduce you to several commands that enable you to get details out your Deployments.

This Deployment served its purpose, delete the Deployment

Show status of Pods during the delete phase:

... several seconds later ...

... several seconds later ...

... several annoying seconds later ...

... several seconds later ...

terminationGracePeriodSeconds default value for Pods is 30 seconds. That is why termination takes so long.

We will do several Deployment demos and such a long delay every time is too long.

We will set terminationGracePeriodSeconds to 0 seconds : kill Pod immediately. VERY BAD during production but enables quick experiments during development.

2) terminationGracePeriodSeconds: 0

Note last line in Pod spec.

Create the Deployment

Show details while Deployment is in progress.

Note several Pods already running ( since creation is so quick ). All other needed Pods are created simultaneously ( ContainerCreating )

Deployment complete in around 10 seconds.

Now the test for terminationGracePeriodSeconds: 0

One second later:

All Pods for this Deployment got deleted immediately.

Note that our previous example also had --force --grace-period=0 at the end.

That got ignored - each Pod still took 30 seconds to terminate.

Why? We have that --force flag on a delete command line for a Deployment. Deployments do not have a grace period so it got ignored.

The Deployment manages a ReplicaSet that manages our 10 Pods. The --force does not get passed from the Deployment on to the ReplicaSet. ReplicaSets do not have a --force option.

So when ReplicaSets command the Pods to terminate, no --force flag is sent to them.

It would have been better if kubectl delete showed a warning when you add --force --grace-period=0 when deleting a Deployment.

... Warning : Deployments do not support --force --grace-period=0, flags ignored.

3) Updating the Image in a Pod

In this section we will update our Pod to use a different busybox image.

terminationGracePeriodSeconds is 10 seconds - otherwise things happen too fast to learn what is happening.

Create the Deployment .

Repeatedly run command below until all 10 replicas are available.

Currently our busybox is using version 1.30 - the latest version.

Let's assume we now need to run version 1.29.3.

We use the following command to update our Deployment to use busybox image 1.29.3

Note the --record at the end. This adds an annotation to the Deployment

Show ongoing status of Deployment ...

busybox-deployment-6b48b9cb8f is the prefix of our old Pods

Several of them are terminating - making place for new Pods with busybox 1.29.3

Several of them are still running - making it possible for our old Pods to still do work during the rollover update

busybox-deployment-8866dfbb4 is the prefix of our new Pods - busybox 1.29.3

There is already several new Pods running

There are 2 in ContainerCreating status - busy being created

2 Pods are in Pending status ... in a queue ... waiting to be created

... several seconds later ...

All old Pods are terminating.

All new Pods are running or being created: ContainerCreating

... several seconds later ...

All new Pods are running.

If you do one more kubectl get pods --show-labels a few seconds later you will see all old Pods deleted.

Delete Pod.

4) maxUnavailable and maxSurge

Two critical settings control how a RollingUpdate works

Summary:

  • maxUnavailable ... the maximum number of Pods that can be unavailable during the update process.
  • maxSurge ... the maximum number of Pods that can be created IN ADDITION TO the desired number of Pods.

We are going to do several exercises so that you can become familiar with how this works.

These settings are easy to understand and they do work.

Unfortunately once a complex update is underway, it is difficult to PRECISELY see those settings are being observed 100% accurately. After these few exercises you will at least get the feeling it works as expected.

Both these fields are optional, since both have a default value of 25%.

We are going to set those fields to drastically different values so you can see the effect.

This exercise:

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods.
  • maxUnavailable: 5 Pods can be unavailable DURING the update process.

Create the Deployment

Show Deployment in progress.

  • maxUnavailable: 5 Pods can be unavailable DURING the update process. WORKS AS EXPECTED.

Right at top. 5 Pods are right now Terminating = unavailable DURING the update process

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods. WORKS AS EXPECTED.

All lines near bottom: 4 Pods are ContainerCreating = created IN ADDITION TO the desired number of Pods

In theory that should have been 5, but 4 is precise enough.

Several seconds later:

All old Pods are Terminating since we specified: maxUnavailable: 5 Pods can be unavailable DURING the update process. WORKS AS EXPECTED.

Only one Pod in ContainerCreating - all Pods at bottom are new ( only running for 8 seconds )

Several seconds later:

ALL old Pods are Terminating They are taking their time since we specified: terminationGracePeriodSeconds: 10

All 10 Pods at bottom are new.

Deployment complete.

Delete Deployment .

5) maxSurge: 5 maxUnavailable: 5

This exercise:

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods.
  • maxUnavailable: ONLY ONE Pods can be unavailable DURING the update process.

Create the Deployment .

Wait 10 seconds for this Deployment to complete.

Submit command to change image the container uses to busybox:1.29.3

VERY QUICKLY afterwards run this:

  • maxUnavailable: ONLY ONE Pods can be unavailable DURING the update process.

Perfect: we see only ONE Terminating Pod.

  • maxSurge: 5 Pods can be created IN ADDITION TO the desired number of Pods.

Since one Pod is terminating this 1 plus these 5 can be created: ContainerCreating = 6 Pods.

No need to view further details - we saw those 2 settings work as expected.

Delete Deployment .

6) maxSurge: 10 maxUnavailable: 10

This exercise:

  • maxSurge: 10 Pods can be created IN ADDITION TO the desired number of Pods.
  • maxUnavailable: ALL 10 Pods can be unavailable DURING the update process.

Create the Deployment

Immediately afterwards:

  • maxUnavailable: ALL 10 Pods can be unavailable DURING the update process.

ALL 10 old Pods are Terminating - as expected.

  • maxSurge: 10 Pods can be created IN ADDITION TO the desired number of Pods.

Bottom 10 Pods are the new ones. Only 3 ContainerCreating ... NOT AS EXPECTED

I expected ALL 10 new Pods to be created at same time. ZERO Pending ones expected.

3 seconds later ... all new Pods still not ContainerCreating ... unexplained.

Demo complete. maxUnavailable works 100% as expected.

Delete Deployment

Conclusion

Now that you have seen demos of different maxSurge and maxUnavailable settings, do this one on your own.

First consider what you learnt about maxSurge and maxUnavailable.

Then predict what you expect will happen. Then run the exercise to confirm your predictions.

Delete Deployment when done

Reference:https://www.alibabacloud.com/blog/kubernetes-basic-deployments_594831?spm=a2c41.12911565.0.0

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store