“迁移策略+新容器运行时”应对有状态应用的冷热迁移挑战

大家好，我的花名是稻农，首先我简单介绍一下我在这个领域的工作。在阿里，我们现在主要的侧重点是做大规模的运维和新的容器运行时。目前，大家可能已经对 Kubernetes 进行了广泛地使用，但多数还没有达到一定规模，有很多痛点以及内部的问题还没有得到充分暴露。
 

容器迁移背景及现状

目前，大多数容器的使用还在百台到千台的规模。我先简单介绍一下阿里目前内部容器服务。阿里的淘系应用如天猫、淘宝，目前已经全部实现了容器化，在集团的场景下面是没有虚拟机的。阿里用了大概三年到四年的时间，做到了 100% 容器化。
 
大家都知道使用容器有很多好处，比如它在资源耗费方面有很大优势。对于“双十一”大家应该有很明显地感受，相比之前，现在的“双十一”会“顺滑”很多，这样地转变也有容器化的功劳。

如果你有存量的业务，那你一定会面临从虚拟机或物理机迁移到容器的过程。绝大多数开发人员其实认为这是一个负担，因为他们的应用已经跑起来了，就不太希望因为基础设施地改变，去做更多工作去进行适配。所以出现了一些我们叫“富容器”或者“丰富复杂应用容器”的特殊容器。

简单说，所谓富容器，就是我们回在容器内放置一些管理组件。阿里内部组件叫 star agent，它会提供登陆服务，提供各种各样的包管理，命令行的执行，诸如此类的事情。在真正运维和使用的过程中，整个容器与虚拟机的差别不大。
 
当然这个东西在业界是存在争议的，比如我们是不是应该先做微服务化，把所有服务都变成单一、不可改变的镜像再run 起来，还是我们为了迁就一些技术债务引入富容器这种技术，这个地方是存在争议的。但是可以告诉大家的是，如果你要完全按照理想化的微服务去执行，基本上很多大的应用（像淘系这些非常复杂的应用，需要改造一下可能要几个月）可能在第一步就被卡死了。因为我们有富容器，所以这个应用是有状态的，并不是随便说我砍掉他，然后异地重启就可以了，这就是双刃剑的另一面，上线改造容易，运维变得复杂了。
 
我们有富容器的一些传统应用，很难对他们进行微服务无状态的改造，所以我们看到有很多场景，比如说容器出现故障时，开发或者运维的同学非常希望故障之后的新容器长得跟原来容器一模一样，比如 ip、名字等任何东西都不变，非常符合他们的理想。 
 
有时候，我们面对一些大规模的容器迁移，比如说在地方开一个很大的机房，我们就会把杭州或者是上海的容器全部迁走。在过程中非常麻烦的是有一些容器是有状态的，你迁的时候你还不敢动它，因为万一砍掉，可能红包就发不了了……

大的有状态的应用会占住物理机，造成没有办法去迁移。以上都是容器可携带状态迁移成为规模化运维的典型场景。


容器可携带状态迁移成为规模化运维难点在于 K8s 或者说整个容器与虚拟机的运维。Docker 公司曾给出说法，虚拟机像宠物一样，需要受到很精心地呵护才能永远活得很好，只要不好就需要去修它，这个就是宠物式的管理。K8s 认为容器应该是牛群式的放养，死了就直接重启而不需要对每一头牛做特别好地呵护，因为成本很高。
 
在 K8s 里面，我们经常看到的就是扩缩容，针对他的假设都是里面的应用是无状态。然后在执行层面，大家现在用的一般都是普通容器，或者说是标准容器引擎，就是 runC，虽然 runC
里面有个 checkpoint 和 restore 的机制，大家用起来就会发现基本上是不可用，坑非常多。
 
容器可携带状态迁移成为规模化运维有两个难点，恰好是我们要解决的两个问题:


首先是管理面，K8s 上支撑 pod 的迁移与伸缩不一样，我们所认为迁移就是这个容器要原封不动地在异地再重生；另外，我们认为冷迁移就是业务时间中断比较长，中断时间短的就是热迁移。那这个长短的分界岭在哪呢？每个云厂商会有一些不同的看法。我们认为大概到毫秒级以下，一百毫秒或者十个毫秒这样的级别，可以认为它是热迁移。其实任何迁移基本上都会有业务中断的时间，任何一种机制去实现都不可能实现零时间切换。我们看一下 K8s 系统对整个容器迁移，2015 年开始，我们就讨论过 pod 的迁移要不要放到K8s里面去，大家可以去翻 K8s 社区 issue，但一直没有下文。
其次是在执行层面，runC 作为容器运行时主流，虽有 CRIU 的项目辅助，仍然无法提供完善可靠的迁移机制。