零停机迁移到Kubernetes的过程

正文

我们在Manifold[1]始终致力于所做的一切都能得到充分利用。出于这个原因，我们不断地考量做过的一些事情，看看它是否仍然满足我们的标准。就在前阵子，我们决定深入研究一下我们的基础设施设定。

在这篇文章里，我们将一起来看看我们迁移到Kubernetes的原因以及我们自问自答的一些问题。随后，我们将一起来看看我们为了迁移到Kubernetes不得不做出的一些妥协，以及为什么需要做出这些妥协。我们也会一起来看看我们是如何配置集群来实现目标。

如果没坏的话，别去修

我们刚到Manifold时，做了我们熟知的一些工作。我们使用Terraform在AWS EC2上部署容器并且通过ELB对外提供服务。我们发现自己的处境是可以花费更多时间来构建一个更成熟的平台。刚开始实施的方案是非常简单的，但是我们开始看到一些痛点：

• 部署非常缓慢（~15分钟）；

• 没有持续交付意味着只有运维人员清楚该怎么部署

• 单个实例运行单个容器的模式成本很高。通过提高容器密度[2]，我们可以降低成本

在过去一年里，Kubernetes变得更加受欢迎。凭借团队以往的经验，我们坚信这项新技术的未来。出于这个原因，我们创建了我们的第一个Kubernetes集成。我们也开始思考怎样集成可以使得Kubernetes变得更易于访问。这也正是萌生出构建Heighliner的想法的地方。

这也引领着我们坚持另外一个生存原则：自给自足[3]。通过用Manifold来构建Manifold，我们也得以确切知道我们用户的需求。

选择一个集群

我们问自己的第一个问题是：“我们要在哪里运行这个集群？”。 AWS目前还没有提供Kubernetes的解决方案，但是Azure和Google云平台都有。我们是否需要留在AWS然后管理自己的集群，还是需要将所有内容迁移到其他云厂商？

我们想要解答的一些关键问题是：

• 我们能在AWS上建设一个高可用的集群吗，管理这个集群有多简单？

• 我们如何连到我们的RDS实例，延迟会是多少？

• 我们如何处理我们的KMS加密？

高可用（HA）和kops

如果我们可以在AWS上轻松地创建和管理一个集群的话，那么自然没有太多必要去更换厂商。我们用kops做的初步测试看上去很有希望，而且我们决定进一步推进。是时候去配置一套高可用的集群了。

为了理解HA对于Kubernetes的意义，我们首先得明白它的通用含义。

一个高可用解决方案的核心基石是一个冗余的，可靠的存储层。高可用的第一原则就是保护数据。无论发生什么意外，无论是怎样的故障，如果你有数据，你就可以重建。如果你丢失了数据，那就完蛋了。

——摘自Kubernetes官方文档[4]

高可用配置下的Kubernetes组件

在一个Kubernetes集群里，这个存储层是etcd，并且运行在master实例上。etcd是一个分布式的键值对存储，它遵循Raft共识算法来实现仲裁。实现仲裁意味着有一组服务器赞成一组值。为了达成这一共识，它需要lower(n/2)+1的群体投赞成票。因此，我们往往需要的实例数量是至少3个。

下面，我们来看几个可能的故障情况。

容忍实例故障

第一个场景是一起来看看单个实例终止时会发生什么。我们能从中恢复吗？

容忍实例故障

通过指定我们期望的节点数量，kops会为每个实例组创建一个自动扩容组。它将确保在一个实例终止时，会创建出来一个新的实例替代它。这使得我们在失去一个实例时仍然能够保持整个集群的一致。

容忍区域（zone）故障

配置实例级别的故障处理使得我们可以容忍单台机器层面的故障。但是如果整个数据中心出了问题，比如机房断电了，会发生什么情况呢？这时候就该地区（Region）和可用区域（AZ）的设定发挥作用了。

让我们一起回头看下我们的共识公式：lower(n/2)+1即至少3个实例。我们不妨把这个翻译成区域，结果就是lower(n/2)+1的区域即至少3个可用区域。

横跨两个区域的3个master节点

横跨三个区域的3个master节点

借助kops，这同样很简单就能办到。通过指定我们master和从节点所要运行的区域，我们可以在区域层面配置HA。然而，这是我们遇到的第一个阻力。无论是出于什么原因，总之我们刚开始在Manifold的时候，我们决定使用的地区是us-west-1。事实证明，该地区只有2个可用区域。这意味着我们必须找到另一种解决方案来容忍区域故障。

容忍地区故障（而且不止如此）

主要目标是复制同步现有的基础设施。之前的基础设施采用的设定没有跨多个区域运行，因此新的配置也无需这样做。我们相信在Kubernetes Federation的帮助下，这将更容易建立起来。

对等内部网络

由于我们地区层面的限制，我们不得不寻找其他方式来容忍区域故障。一种选择是在一个单独的地区里创建我们的集群。

每个地区有它们自己单独的网络。这意味着我们无法直接在其他地区里使用这个地区的资源。针对这一点，我们研究了一下地区间的VPS对等。这将允许我们连到us-west-1地区然后访问RDS和KMS。

在us-west-1和us-west-2之间的地区间对等

这个方案也让我们失望了。事实证明，us-west-1地区不是最佳的地区选择。在我们调查这一点时，us-west-1还不支持地区间VPC对等。这意味着这个解决方案也无法使用。

决策和妥协

通过积累所有这些新的认知，是时候做出决定了。我们是选择仍然留在AWS还是迁移到其他厂商呢？

值得一提的是，迁移到其他厂商也会带来很多额外的开销。我们必须对外暴露我们的数据库，迁移我们的KMS并且重新加密我们所有的数据。

请到「今天看啥」查看全文