写点什么

如何在 Kubernetes 中对无状态应用进行分批发布

  • 2019-03-25
  • 本文字数:1957 字

    阅读完需:约 6 分钟

如何在 Kubernetes 中对无状态应用进行分批发布

在 Kubernetes 中针对各种工作负载,提供了多种控制器,其中 Deployment 为官方推荐,被用于管理无状态应用的 API 对象。本文将结合 Deployment 的特性,与常见的发布策略,以及我们在分批发布场景下的实践,做一些分享。

使用 Deployment 的场景

Deployment 在 Kubernetes 1.9 版本后被晋升为 GA 版本,基于 Spec 定义管理 Pod,无需关心每个实例的部署结构差异。


对于日常应用变更,可以满足如下典型场景:


• 应用变更,提供滚动升级策略,失败自动暂停。


• 应用变更失败,回滚到之前版本。


• 应用水平伸缩,支撑更高负载。


• 历史资源回收,不需要手工回收 Pod 或 ReplicaSet 资源。


Deployment 提供了 RollingUpdate 滚动升级策略,升级过程中根据 Pod 状态,采用自动状态机的方式,通过下面两个配置,对新老 Pod 交替升级,控制升级速率。


• Max Unavailable : 最大不可用实例数/比例。


• Max Surge : 调度过程中,可超过最大期望实例数的数/比例。

Kubernetes 生态中常见变更策略

基于 Deployment 的基础功能,结合 Service / Ingress / Istio 等流量控制组件,常见如下几种策略。具体对比分析与实现,可参考网上文章 ,这里不做过多展开:


  1. 滚动 Rolling:渐进式创建新版本,然后停止老版本,自动完成整个流程。



  1. 金丝雀 Canary:小部分流量,升级并导入新版本,手工验证完毕后,全量升级部署。



  1. 蓝绿 Blue/Green:创建出新版本,与老版本并存,通过切换流量实现发布与回滚。



  1. 重建 Recreate:杀死所有老版本,再用新版本重建。适用于开发、测试环境重新初始化。

  2. A/B 测试:部署新版本,流量控制倒流,长期在线。严格来说,这是一种线上业务与商业化验证的模式,不是变更策略。


为何需要分批暂停

在日常变更中,上述机制会让变更变得简单和便捷,但 Deployment 有如下限制:


• 需要手工回滚。


• 无法暂停滚动升级过程。


那么客户发布过程中,经常会遇到哪些情况,导致发布失败呢?我们 在整理与分析客户失败的发布时发现,主要出现在下面阶段:


• 开始灰度发布:因配置错误、打包异常、代码 BUG,或灰度后功能验证中发现了问题。


• 灰度验证成功,分批发布过程中:因网络白名单、资源不足、单机配置错误。


• 发布上线后:客户反馈、监控报警。


不难看出,一次常见的发布,在不同发布阶段,需要一个手动的、可以更细粒度的控制,减少对线上的不良影响。所以滚动升级的分批暂停功能,对核心业务发布来说,是质量保障必不可少的一环。那有没有什么方法,即可使用 Deployment 的滚动升级机制,又可以在发布过程中,结合金丝雀发布,分阶段暂停发布流程呢?

阿里在 K8s 中的分批发布实践:手动灰度+自动/手动分批发布

在阿里巴巴内部,分批发布是最常见的发布手段,用于保障线上发布。结合“可灰度、可监控、可回滚”作为基本发布要求,发布阶段可以分为主要两个阶段:


• 灰度阶段:先灰度 1-2 台,线上验证流量正确性。该阶段出现问题后,影响面可控、可快速回滚。大部分应用变更过程中,可能会出现的问题,均会在此阶段被发现或暴露。


• 自动/手动分批阶段:灰度成功后,一批批发布,为监控和报警,留足时间窗口,提前发现问题。


结合上述场景,我们采用管控 + 双 Deployment 方式实践了可暂停的分批发布。主要是基于如下两种发布策略的组合使用:


• Canary + Batch Rolling 策略结合。


• Canary : 灰度发布 XX 台,发布后暂停。线上验证流量。


• Batch Rolling : 分批发布 XX 批,发布后自动/手动继续发布下一批。


针对具体发布策略,我们的考虑和做法是这样的:


• 创建新 Deployment : 新版本发布,作为灰度验证的部署实例,初始实例数为 0;


• 进入灰度阶段:仅选取少量实例,扩容新版本 Deployment,缩容线上 Deployment;


• 进入分批阶段:根据分批实例,自动变更新老 Deployment 实例;


• 回滚阶段:反向做分批流程,将新版本实例数缩容到 0,老版本重新扩容到原有预期的实例数。



若发布过程中出现异常状态,如何及时发现错误,设置滚动升级卡点,或做到自动回滚呢?现在考虑如下:


• 自动健康检查:结合应用 Liveness / Readiness 检查配置,根据 Kubernetes Pod 状态,若发布过程中有任何发布失败情况,均停止当前批次新老 Deployment 的滚动升级操作。


• 终止发布回滚:认为任何的发布失败,不应该是等待排查问题再发一次,而是应该第一时间回滚代码,保障线上业务质量,然后再考虑第二次变更。所以当未完成本次分批发布时,终止变更,会自动回滚本次变更。

思考

通过扩展滚动更新,提供手工分批能力后,还有更多可以保障发布的策略与发布。


• 对灰度发布,结合流量控制规则,进行线上灰度验证。


• 结合更多监控指标,与线上服务情况,确定指标基线,作为发布卡点,让分批发布更自动化。




作者简介


孙齐(花名:代序),阿里巴巴高级工程师,负责企业级分布式应用服务 EDAS 及 EDAS Serveless 的开发和维护工作。


2019-03-25 15:084477

评论

发布
暂无评论
发现更多内容

XDAG技术详解1

老五

软件测试中需要使用的工具

测试人生路

软件测试

15天成功拿到阿里offer 我是如何逆袭成功?全靠“Java程序员面试笔试通关宝典”真够可以!

比伯

Java 编程 架构 面试 程序人生

资深码农:拿下软件测试,只需掌握好这两种方法!

华为云开发者联盟

软件 工具 测试

Native 与 JS 的双向通信

Minar Kotonoha

数字货币交易所系统开发,区块链交易所搭建

薇電13242772558

区块链 数字货币

5年Java高工经验,我是如何成功拿下滴滴D7Offer的?

Java架构追梦

Java 学习 架构 面试 滴滴

如何从危机中提炼总结,做好2020年的复盘?

CECBC

复盘 经济

25道mybatis面试题,不要说你不会

田维常

mybatis

浅谈 WebRTC 的 Audio 在进入 Encoder 之前的处理流程

阿里云CloudImagine

阿里云 音视频 WebRTC 音频技术 音频

腾讯五面、快手三面已拿offer(Java岗位),分享个人面经

程序员知识圈

Java 程序员 架构 面试 编程语言

iOS面试基础知识 (五)

iOSer

ios 面试 底层知识

观察者模式

soolaugust

设计模式 观察者模式 七日更

排查指南 | mPaaS 小程序被卡在了三个蓝点

蚂蚁集团移动开发平台 mPaaS

小程序 问题排查 mPaaS

高光时刻!美团推出Spring源码进阶宝典:脑图+视频+文档

996小迁

spring 源码 架构 笔记

json处理

Isuodut

《迅雷链精品课》第十三课:PBFT算法

迅雷链

区块链

AOFEX交易所APP系统开发|AOFEX交易所软件开发

系统开发

Locust快速上手指南

行者AI

jenkins实现接口自动化持续集成(python+pytest+ Allure+git)

行者AI

3面抖音犹如开挂,一周直接拿下offer,全靠这份啃了两个月「Java进阶手册」+[Java面试宝典]

编程 程序员 面试 计算机

小程序市场的「App Store」来了!你准备好吃“螃蟹”了吗?

蚂蚁集团移动开发平台 mPaaS

小程序生态 mPaaS appstore

接口自动化测试的实现

行者AI

接口自动化传值处理

行者AI

得物App亮相QCon全球软件开发大会,分享百倍增长背后的技术力量

得物技术

效率 技术 得物 得物技术 Qcon

【得物技术】如何测试概率性事件-二项分布置信区间

得物技术

测试 开发 概率 得物 得物技术

浅谈数据仓库质量管理规范

数据社

数据仓库 数据质量管理 七日更

双循环背景下的全球供应链机遇与挑战

CECBC

供应链物流

为什么要在以太坊上构建去中心化缓存层?到底要怎样做呢?

CECBC

以太坊

盘点 2020 |协作,是另外一种常态

冯文辉

领域驱动设计 DDD 协作 远程协作 盘点2020

我的 500 张技术配图是怎么画的?

小林coding

程序人生 画图软件

如何在 Kubernetes 中对无状态应用进行分批发布_文化 & 方法_孙齐_InfoQ精选文章