如何将基础架构从经典 VM 迁移到由 Kubernetes 编排的容器

这篇博文是关于如何图表大亨退役了其在 DigitalOcean 上的最后一部分基础设施，标志着其向 AWS 的迁移完成。

旅程不是您的常规 AWS 迁移，因为它涉及将我们的基础设施从经典 VM 迁移到由 Kubernetes 编排的容器。

在一系列文章中，我们将分享我们的经验：

• 我们的 AWS EKS（Kubernetes 托管服务）之旅。
• 我们遇到的一些最关键的障碍。
• 我们当前的堆栈和工具。
• 我们的基础设施计划向前发展，希望它们能对整个社区有所帮助。

DigitalOcean 的生活

自 2014 年成立以来，一直到 2021 年年中，我们的整个基础架构都在 DigitalOcean droplets（自我管理的云虚拟机）上运行。我们需要一个云提供商来帮助我们快速、可靠且经济高效地起步。

DigitalOcean 很有意义，是一个不错的选择。我们在哪里，因为他们。这一选择让我们可以自由地专注于产品构建，而不必担心可扩展性和基础架构的复杂性——这些方面通常会在后期出现。

我们基础设施的每个方面都是在内部进行配置、配置和管理的。我们使用配置管理和基础设施即代码工具（Saltstack 和 Terraform）来管理事物。

这些年来我们一直在增长，到 2019 年，我们发现自己正在寻找大约 50 台机器组成的机队，它们不断需要管理、软件更新、安全补丁等。随着我们正在筹备的新项目，我们预计到 2020 年底，我们的计算能力需求将翻一番。

为什么移动，为什么现在？

作为一个很好的选择 DigitalOcean 是，我们的有机增长多年来一直在推动我们设置的界限。我们面临着多个领域的挑战，有些是可以修复和预防的，有些则不是。

各种故障

• 突然中断生产的临时临时维护窗口。

  
  

• 多次出现硬件故障，影响我们的主副本数据库设置（例如，droplet 在没有通知的情况下进入“实时迁移状态到其他硬件机器”，这意味着该 droplet 有 1-2 小时的停机时间。）

  
  

• DigitalOcean 的支持团队从未清除过的机器之间的无法解释的网络延迟问题（这对于我们的 Postgres 读取副本延迟、Redis 实例和一般的 HA 至关重要）。

AMS2 区域弃用

我们的 DigitalOcean 区域 (AMS2) 被宣布为“即将退役”，这意味着支持有限。我们无法按需获得额外的资源，执行简单的任务通常意味着长时间的计划和资源浪费。

升级 Postgres 版本和配置新机器来执行任务等简单的事情变得不可能完成。

有限的硬件选择

进入订阅分析领域意味着数据密集型操作、大容量以及经常相应扩展的能力。

具有更广泛硬件资源的现代机器仅在其他地区可用。网络性能下降是经常发生的事情，我们很快意识到迁移到不同的区域是我们最好的选择。

缺乏现代云功能和托管服务

维护我们的基础设施以跟上增长率（并同时处理技术债务）的运营工作量增加了。

我们必须仔细检查我们的设置，并了解迁移到不同的 DigitalOcean 区域或新的云提供商是否是最佳选择。

我们应该留下还是应该走？

我们开始研究留在 DigitalOcean 并简单地搬到一个新地区的好处——一个更悠闲、更快、更便宜、更不痛苦的选择。

但与此同时，我们将这一举措视为对我们的部分堆栈进行现代化改造的机会，以服务于预期的用户增长和更高的进度。

在我们的评估结束时，我们意识到通过留下并简单地切换区域很难实现特定的必备要求。最重要的是：

• 自动缩放计算资源的灵活性。

• 托管数据库。

• 根据临时使用情况提供资源。

• 低（呃）延迟。

• 服务互操作性。

• 具有 Kubernetes 编排的基于容器的基础架构。

  
  

这份要求列表以及上一节中列出的挑战使规模有利于切换供应商。

为什么选择 AWS？

选择一个新的云提供商来支持 ChartMogul 基础设施是一个漫长的过程。我们研究了市场，发现了新供应商可以带来的许多权衡和优势。

我们的选择是亚马逊网络服务 (AWS)、谷歌云 (GCP) 和 Azure。最终，我们决定使用 AWS。我们在下面列出了一些主要原因。

团队专长

我们已经在生产环境中使用了一些 AWS 服务（例如，用于存储增量 Postgres 备份的 S3）。更重要的是，我们的一些工程师之前拥有在生产系统中广泛使用各种 AWS 服务的专业经验。

可扩展性

• 我们可以通过按一下按钮来增加或减少 AWS 实例。

  
  

• 我们可以立即预置资源，例如 RDS 数据库和临时计算资源。

  
  

• 我们可以快速迭代实验和概念证明。

  
  

• 由 EC2 自动扩展支持的 Kubernetes 节点池的灵活性和可扩展性无可匹敌。

数据安全与合规

数据安全一直是首要考虑因素。多年来，AWS 的安全功能已大幅增长。

AWS 围绕数据安全开发的新服务数量满足了我们在容器/Kubernetes 领域的大部分需求。

它们与完善的服务（例如私有 VPC 隔离、细粒度的策略控制和 IAM 角色）配合得很好。

在合规性方面，我们计划尽快获得 SOC II 认证，并且我们发现 AWS合规性计划是一种优势，可以帮助加快这一进程。

管理服务

Postgres 是我们在 ChartMogul 工作的核心，我们通常会花费大量时间积极管理我们的数据库机器以支持我们的增长。

数据库的高可用性和可靠性正成为越来越受关注的问题，因此我们决定评估来自主要云提供商的多个使用托管 PostgreSQL 的产品。 AWS RDS 显然是赢家。

托管 Kubernetes 是另一个需要考虑的主要因素，这与谷歌云 (GCP) 并驾齐驱。谷歌的托管 Kubernetes (GKE) 感觉比 AWS 当时的要好，但是将 RDS 与 CloudSQL 进行比较在功能方面并不接近。

然而，现在看来，AWS 正在赶上 EKS。我们受益于出色的 RDS 功能，例如快照灵活性、备份持久性（使用 SLA）、Postgres 的只读副本、无痛升级、专用 IOPS、Cloudwatch 指标、性能洞察等等。

数量惊人的 AWS 服务

在撰写本文时，AWS 提供了 200 多项服务。它们中的大多数使您能够从计算、数据库、数据分析、数据仓库、无服务器和存储等众多领域即时访问托管服务。

我们的工程团队现在可以利用一流的集成来快速解决核心问题，并在有意义的地方优先考虑购买与构建。

灾难恢复

AWS 云是我们灾难恢复计划的重要组成部分。这是因为实例很容易启动，我们可以通过单击按钮将 RDS 只读副本提升为主副本，快照是轻而易举的，我们可以托管在多个区域，并且我们与 IaC 工具进行了一流的集成选择。

AWS 积分

我们通过 AWS Startup 计划获得了价值 10 万美元的信用额度。我们能够计划、测试和完成迁移，而无需支付大量费用。

迁移到 AWS

我们从 DigitalOcean 到 AWS 的迁移历时十个月。整个工作得到了我们所有工程团队的志愿者的支持，并由 DevOps 工程师、后端工程师和我们的工程主管推动。

有些事情涉及试错。我们尝试了多种方式：

• 将数据从 Postgres 移动到 RDS，停机时间几乎为零。

  
  

• 将我们的应用程序和服务从基于 VM 的架构迁移到 Kubernetes 中的容器化架构。

  
  

• 从根本上改变我们的部署方式。

一个完美的计划已经到位，纸面上的一切看起来都很好，但我们经历了艰难的历程，事情并不总是按计划进行。

有时，我们接近零停机时间的迁移目标面临严重风险，我们又回到了绘图板上。

毅力、动力和出色的团队合作帮助我们克服了所面临的挑战。

仔细的计划也创造了奇迹。鉴于我们的能力，我们很早就确定将实际迁移分为三个阶段（或几天）效果最好。

D-Day 前一周

• 启动从 DigitalOcean 到 RDS 实例的 Postgres 复制。
• 查看我们的 AWS 未来生产基础设施。
• 密钥配置（AWS Parameter Store）。
• 确保 CI/CD 管道已准备好部署到我们的新 Kubernetes 集群。

D 日前一天

• 准备我们的 AWS 临时 webhook 记录器基础设施（在我们的迁移过程中丢失事件不是一个选项）。

  
  

• 提前移动一些数据（例如，DigitalOcean Spaces 到 S3）。

  
  

• 将所有 Parameter Store 机密更新为生产值。

  
  

• 准备 DNS 更改。

  
  

• 将所有 Kubernetes 部署设置为零 pod，以防止服务在迁移期间访问生产数据。

D-day：轻弹开关

• 将所有 webhook 重定向到 AWS 临时记录器。

  
  

• 停止 DigitalOcean 上的所有服务。

  
  

• 等待 Postgres 复制赶上最新更新。

  
  

• 比较 DigitalOcean 和 RDS Postgres 数据（以确保完整性和复制赶上）。

  
  

• 将订阅从 RDS 删除到在 DigitalOcean 中运行的 Postgres。

  
  

• 创建 RDS 只读副本。

  
  

• 使用新的 RDS 端点和密码更新我们的 Parameter Store 密码。

  
  

• 部署到 Kubernetes 并重新启动 PgBouncer 以加载新配置。

  
  

• 将app.chartmogul.com的 DNS 记录切换到 AWS。

  
  

此时，我们正在闪亮的新基础架构上运行我们的生产工作负载！我们在 10 小时内完成了整个工作（我们最初估计需要 8 小时——还不错）。

AWS 面临的挑战

最大的困难在于 DMS 服务（将数据库迁移到 RDS 的 AWS 托管服务）。

它并不像宣传的那么容易使用。在我们使用 Postgres 的情况下，它没有帮助。最终，我们开发了一种将数据移动到 AWS 的自定义方式。

我们也意识到将零停机时间的数据库迁移到支持 webhook 的 AWS 是很复杂的。我们开发了一种自定义方法来支持此设置。

在以后的文章中更多关于这些自定义方法的信息。

系列中的未来文章

请留意未来的文章，这些文章记录了我们从 DigitalOcean 到 AWS 的迁移过程。我们将讨论以下主题：

• 为什么我们选择 Kubernetes 来支持 ChartMogul。
• 我们如何将 PostgreSQL 迁移到 RDS。
• 我们如何将 Rails 应用程序迁移到 Kubernetes。
• 我们如何设置到 AWS VPC 的 IPSEC 隧道。