快速交付云原生应用的多种发布策略详解

前言

软件技术更新换代很快，但我们追求的目标是一直不变的，那就是在安全稳定的前提下，增加应用的部署频率，缩短产品功能的迭代周期，这样的好处就是企业可以在更短的时间内获得产品的价值、更快地获得客户反馈和响应客户需求，从而进一步提升产品的竞争力；除此之外，企业还可以释放更多的资源投入到创新业务的研发上，创造更多的价值，这是一个良性循环的过程。

应用产品的快速迭代诚然能给我们带来各种各样的好处，但挑战也与其并存。更高频率的应用发布，意味着线上业务有不可预期故障的风险更大，除了产品上线之前在预发测试环境中充分测试验证迭代功能之外，制定最合适的应用发布策略就是另外一个非常重要的话题，因为它可以最大限度的降低业务故障的风险以及带来的损失。

云原生应用交付的关键点

我们说更频繁地产品迭代意味着更大的故障风险，传统应用如此，云原生应用更是如此，因为云原生应用通常都是基于云的分布式部署模式，且每个应用可能是由多个功能组件互相调用来一起提供完整的服务的，每个组件都有自己独立的迭代流程和计划。在这种情况下，功能组件越多，意味着出错的概率越大。那么如何在应用交付层面对上述这些痛点做出改进，我们总结出以下几个云原生应用交付的关键点。

• 如何充分利用云原生架构基础设施的优势。这个优势我们可以简单总结为两点：弹性和高可用
• 如何具有跨平台移植和交付的能力。基础设施底层的计算、存储、网络资源有很大的差异化，在以前，基础架构的不同是由上层应用决定的，而云原生应用的交付需要具有跨平台移植和交付的能力
• 如何实现应用运维自治化。自治化不等于自动化，自动化是指触发一个流程，流程结束后能自动达到想要的一个预期结果，而自治化是指应用再高可用的运行态时，如果其中某个功能组件的某个副本出现故障，应用能自动移除故障副本并补充新的应用副本
• 如何让应用变得更具有可预测性。应用的交付终态，在我们编写应用编排模板的时候就是可预测到的，如果应用的交付变得更有可预测性，那么风险也会最大程度地降低
• 如何提高应用更快的平均恢复时间。如果应用有超出了应用自治的能力范畴之外的故障发生需要人工介入，那更快的平均恢复时间就意味着更低的业务损失。

Kubernetes是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。它自身的平台能力已经满足了我们前面提到的大部分需求。Kubernetes使用容器技术部署应用，这样的好处包括但不限于：

• 应用程序创建和部署更敏捷
• 可移植性
• 环境一致性
• 松耦合和分布式
• 资源隔离
• 高效率和高密度的资源利用
  

Kubernetes又提供了应用管理、调度、监控和运维的强大能力：

• 服务发现和负载均衡能力
• 应用的自动部署和回滚能力
• 应用的自治修复能力
• 存储编排能力
• 密钥和配置管理能力

但Kubernetes它也有很多功能是不提供但允许扩展的部分，比如日志采集、监控报警等能力，下面这张图就是阿里云容器服务是在支持标准Kubernetes的基础上对与用户息息相关的能力做了增强和提升后的架构大图，包括提供最大的弹性化与低廉成本的全球化接入能力，强大的安全架构支撑能力，深度整合阿里云基础资源服务的能力并经过双十一验证和沉淀了海量用户经验，同时支持专有、托管、无服务化、边缘和神龙裸金属等多种产品形态，我们今天后面的所有演示就是在此平台上做的。

应用交付的边界

在Kubernetes中应用交付的边界是什么？从简单处入手，我们可以认为应用的交付就是它的网络服务模式，服务的的后端资源以及业务数据的持久化存储，这些资源被分别抽象成service、deployment/pod，volume资源等。

以一个wordpress应用为例，它包括两个功能组件，前端组件处理用户请求，后端组件存储数据，前端组件包括一个frontend service和3个pod，后端组件包括一个backend service和一个pod组件，所以这个wordpress应用交付的资源就是2个service和总共4个后端pod。这个后端的pod资源我们在kubernetes中通过deployment来统一管理，service资源相当于一个负载均衡器，把请求路由到后端pod上，它涉及集群内各个组件之间调用以及外部用户访问集群内服务，所以有不同的种类划分。

根据服务暴露的方式不同，可以分为以下几种：

ClusterIP

通过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP（Cluster IP），实现集群内的访问。为最常见的方式。

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: ClusterIP      # 默认的service类型，服务仅暴露为集群内部可访问
  ports:
    - port: 80         # 暴露给集群内部的服务端口
      targetPort: 80   # 容器监听的服务端口
      protocol: TCP
  selector:
    app: wordpress     # 转发请求到有相同标签的后端pod

NodePort

NodePort是把service的port映射到集群节点的一个端口上，如果你不指定这个端口，系统将选择一个随机端口。大多数时候我们应该让 Kubernetes 来选择端口，用户自己来选择可用端口代价太大。

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: NodePort       # NodePort service类型，服务暴露一个固定的静态端口用于集群外部访问
  ports:
    - port: 80         # 暴露给集群内部的服务端口
      targetPort: 80   # 容器监听的服务端口
      protocol: TCP
      nodePort: 31570  # 集群外部可以通过此端口访问服务
  selector:
    app: wordpress     # 转发请求到有相同标签的后端pod

NodePort的方式虽然可以把服务暴露给集群外访问，但是也有很多缺点：

• 每个端口只能是一种服务
• 端口范围有限制，一般是30000-32767
• 如果节点的IP地址变化了的话，你需要做一些变更操作去适配
  所以在生产中一般不推荐这种方式，但如果你的应用对成本比较敏感又能容忍服务有不可用窗口期的话，是可以使用这种方式的

LoadBalancer

是服务暴露到集群外或者公网上的标准方式，但它依赖cloud provider提供的一个负载均衡器的能力，负载均衡器会单独分配一个ip地址并监听后端服务的指定端口，请求的流量会通过指定的端口转发到后端对应的服务。

apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  type: LoadBalancer       # LoadBalancer service类型，一般依赖于公共云厂商供的负载均衡能力
  ports:
    - port: 80         # 暴露给集群内部的服务端口
      targetPort: 80   # 容器监听的服务端口
      protocol: TCP
  selector:
    app: wordpress     # 转发请求到有相同标签的后端pod

Ingress

ClusterIP 服务类型仅限集群内通信，NodePort可以实现暴露服务访问入口，但每个节点都会占用一个端口，会增加端口管理的复杂性，LoadBalancer通常需要第三方云提供商支持，有一定的约束性。而Ingress这个服务类型跟我们前面的三种服务类型不一样，它实际上不是一种服务类型，而是类似一种集群服务入口的存在，它可以基于你配置的不同路径或者子域名把流量路由到对应的后端服务，更像是一个“智能路由”服务

前面是介绍了一些应用发布涉及到的资源类型，以及service资源类型的几种模式，那service是如何找到对应的后端pod的呢，这个就是标签的作用，我们可以每个应用的pod和service都被打了同样的标签，这个标签的机制就是我们后面要讲的几种应用发布策略的关键点了。

应用的发布策略

在kubernetes集群中除了根据业务需求选定服务暴露方式外，为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就非常重要了。

滚动发布

第一种应用发布策略呢就是滚动发布，这也是比较常见的策略，它是通过逐个替换实例来逐步部署新版本的应用，直到所有实例都被替换完成为止。 我们看这个示意图，当前我的应用提供的服务版本是v1， 这个服务的后端有3个副本， 但我更新版本v2的时候，它是一个副本一个副本地开始替换，直到最终服务的后端全部替换成v2版本。

一个应用示例的编排文件如下：
go-demo-v1.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-demo
  template:
    metadata:
      labels:
        app: go-demo
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
  type: ClusterIP

部署版本v1：

$ kubectl apply -f go-demo-v1.yaml

查看pod运行状态：

$ kubectl get po
NAME                       READY   STATUS    RESTARTS   AGE
go-demo-78bc65c564-2rhxp   1/1     Running   0          19s
go-demo-78bc65c564-574z6   1/1     Running   0          19s
go-demo-78bc65c564-sgl2s   1/1     Running   0          19s

访问应用服务：

$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1

更新go-demo-v1.yaml为go-demo-v2.yaml并更新镜像tag：

...
registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
...

部署版本v2：

$ kubectl apply -f go-demo-v2.yaml

可以查看pod会被新版本pod逐个替换：

$kubectl get po -w
NAME                                READY   STATUS              RESTARTS   AGE
application-demo-8594ff4967-85jsg   1/1     Running             0          3m24s
application-demo-8594ff4967-d4sv8   1/1     Terminating         0          3m22s
application-demo-8594ff4967-w6lpz   0/1     Terminating         0          3m20s
application-demo-b98d94554-4mwqd    1/1     Running             0          3s
application-demo-b98d94554-ng9wx    0/1     ContainerCreating   0          1s
application-demo-b98d94554-pmc5g    1/1     Running             0          4s

访问服务会发现在应用滚动升级过程中，版本v1和v2都会被访问到，这个时间的长短取决于应用的启动速度：

$ while sleep 0.1; do curl http://172.19.15.25; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2
Version: v1
Version: v1
Version: v2

滚动发布优点就是它比较简单，而且不会占用太多的计算资源；缺点是

• 版本在实例之间缓慢替换
• 这个滚动发布可能需要一定时间
• 无法控制流量
  从应用再集群中的终态上来说，集群中要么只有版本1的应用后端，要么只有版本2的后端；如果版本2有缺陷，那么线上服务应用到的就是整体用户， 虽然我们有机制可以快速回滚，但涉及到整体用户使用故障的代价还是太大。

蓝绿发布

第二种就是蓝绿发布，蓝/绿发布是应用版本1与版本2的后端pod都部署在环境中，通过控制流量切换来决定发布哪个版本。 与滚动发布相比，蓝绿发布策略下的应用终态，是可以同时存在版本1和版本2两种pod的，我们可以通过service流量的切换来决定当前服务使用哪个版本的后端。

一个应用示例的编排文件如下：
go-demo-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v1
spec:
  replicas: 4
  selector:
    matchLabels:
      app: go-demo
      version: v1
  template:
    metadata:
      labels:
        app: go-demo
        version: v1
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

go-demo-v2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v2
spec:
  replicas: 4
  selector:
    matchLabels:
      app: go-demo
      version: v2
  template:
    metadata:
      labels:
        app: go-demo
        version: v2
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v1
  type: ClusterIP

部署以上3个资源：

$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml

访问服务可以看到目前只访问到版本1的服务：

$ while sleep 0.1; do curl http://172.19.8.137; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1

修改service.yaml的spec.selector下version=v2为：

apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v2
  type: ClusterIP

重新部署：

$ kubectl apply -f service.yaml

重新访问服务可以看到很快切换到了版本2上：

$ [root@iZbp13u3z7d2tqx0cs6ovqZ blue-green]# while sleep 0.1; do curl http://172.19.8.137; done
Version: v2
Version: v2
Version: v2

我们刚才说道滚动升级有一个过程需要时间，即使回滚，它也需要一定的时间才能回滚完毕，在新版本应用有缺陷的情况下，蓝绿发布的策略可以快速在v1和v2两个版本之前切流量，所以这个切换流量的时间跟滚动升级相比就缩短了很多了，但蓝绿发布的缺点跟滚动发布相同的就是这个缺陷会影响到整体用户，服务要么百分百切换到版本2上，要么百分百切换到版本1上，这是个非0即100的操作，即使蓝绿发布策略可以大大缩短故障恢复时间，但在某些场景下也是不可接受的。 而且集群环境中同时存在两个版本的pod副本，资源占用的话相比滚动发布是2倍的

金丝雀发布（灰度发布）

第三种要介绍的发布策略是金丝雀发布，金丝雀部署是应用版本1和版本2同时部署在环境中，并且用户请求有可能会路由到版本1的后端，也可能会路由到版本2的后端，从而达到让一部分新用户访问到版本2的应用。 这种发布策略下呢我们可以通过调整流量百分比来逐步控制应用向新的版本切换，它与蓝绿部署相比，它不仅继承了蓝绿部署的优点，而且占用资源优于蓝绿部署所需要的2倍资源，在新版本有缺陷的情况下只影响少部分用户，把损失降到最低。

对于灰度发布的概念来说，有人认为它跟金丝雀发布讲的是一个东西，有人认为它们不同，它跟金丝雀发布的过程是相同的，但目的有所不同，金丝雀发布它更倾向于能快速获取用户的一些反馈，比如我可能不确定我的这个新版本功能的用户体验是否能被大众很好的接受，我期望能得到线上用户的一些及时反馈，在产品侧做功能体验做调整之后再迭代v3版本；而灰度发布则是我的产品功能已经设计并开发的很完善了，现在就是要逐步替换线上的旧版本，但是要控制发布可能带来的风险，所以要灰度发布。

示例应用1如下， 这个示例中我们通过pod的数量来控制流量比例：
go-demo-v1.yaml 设定副本数为9

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v1
spec:
  replicas: 9
  selector:
    matchLabels:
      app: go-demo
      version: v1
  template:
    metadata:
      labels:
        app: go-demo
        version: v1
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

go-demo-v2.yaml 设定副本数为1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-demo
      version: v2
  template:
    metadata:
      labels:
        app: go-demo
        version: v2
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: go-demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
  type: ClusterIP

部署以上3个资源：

$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml

访问服务可以看到基本上是10%的流量切换到版本2上：

$ while sleep 0.1; do curl http://172.19.8.248; done
Version: v1
Version: v2
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1

另外我们可以使用nginx ingress controller来控制流量切换，这个方式要更精准。
go-demo-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-demo
      version: v1
  template:
    metadata:
      labels:
        app: go-demo
        version: v1
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

go-demo-v2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-demo-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-demo
      version: v2
  template:
    metadata:
      labels:
        app: go-demo
        version: v2
    spec:
      containers:
      - name: go-demo
        image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

service-v1.yaml

apiVersion: v1
kind: Service
metadata:
  name: go-demo-v1
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v1
  type: ClusterIP

service-v2.yaml

apiVersion: v1
kind: Service
metadata:
  name: go-demo-v2
spec:
  ports:
  - port: 80
    targetPort: 8080
    name: go-demo
  selector:
    app: go-demo
    version: v2
  type: ClusterIP

ingress.yaml， 设置nginx.ingress.kubernetes.io/service-weight: | go-demo-v1: 100, go-demo-v2: 0， 版本1 100%流量， 版本2 0%流量：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: |
        go-demo-v1: 100, go-demo-v2: 0
  name: go-demo
  labels:
    app: go-demo
spec:
  rules:
    - host: go-demo.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: go-demo-v1
              servicePort: 80
          - path: /
            backend:
              serviceName: go-demo-v2
              servicePort: 80

部署以上4个资源：

$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service-v1.yaml -f service-v2.yaml -f nginx.yaml

访问服务可以看到流量100%到版本1上：

$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1
Version: v1

更新ingress.yaml， 设置流量比为50:50

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: |
        go-demo-v1: 50, go-demo-v2: 50
  name: go-demo
  labels:
    app: go-demo
spec:
  rules:
    - host: go-demo.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: go-demo-v1
              servicePort: 80
          - path: /
            backend:
              serviceName: go-demo-v2
              servicePort: 80

访问服务可以看到流量50%到版本1上， 50%到版本2上：

$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v2
Version: v1
Version: v1
Version: v1
Version: v2
Version: v2
Version: v1
Version: v1
Version: v2
Version: v2

更新ingress.yaml， 设置流量比为0:100

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: |
        go-demo-v1: 0, go-demo-v2: 100
  name: go-demo
  labels:
    app: go-demo
spec:
  rules:
    - host: go-demo.example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: go-demo-v1
              servicePort: 80
          - path: /
            backend:
              serviceName: go-demo-v2
              servicePort: 80

访问服务可以看到流量100%到版本2上：

$ while sleep 0.1; do curl http://go-demo.example.com; done
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2
Version: v2

不管是金丝雀发布还是灰度发布，缺点就是发布周期相对来说要慢很多。

在这些发布策略当中，当你在开发测试环境中对用用做更新发布的话，用滚动发布。在生产环境，滚动更新或者蓝绿发布在新版本已经提前测试充分的情况下可以用。如果对新版本的应用的更新需要最大限度地控制风险，降低故障对用户的影响的话，那就使用金丝雀发布或灰度发布。以上就是我们在kubernetes当中常用的几种发布策略的介绍。