从OpenStack到Kubernetes | 如何在大规模产线应用迁移中保证高可用性？

供稿 | eBay PaaS Team 

作者 | 王海涛

编辑 | 顾欣怡本文2933字，预计阅读时间11分钟更多干货请关注“eBay技术荟”公众号

01

 引言 

高可用性（High Availability，缩写为 HA），指系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。为了达到这个目标，eBay内部要求每一个Raptor的Production应用必须跨多个数据中心，通过GTM来实现负载均衡，时刻保证每一个Production应用的HA是PaaS team日常工作中最重要的部分。随着容器应用逐渐进入大规模工业生产环境，eBay也基于 Kubernetes开发了内部的新一代基础架构云平台Tess。如何保证每一个Raptor的Production应用能够无缝地从OpenStack(VM)搬迁到Kubernetes(Pod)，并且在迁移过程当中时刻保持Production应用的HA不造成ATB，成为了PaaS team 面临的一大挑战。

02

 当下的高可用是如何保障的？

PaaS team为了保证从VM到Pod在迁移过程中的的HA，需要设计一个合适的搬迁计划。在此之前，我们首先要分析一下在VM的世界中，每一个Raptor的应用是如何在硬件和软件上保障HA的。

1.

硬件层面

在eBay内部，每一个Production应用都至少应该跨多个数据中心，并且各个数据中心（SLC， LVS和RNO）之间通过GTM来进行负载均衡实现HA。在这样的情况下，如果某个应用在某个数据中心的VM因为某种问题出现了不可用，GTM就可以通过负载均衡将流量迁移到其他的数据中心，以保证该应用的HA。

图1（点击可查看大图）

2.

软件层面

在PaaS管辖的所有Raptor pool中，有一个类似于“StateLess” （无状态化）的Compliance概念。首先我们了解一下什么是“StateLess”（无状态化）：服务的无状态化就是冗余部署的多个服务模块（进程），使其完全对等；也就是部署多个相同服务，请求到任一服务的处理结果是一样的。无状态化要求应用的服务内容和数据在每一台机器上都是一致的，我们可以随时对该应用进行扩容或者缩容，比如我们随时可以将4 台机器变成 5 台机器。PaaS 对于Compliance的应用定义是“PaaS team 的automation能否接管某一个应用的所有配置，包括LB（Load Balancer）配置、防火墙、白名单、证书、https/http支持等”。换句话说，便是PaaS team能否随时地对该应用进行扩容或者缩容，然后 PaaS team的automation会cover掉所有的配置。

3.

小结

正是由于当前每一个Production的应用在硬件和软件层面都已经有了良好的确保HA的措施，所以PaaS team才有可能在将Raptor 应用从VM搬迁到POD的过程中继续确保其HA。

03

 如何设计搬迁计划？

1.

现状分析

在eBay内部，PaaS team管理着数千个Production的Raptor 应用，通过什么样的策略将如此大规模的VM 搬迁到 Pod，成为了摆在PaaS team面前的一道难题。上节提到，每一个Production的应用在eBay内部都应该跨多个数据中心，通过GTM来进行负载均衡到达HA的目的。其实在每一个数据中心内部，都存在着不同的 AZ (AvailabilityZone)，这些AZ独立存在，不同的AZ之间互不影响。比如在SLC这个数据中心就存在着SLCAZ00，SLCAZ01和SLCAZ02三个互相独立的AZ。同时由于大部分Production应用在每一个数据中心都以AZ的形式存在，因此PaaS team设计了基于AZ的搬迁计划。在定下了基于AZ的搬迁方案基调之后，接下来便是对Production应用现状的一个分析和梳理，在eBay三个数据中心SLC，LVS和RNO中存在着两种不同技术代的AZ。其中在SLC和LVS这两个数据中心里存在着技术栈比较老的上一代Legacy AZ SLCAZ00和LVSAZ00，而在RNO中则只有技术栈比较新的RNOAZ01、RNOAZ02等AZ。

图2（点击可查看大图）当前大部分的Production应用都是以VM形式运行在不同的数据中心，但是数据中心之间还存在较大的差异。大部分应用在SLC和LVS中都以Legacy AZ的形式出现，而在RNO中则以新的AZ的方式出现，这个时候就需要考虑到技术栈的不同情况，来分别设计不同的搬迁计划。

2.

针对Legacy AZ的搬迁计划

经过讨论和分析，为了在完成VM到Pod的搬迁计划的同时做到数据中心的更新换代，PaaS Team针对Legacy AZ设计的搬迁计划是将用户的代码整体迁移到新的AZ，具体可概括为：在新的AZ为用户的应用重新配置相同数量的Pod，然后部署用户的代码，从GTM引入traffic，接着再把Legacy AZ 的traffic从GTM上移除，最终把VM关机并移除。

图3（点击可查看大图）

3.

针对New AZ的搬迁计划

对于已经处于较新技术栈的新AZ，由于不涉及数据中心的更新换代，PaaS team设计了较为轻量级的In_place migration的搬迁计划。通过复用已有的LB配置，只需要为用户的应用重新配置相同数量的Pod，然后部署用户的代码，逐步引入traffic，最终把VM关机并移除便可。

图4（点击可查看大图）

4.

小结

在整个搬迁计划中，PaaS team通过提前为用户的应用进行扩容，保证在在硬件层面上每一个应用都会有冗余的机器存在。如此一来，即使某个应用在搬迁过程中流量剧增，也能时刻保证有备用的机器来承担流量。

04

 如何监控搬迁流程？

在设计具体的搬迁计划后，接下来 PaaS team面临的便是：如何监控当前的迁移进度？如何知道当前每一个应用详细的进度？如何在搬迁的过程中尽量做到人为的干预以自动化来代替？PaaS team开发了一个基于工作流（workflow）的管理工具AMT（automation）来解决这个问题。

图5（点击可查看大图）为了实现自动化的搬迁流程，需要调用底层的多个系统之间的API，并跨越多个步骤。因此在AMT设计中，最小的执行单位是基于步骤 Step的。每一个Step代表着一个底层系统API的执行，最后将多个Step组合起来形成workflow。每一个workflow会将定义的Step串行执行，不同的workflow之间相互独立地运行。具体而言，我们针对Legacy AZ的搬迁方案设计了更为具体的 New_AZ_ADD和AZ_Decommission workflow，针对 New AZ 的搬迁计划则设计了In_Place_Migration的workflow。每一个工作流负责处理不同的任务。在这些工作流中的最小工作单位是AZ，如果尝试给一个应用已有的三个AZ都做迁移，那么在当前workflow当中将存在三条记录。

1.

New_AZ_ADD 工作流

该工作流主要负责为用户的应用进行扩容操作，即为应用在新的AZ添加和VM相同数量的Pod，然后利用自动化进行包括LB、防火墙、白名单、证书、https/http支持等相关的配置。

图6（点击可查看大图）

2.

AZ_Decommission 工作流

该工作流主要负责为用户的应用进行缩容操作，即在旧的AZ进行VM的关机和回收。在这个工作流中，为了防止应用从VM搬迁到Pod后因不适配而导致不工作的情况，PaaS team设计了基于eBay内部Sherlock（基于Prometheus的监控平台）的HEALTH_CHECK功能。HEALTH_CHECK会对比新旧两个AZ在某一时间段的Error Count和Traffic比例的差异。如果该差异没有大于特定的阈值，则认为这两个AZ已经在功能上接近，意味该应用在搬到新的AZ以后没有产生更多的错误，那么我们便能够回收旧的VM。

图7（点击可查看大图）

3.

In_Place migration 工作流

该工作流主要负责在相同的AZ中同时进行Pod的扩容和VM的缩容操作，在该工作流中，我们同时也引入了监控应用健康的HEALTH_CHECK功能，只有确定在同一个AZ的Pod能够像VM一样工作的时候，才会触发Job去关机并回收VM。

图8（点击可查看大图）

4.

迁移进度

通过自动化工具AMT，PaaS team将利用可视化功能动态跟踪每一个应用的进度。目前已经把将近87%的应用搬迁到了Tess，其余的应用正通过AMT有条不紊地继续剩下的搬迁工作。

05

 总结 

对于每一个Production应用，PaaS team从当前高可用性出发，分析并且设计了基于AZ的标准化步骤来规范大规模的搬迁流程。此外，我们尝试用自动化做好服务监控，预判不可用情况的出现，并在出现之前发现问题，解决问题，最终确保每一个应用从OpenStack切换到Kubernetes的高可用性。参考链接

1. 高可用性

   https://zh.wikipedia.org/wiki/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7

2. Stateless versus stateful

   https://subscription.packtpub.com/book/application_development/9781788831437/1/ch01lvl1sec16/stateless-versus-stateful

3. 分布式系统关注点——“无状态”详解

   https://www.infoq.cn/article/Acxp9dIwWmwm1_stwPzA

4. 为了做到微服务的高可用，鬼知道我出了多少张牌

   https://developer.51cto.com/art/201907/600209.htm

5. 服务端高并发分布式架构演进之路

   https://segmentfault.com/a/1190000018626163?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

6. 京东从OpenStack切换到Kubernetes的经验之谈

   https://jimmysong.io/docker-handbook/docs/jd_transform_to_kubernetes.html

7. Kubernetes如何改变美团的云基础设施？

   https://tech.meituan.com/2020/08/13/openstack-to-kubernetes-in-meituan.html

8. 现在，Serverless 真的已经成熟了吗？

   https://mp.weixin.qq.com/s/PwDbbPdtdK0aINDjjCaV8g

9. 基于Grafana和Prometheus的监视系统

   https://www.jianshu.com/p/339db34e4afe

10. 分享 | eBay TESS，我心中的那朵“云” （点击即可跳转）

您可能还感兴趣：

👇点击阅读原文，一键投递 

    eBay大量优质职位，等的就是你