探秘金融级云原生发布工做负载 CafeDeployment

本文做者:蚂蚁金服 昊天,枫晟node

本文简单介绍了蚂蚁金服 SOFAStack 的 Kubernetes 自定义资源 CafeDeployment 的开发背景和功能特性,咱们将会在6月25日的 KubeConf 上对其作详细的介绍和演示,欢迎你们来交流。api

背景介绍

Kubernetes 原生社区 Deployment 和 StatefulSet 解决了“服务节点版本一致性”的问题,而且经过 Rolling Update 实现了滚动升级,提供了基本的回滚策略。对于高可用建设要求不高的“年轻”业务,是一个不错的选择。安全

可是,在金融场景下,要解决的场景复杂得多。所以咱们在金融分布式架构-云应用引擎(SOFAStack-CAFE,参见金融级云原生探索实践系列 - 开篇)中提出了 CafeDeployment 的云原生模型,致力于解决如下问题:bash

1. IP 不可变
架构

对于不少运维体系建设较为早期的用户,使用的服务框架、监控、安全策略,大量依赖 IP 做为惟一标识而被普遍使用。迁移到 Kubernetes 最大的改变就是 IP 会飘,而这对于他们来讲,无异于运维、服务框架的推倒重来。app

2. 金融体系下的高可用
框架

Deployment/StatefulSet 没法根据特定属性进行差别化部署。而在以同城双活为建设基础的金融领域,为了强管控 Pod 的部署结构(即保证每一个机房/部署单元都有副本运行),若经过原生组件进行部署,咱们不得不维护多个几乎如出一辙的 Deployment/StatefulSet,来保证 Pod 必定会飘到指定机房/部署单元的 node 上。在规模上到必定程度后,这无疑加大了运维管控的复杂度和成本。运维

3. 灵活的部署策略分布式

Deployment 没法控制发布步长,StatefulSet 虽然能够控制步长,可是每次都须要人工计算最新版本须要的副本数并修改 Partition,在多机房/部署单元的状况下,光想一想发布要作的操做都脑壳炸裂。ui

在面对以上这些问题的时候,咱们思考:能不能有一个相似 Deployment 的东西,不只能够实现副本保持,而且能协助用户管控应用节点部署结构、作 Beta 验证、分批发布,减小用户干预流程,实现最大限度减小发布风险的目标,作到快速止损,并进行修正干预。这就是咱们为何选择定义了本身的资源——CafeDeployment

模型定义

image.png

CafeDeployment 主要提供跨部署单元的管理功能,其下管理多个 InPlaceSet。每一个 InPlaceSet 对应一个部署单元。部署单元是逻辑概念,他经过 Node 上的 label 来划分集群中的节点,而 InPlaceSet 则经过 NodeAffinity 能力,将其下的 Pod 部署到同一个部署单元的机器上。由此实现 CafeDeployment 跨部署单元的管理。

CafeDeployment 做为多个部署单元的上层,除了提供副本保持,历史版本维护等基本功能,还提供了跨部署单元的分组扩容,分组发布,Pod 调度等功能。模型定义以下:

apiVersion: apps.cafe.cloud.alipay.com/v1alpha1
kind: CafeDeployment
metadata:
  ......
spec:
  historyLimit: 20
  podSetType: InPlaceSet        # 目前支持底层PodSet:InPlaceSet,ReplicaSet,StatefulSet
  replicas: 10
  selector:
  matchLabels:
    instance: productpage
    name: bookinfo
  strategy:
    batchSize: 4                # 分组发布时,每组更新的Pod数目
    minReadySeconds: 30
    needWaitingForConfirm: true # 分组发布中,每组结束时是否须要等待确认
    upgradeType: Beta           # 目前支持发布策略:Beta发布,分组发布
    pause: false
  template:
    ......
  volumeClaimTemplates:         # 用于支持statefulSet
  serviceName:                  # 用于支持statefulSet
  topology:
    autoReschedule:
      enable: true              # 是否启动Pod自动重调度
      initialDelaySeconds: 10
    unitType: Cell              # 部署单元类型:Cell,Zone,None
    unitReplicas:
      CellA: 4                  # 固定某部署单元的Pod数目
    values:                     # 部署单元
      - CellA
      - CellB复制代码

由于咱们将大部分的控制逻辑都抽取到上层 CafeDeployment 中,所以咱们从新设计了 InPlaceSet,将它作得足够简单,只关注于“InPlace”相关的功能,即副本保持和原地升级,保持 IP 不变的能力,模型定义以下:

spec:
  minReadySeconds: 30
  replicas: 6
  selector:
    matchLabels:
      instance: productpage
      name: bookinfo
      deployUnit: CellB
  strategy:
    partition: 6    # 控制发布时更新Pod的进度
  template:
    ......复制代码

功能特性

灵活的分组定义

CafeDeployment 支持跨部署单元的分组扩容,Pod 调度,分组发布。分组策略主要分为两种,Beta 分组和 Batch 分组:

  • Batch 分组

即根据 BatchSize 将 Pod 分为多个批次,每批中的 Pod 会同时发布。待用户确认(needWaitingForConfirm=true时)无误时,或当前批次全部 Pod 都 ready 后(needWaitingForConfirm=false 时),则会开始进行下一组的发布。

在分组暂停时,CafeDeployment 会被打上 Annotation: cafe.sofastack.io/upgrade-confirmed=false,用户可经过将 Annotation 的值改成 true,确认当前分组。

  • Beta 分组

相比 Batch 发布,会在第一组发布以前多一步 Beta 分组。此组会在每一个部署单元内选择一个 Pod 进行发布,以减少错误配置带来的影响。若用户确认无误,能够确认继续,以进入正常的 Batch 发布流程。

安全的分组扩容和发布能力

分组扩容

为预防不正确的配置形成大量错误 Pod 同时建立,占用大量资源等意外状况出现,CafeDeployment 支持分组扩容,以下降风险。

在以下配置时,CafeDeployment 会建立两个 InPlaceSet 实例,并开始分组建立(扩容)Pod。

spec:
  ......
  replicas: 10                  # 副本数为10
  strategy:
    upgradeType: Beta           # Beta发布
    batchSize: 4                # 每组Pod数为4
    needWaitingForConfirm: true # 分组暂停
  topology:
    ......
    values:                     # 两个部署单元,CellA和CellB
      - CellA
      - CellB复制代码

初始时,InPlaceSet 的 replicas 和 partition 都为 0,CafeDeployment 会在以后默认将 10 个 Pod 均分到两个部署单元中,并参考 Beta 发布和 BatchSize 配置,分红 3 组进行,以下图所示。

image.png

第一组,为 Beta 分组,会在两个部署单元中各建立一个 Pod。待 Pod 都 ready 后,会要求用户进行确认,方可继续第二组。

第二组,为普通发布,由于 BatchSize=4,因此会在两个部署单元中各建立 2 个 Pod。以后一样须要通过用确认才会继续进入第三组。若 CafeDeployment 中的配置 needWaitingForConfirm=false,则在当前批次的全部 Pod 都 ready 后,会自动进入下一组的发布。

第三组,为最后一组发布,当全部 Pod 都 ready 后,则会结束当前发布。

发布过程当中若出现问题,可经过修改 CafeDeployment 的 replicas 值等方式结束当前发布。

分组发布

当修改 CafeDeployment 中的 PodTemplate 里的相关配置后,就会触发发布流程。目前一样支持 Beta 发布和 Batch 发布两种类型。当 CafeDeployment 有以下配置时,CafeDeployment 的 10 个 Pod 会被分到三组中进行发布。

spec:
  ......
  replicas: 10                  # 副本数为10
  strategy:
    upgradeType: Beta           # Beta发布
    batchSize: 4                # 每组Pod数为4
    needWaitingForConfirm: true # 分组暂停
  topology:
    ......
    values:                     # 两个部署单元,CellA和CellB
      - CellA
      - CellB复制代码

第一组为 Beta 分组,每一个部署单元会选择一个 Pod 进行发布。

第二组和第三组各有 4 个 Pod。

若当前 Pod 在部署单元的分配不均匀,以下图所示,CafeDeploymentController 也会负责计算并分配对应的配额给两个部署单元,来对发布进度进行统一的调度。

若是配置了分组暂停,则每组结束后都会须要用户进行确认。

image.png

Pod 发布与外部的通讯机制

使用 Readiness Gate 做为 Pod 是否能够承载外部流量的标识。在发布前,经过将 Readiness Gate 设置为 False,使得当前 Pod IP 在 Endpoint 上从 addresses 列表转移到 notReadyAddresses 列表;在发布完成后,将 Readiness Gate 设置为 True,Pod IP 在 Endpoint 上又会从 notReadyAddresses 转移到 addresses。相关流量组件经过 Watch Endpoint 上地址变化完成切流和引流,并经过 finalizer 对 Pod 进行打标保护。

pod-graceful-shutdown.jpg

自适应的 Pod 重调度

在建立 Pod 的过程当中,可能会遇到某个部署单元资源不足的状况,新的 Pod 会一直 Pending。这时若是打开自动重调度功能(以下所示),则 CafeDeploymentController 会尝试将 Pod 分配到其余未出现资源紧张的部署单元上。

spec:
  topology:
    autoReschedule:
      enable: true            # 是否启动Pod自动重调度
      initialDelaySeconds: 10 # Pod因为资源不足,10秒后会被尝试重调度复制代码

在 Pod 部署过程当中,以下图所示,

image.png

若是在最后一批分组发布的时候,出现 Pod 因资源不足而没法启动的状况,则 CafeDeploymentController 会自动将此 Pod 的配额调度到其余的资源充足的部署单元中。

固然,CafeDeployment 也支持手动指定 Pod 的分配方案,经过修改以下相关配置能够进行精确的指定:

spec:
  topology:
    ......
    unitReplicas:
      CellA: 4    # 固定某部署单元的Pod数目
      CellB: 10%  # 经过百分比指定
    values:
      - CellA
      - CellB
      - CellC复制代码

这时,CafeDeploymentController 会优先根据指定方案进行 Pod 分配。

可适配多种社区工做负载

CafeDeploymentController 自己只提供了发布策略和跨部署单元管理的一个抽象实现,它对底层的 Pod 集合是经过 PodSetControlInterface 接口来控制。所以,经过对此接口的不一样实现,能够保证对接多种 workload。目前已经实现了与 InPlaceSet 和 ReplicaSet 的对接,对 StatefulSet 的对接也在进行中。

image.png

由于 CafeDeployment 只负责各类策略的实现,因此并不会对 Kubernetes 原生的功能有任何入侵。ReplicaSetController,StatefulSetController 会继续履行他们以前的职责,保证各自的特性。

总结

CafeDeployment 的设计与实现,并不是一日之功,咱们走过弯路,也受到过质疑。但咱们仍然坚信,在金融场景下须要这样的一种工做负载,由于不管是 Deployment、StatefulSet 仍是 InPlaceSet,为了实现高可用和无损发布,都无疑须要付出比 apply yaml 更多的精力,而这些每每都不是一个业务开发所关心的。

目前,CafeDeployment所提供的各类发布策略,灵活的分组发布,高可用和无损升级的能力已成为了金融云应用发布的重要一环,为产品层提供容器云原生的部署能力,并给咱们用户的生产力和效率带来极大提高。后续咱们将会继续加强 CafeDeployment 的能力,好比提供更灵活的自定义拓扑结构、机房/部署单元内更灵活的部署策略以知足更多的高可用发布场景的需求等。

KubeCon + CloudNativeCon | Open Source Summit 2019 中国论坛

分享主题:《为互联网金融关键任务场景扩展部署》-蚂蚁金服

分享嘉宾:

Mengyi ZhouMengyi Zhou is a software engineer at PaaS cloud service team of Ant Financial, where she focuses on building large-scale deployment platform for both vm and container services on cloud. She indulges herself into devops workflow and experience. She is one of the core developer of AntCloud kubernetes service.

Ke WuKe Wu is a Senior Engineer from Ant Financial. Ke works in Ant Financial PaaS cloud service team, with a focus on AntCloud Kubernetes Service development including extending Kubernetes for financial scenario. Ke has worked on PaaS and Big Data for years. He is also a contributor of Kubernetes.

活动时间:2019.6.25

详情请戳“这里”。

公众号:金融级分布式架构(Antfin_SOFA)

相关文章
相关标签/搜索