将微服务从Mesos DCOS迁移到Kubernetes

对于一些微服务，数据传输和稳定性会导致问题，特别是在用户尝试长时间获取更大数据的情况下。设备能够将数据推送到数据库，但数据加载和显示导致数据丢失或服务失败。由于微服务的 I/O 更高，CPU 和内存的更高使用率启用了负载均衡器，并最终导致更高的计费。

我们决定重新设计编排并找到 Apache Mesos 的替代方案。Docker Swarm 和Kubernetes是领先且高度使用的容器编排工具，用于 DevOps 基础设施管理工具。

在我们探索 Docker Swarm 和 Kubernetes 之前，我们定义了我们如何使用 Mesos。

阿帕奇梅索斯

它提供了以分布式方式运行容器化和非容器化服务的能力。Mesos 采用分布式内核设计，因此 API 编程可以直接针对数据中心进行设计。在我们的案例中，配置为主/从的 MESOS DCOS 是基于数据库请求并进行管理的。在服务失败时，Mesos master 永远不会自动重启服务，这增加了应用程序的停机时间。

Mesos 面临的挑战

现有基础设施经常出现服务故障，导致最终用户无法使用基础设施、数据丢失和更高的 AWS 账单。

现有基础架构和编排

云：AWS

CI/CD：詹金斯

编程语言：Python、JAVA、C、C++等。

源代码：Github

部署策略：自动化+手动

基础设施监控：自动化 + 手动（定期执行验证步骤）

当前的策略和工具

EC2 Auto Scaling 组

根据 CPU 使用率进行缩放

EC2 上的 DCOS 微服务

Slack 和通过电话/电子邮件通知

其他工具/服务：Splunk、Looker、HA Proxy、S3、Graphite、Grafana

挑战

CPU 使用率会根据客户和产品使用情况而波动

弹性伸缩后服务频繁失败

频繁停机

频繁的补丁

最终客户因稳定性和可用性而担心数据丢失

由于多个 EC2 实例导致的高 AWS 账单

码头工人群

Docker swarm 使用 Docker API 和网络概念，因此我们可以轻松配置和使用它。它的架构可以强有力地管理故障。在 Docker swarm 中，新节点可以作为工作节点或主节点加入现有集群。Docker Swarm 不允许集成第三方日志工具。与 Kubernetes 相比，Docker Swarm 在 AWS、Azure 和 Google Cloud 等不同云服务提供商上的轻松集成是不可用的。

Kubernetes

Kubernetes 易于配置且体积轻巧。在服务失败的情况下，Kubernetes 会执行自动缩放并保持服务可用。Kubernetes 用途广泛且应用广泛。主要云服务为 Kubernetes 提供自定义 master 支持。

另请阅读：关于 EKS（弹性 Kubernetes 服务）部署的分步指南

由于 AWS 为 Kubernetes Master 提供了一个平台，我们决定使用 EKS。

Amazon EKS 定价模型要求用户为每个 EKS 集群承担 0.20 美元/小时的额外费用。这让我们思考，但是当我们比较收益时，它不应该像听起来那么糟糕。作为用户，我们在单个集群上设计和部署了多个具有不同命名空间和 VPC 范围的应用程序。

我们为一个集群启动了该流程，迁移了一项服务，并在 Docker Swarm 和 Amazon EKS 上验证了稳定性。其他基础设施已经在 AWS 上，我们发现 Docker Swarm 配置会非常耗时，并且需要付出很多努力来监控和管理。

借助 EKS，我们得到了亚马逊的支持和指导，以设计和部署服务以及如何降低成本，因此我们决定使用 EKS。

从 Mesos 迁移到 Kubernetes

对于 EKS 上的环境创建、映射和部署，我们使用了 CloudFormation （YAML） 模板。

云形成

AWS CloudFormation 提供了一个基于 YAML 的自定义图形界面来创建、管理和修改大量 AWS 资源，并映射它们的依赖关系。由于 CloudFormation 是 AWS 的一项服务，因此任何新服务都可以使用。

诸如 Terraform 之类的选项是开源的，并且支持主要的云平台以将基础设施设置为代码，但我们使用了 CloudFormation，因为我们在 AWS 上拥有一切。

EKS 如何提供帮助

使用 EKS 可以减少 AWS 账单

更少的 EC2 实例

使用 EKS 进行自动缩放

EKS 监控服务和警报服务

​新基建

将 EC2 实例从 15 个中型减少到 3 个大型

移除石墨

使用 EKS 自动缩放

减少 Datadog 和 Pager 任务 警报配置成本和复杂性

基于 Prometheus + Grafana 的 Alert 配置

数据狗

我们为 Datadog 配置了 CloudWatch 的扩展，用于监控 EC2 实例和连接的 AWS 服务。我们在实例上安装了 Datadog 代理，可以在 15 秒内收集内存、CPU、存储、磁盘 I/O、网络等的系统级指标。

为了对 Kubernetes 集群进行额外的警报和监控，我们配置了 Prometheus + Grafana。

Prometheus 帮助捕获和保留 POD、容器、systemd 服务等数据。我们可以使用这些数据来分析应用程序和环境的稳定性和行为。

GRAFANA 使用 Prometheus 存储的数据，并提供统计数据和警报配置的图形表示，以便于评估。

迁移后最佳实践

维持 MTTR（平均响应/解决时间）

列出关键情况并报告

立即行动

事故报告

根本原因分析

定义流程的持续改进

实现战略

手动

定期执行验证步骤

观察到意外行为时进行调试

按照 Runbook 的定义步骤

如果未在规定时间内解决，请致电或发送电子邮件给开发支持团队

记录现有故障后，如果需要，重新启动服务

自动化实用程序

使用 Jenkins + Selenium/Dynatrace 持续执行定义验证工具

增强 Python 脚本的验证步骤覆盖率

Slack 频道的通知

传呼义务

行动

15 分钟内未解决的电子邮件

如果在一小时内未解决，则升级至 4 级

如果没有解决，升级到 5 级

启动并运行环境

最佳实践

观察环境几个小时

创建根本原因分析文档

获得开发团队确定的根本原因分析的批准

从开发团队收集分辨率信息

如果将来观察到相同的 RCA，请立即采取行动以最大程度地减少停机时间

更新运行手册以供将来参考

好处和应用

在我们的案例中，AWS 账单减少了约 40%，因为 EC2 数量从 15 个减少到 3 个

基于扩展配置的自动服务重启有助于提高应用程序的可用性

数据丢失和最终客户升级减少

更高级的监控方式，帮助 DevOps 工程师快速识别根本原因

结论

当我们谈论关于我们案例的结论时，我们发现 EKS 更有帮助，因为我们发现在编排更改后我们的应用程序更加稳定。借助 EKS，我们观察到了服务稳定性、自动扩展和负载平衡——这有助于我们保持产品可用性。同样，Kubernetes 和 Mesos 都提供了将应用程序部署为云上容器的设施。根据不同的应用需求，解决方案可能会有所不同。

审核编辑：郭婷