挑战
Nav 成立于 2012 年，为小企业主提供来自三大商业信用局（Equifax、Experian 和 Dun & Bradstreet）的企业信用评分以及最适合其需求的融资方案。五年后，这家初创公司发展迅速，“我们的云环境变得非常庞大，而我们对这些环境的使用率却极低，不到 1%，”工程总监 Travis Jeppson 说道。“我们希望我们对云环境的使用与我们的实际需求更加紧密地结合，因此我们开始寻求容器化和编排来帮助我们运行彼此独立但可以共享相似资源池的工作负载。”
解决方案
在评估了许多编排解决方案后，Nav 团队决定采用在 AWS 上运行的 Kubernetes。Kubernetes 周围强大的社区以及其 Google 血统是吸引他们的主要因素。此外，“其他解决方案往往相当笨重、非常复杂、规模庞大，而且一开始就很难管理，”Jeppson 说道。“Kubernetes 为我们提供了一种非常简单的方式来逐步采用适合我们当时需求的编排解决方案，但它的可扩展性也使我们能够随着它的发展而成长，并在以后构建更多功能。”
影响
这个四人团队在六个月内就完成了 Kubernetes 的搭建和运行，并在接下来的六个月内完成了 Nav 的 25 个微服务的全面迁移。结果令人印象深刻：最初促使公司走上这条道路的资源利用率从 1% 提高到 40%。过去，启动一项新服务需要两名开发人员花费两周时间；现在，只需要一名开发人员不到 10 分钟即可完成。部署次数增加了 5 倍。而且该公司节省了 50% 的基础设施成本。
几年前，Nav 意识到了自身成功道路上的一个障碍。Jeppson 表示，业务发展迅速，“我们的云环境变得非常庞大，而我们对这些环境的使用率却极低，不到 1%。”“大部分问题都与扩展能力有关。我们只是在烧钱。‘让我们多启动一些服务器。让我们做更多的事情来处理不断增长的负载。’而作为一家初创公司，这可能会导致我们走向灭亡。我们没有那么多钱可以烧。”
此外，每项新服务都必须经过 10 个不同的人员，启动时间长达两周，令人无法接受。“所有的补丁管理和服务器管理都是非常手动完成的，因此我们都必须密切关注并维护它，”Jeppson 补充道。“这真是一个非常麻烦的系统。”
Jeppson 在之前的工作中使用过容器，他向 Nav 的管理层提出了这项技术，将其作为解决这些问题的方案。他在 2017 年初获得了批准。“我们希望我们对云环境的使用与我们的实际需求更加紧密地结合，因此我们开始寻求容器化和编排来帮助我们运行彼此独立但可以共享相似资源池的工作负载，”他说道。
在评估了许多编排解决方案后，该公司决定采用在 AWS 上运行的 Kubernetes。Kubernetes 周围强大的社区以及其 Google 血统是吸引他们的主要因素。此外，“其他解决方案往往相当笨重、非常复杂、规模庞大，而且一开始就很难管理，”Jeppson 说道。“Kubernetes 为我们提供了一种非常简单的方式来逐步采用适合我们当时需求的编排解决方案，但它的可扩展性也使我们能够随着它的发展而成长，并在以后构建更多功能。”
Jeppson 的四人工程服务团队在六个月内就完成了 Kubernetes 的搭建和运行（他们决定使用 Kubespray 来启动集群），并在接下来的六个月内完成了 Nav 的 25 个微服务和一个主要单体的全面迁移。“我们不可能重写所有内容；我们不能停下来，”他说道。“我们必须保持正常运行，我们必须保持可用，而且我们必须将停机时间降至最低。因此，我们对构建管道、指标和日志记录以及 Kubernetes 本身都非常熟悉：如何启动它、如何升级它、如何维护它。我们一点一点地迁移。”
该过程的一个关键部分是培训 Nav 的 50 名工程师，并对新的工作流程以及迁移路线图保持透明。Jeppson 定期进行演示，并为所有工程师提供为期一周、每天四小时的实验室培训。然后，他在 GitLab 中创建了一个存储库来存放所有信息。“我们向所有前端和后端开发人员展示了如何进入，使用 kubectl 创建自己的命名空间，所有这些都是他们自己完成的，”他说道。“现在，很多时候，他们只是来找我们说，‘这个准备好了。’我们在 GitLab 中点击一个小按钮，允许它发布到生产环境中，然后他们就可以开始了。”
自 2018 年初完成迁移以来，结果令人印象深刻：最初促使公司走上这条道路的资源利用率从 1% 提高到 40%。过去，启动一项新服务需要两名开发人员花费两周时间；现在，只需要一名开发人员不到 10 分钟即可完成。部署次数增加了 5 倍，从每天 10 次增加到每天 50 次。而且该公司在计算方面的基础设施成本节省了 50%。“接下来，我们希望解决数据库方面的问题，一旦我们做到了这一点，我们将继续大幅降低成本，”Jeppson 说道。
Kubernetes 还帮助 Nav 满足了其合规性需求。Jeppson 表示，以前，“我们必须将一个应用程序映射到一台服务器，这主要是由于围绕数据的不同合规性法规”。“借助 Kubernetes API，我们可以添加网络策略，并在需要时隔离和限制数据。”该公司将其集群隔离为不受限制的区域和受限制的区域，后者拥有自己的一组节点，用于进行数据保护。该公司还使用 Twistlock 工具来确保安全，“这让我们晚上睡得更安稳，”他补充道。
随着 Kubernetes 的到位，Nav 团队还开始通过采用 Prometheus 来改进系统的指标和日志记录。“Prometheus 创建了一个围绕指标的标准，开发人员很容易采用，”Jeppson 说道。“他们可以自由地显示他们想要的内容，做他们需要做的事情，并保持代码库的整洁，这对我们来说绝对是必须的。”
Nav 明年的下一步计划是：研究跟踪、存储和服务网格。在与其他公司进行了大量的 KubeCon 会谈后，他们目前正在评估 Envoy、OpenTracing 和 Jaeger。“社区绝对至关重要：能够交流想法，讨论我们所有人面临的许多类似挑战，并获得帮助。我喜欢我们能够出于不同的原因解决相同的问题，但在此过程中互相帮助，”Jeppson 说道。“在可扩展性方面，在真正完全采用云原生解决方案方面，还有很多很多工作要做。”
当然，这一切都始于 Kubernetes。Jeppson 表示，借助这项技术，他的团队构建了一个允许 Nav 进行扩展的平台，“通过赋予我们所有这些前所未有的新自由，为 Nav 带来了巨大的价值。”
过去，关于新产品的讨论常常会陷入困境，因为他们必须等待六个月才能建立一个具有隔离性的环境，然后才能弄清楚如何处理流量高峰。“但现在这对我们来说已经不算什么了，”Jeppson 说道。“我们现在处理的流量是之前的 4 到 10 倍，而我们只是觉得，‘哦，是的。Kubernetes 会为我们处理好这些。’”