ASP.NET Core on K8S深入学习(5)Rolling Update

本篇已加入《.NET Core on K8S学习实践系列文章索引》,可以点击查看更多容器化技术相关系列文章。

一、什么是Rolling Update?

  为了服务升级过程中提供可持续的不中断的服务,K8S提供了Rolling Update机制,它可以使得服务近乎无缝地平滑升级,即在不停止对外服务的前提下完成应用的更新。滚动更新采用渐进的方式逐步替换旧版本Pod,如果更新不如预期,那么也可以通过回滚操作恢复到更新前的状态。

滚动更新的最大好处在于零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性。

  为了实践滚动更新,我们先做一些准备工作:

  (1)准备一个ASP.NET Core WebAPI项目,具体项目代码参见这里

  项目代码里边有三个版本,如下图所示:

  

  他们之间的差别在于一个接口的返回JSON数据,比如V1.0版本中返回的是Version: 1.0,而V1.1版本中返回的是Version:1.1,那么V1.2版本则是返回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"
            };
        }
    }

  (2)将此项目各个版本根据Dockerfile打成镜像,分别是k8s-demo:1.0,1.1,1.2

  (3)将本地镜像push到远程镜像仓库,这里我传送到了docker hub的一个公共仓库里边:

docker push edisonsaonian/k8s-demo:1.0
docker push edisonsaonian/k8s-demo:1.1
docker push edisonsaonian/k8s-demo:1.2

  

二、更新实践

  首先,我们先创建一个1.0版本到K8S中,准备YAML配置文件(这次我们将Deployment和Service的资源定义写在了一起):

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

  然后,通过kubectl进行创建:

kubectl apply -f k8s-demo.yaml

  通过kubectl进行验证:

  

  通过外部访问接口验证:

  

  假设1.0版本运行了一段时间,我们又做了一些优化准备发布1.1版本,那么这时我们可以借助Rolling Update进行滚动更新,只需要修改一下YAML配置文件:将镜像版本的Tag更改为1.1即可。

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

  同样,再次通过kubectl进行创建即可完成实时更新:

kubectl apply -f k8s-demo.yaml

  再次验证一下:镜像已经变成了1.1

  

  通过外部接口访问,返回数据也已经更新:

  

  按照上面的步骤,我们再次更新到1.2,最后的效果如下:

  

三、回滚实践

  当我们通过kubectl每次更新应用时,K8S都会记录下当前的配置,保存为一个revision(版次),这样就可以回滚到某个特定的revision。回想一下,我们在版本管理工具类似于SVN,Git中,都可以方便的回滚到之前的某个revision中。

  默认配置下,K8S只会保留最近的几个revision,可以在Deployment配置文件中通过revisionHistoryLimit属性增加revision数量。例如下面的例子,将revision数量设置为10:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: edc-webapi-deployment
  namespace: aspnetcore
spec:
  revisionHistoryLimit: 10
  ......

  下面,以上面的示例为例,我们发现V1.2版本中存在某些bug,需要回退到上一个V1.1版本:

kubectl rollout undo deployment edc-webapi-deployment -n aspnetcore

  

  通过外部访问接口验证一下:已经回退到了1.1了。

  

  如果想要回退到更远的老版本呢?这时,就需要借助--record命令了。怎么弄呢?下面慢慢道来:

  (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

作者:周旭龙

出处:https://edisonchou.cnblogs.com

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。

原文地址:https://www.cnblogs.com/edisonchou/p/aspnet_core_on_k8s_deepstudy_part5-1.html

时间: 2024-07-31 19:01:56

ASP.NET Core on K8S深入学习(5)Rolling Update的相关文章

ASP.NET Core on K8S深入学习(2)部署过程解析与Dashboard

上一篇<K8S集群部署>中搭建好了一个最小化的K8S集群,这一篇我们来部署一个ASP.NET Core WebAPI项目来介绍一下整个部署过程的运行机制,然后部署一下Dashboard,完成可视化管理.本篇已加入了<.NET Core on K8S学习实践系列文章索引>,更多内容请到索引中查看. 一.部署示例项目 1.1 准备一个ASP.NET Core WebAPI 这里准备一个空的ASP.NET Core WebAPI项目,使用默认自带的ValuesController控制器,

ASP.NET Core on K8S深入学习(8)数据管理

本篇已加入<.NET Core on K8S学习实践系列文章索引>,可以点击查看更多容器化技术相关系列文章. 在Docker中我们知道,要想实现数据的持久化(所谓Docker的数据持久化即数据不随着Container的结束而结束),需要将数据从宿主机挂载到容器中,常用的手段就是Volume数据卷.在K8S中,也提供了存储模型Volume,支持我们将应用中的数据持久化存储到容器中. 一.Volume 1.1 关于K8S Volume 为了持久化保存容器的数据,我们可以使用K8S Volume,其

ASP.NET Core on K8S深入学习(10)K8S包管理器Helm

本篇已加入<.NET Core on K8S学习实践系列文章索引>,可以点击查看更多容器化技术相关系列文章. 一.关于Helm 1.1 为何需要Helm? 虽然K8S能够很好地组织和编排容器,但是缺少一个更高层次的应用打包工具,而Helm就是专门干这个事的. 通过Helm能够帮助开发者定义.安装和升级Kubernetes中的容器云应用.同时,也可以通过Helm进行容器云应用的分享. 1.2 Helm的架构 Helm的整体架构如下图(图片来源-Kubernetes中文社区)所示: Helm架构由

ASP.NET Core on K8S深入学习(3-2)DaemonSet与Job

本篇已加入<.NET Core on K8S学习实践系列文章索引>,可以点击查看更多容器化技术相关系列文章. 上一篇<3-1 Deployment>中介绍了Deployment,它可以满足我们大部分时候的应用部署(无状态服务类容器),但是针对一些特殊的场景应用,就可以用到今天介绍的DaemonSet和Job. 一.DaemonSet 1.1 DaemonSet是个啥? Deployment的部署可以指定副本Pod分布在多个Node节点上,且每个Node都可以运行多个Pod副本.而D

ASP.NET Core on K8S学习初探(1)K8S单节点环境搭建

当近期的一个App上线后,发现目前的docker实例(应用服务BFF+中台服务+工具服务)已经很多了,而我司目前没有专业的运维人员,发现运维的成本逐渐开始上来,所以容器编排也就需要提上议程.因此我决定开始学习Kubernetes,会将学习当中的过程记录下来,预计会形成一个系列,暂且命名为:ASP.NET Core on K8S,而这个系列会由3个部分组成,且会在不同的时期写完: ASP.NET Core on K8S学习初探:在Docker for Windows中搭建单节点环境,初步了解有个感

ASP.NET Core 借助 K8S 玩转容器编排

原文:ASP.NET Core 借助 K8S 玩转容器编排 Production-Grade Container Orchestration - Automated container deployment, scaling, and management. 生产级别的容器编排系统--自动化的容器部署.扩展和管理. 1. 引言 由于最近在学习微服务,所以就基于之前docker的基础上把玩一下k8s(Kubernetes),以了解基本概念和核心功能. 2. What's k8s? k8s涉及到很多

ASP.NET Core on K8S学习初探(2)K8S基本概念快速一览

在上一篇<单节点环境搭建>中,通过Docker for Windows在Windows开发机中搭建了一个单节点的K8S环境,接下来就是动人心弦的部署ASP.NET Core API到K8S了.但是,在部署之前,我还是把基本的一些概念快速地简单地不求甚解地过一下. 一.K8S集群基本概念 (1)集群 首先,K8S集群也是需要多台服务器组成,作为容器的编排管理平台,只有一个节点在生产环境是不够的. (2)Node 其次,Node作为K8S集群中的工作节点,一个Node可以是VM或物理机,它运行真正

Kubernetes学习 Service + Rolling Update(三)

四.外网如何访问Service 除了 Cluster 内部可以访问 Service,很多情况下我们也希望应用的 Service 能够暴露给 Cluster 外部.Kubernetes 提供多种类型的 Service,默认是 Cluster IP.     (1)Cluster IP Service 通过 Cluster 内部的 IP 对外提供服务,只有 Cluster 内部的节点和 Pod 可访问,这是默认的 Service 类型,前面实验中的 Service 都是 CLuster IP. (2

ASP.NET Core中间件(Middleware)实现WCF SOAP服务端解析

ASP.NET Core中间件(Middleware)进阶学习实现SOAP 解析. 本篇将介绍实现ASP.NET Core SOAP服务端解析,而不是ASP.NET Core整个WCF host. 因为WCF中不仅仅只是有SOAP, 它还包含很多如消息安全性,生成WSDL,双工信道,非HTTP传输等. ASP.NET Core 官方推荐大家使用RESTful Web API的解决方案提供网络服务. SOAP 即 Simple Object AccessProtocol 也就是简单对象访问协议.