别了Swarm：往Kubernetes之路

客座文章做者：Kevin Crawley，Containous开发者倡导者

为了讲述这个故事，咱们得回到三年前，当时我做为投资人加入了Single，为他们搭建了一个平台，并在整个过程当中为他们提供技术方面的建议。尽管围绕微服务架构和复杂性存在分歧，但这其实是一个成功的故事，讲述的是一个由专一的工匠组成的很是小的团队如何在云原生生态系统上创建起一个蓬勃发展的初创公司。

简单介绍一下我本身，我是Kevin Crawley，是Containous公司的开发者，该公司建立了Traefik和Maesh。我在Containous和Single的目标，是教育和使技术人员可以参与开发他们的产品与现代DevOps工具和实践。和我一块儿踏上咱们的旅程，了解包括Kubernetes和Traefik在内的整个云原生生态系统，是如何帮助像Travis Scott、Harry Styles、Lil Peep和TOOL这样的音乐家，经过他们的音乐和艺术做品接触数百万粉丝的。

开始

2016年，Single仍是一个单体原型，这个想法是由一辈子的朋友Tommy和Taylor造成的。Single背后的理念是让艺术家可以在网上销售本身的音乐，让他们的销售获得诸如Nielsen这样的主要报告系统的承认，并让他们的收入直接进入本身的口袋。我以前曾与Taylor合做过一个大型项目，经过实施咱们如今仍然称之为12要素应用的东西来“数字化改造”一家抵押贷款公司，那是在“云原生化”成为现代应用设计原则事实上的流行词以前。

当我在2017年4月加入Single，目标很简单：构建并实施所需的工具，以便负责该产品的开发者可以彻底不依赖于我（或与此有关的任何其余人）来发布和管理其应用程序。在过去的一年中，Taylor和我都一直在使用SwarmKit并对此感到满意，所以最终成为了咱们将来三年的编排器。

咱们当时考虑过Kubernetes，但当时甚至尚未一家通过认证的托管云提供商。CNCF直到2017年末才给GKE认证，而亚马逊的EKS在2017年re:Invent大会上匆忙宣布，并在2018年晚些时候发布了GA，但人们对此褒贬不一。在过去的两年里，AWS一直在努力支持K8s，确保平台能力和用户体验与竞争对手不相上下。做为一个团队，咱们并不后悔咱们所作的决定，最终，由于这个决定，（剧透警告），迁移到Kubernetes多是我所作过的最简单的平台迁移。

别了Swarm

在我解释迁移的细节以前，我可能应该解释一下咱们决定迁移的缘由。在将近4年的时间里，咱们共同创建了许多定制的工具和流程来管理咱们的部署和本地开发环境。这些工具是基于CLI和GUI的组合，提供了各类功能，包括用于在咱们的环境中可视化和提高服务，创建本地开发环境以及管理这两个环境中的共同任务的管理门户--这甚至不尽相同--生产集群使用SwarmKit，而开发者仅在POD（纯旧Docker）中运行其服务。咱们拥有适当的工具来审核并确保Swarm中的网络平面运行情况良好，而且还执行了一些其余特定于部署基于撰写项目的任务（将值解析/注入到模板等）。

除了修补工具以外，咱们很快就到达了一个点，咱们可能须要扩展咱们的关键基础设施组件，如Redis和RabbitMQ，虽然Swarm很适合扩展无状态应用程序，但它不太适合管理状态的应用程序。随着操做器（Operators）的引入和Kubernetes的成熟，有状态集群应用程序正在迅速接近在生产中能够依赖它们的程度。

胆大妄为

自动化的快速破坏咱们的集群和重建并不存在。结果，个人运行手册中填充了几页手工步骤，这些步骤须要配置实例、将它们加入集群、保护它们，以及管理工具和Single Music服务自己的仔细过程。这项工做的大部分本能够自动化，但对于每一年最多发生两次的事情，那将须要数周的工做。

这种状况并不理想，若是管理平面崩溃，咱们将面临离线8个小时手工重建。考虑到Single Music如今每周至少要发行一个很是知名艺术家的新发行，所以这是巨大的业务风险。我知道咱们必须在某个时候解决这个问题，但我估计所需的时间在80-120小时之间。Single Music并非个人全职工做，像这样的迁移须要持续的专一工做，在几个月的周末里零零碎碎地作并不能解决问题。

设定目标

在移动应用程序以前，我必须确保咱们可以知足软件的开发和操做需求，同时只构建最小的工具集来管理平常操做。我与团队一块儿为迁移设置了合理的基准和要求：

1. 在云中运行所需的全部底层平台服务和工具必须在1小时内从零开始为咱们的生产应用程序服务。
2. 本地开发环境必须使用可以使用彻底相同的清单、工具以及兼容或相同的基础设施组件的平台来服务，此外，还必须在15分钟或更少的时间内彻底配置/操做。
3. 除了咱们的持续部署系统以外，用于提高和管理部署的任何定制工具都必须用于本地操做。

这是一个实验的核心，虽然我相对有信心咱们能够实现这些目标，但我不肯定须要多长时间。使用Kubernetes是显而易见的选择，由于咱们的构建工具、应用程序和架构已经与云原生兼容。基于我构建研讨会和演示的经验，我有信心在开发团队的其余成员的帮助下可以实现其余目标。

实验

Lift and shift迁移应用程序并不像一些供应商所作的那样容易，可是咱们有一些能够利用的方法。咱们已经在全部应用程序中使用了一致的模式和工具，全部这些都很好地适应了云原生生态系统。我将列举以下以供参考：

• Maven/Fabric8--在咱们全部的应用程序中，甚至是非java应用程序、版本管理、测试等等，都采用一致的构建模式。
• Gitlab/GitlabCI--咱们全部的应用程序都被设计为持续构建，咱们的镜像被标记，被推到docker镜像注册表中，并部署到预生产环境中。

下一个阶段是决定咱们将使用哪些工具来管理咱们的应用程序的生命周期，包括部署平台自己、咱们的服务，以及咱们将如何监控它。咱们选择了一些不一样的工具：

• Helm--为咱们的后端服务预先作好生产准备的清单，我已经有了为研讨会和教程构建chart的经验。成熟的社区和普遍采用的，这使咱们可以为全部分布式应用程序建立一个统一的chart，并为可伸缩的后端组件利用社区chart。
• eksctl--虽然没有kops那么灵活，这个工具在第一轮就能够工做，并知足了咱们自动设置生产集群的初始需求。
• kind--很是适合本地开发和测试，这是一种轻量级解决方案，用于建立本地开发所需的一次性K8s环境，而不依赖于大型而缓慢的VM。
• Kontena Lens--Kubernetes的一个可视化工具，这个应用程序很是适合管理运行在本地和云中的K8s中的服务和后端组件。这取代了咱们为Swarm内部构建的定制工具之一，该工具处理了Lens中可用的大部分功能，好比快速访问状态、执行、日志和工做负载的配置细节。

Hello Kubernetes

因为新冠肺炎对经济的影响，我于2020年3月底从全职工做中下岗。我决定如今是时候了，由于我已经预料到在这场经济冰雹风暴中很难找到一份新工做。幸运的是，Containous和我找到了彼此，在被解雇的一周内，我开始了一个很棒的新角色。可是，在开始以前，我决定完成这个迁移，因此让咱们开始。

步骤1：

开发者。开发者。开发者。

重要的是，开发者要有一个尽量接近将在生产环境中运行的环境。在此以前，他们一直依赖fabric8-maven-plugin在本地docker网络上启动应用程序--这与咱们在云中运行相同的应用程序的方式相去甚远。我知道，要想让它发挥做用，就必须有一个尽量接近部署到新平台的快速本地环境。我最终在这里构建的工具不只能够用于本地环境，还能够用于咱们的云堆栈。

在笔记本电脑上运行本身的Kubernetes集群并不彻底是轻量级的。咱们须要一个不涉及VM或其余云资源的解决方案。我还须要一些轻量级的、容易拆卸和从新配置的、在WSL2（个人环境）和Linux（其余开发者+咱们的CI）上工做的东西。

Hello kind, Kubernetes-IN-Docker。这个项目最初是为处理Kubernetes的持续集成测试而构建的，很是适合咱们的需求。我但愿咱们的开发者可以在15分钟内从零起步，建立一个包含20多个服务和配套基础设施组件的完整工做应用程序栈。此外，部署新构建须要花费几秒钟的时间。

cmdr是什么？

为了管理本地环境的过程，我建立了一个Python应用程序“cmdr”，它处理配置类型、安装Traefik、MetalLB，以及经过Helm部署咱们的基础设施、应用程序和UI组件。咱们已经标准化了如何命名、构建和配置咱们的服务，因此一切都已经抽象和DRY（Don't Repeat Yourself）--这使得建立新服务对于Single Music团队的开发者来讲至关轻松。

除了本地引导程序外，我还建立了一个deploy命令，该命令接受一个项目名称，该名称在整体上的projects.yaml文件中引用，而后提取特定于环境的详细信息（入口端点，环境配置）以应用到该项目的相关Helm chart。咱们为基础设施组件使用了一些开源Helm chart，如MySQL、Postgres、Redis、RabbitMQ和Confluent Cloud（Kafka）。deploy命令也接受env标志、镜像标签、应用程序版本，全部这些配置元数据和chart特定的版本标签，帮助咱们在EKS中跟踪环境中的应用程序版本。

开发者还构建了一个命令“promote”，经过GitLab流水线从咱们的登台环境（咱们的CI是惟一可以部署到咱们集群的代理）提高应用。此时，咱们已经准备好在托管的Kubernetes环境中运行咱们的服务。咱们选择Amazon EKS是由于咱们已经在该提供商中运行，而且刚刚购买了价值几千美圆的保留实例。咱们还将全部客户的音乐安全存储在S3中，并依赖于他们的其余数据服务，如Redshift和RDS。各位，供应商锁定是真的。

第二步：一步一步来

Single Music天天要处理大约150万笔交易。扩展或失败的迁移将是一场灾难。除了构建开发人员可使用的环境以外，咱们还必须确保咱们也使用兼容的基础架构组件，包括从Traefik 1.7升级到2.2，利用他们的新CRD以及使用Bitnami Redis和RabbitMQ chart，所以咱们的缓存和消息传递系统能够在不久的未来进行扩展并高度可用。

迁移Traefik

虽然继续使用Traefik 1.7和“official/stable”Helm chart能够工做，但这并无意义，有三个缘由：

1. Traefik 1.7的支持将于2021年结束
2. Traefik 2.x引入了现代概念，如服务、路由器和中间件，新的helm chart利用了CRD，这有助于减小注释的混乱
3. Containous正处于从“stable”变为官方支持的图表的过程当中，由于它在今年年末被弃用，许多其余的维护者也是如此。

咱们还认识到从1.7到2.x的迁移须要一种新的配置方法，既然咱们已经从Swarm迁移到Kubernetes，咱们如今就应该继续使用最新版本。

升级后，咱们能够选择利用现有的Kubernetes Ingress模式以及注释，或利用CRD--对咱们来讲，使用CRD选项很合适，由于它减小了在已经有些复杂的清单中添加和管理一堆条件注释的麻烦。

迁移基础设施

在Kubernetes以前，咱们使用Redis的单个实例来处理缓存和锁定问题，使用RabbitMQ来处理异步任务队列。在将来一两年的某个时候，咱们的工做负载将须要向外扩展这些技术，以处理预计的事务负载。咱们也在完善咱们的分析平台，而且已经开始为这个项目实施Kafka和Redshift。

咱们的生产工做负载彻底依赖于咱们的事务性数据存储（RDS、Redshift、Kafka）的托管服务，但咱们的非生产环境利用了同等的开源服务。迁移到Kubernetes意味着，当咱们最终不得不处理生产中的RabbitMQ和Redis时，咱们能够选择利用操做器来实现这些技术，同时也能够为咱们的交易组件提供非生产环境。咱们在实现RabbitMQ和Redis的bitnami chart时没有遇到任何麻烦，同时使用Kafka的官方confluent helm图表。

咱们尚未开始扩展这些组件，但咱们已经准备好了，能够先在本地进行试验，而后最终在生产中实现高可用性。若是不先迁移到Kubernetes，就不可能同时得到商业和社区对该功能的支持。

准备……哎呀……

咱们达到了开发环境的基准，成功地在EKS上搭建了咱们的平台，成功地迁移了咱们的关键基础设施组件，并解决了咱们发现的一些问题。

咱们发现的一个值得注意的问题是，当咱们捕获用户地理位置数据时，服务在处理交易时开始失败。现代负载平衡器生成一个“X-Forwarded-For”头，它容许目标服务经过验证请求链中代理的子网来验证事务，但它也是咱们的报告系统的真相来源。一开始，咱们只是简单地将缺乏头信息的缘由，归咎于Metallb和本地环境的古怪，可是咱们很快发现这个问题也出如今EKS的登台（staging）环境中，这个环境最终将成为咱们的生产环境。

确保咱们的客户对其客户的购买有准确的报告数据是没有商量余地的。迁移被阻塞，直到咱们可以肯定问题。幸运的是，个人整个DevOps职业生涯实际上只是在谷歌上搜索时的偶然运气，我发现了最有可能致使这个问题的缘由。Spring Boot的最新版本引入了一种行为变化，即运行时检测到它正在Kubernetes上运行，并简单地删除了header，这致使咱们的服务在尝试读取该键值时失败。

第三步：上线！

当咱们配置好集群，并确认全部工做负载在登台环境上都是可操做的，实际的迁移就很简单了。因为咱们的服务彻底是基于webhook和消息的，咱们能够在数据库被移动后，让队列耗尽，并切换工做负载。咱们预计此次行动将不超过30分钟，分为三个阶段：

1. 咱们的关键基础设施组件，如Traefik、Redis和RabbitMQ，已经在生产命名空间中运行。咱们继续在维护模式下运行咱们的着陆服务，并将咱们在Route 53的全部A记录，指向已经注册了上述Traefik服务的新ALB。任何请求都将使用503维护页面来回答。
2. 这容许队列耗尽咱们的Swarm集群，此时咱们中止了Swarm中的全部生产服务，并开始将RDS实例移动到新的VPC上。咱们不知道这将花费多长时间，最终它花了大部分时间来进行迁移。数据库在新的VPC中以后，咱们验证了集群中的链接性，而后进入下一个步骤。
3. 咱们开始了打开服务和关闭维护模式的过程。咱们启动了事件分派器，它处理传入的webhook，以及咱们的UI服务和API。当确认工做正在排队，咱们便履行服务，并使用APM提供商DataDog密切关注咱们的基础架构指标和跟踪遥测，以避免出现麻烦。

几个小时后，咱们没有注意到任何问题，全部迹象都代表这是一次很是成功的迁移。

回顾

整个迁移过程大约花了三周时间。若是没有咱们团队中开发者的支持，这是不可能的。当他们迁移到一个新的开发平台，并忍受因为使用和适应新工具而带来的不便时，他们会不断地提供反馈。总的来讲，Kubernetes的迁移，对于Single Music来讲是一个巨大的成功。咱们解决了业务运营的主要风险，提升了咱们的可靠性、容错性和增加能力，同时下降了开发和运营成本。

若是没有Kubernetes、Helm、Traefik等开源项目，像如今这样的项目将须要更多的工程师和复杂性。很是感谢Docker团队将SwarmKit做为咱们启动的初始平台，并为咱们提供了支持、经验和实践，使咱们可以绝不费力地迁移到Kubernetes。咱们感谢社区和工具给了咱们建立服务的机会，帮助小型独立艺术家和世界上一些最大的艺术家，将他们的创做直接带给他们的观众。

参与

尽管咱们的堆栈中有许多关键组件，其中一个从一开始就存在的组件是Traefik。做为CNCF的成员和开源人士，有不少不一样的方式加入Traefik社区，并了解更多关于Containous构建的产品和解决方案：

• 在咱们的社区论坛上与其余Traefik用户和开发者进行交流
• 在咱们的Github仓库的各类Containous项目作出贡献
• 了解更多关于Traefik如何为开发者提供灵活易用的Kubernetes Ingress的信息

你能够在社区论坛上找到咱们的Traefik大使和维护者，包括我本身，或者你能够直接经过电子邮件kevin.crawley@containo.us联系我。

点击阅读网站原文。

---

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。咱们经过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。