写点什么

如何在 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:084588

评论

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

java 数据结构与算法之稀疏矩阵算法,BTAJ面试有关散列(哈希)表的面试题详解

Java 程序员 后端

Java 虚拟机1:什么是 Java,太完整了

Java 程序员 后端

学生管理系统-详细架构设计文档

joukosusi

架构

Prometheus HTTP API 查询(三)查询元数据

耳东@Erdong

Prometheus PromQL HTTP API 11月日更

Java transient关键字的使用,java商城项目面试

Java 程序员 后端

Java 低代码开发平台“光”发布 2,javapdf模板下载百度云

Java 程序员 后端

Hello Git快速入门,三年经验Java开发面经总结

Java 程序员 后端

Android C++系列:JNI调用 Java 类的构造方法和父类的方法.md

轻口味

c++ android jni 11月日更

jackson学习之八:常用方法注解,复习指南

Java 程序员 后端

Java 多线程 —— 定时器,svnlinux使用教程

Java 程序员 后端

Java 方法的使用(方法重载、形参和实参调用关系,java高级面试最新

Java 程序员 后端

Java 高并发之设计模式,深入linux内核架构mobi

Java 程序员 后端

InnoDB(3,韩顺平java从入门到精通课件

Java 程序员 后端

Java 反射:框架设计的灵魂,springboot运行原理

Java 程序员 后端

JAVA 微信小程序 解密 用户信息encryptedData,linux系统架构与目录解析

Java 程序员 后端

JAVA 获取系统日期时间,java基础百度云

Java 程序员 后端

IDEA类和方法注释模板设置(超详细教程),java程序执行过程与编译原理

Java 程序员 后端

一行代码爬取微博热搜数据

老表

爬虫 python学习 11月日更

Java 里面的异常,java语言程序设计教程pdf

Java 程序员 后端

HTML笔记 —— 标签和超链接,java面试数据库隔离级别实战

Java 程序员 后端

InnoDB(4,java中级工程师面试题

Java 程序员 后端

Jaeger知识点补充,java菜鸟教程面向对象

Java 程序员 后端

Java 世界里的垃圾回收规则你搞懂了吗?,springboot输出视频流

Java 程序员 后端

IDEA的Docker插件实战(Docker Image篇),rabbitmqpdf百度云

Java 程序员 后端

InnoDB(4(1),java技术架构知识

Java 程序员 后端

jackson学习之八:常用方法注解(1),java虚拟机实现原理

Java 程序员 后端

Java 虚拟机1:什么是 Java(1),DubboSPI及自适应扩展原理

Java 程序员 后端

IDEA这样配置,好用到爆炸!,Java开发必须要会

Java 程序员 后端

James邮件服务器,高级java工程师简历模板

Java 程序员 后端

如何编写 Go 包

baiyutang

golang 11月日更

Java this关键字详解(3种用法),Java程序员最新职业规划

Java 程序员 后端

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