“All in Cloud”之后,和你聊聊「云原生DevOps的Kubernetes技巧」 了解详情
写点什么

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

  • 2019 年 3 月 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 年 3 月 25 日 15:083562

评论

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

JETPACK-COMPOSE-ALPHA-版现已发布!(1)

android 程序员 移动开发

JS Bridge实现

android 程序员 移动开发

Koltin28

android 程序员 移动开发

Kotlin Lambda巩固

android 程序员 移动开发

Kotlin 协程使用手册

android 程序员 移动开发

JetPack现在都成了Android开发必备技能嘛?

android 程序员 移动开发

Http 状态码详解

android 程序员 移动开发

HTTPS详解

android 程序员 移动开发

IOS开发之——事件处理-hiTest(69)

android 程序员 移动开发

JAVA-Android-多线程实现方式及并发与同步

android 程序员 移动开发

Java线程(十):CAS

android 程序员 移动开发

Jetpack Compose 1

android 程序员 移动开发

Fabric.js 从入门到________

德育处主任

大前端 可视化 canvas 画布 FabricJS

Jaxb2 实现JavaBean与xml互转

android 程序员 移动开发

JETPACK-COMPOSE-ALPHA-版现已发布!

android 程序员 移动开发

hencoder学习自定义view(1)

android 程序员 移动开发

HTTPS工作原理以及Android中如何防止抓包

android 程序员 移动开发

Java 创建型模式:单态模式,原型模式,工厂方法

android 程序员 移动开发

Java的Url编码和解码

android 程序员 移动开发

hook(1)入门篇

android 程序员 移动开发

IOC架构设计之Dagger2架构设计(三)

android 程序员 移动开发

Jetpack-在数据变化时如何优雅更新Views数据

android 程序员 移动开发

JNI 与 NDK 入门(一)

android 程序员 移动开发

Koltin47

android 程序员 移动开发

Http详解

android 程序员 移动开发

Java 网络:InetAddress类的应用以及通过Socket实现TCP编程

android 程序员 移动开发

Java之JNI初步认识

android 程序员 移动开发

IOS开发之——CABasicAnimation(95)

android 程序员 移动开发

Jetpack系列(一) — Navigation

android 程序员 移动开发

Jetpack系列——ViewModel

android 程序员 移动开发

Kotlin-+-协程-+-Retrofit-+-MVVM优雅的实现网络请求

android 程序员 移动开发

西门子低代码:探讨应用程序开发的下一步演进方向

西门子低代码:探讨应用程序开发的下一步演进方向

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