客座文章作者：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微信公众号。