Get to Know Kubernetes | Application Orchestration and Management

Image for post
Image for post

1) Need

Background

This section describes the background of Kubernetes application orchestration and management. For instance, to directly manage all pods in a cluster, pods of applications A, B, and C are scattered in the cluster, as shown in the following figure.

Image for post
Image for post
  • How to update the image version for all pods? Is it necessary to update the version of a pod?
  • How to ensure service availability during the update?
  • How to roll back a pod to the previous version if a problem occurs during the update?

Deployment Management Controller for Deployment and Release

This section introduces the key topic of this article: Deployments.

Image for post
Image for post

2) Use Cases

Deployment Syntax

This section uses a simple case to explain how to operate a Deployment.

Image for post
Image for post
  • The other is Pod.spec. In the template, Pod.spec is used by Deployment to create pods. Here, container.nginx is defined, with the image version Nginx:1.7.9.
  • Templates indicate pod-related templates.

View the Deployment Status

While creating a Deployment, run the kubectl get deployment command to view the overall status of the Deployment, as shown in the following figure.

Image for post
Image for post
  • CURRENT: The number of the current pods, which is 3.
  • UP-TO-DATE: The number of pods with the latest expected version.
  • AVAILABLE: The number of pods available in the running process. Actually, AVAILABLE also includes the number of pods that have exceeded their availability period.
  • AGE: The duration of a created Deployment. In the preceding figure, the Deployment has been running for 80 minutes.

View Pods

View the pods, as shown in the following figure.

Image for post
Image for post

Update Images

This section describes how to update the image versions of all pods for a given Deployment. Run the kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 command.

  • The following “set image” is deployment.v1.apps, indicating the type of the resource to be operated on. This part is fixed, where "deployment" indicates the resource name, "v1" indicates the resource version, and "apps" indicates the resource group. Use "deployment" or deployment.apps to replace deployment.v1.apps. For example, while using "deployment" to replace deployment.v1.apps, the v1 version of apps will be used by default.
  • The third part is “nginx-deployment”, indicating the name of the deployment with the image to be updated. “nginx” following the name indicates a template, which is the container.name of a pod. A pod may contain multiple containers and the container.name specified here, Nginx is the container name of the image to be updated.
  • The last part is nginx:1.9.1, indicating the expected image version of the container. Running this command shows that template.spec of the Deployment is updated to nginx: 1.9.1.
Image for post
Image for post

Quick Rollback

Perform a quick rollback when problems occur during the release. Run the kubectl rollout undo command to roll back the Deployment to the previous version or run the kubectl rollout undo command suffixed with to-revision to roll back the Deployment to a specific version.

Image for post
Image for post

DeploymentStatus

This section introduces DeploymentStatus. Each resource has its spec.Status. DeploymentStatus describes the conversion statuses, including Processing, Complete, and Failed, as shown in the following figure.

Image for post
Image for post

3) Demonstration

Deployment Creation and Status

An Alibaba Cloud service cluster is connected. The cluster contains several available nodes.

Image for post
Image for post
Image for post
Image for post

Deployment Structure

As shown in the figure, there are three replicas in “spec”, the “labels” defined in “selector” and “template” is app:nginx, the "image" in "spec" is the expected value nginx: 1.7.9, and values of available.replicas, readReplicas, and updatedReplicas in "status" are all 3.

Image for post
Image for post

Pod Status

You can view the status of a pod.

Image for post
Image for post

Upgrade

Currently, only the ReplicaSet of the latest version is available. Now, try to upgrade the Deployment.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

RevisionHistoryLimit

As shown in the preceding figure, the ReplicaSet of the latest version contains three pods, and there are two ReplicaSets of earlier versions. You may wonder whether the quantity of earlier-version ReplicaSets will constantly grow as the Deployment is continuously updated. In fact, the Deployment provides a mechanism to prevent this problem. In spec of the Deployment, the default value of RevisionHistoryLimit is 10, specifying the number of ReplicaSets of historical versions that are retained. You may change it to 1.

Image for post
Image for post
Image for post
Image for post

Rollback

This section describes how to perform rollback. Run the kubectl get replicaset command. The number of ReplicaSets of earlier versions increases from 0 to 2 while the number of ReplicaSets of the new version decreases from 3 to 1, indicating that the rollback has started. After a while, the number of ReplicaSets of the earlier version becomes 3, indicating that the rollback was successful. At this time, the number of ReplicaSets of the new version is 0.

Image for post
Image for post
Image for post
Image for post

4) Architecture Design

Management Mode

Image for post
Image for post

Deployment Controller

This section describes the controller implementation principle.

Image for post
Image for post

ReplicaSet Controller

Image for post
Image for post

Scale-up and Scale-down Simulation

This section describes some simulated operations, such as the scale-up operation. Assume there is a Deployment with two replicas and its corresponding ReplicaSet has Pod1 and Pod2. If you modify the Deployment replicas, the controller synchronizes the replicas to the ReplicaSet of the current version. When the ReplicaSet finds two pods, and not the three pods expected; the ReplicaSet creates the third pod.

Image for post
Image for post

Release Simulation

This section describes how to simulate release, which is a little more complex. For example, assume the Deployment template of the current version is template1. The ReplicaSet corresponding to template1 contains three pods: Pod1, Pod2, and Pod3.

Image for post
Image for post

Rollback Simulation

This section describes how to simulate a rollback. After the release simulation in the preceding section, Pod4, Pod5, and Pod6 are released. Assume you discover a problem with the current business version. In this case, run a rollout command or perform a rollback to roll back the template to template1.

Image for post
Image for post

Spec Fields

This section describes some fields in a Deployment. The following describes the spec fields in a Deployment:

  • RevisionHistoryLimit: The number of old ReplicaSets that can be retained. The default value is 10. Set this parameter to 1 or 2. If rollback is highly probable, set it to a value greater than 10.
  • Paused: A label indicating that the Deployment is paused and only maintains the quantity, without any new releases. This field may be used in debugging scenarios.
  • ProgressDeadlineSeconds: When the Deployment is in the Scaling or Releasing state, its condition is Processing. A timeout interval is set for the Processing state. If the state is still Processing after the timeout interval, the controller considers the pod to have entered the Failed state.
Image for post
Image for post

Upgrade Policy Fields

The Deployment provides two policies in RollingUpdate, MaxUnavailable, and MaxSurge. These two fields are also explained in the following figure.

  • MaxSurge: The maximum number of pods that are scheduled above the expected number of replicas during the update.
Image for post
Image for post

Summary

This section concludes the article.

  • The Deployment creates a ReplicaSet for the template of each version, and then the ReplicaSet maintains a certain number of pod replicas. The Deployment only needs to specify the number of pods in ReplicaSets of each version.
  • In short, a Deployment adjusts the final number of replicas in ReplicaSets to upgrade and roll back pods of different versions.

Original Source:

Written by

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