Benpian has joined " the .NET Core ON K8S study and practice series index ", you can click to see more container technology related series of articles.
First, what is the Rolling Update?
In order to provide a sustainable service uninterrupted service during the upgrade process, K8S Rolling Update provides a mechanism that can make service almost seamlessly smooth upgrade, to complete the application update without stopping external services. Rollover gradually replace the old version Pod gradual approach, if the update as expected, you can also update the state before the recovery by rolling back the operation.
The greatest benefit is that rollover zero downtime , there is always a copy of the entire update process is running, thus ensuring business continuity.
In order to practice rollover, we do some preparatory work:
(1) preparing a ASP.NET Core WebAPI project, specific project code can be found here .
There are three versions of the code inside the item, as shown below:
The difference between them lies in a return JSON data interfaces such as V1.0 version returns Version: 1.0, and V1.1 version returns Version: 1.1, then the V1.2 version is returned Versioin: 1.2 .
[Route("api/[controller]")] [ApiController] public class HomeController : ControllerBase { // GET api/home [HttpGet] public ActionResult<IEnumerable<string>> Get() { return new string[] { "Hello, welcome to EDC's demo. Version: 1.0" }; } }
Each version (2) this image according to item labeled Dockerfile, respectively k8s-demo: 1.0,1.1,1.2
(3) the local mirror push to a remote repository mirroring, where I transferred to a public warehouse docker hub's inside:
docker push edisonsaonian/k8s-demo:1.0 docker push edisonsaonian/k8s-demo:1.1 docker push edisonsaonian/k8s-demo:1.2
Second, practice updates
First, let's create a version 1.0 to K8S, the preparation YAML configuration file (this time we will define the resource and Service Deployment write together):
apiVersion: apps/v1 kind: Deployment metadata: name: edc-webapi-deployment namespace: aspnetcore spec: replicas: 2 selector: matchLabels: name: edc-webapi template: metadata: labels: name: edc-webapi spec: containers: - name: edc-webapi-container image: edisonsaonian/k8s-demo:1.0 ports: - containerPort: 80 imagePullPolicy: IfNotPresent --- apiVersion: v1 kind: Service metadata: name: edc-webapi-service namespace: aspnetcore spec: type: NodePort ports: - nodePort: 31000 port: 8080 targetPort: 80 selector: name: edc-webapi
Then, created by kubectl:
kubectl apply -f k8s-demo.yaml
Verified by kubectl:
By external access interface verification:
Assuming that 1.0 version running for a while, we did some optimization ready to release version 1.1, so this time we can make use of Rolling Update rolling update, only need to modify the YAML configuration file: Change of Tag mirrored version 1.1 can be.
apiVersion: apps/v1 kind: Deployment metadata: name: edc-webapi-deployment namespace: aspnetcore spec: replicas: 2 selector: matchLabels: name: edc-webapi template: metadata: labels: name: edc-webapi spec: containers: - name: edc-webapi-container image: edisonsaonian/k8s-demo:1.1 ports: - containerPort: 80 imagePullPolicy: IfNotPresent
Also, again to create real-time updates can be completed by kubectl:
kubectl apply -f k8s-demo.yaml
Again verify: Mirror has become 1.1
The external interface accessible through the return data has also been updated:
Follow the steps above, we again update to 1.2, the final effect is as follows:
Third, the rollback practice
When we update every application by kubectl current configuration K8S will be recorded, saved as a revision (Revision), so that you can roll back to a specific revision. Recall that we like in SVN version management tool, Git in, you can easily roll back to a previous revision in.
The default configuration, K8S only the most recent of several revision, revision number can be increased by revisionHistoryLimit property in Deployment configuration file. For example the following example, the revision number is set to 10:
apiVersion: apps/v1 kind: Deployment metadata: name: edc-webapi-deployment namespace: aspnetcore spec: revisionHistoryLimit: 10 ......
Here, in order from the example above, we find that there are some bug V1.2 version, we need to roll back to the previous version V1.1:
kubectl rollout undo deployment edc-webapi-deployment -n aspnetcore
By external access interface to test: has a fall back to 1.1.
If you want to fall back to the old version farther it? At this time, we need to use --record commands. How to get it? Slowly come below:
（1）准备三个YAML配置文件，分别是：k8s-demo-v1.0.yaml，k8s-demo-v1.1.yaml及k8s-demo-v1.2.yaml。
（2）通过kubectl apply部署并更新应用，需要注意的就是加上 --record。
加上--record的作用在于将当前命令记录到revision（版次）记录中，这样可以方便我们在后面通过kubectl rollback时去指定revision。我们也可以通过以下命令去查看各个revision的记录：
kubectl rollout history deployment edc-webapi-deployment -n aspnetcore
这里可以通过CHANGE-CAUSE看到每个revision的具体含义，前提条件就是需要在kubectl apply时加上--record参数。
（3）这时我们再进行rollback时，可以指定具体revision号了：
kubectl rollout undo deployment edc-webapi-deployment --to-revision=1 -n aspnetcore
验证一下是否回退到了1.0版本：
可以看到，已经从1.2回退到了1.0版本，符合预期！
四、Rolling Update原理
K8S中对于更Rolling Update的操作主要是针对ReplicaSet的操作，可以通过如下命令查看验证：
kubectl get replicaset -n aspnetcore -o wide
可以看到1.0的ReplicaSet edc-webapi-deployment-75977bbfdc创建之后然后被清理了，已经没有正在运行的Pod了。转而创建了新的ReplicaSet edc-webapi-deployment-797dd9b8f8，它有两个正在运行的Pod。
具体过程我们还可以通过以下命令查看：
kubectl describe deployment edc-webapi-deployment -n aspnetcore
通过日志可以看到，在进行对ReplicaSet的伸缩过程中，ReplicaSet会随之增加或减少一个Pod，从而完成Pod的替换以实现滚动更新的结果。
五、小结
滚动更新的最大好处在于零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。本文介绍了滚动更新的概念，然后通过更新和回滚一个ASP.NET Core应用演示了如何在K8S中进行滚动更新。
参考资料
（1）CloudMan，《每天5分钟玩转Kubernetes》
（2）李振良，《一天入门Kubernets教程》
（3）马哥（马永亮），《Kubernetes快速入门》
（4）go4it，《使用kubernetes的deployment进行RollingUpdate》