Rolling Upgrade Stateless App

A stateless application can contain multiple instances, all of which are the same, but the instances are independent and independent of each other. Any web request is completely isolated from other requests. The user does not need to save the state of the application or persist data to access The system will automatically distribute requests for multi-instance applications, and all instances share storage volumes. Kato adopts a rolling upgrade strategy for stateless applications.

Application Scenario

When the application is deployed and running, if the application does not require any stable status indication, orderly deployment, update upgrade, deletion and expansion, it is recommended to use the stateless (Deployment) method of deployment. Stateless applications can be used for most Web classes and API classes. By default, applications created on the platform are stateless applications.

Platform Settings

Source code construction is still mirrored, and the configuration process is the same. Here, mirroring is taken as an example.

Set the application type when creating an application

Advanced settings can be configured after the app is detected

Created application modify application type

Currently, only closed apps can be modified by app type.

The application type can be configured in the Other Settings–>Basic Information of the application. It should be noted that modifying the application type will lose the original data.

Rolling Update (RollingUpdate)

Kato uses the Deployment type to deploy web applications by default, and a rolling upgrade strategy is adopted in the application upgrade strategy. The so-called rolling The upgrade strategy is to adopt a gradual replacement method, using new instances to gradually update and replace the old instances. The advantage is that the service will not be interrupted, but it will cause inconsistent application versions and inconsistent output content when calling.

Rolling Update Strategy

# Default RollingUpdateStrategy
25% max unavailable, 25% max surge

Deployment can ensure that only a certain number of instances will be shut down during the update. By default, it ensures at least 25% less than the required number of instances (25% max unavailable). Deployment can also ensure that only a certain number of instances can be created on top of the required number of instances. By default, it ensures at most 25% more than the required number of instances (25% max surge). If your number of instances is 3, ensure that the number of available instances is at least 2, and that the total number of instances is at most 4.

Operation

Rolling upgrades are embodied in two operational procedures on the platform, one is the build and start process, and the other is the scaling process.

If you look closely at the above deployment, you will see that it first created a new Pod, then deleted some old Pods and created new Pods. It will not kill old Pods until a sufficient number of new Pods appear, and will not create new Pods until a sufficient number of old Pods have been killed. It ensures that the number of available Pods is at least 2 and the total number of Pods is at most 4. You can also view specific events by naming rows to determine the specific rolling update process.

Name: eb02a36a5f8d0b349b2254461393369e-deployment
Namespace: 34869bb254f6491e97d4993980a2cf85
Annotations: deployment.kubernetes.io/revision=4
Selector: name=gr93369e,service_id=eb02a36a5f8d0b349b2254461393369e,tenant_id=34869bb254f6491e97d4993980a2cf85
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Conditions:
  Type Status Reason
  ---- ------ ------
  Available True MinimumReplicasAvailable
  Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: eb02a36a5f8d0b349b2254461393369e-deployment-9fcdf797 (3/3 replicas created)
Events:
  Type Reason Age From Message
  ---- ------ ---- ---- -------
  Normal ScalingReplicaSet 27m deployment-controller Scaled up replica set eb02a36a5f8d0b349b2254461393369e-deployment-84dc79c979 to 1 #For the first deployment, set the number of new instances to 1
  Normal ScalingReplicaSet 25m deployment-controller Scaled up replica set eb02a36a5f8d0b349b2254461393369e-deployment-d5ff5fbd4 to 1 #Build operation, set the number of new instances to 1
  Normal ScalingReplicaSet 24m deployment-controller Scaled down replica set eb02a36a5f8d0b349b2254461393369e-deployment-84dc79c979 to 0 #Build operation, the number of old instances is set to 0
  Normal ScalingReplicaSet 24m deployment-controller Scaled up replica set eb02a36a5f8d0b349b2254461393369e-deployment-66b58566c9 to 1 #Scaling operation, the number of new instances is set to 1
  Normal ScalingReplicaSet 24m deployment-controller Scaled down replica set eb02a36a5f8d0b349b2254461393369e-deployment-d5ff5fbd4 to 0 #Scaling operation, the number of old instances is set to 0
  Normal ScalingReplicaSet 30s deployment-controller Scaled up replica set eb02a36a5f8d0b349b2254461393369e-deployment-66b58566c9 to 3 #Scaling operation, the number of new instances is set to 3
  Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set eb02a36a5f8d0b349b2254461393369e-deployment-9fcdf797 to 1 #Build operation, set the number of new instances to 1
  Normal ScalingReplicaSet 20s deployment-controller Scaled down replica set eb02a36a5f8d0b349b2254461393369e-deployment-66b58566c9 to 2 #Build operation, the number of old instances is set to 2
  Normal ScalingReplicaSet 20s deployment-controller Scaled up replica set eb02a36a5f8d0b349b2254461393369e-deployment-9fcdf797 to 2 #Build operation, the number of new instances is set to 2
  Normal ScalingReplicaSet 18s deployment-controller Scaled down replica set eb02a36a5f8d0b349b2254461393369e-deployment-66b58566c9 to 1 #Build operation, the number of old instances is set to 1
  Normal ScalingReplicaSet 18s deployment-controller Scaled up replica set eb02a36a5f8d0b349b2254461393369e-deployment-9fcdf797 to 3 #Build operation, the number of new instances is set to 3
  Normal ScalingReplicaSet 16s deployment-controller Scaled down replica set eb02a36a5f8d0b349b2254461393369e-deployment-66b58566c9 to 0 #Build operation, the number of old instances is set to 0

No Impact Upgrade

The premise of no impact is that multiple instances have been deployed. If you deploy a single instance, you need to ensure that the application starts as a service.

Configure Application Health Check

Kato provides the application health check function, which is used to check whether the application and user business are running normally. Setting the health check can check the health status of the application regularly according to the setting requirements during the application running process. If the health check is not set, our default application and user business are running normally; if the health check is set, we will detect whether the application or business is running normally according to the configuration to ensure the reliability of the business.

By default, we provide two health check methods:

  • Application startup check (application instance survival check): Detect whether the application instance has been started. This check method is used to detect whether the instance is alive or whether the service is started, similar to executing ps to check whether the process exists. If the check fails, the application status will be set to unhealthy; if the check succeeds, no operation will be performed.
  • Application runtime check (application service readiness check): Detect whether the application service is ready. This check method is used to check whether the instance is ready to start processing user requests or whether the service exits abnormally during operation. If the check fails, the instance will be restarted; if the check succeeds, no operation is performed.

Distributed Session Sharing Under Microservice Architecture

In some scenarios, in the case of a single instance, most sessions are stored in the memory, and all user requests are processed by the single instance to meet the needs of maintaining user status. With the popularization and development of microservice architecture, it is necessary to transform and split the original single-instance application to realize the migration of the application to the cloud platform. Each micro-application has its own Web page, which will be displayed to users through the browser client. The entire micro-application architecture can be roughly regarded as a large-scale distributed application, so each micro-application needs There is a Session object, and in the entire micro-application architecture, the session data of the same user should be consistent. Therefore, under the microservice architecture, the processing of the session is no longer stored in the memory, but an independent intermediate storage medium such as redis or memcache is introduced into the architecture to manage the session of enterprise applications in a unified manner.

For such scenarios, you can refer to: Tomcat realizes Session sharing based on Redis