SpringCloud 应用在 Kubernetes 上的最佳实践 —— 线上发布(可回滚)

我们两清 提交于 2020-08-14 02:28:17

通常一次应用的线上发布就表示了一次新功能的上线。在上线过程中,可能发生一些非预期的情况,如新版本软件有bug,或者功能不达预期,就会影响了线上客户的使用。 为了尽快减少对线上用户的影响,发布系统需要提供回滚到前一个或前几个版本的能力。达到快速恢复线上业务的目的。

从应用的部署变更层次来看,可以分为以下三层:

1.png

所以对应了以下的回滚场景:

  • 回滚应用内的配置,适用于由于应用配置变更导致的问题。此时如果应用能够实现动态的配置加载,通过回滚配置就能实现业务恢复的目的。否则需要重启应用
  • 回滚应用代码的版本,适用于代码修改导致的问题。此时需要回滚代码的版本(镜像),重启应用。
  • 回滚应用的工作负载与运维配置(基础设施层)。

 

应用内配置回滚

应用内的配置通常与应用系统需要或业务逻辑配置有关,如配置数据库的连接信息,业务规则配置等,配置的变更也很容易造成线上系统的问题,一般的做法是通过configmap或properties配置文件来实现,这种情况下很难做到动态推送和回滚的能力,因为回滚需要保存不同版本的配置。

通过 分布配置管理(ACM)(EDAS默认支持)很容易实现配置的集中管理,回滚和灰度,分布式推送,审计等功能。可以在ACM或EDAS的控制台上实现一键回滚,如下图所示:

2.png

 

应用代码回滚

Deployment是一种常见部署的应用的workload,回滚代码其实对应了回滚对应代码版本的镜像,其实就是对应就是Deployment的回滚,Kubernetes可以通过以下方式支持Deployment的回滚。

 

Deployment回滚

在一个标准的 Kubernetes 体系下,如果出现新版本的pod不能正常工作,需要将deployment回滚到历史版本,Kubernetes 提供了原生的支持;其原理是在默认情况下,kubernetes 会将历史记录保留在系统中,直接使用使用 rollout 命令回滚即可,如下:。

  • 回滚到上一个版本
kubectl rollout undo deployment.v1.apps/{deployment.name}
  • 回滚到指定的版本

    • 可以通过kubectl rollout history查看历史的版本
kubectl rollout history  deployment.v1.apps/{deployment.name}
  • 可以通过以下命令回滚到指定的版本
kubectl rollout undo deployment.v1.apps/{deployment.name} --to-revision={version}

 

EDAS中应用回滚

而在 EDAS 中,结合了原生的能力做了更丰富的白屏的体验,我们就发布过程中发布完成后两个场景分别描述。

 

发布过程中回滚

发布过程中回滚是指在应用发布过程中,就发现了问题,需要将应用回滚到前一个版本。此时的操作就是中断发布流程,将已经升级完成后或正在升级的服务器回滚到前一个版本。

EDAS在每次变更时候,可以直接中断发布流程,一键回滚。如下图所示:

3.png

另外,EDAS发布系统提供单批,分批,金丝雀灰度等多种发布形式,在分批和金丝雀灰度的发布的时候,EDAS还提供不同批次的监控信息,如系统指标,应用指标,应用异常检测等能力,提供快速发现问题能力,如果存在问题,可以立即进行回滚。如下图所示:

4.png



我们推荐的方式也是在发布过程中尽量使用分批和金丝雀的能力,以将发布引起的不可用降至最小。

 

发布完成后回滚

发布后回滚是指一次部署过程已经完成,包含部署成功或失败。这个时候,可以通过部署历史的版本来实现回滚的功能。EDAS 默认会存储最多十个部署过的版本,如下图所示:

5.png

通过以上的功能,基本上可以覆盖应用在上线过程中需要回滚的场景。减少由于系统发布出问题,造成系统功能使用上的影响。

 

应用自动回滚

从上面的介绍,可以看到回滚的操作都是人工进行的,其实在一些场景里,可以根据一些监控指标,如CPU,load,内存等维度,快速发现问题,就能做到自动回滚,可以能够更快地恢复系统。在 Kubernetes 的体系中,Flagger(https://github.com/weaveworks/flagger) 就是能够实现自动回滚的一个很好的工具。

 

应用工作负载和运维配置回滚

上面介绍了应用内配置和应用代码回滚的方式,在常见的变更中,还存在工作负载及运维配置的变更,如更改工作负载的类型,变更JVM参数,日志配置, 弹性伸缩等。其中JVM参数等通常可以随Deployment进行回滚,但是类似Kubernetes service,日志,弹性伸缩规则等这些基础设施和运维相关的能力回滚就很难做到了。需要将应用的代码,工作负载,运维配置等实现配置化来实现回滚的能力。

这里推荐阿里巴巴与微软联合提出的OAM(Open Application Model)的规范,他定义了应用的统一交付模型.

6.png


在OMA中,一个应用程序包含以下几个核心的理念:

  • Component: 是指应用中的组件,可以是应用运行所依赖的服务如MySQL数据库等,也可以是应用的本身,如Spring cloud的服务提供者。可以通过Component的定义规范来编写一个组件。
  • Trait:是指应用的运维特征,描述了应用部署在具体环境中的运维特征,比如弹性伸缩规则和Ingress配置等,这些运维特征会应用到具体的组件上。
  • Applicationconfiguration:是将Components和traits组装成一个真正能运行起来应用的定义。这个配置文件就是OAM规范中的一个声明式是API,通过它就能实例化出对应的,真实运行的应用。

一个OAM的应用例子如下:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: springcloud-provider-deployment
  annotations:
    version: v1.0.0
    description: "Description of this deployment"
spec:
  components:
    - componentName: springcloud-provider-component
      parameterValues:
        - name: PARAMETER_NAME
          value: SUPPLIED_VALUE
        - name: ANOTHER_PARAMETER
          value: "AnotherValue"
      traits:
        - name: manualscaler.core.oam.dev
          version: v1
          spec:
            replicaCount: 3
      scopes:
        - scopeRef:
            apiVersion: core.oam.dev/v1alpha2
            kind: NetworkScope
            name: example-vpc-network

通过OAM的ApplicationConfiguration这份配置,就能描述线上真正运行的应用,结合能将配置版本化的系统,如Git,ACM等,采用对应的ApplicationConfiguration的版本,就能实现应用的一键回滚。EDAS里就是通过OAM规范来管理Kubernetes的应用,结合OAM声明式API的方式,EDAS里将会实现多种应用回滚的场景,为线上业务保驾护航。

 

后续及结语

本章我们介绍了EDAS的发布系统在EDAS Kubernetes集群上进行应用发布的时候,针对一些异常场景,如何进行快速回滚。但是如果出现问题,如何快速找到问题所在,接下来的文章我们将介绍,在EDAS里通过线上里联调来进行问题诊断。

 

原文链接:https://developer.aliyun.com/article/769309
本文为阿里云原创内容,未经允许不得转载。

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!