挑战
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 认识到自身成功之路上的一个障碍。业务增长迅速，“我们的云环境变得非常庞大，而这些环境的利用率却极低，比如低于 1%，”Jeppson 说。“大部分问题都与扩展能力有关。我们只是在往里面扔钱。“让我们启动更多的服务器。让我们做更多的事情来处理增加的负载。”而对于我们这样一家初创公司来说，这可能会导致我们的灭亡。我们没有钱花在这种事情上。”
此外，每个新服务都必须经过 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 为我们处理这一切。’”