Kubernetes Application Management — Upgrade (1)

Background

  • Downtime release — Completely shuts down the old application instance, and then releases the new version. This release model mainly solves the problem that the old and new application versions are incompatible with each other. The drawback is that the application is completely unavailable for a period of time.
  • Blue-green release — Deploys the same number of old and new application instances. After a new version passes the test, data traffic is switched to new application instances all at once. This release model solves the problem where the application is completely unavailable during the downtime release. However, it causes significant resource consumption.
  • Rolling release — Gradually replaces application instances in batches. This release model does not interrupt the running service, or consume too many additional resources. However, this may cause compliance problems when a request from the same client is transmitted between old and new application versions.
  • Canary release — Gradually transits traffic from old instances to new instances. If no problems are found for some time after the release, increase the traffic to the new version and reduce it to the old version.
  • A/B testing — Releases two or multiple versions simultaneously, collect user feedback on these versions, and determine the best version for official release through analysis and evaluation.

K8s Application Upgrade

Deployment

Parameters

kind: Deployment
...
spec:
replicas: 8
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3
maxUnavailable: 2
minReadySeconds: 120
...
template:
...
spec:
containers:
- name: spring-boot-probes
image: registry.cn-hangzhou.aliyuncs.com/log-service/spring-boot-probes:1.0.0
ports:
- containerPort: 8080
terminationGracePeriodSeconds: 60
readinessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
failureThreshold: 1
livenessProbe:
httpGet:
path: /actuator/health
port: 8080
initialDelaySeconds: 40
periodSeconds: 20
successThreshold: 1
failureThreshold: 3
...

Configuring Strategies

  • .spec.strategy.type - Used to specify the strategy type of the pod to be replaced. Valid values: Recreate and RollingUpdate. Default: RollingUpdate.
  • Recreate — K8s deletes all existing pods and then creates new ones. This method is suitable for scenarios where the old and new application versions are incompatible with each other. Take caution if you want to use this method in a different scenario, because it may cause the service to be completely unavailable for a period of time.
  • RollingUpdate — K8s gradually replaces existing pods in batches. This method can be used to implement hot upgrade of services.
  • .spec.strategy.rollingUpdate.maxSurge - Specifies the maximum number of additional pods that can be created during the rolling update process. The value of this parameter can be an integer number or a percentage. A higher value leads to faster upgrade, but it also consumes extra system resources.
  • .spec.strategy.rollingUpdate.maxUnavailable - Specifies the maximum number of pods that are allowed to be unavailable during the rolling update process. The value of this parameter can be an integer number or a percentage. A higher value leads to faster upgrade, but it also causes the service to be unstable.

Configuring Probes

  • ReadinessProbe — If all containers of a pod are started, K8s considers this pod as ready, and forwards traffic to this pod. However, after some applications are started, you need to load data or configuration files before they are truly ready for providing external services. Therefore, determining whether a pod is ready based on whether containers running in it are started is inaccurate. You can accurately determine whether containers of a pod are ready by configuring readiness probes for these containers. This allows you to build robust applications. K8s only allows services to send traffic to a pod after all containers of the pod pass readiness detection. If a pod fails readiness detection, K8s stops sending traffic to this pod.
  • LivenessProbe — K8s considers running containers as available by default. However, this logic has a flaw. The application may keep running and cannot automatically exit when it encounters an error or when it is unhealthy (for example, in the case of a serious deadlock). You can allow K8s to accurately determine whether containers run normally by configuring liveness probes for these containers. If a container fails the liveness detection, Kubelet will terminate it and restart it based on the restart strategy.

Configuring minReadySeconds

Configuring terminationGracePeriodSeconds

Viewing the Upgrade Progress

Rolling Back Upgrades

StatefulSet

Strategy Types

  • OnDelete: After you update PodTemplateSpec of StatefulSet, K8s creates new pods only after you manually delete old pods. This is the default update strategy. This strategy is designed to ensure compatibility with K8s 1.6 and earlier versions. In addition, it avoids the problem that pods of old and new application versions are incompatible with each other during the upgrade.
  • RollingUpdate — K8s gradually replaces pods managed by StatefulSet in batches. The difference between this RollingUpdate strategy and that of the Deployment mode is that this strategy replaces pods in order. For example, a StatefulSet runs N pods, each of which is assigned a monotonically increasing ordinal number when they are deployed. During the rolling update, they are replaced in a descending order.

Partition

DaemonSet

  • OnDelete: After you update PodTemplateSpec for DaemonSet, K8s creates new pods only after you manually delete old pods. This is the default update strategy. This strategy is designed to ensure compatibility with K8s 1.5 and earlier versions. In addition, it avoids the problem where pods of old and new application versions are incompatible with each other during the upgrade.
  • RollingUpdate: The meaning and configurable parameters of this strategy are the same as those of the RollingUpdate strategy of Deployment.

Job

Summary

Reference

--

--

--

Follow me to keep abreast with the latest technology news, industry insights, and developer trends. Alibaba Cloud website:https://www.alibabacloud.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The most interesting C# / .NET blogs and websites

Ideas and Methods for System Refactoring

Concurrency in Go: Using a channel to append to slices

How to add Double Jump to your Game

Invoking APIs In Asgardeo

Kubernetes Tip: Is DNS your service discovery ?. May be not.

Manage the secrets using ASP.NET Core secret manager with Visual Studio

Logic Apps — How To Convert Excel File To a CSV File During Copy

Test Data

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
Alibaba Cloud

Alibaba Cloud

Follow me to keep abreast with the latest technology news, industry insights, and developer trends. Alibaba Cloud website:https://www.alibabacloud.com

More from Medium

Getting Started with Minikube Kubernetes

Rolling updates & rollbacks in Deployments (Kubernetes)

Debugging Python-Based Microservices Running on a Remote Kubernetes Cluster

Kubernetes, rke2, containerd, Elasticsearch, limits.conf , Increasing the # of open files.