为什么把代理商和客户迁移到 Kubernetes 如此重要？

本文最初发布于 Mess 官方博客，经原作者 Jack Shedd 授权由 InfoQ 中文站翻译并分享。

导读：Kubernetes （简称 K8s）是用于自动部署、扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes 构建在 Google 15 年生产环境经验的基础之上，并结合来自社区的最佳创意和实践。基于允许 Google 每周运行数十亿个容器的原则进行设计，Kubernetes 可以在不增加运维团队的情况下进行弹性扩展。Kubernetes 具有灵活性，无论应用运行在本地还是全球任何地域，它都可以随着用户需求复杂度的不断增加，持续、轻松地对外提供服务。今天，InfoQ 将翻译并分享这篇来自 Mess 工作室的 Jack Shedd 关于迁移系统到 Kubernetes 的心得与经验。

为什么把代理商和客户迁移到 Kubernetes 如此重要？

一言以蔽之，因为 Kubernetes 代表了一种开发和托管网站的全新方式。

我管理过很多服务器。在我写下这篇文章时，我在我们主要的 DigitalOcean 账户上统计了一下，我们管理的服务器不少于 55 台。在我为客户管理的各种 DigitalOcean 账户中，还有另外 12 台服务器、3 台 AWS 服务器和 2 台裸机服务器。我们还要管理许多 WPEngine 实例。

除 WPEngin 之外，所有服务器都运行某种版本的 Mess “堆栈”，这是一种我已经使用了近五年的特定“配方”。除了这些年发生的一些并非由我们引起的故障外，我们的服务器非常稳定，几乎不需要管理。

然而，这并非什么自动化的“壮举”。我们的服务器有严格的规则管理，包括谁拥有访问权限以及如何在服务器上进行配置和安装软件。一旦设置好服务器，我就几乎可以忘记它的存在，直到我们需要更改它的某些方面。

那么，为什么在 2018 年 10 月，我开始踏上了这样一条道路——让 Mess 用 Kubernetes 集群来替换所有的服务器呢？

为何我们愿意为客户提供托管服务

对于客户项目，Mess 并没有太多的“规则”。如果客户说他们需要一个解决方案，在 Y 约束下进行 X，并具有 Z 流程，那么这就是我们要做的内容。但当谈到最终项目的托管地点时，我总是非常挑剔。

大多数商业 Web 主机都很糟糕，而这种糟糕的状况会在某种程度上影响其商业模式。他们采用非常通用的组件，在带有白色标签的主机管理软件上将它们拼凑在一起，并尽可能多地销售该产品，同时提供最少的必要支持。这是一项批量业务。如果你遇到问题，你要祈祷的是能够找到可以响应你的技术人员，这个人还要懂一些托管方面的知识。我就经常遇到不懂的人，他搜索知识库后，并没有找到答案，却把我的标签改成了“已解决”。我想大多数人都遇到过这样的人。

由客户内部 IT 团队负责的主机托管往往是随意的，但一般来说，企业越大，情况就越槽糕。企业 IT 团队的工作具有挑战性，他们需要管理异构服务器的套件，而这些服务器全天 24 小时都受到员工和供应商的严峻考验。任何优秀的团队都会设定严格的限制，比如服务器上允许使用的软件类型以及如何配置这些软件等等。这将不可避免地使其与我们的团队发生冲突，因为我们的团队也有非常具体的规范，要求服务器必须运行某种软件等等。我们的项目已经拖延了几周，甚至几个月，因为我们需要等待一些内部 IT 管理员批准更改配置、更新 DNS 记录，或者只是给我们一个需要的密码。

当 Mess 成为最终的、长期的托管服务商时，我们就可以向客户保证，不会再有任何在最后一刻出现“在模拟环境会工作得很好”的问题。在网站上线的前一天，也不会有人愤怒地要求召开群组电话会议。而且，如果网站宕机了，客户也就不用阅读我们礼貌地告知“我们无能为力”的电子邮件了。

让我们的托管，人人都负担得起

虽然我们永远无法、也不想在成本上与像 DreamHost 或 GoDaddy 这样的在线服务器竞争，但我们也不能盲目地向客户收取 Rackspace 托管专用裸机服务器每月 500 美元的费用。我们的许多客户都是小型企业或者大公司内部的小型营销团队。如果我们想鼓励他们交给我们托管，我们的报价至少要在合理范围内。

一般来说，“合理定价”大约是每月 50 美元。

虽然作为个人来讲，你可以很容易地以每月 5 美元或 10 美元的价格来托管一个网站。但对于一个机构来说，这是很难做到的。因为我们有管理费用，如办公场所、照明等等。以每月 50 美元的价格，我每月只能花 30 分钟时间在任何一台服务器上，直到公司在那台服务器上亏损。

在过去的五年里，DigitalOcean 无论从成本还是性能上来说，都是天赐之物。尽管其他主机提供商的表现有所改善，但没有一家主机提供商在每一美元的表现上具有相同的优势，也没有一家接近我们的支持水平。我们能够以每台 10—25 美元的成本启动服务器，从而收取合理的费用。然而，尽管 DigitalOcean 价格实惠，单一用途的 VPS 却并不具有规模效应。

对于大多数项目，我们既需要模拟环境，也需要生产环境。对于某些类型的项目（主要是静态项目）来说，使用一个登台服务器处理多个项目是可以接受的，但是进展对我们并不利。现在，我们的许多新项目与旧项目的需求存在冲突，或者需要一定程度的隔离，这让我不愿意将它们与不同的项目放在一起进行托管。虽然我们的成本正在上涨，但提高价格的做法可能是行不通的。

更槽糕的是，我们现在还有不少客户有不同的流量需求。对于特定的月份或年份的大部分时间里，他们的服务器接收的访问量都是合理的、低水平的。然后它们就会出现很多峰值，而且还是突然间出现的。一个通常可以由一两台服务器提供服务的项目可能会需要 5 台或 20 台服务器，而一个周末就需要 150 台服务器。虽然我们可以轻松地构建可扩展的架构，但是管理它们（通常是手动对它们进行扩展），需要花费我超过 30 分钟的时间。

了解容器

开发软件，尤其是 Web 站点，通常要涉及到很多软件。即使是一个简单的内容管理系统，如 Django 或 WordPress，也需要至少三个独特的软件包才能运行，即用于存储内容的数据库、用于运行连接到数据库并生成 Web 代码的应用服务器、用于响应用户请求的 Web 服务器。而更复杂的项目可能需要额外的东西，比如搜索引擎、内存缓存，或我们在 Mess 内部编写的完全定制的应用程序。每个项目都需要设置三台“计算机”：活动服务器、登台服务器和开发人员工作站。

每台计算机都需要以完全相同的方式进行设置。相同的应用存储在相同的位置，使用完全相同的首选项设置，引用完全相同的文件名称。对其中一台计算机的任何更改，都需要在其他计算机上重复该更改。但是，让事情变得更加棘手的是，一台或多台计算机及其运行的操作系统与其他计算机完全不同。

有了容器，我们就可以只用一台计算机。我们有一个名为 Dockerfile 的文件，它列出了如何构建计算机，安装哪些软件，要创建哪些文件的详细说明。当我们想对“计算机”进行更改时，只需对 Dockerfile 进行更改即可，然后再构建反映这些更改的计算机的新副本。

我们就可以在自己的任何一台计算上运行那台“计算机”。这样一来，无论我们在哪台计算机上，都可以打开 Dockerfile 并启动一个完美的计算机副本。我们可以相信，一切都会如我们所愿。我们可以在台式机、笔记本电脑、服务器或运行大量其他服务器软件的服务器上运行我们的计算机。

包含我们的容器

与 VPS 或裸机服务器不同，基于容器构建的项目可以直接与容器上构建的其他项目一起托管。每个“服务器”都是完全隔离的。该服务器需要哪种版本的软件并不重要，它的存在并不影响其他服务器。

扩展基于容器的项目很容易。如果我们需要三台服务器，就不必手动创建和配置三台独立的服务器。我们只是运行容器的另一个副本或“实例”。如果我们正确地设置了我们的项目，我们的项目需要的每一个“东西”：Web 服务器、数据库服务器、搜索引擎等。它们都是各自的容器，可以单独进行扩展。

实际上，它并没有那么神奇。我们必须配置运行其他服务器的服务器。必须考虑运行服务器的服务器可以运行多少台服务器。如果服务器运行服务器的空间不足怎么办？这时候就必须配置另一台运行服务器的服务器。这样一来，我们就不得不担心一组服务器如何跨多个运行服务器与另一组服务器进行通信。我们还必须考虑安全性和冗余性。

有请我们的英雄 Kubernetes 登场！

Kubernetes 最初是作为运营 Google 的平台，代号为 “Borg”。多年来，它在 Google 内部经受了考验。在那里，他们的团队在数万台服务器上解决了大量复杂的问题。2014 年，Google 将 “Brog” 作为开源项目向公众发布，供其他公司使用。

Kubernetes 管理容器极为容易。你让 Kubernetes 运行一个容器，它就会运行这个容器。你让它运行一个容器的 20 个副本，它也会如你所愿，运行那个容器的 20 个副本。如果它需要更多的资源来做这件事，它就会创建这些资源。如果你要求它停止托管一个容器的 20 个副本，它就会破坏其创建的资源。这意味着它可以毫不费力地进行“横向扩展”，并使我们的项目也能够做到这一点。

迁移我们的客户

如果一个项目正在运行，我就不愿意进行任何更改。但是 Kubernetes 和 Docker 从根本上代表了一种更好的开发和部署工作流程的方式。我一直在积极地将客户从 DigitalOcean 迁移到 Kubernetes。

然而，这一过程并没有那么容易。我们的一些项目建立在不再维护的软件之上。在个别情况下，这些软件甚至都不能从官网渠道下载。每个项目都必须更新到最新版本，每个项目所做的假设都必须重新审视，在某些情况下，项目的大部分都必须重构。

现实中，并没有神奇的“让它成为 Kubernetes”按钮。有的只是，在漫漫长夜中，没有任何人注意，而我在孤独、努力地工作着。但是这个过程已经得到了回报。我们的一位客户，一直在规模问题上进行思想斗争。因为在绝大多数时候，他们的网站几乎都没有什么流量。他们的网站在一台每月 10 美元的服务器上运行也没有问题。但每隔几个月，他们就会有一次促销活动，每逢此时，网站流量会因此暴涨 100% ，甚至 1000%。

在我将他们迁移到 Kubernetes 之前，所谓的“解决方案”只不过是过度配置他们的服务器。我们不得不围绕最坏的情况进行架构设计，销售活动必须精心策划，这样我才能在前一晚“扩大规模”。

几个月前，我在幕后将它们迁移到了 Kubernetes。他们从未注意到这一点。一个星期六，当我从奥斯汀驾车回芝加哥时，一场促销活动开始了。哇！大减价！销售额是我们以前的十倍！在 40 分钟的时间里，我将它们扩展到 150 台服务器。而就在这 40 分钟里，我可以完成几天前我应该做的事情：驾车在田纳西州的一条洲际高速公路上飞驰。三个小时后，Kubernetes 缩减到 1 台服务器。

我们接下来要做什么？

我们正忙于对我们的默认项目 “stacks” 进行标准化，以利用 Docker 的优势。我正忙着记录我为团队所做的一切，这样他们就可以自行启动项目，无需我的干预。我们有了新的日志记录和报警流程、新的安全协议、新的工具。

Kubernetes 是迈出的第一步，但正是这第一步，将使 Mess 需要做的所有事情保持对客户的成本竞争力，同时确保我们可以托管大规模的项目，而无需增加一群 DevOps 员工。

既要干得少，还要干得好，更要花得少。很少有托管技术能做到这一点，但 Kubernetes 就是做到了。

作者简介：

Jack Shedd，Mess 公司董事兼合伙人，有十年构建数字平台的经验。凭借多个领域的专业知识，Jack 领导了一个开发团队，弥合了工程和创意之间的差距。

原文链接：

Why we’re moving our agency, and clients, to Kubernetes.