将微服务从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 都提供了将应用程序部署为云上容器的设施。根据不同的应用需求，解决方案可能会有所不同。

　　审核编辑：郭婷