Use kubernetes deployment for RollingUpdate-Alibaba Cloud Developer Community

2018-12-17 1494

introduction: sequential rolling update allows services to be upgraded seamlessly, that is, applications can be updated without stopping external services. The difference between replication controller and deployment is replication controller Replication Controller a core content of Kubernetes. After an application is hosted in the Kubernetes, it is necessary to ensure that the application can run continuously. Replication Controller is the key to this guarantee. The main functions are as follows: ensure the number of pods: it ensures that a specified number of pods are running in the Kubernetes.
+ Follow to continue viewing

order

rolling update allows services to be upgraded seamlessly, that is, applications can be updated without stopping external services.

Differences between replication controller and deployment

replication controller

Replication Controller is a core content of the Kubernetes. After the application is hosted in the Kubernetes, it is necessary to ensure that the application can run continuously. Replication Controller is the key of this guarantee. Its main functions are as follows:

  • ensure the number of pods: it ensures that a specified number of pods are running in the Kubernetes. If the number of pods is less than the specified number, the Replication Controller creates new ones. Otherwise, the redundant ones are deleted to ensure that the number of pods remains unchanged.

  • Make sure the pod is healthy: when the pod is unhealthy, runs incorrectly, or fails to provide services, the Replication Controller also kills the unhealthy pod and creates a new one.

  • Auto Scaling: during peak hours or off-peak hours, you can Replication Controller to dynamically adjust the number of pods to improve resource utilization. In addition, if you configure the corresponding monitoring function (Hroizontal Pod Autoscaler), the system automatically obtains the overall resource usage of Replication Controller associated pods from the monitoring platform at regular intervals to achieve automatic scaling.

  • Rolling upgrade: rolling upgrade as a smooth upgrade way, through the gradual replacement strategy, ensure overall system stability, in the initialization upgrade when can discover and solve problem, avoid expanding problems.

Deployment

Deployment is also a core part of the Kubernetes. Its main responsibility is to ensure the number and health of pods. 90% of the functions are exactly the same as those of Replication Controller, which can be regarded as a new generation of Replication Controller. However, it has new features besides Replication Controller:

  • Replication Controller all functions: Deployment inherits all the functions described above Replication Controller.

  • Event and status: You can view the update progress and status of Deployment.

  • Rollback: if a problem occurs when you upgrade the pod image or related parameters, you can use the rollback operation to roll back to the previous stable version or the specified version.

  • Version Records: each operation on Deployment can be saved for subsequent rollback.

  • Pause and start: each upgrade can be paused and started at any time.

  • Multiple upgrade schemes: Recreate: delete all existing pods and create new ones; RollingUpdate: rolling upgrade, step-by-step replacement, and support more additional parameters during rolling upgrade, for example, set the maximum number of unavailable pods and the minimum upgrade interval.

Common deployment commands

view deployment status

kubectl rollout status deployment/review-demo --namespace=scm
kubectl describe deployment/review-demo --namespace=scm

or this way of writing

kubectl rollout status deployments review-demo --namespace=scm
kubectl describe deployments review-demo --namespace=scm

upgrade

kubectl set image deployment/review-demo review-demo=library/review-demo:0.0.1--namespace=scm

or

kubectl edit deployment/review-demo --namespace=scm

edit the value of. spec.template.spec.containers[0].image

terminate upgrade

kubectl rollout pause deployment/review-demo --namespace=scm

continue to upgrade

kubectl rollout resume deployment/review-demo --namespace=scm

roll back

kubectl rollout undo deployment/review-demo --namespace=scm

see deployments version

kubectl rollout history deployments --namespace=scm

roll back to the specified version

kubectl rollout undo deployment/review-demo --to-revision=2 --namespace=scm

upgrade history

kubectl describe deployment/review-demo --namespace=scmName: review-demo
Namespace: scm
CreationTimestamp: Tue, 31 Jan 201716:42:01 +0800
Labels: app=review-demo
Selector: app=review-demo
Replicas: 3updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1max unavailable, 1max surge
OldReplicaSets: <none>
NewReplicaSet: review-demo-2741031620 (3/3 replicas created)
Events:
 FirstSeen LastSeen CountFrom SubobjectPath Type Reason Message
 --------- -------- ----- ---- ------------- -------- ------ -------1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620to11m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649to21m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620to21m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649to11m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set review-demo-2741031620to31m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set review-demo-1914295649to0

deployment File

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: review-demo namespace: scm labels: app: review-demo spec: replicas: 3# minReadySeconds: 60 #滚动升级时60s后认为该pod就绪 strategy: rollingUpdate: ##由于replicas为3,则整个升级,pod个数在2-4个之间 maxSurge: 1 #滚动升级时会先启动1个pod maxUnavailable: 1 #滚动升级时允许的最大Unavailable的pod个数 template: metadata: labels: app: review-demo spec: terminationGracePeriodSeconds: 60 ##k8s将会给应用发送SIGTERM信号,可以用来正确、优雅地关闭应用,默认为30秒 containers: -name: review-demo image: library/review-demo:0.0.1-SNAPSHOT imagePullPolicy: IfNotPresent livenessProbe: #kubernetes认为该pod是存活的,不存活则需要重启 httpGet: path: /health port: 8080 scheme: HTTP initialDelaySeconds: 60 ## equals to the maximum startup time of the application + couple of seconds timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5 readinessProbe: #kubernetes认为该pod是启动成功的 httpGet: path: /health port: 8080 scheme: HTTP initialDelaySeconds: 30 ## equals to minimum startup time of the application timeoutSeconds: 5 successThreshold: 1 failureThreshold: 5 resources:  # keep request = limit to keep this container in guaranteed class requests: cpu: 50m memory: 200Mi limits: cpu: 500m memory: 500Mi env: -name: PROFILE value: "test" ports: -name: http containerPort: 8080

several important parameters

maxSurge and maxUnavailable

maxSurge: 1 said rolling upgrade when first starting 1 pod maxUnavailable: 1 said rolling upgrade when the maximum allowed Unavailable pod number because replicas is 3, the entire upgrade, the number of pods is between 2 and 4.

terminationGracePeriodSeconds

k8s will send SIGTERM signal to the application, which can be used to close the application correctly and gracefully. The default is 30 seconds.

If you want to disable it more gracefully, you can use the pre-stop lifecycle hook configuration declaration provided by k8s, which will be executed before sending the SIGTERM.

livenessProbe and readinessProbe

livenessProbe, kubernetes considers that the pod is alive. If it does not exist, it needs to kill it and start another pod to reach the number specified by replicas.

readinessProbe is kubernetes think the pod is start successful, here according to each application characteristics, own judgment, can perform command, can also be httpGet. For example, for applications that use java web services, tomcat is not simply started to provide external services, but also needs to wait for spring container initialization and database connection. For spring boot applications, the default actuator has the/health interface, which can be used to determine whether the startup is successful.

readinessProbe.initialDelaySeconds can be set to the minimum time required for the system to start completely, livenessProbe.initialDelaySeconds can be set to the maximum time required for the system to start completely + several seconds.

After these parameters are configured, you can basically smoothly upgrade them almost seamlessly. For applications that use service discovery, readinessProbe can run the command to check whether the registration in service discovery is successful.

This article is forwarded from SegmentFault- use kubernetes deployment for RollingUpdate

Kubernetes Java Perl container Spring surveillance elastic Computing application service middleware database Connection
remote access to kubernetes kubernetes static remote kubernetes dns kubernetes cluster kubernetes process
developer Community&gt; development and O &amp; M &gt; article
Selected, One-Stop Store for Enterprise Applications
Support various scenarios to meet companies' needs at different stages of development

Start Building Today with a Free Trial to 50+ Products

Learn and experience the power of Alibaba Cloud.

Sign Up Now