挑战
Nav 成立于 2012 年，为小型企业主提供访问其在所有三家主要商业信用局（Equifax、Experian 和 Dun & Bradstreet）的商业信用评分的途径，以及最适合其需求的融资选项。Nav 工程总监 Travis Jeppson 表示，在运营了五年后，这家初创公司发展迅速，“我们的云环境变得非常庞大，而这些环境的使用率却极低，低于 1%。”“我们希望我们的云环境使用率能更紧密地与我们实际所需挂钩，所以我们开始研究容器化和编排，以帮助我们能够运行彼此独立但可以共享相似资源池的工作负载。”
解决方案
在评估了许多编排解决方案后，Nav 团队决定采用在 AWS 上运行的 Kubernetes。Kubernetes 社区的力量以及其来自谷歌的出身是极具吸引力的因素。此外，Jeppson 说：“其他解决方案往往相当笨重、非常复杂、规模庞大且刚开始管理起来非常困难。Kubernetes 提供了一种非常简单的方式，让我们能够轻松进入一个当时符合我们需求的编排解决方案，而且它的可扩展性也使我们能够随之成长，并在以后构建更多特性和功能。”
影响
这个由四人组成的团队在六个月内将 Kubernetes 成功运行起来，随后又花了六个月完成了 Nav 的 25 个微服务的全面迁移。结果令人印象深刻：资源利用率（最初引导公司走上这条道路的因素）从 1% 增加到 40%。过去，启动一项新服务需要两名开发者花费两周时间；现在只需一名开发者不到 10 分钟即可完成。部署次数增加了 5 倍。而且公司在基础设施计算方面节省了 50% 的成本。
几年前，Nav 认识到自身成功道路上的一个障碍。Jeppson 说，业务发展迅速，“我们的云环境变得非常庞大，而这些环境的使用率却极低，低于 1%。大部分问题在于可扩展性。我们只是在烧钱。‘我们多启动一些服务器吧。我们多做些事情来处理增加的负载吧。’作为一家初创公司，这可能会导致我们走向灭亡。我们没有钱烧在这些事情上。”
此外，每项新服务都必须经过 10 个不同的人，耗时两周才能上线，这时间太长了。“所有的补丁管理和服务器管理都是非常手动完成的，所以我们都必须很好地监控和维护它，”Jeppson 补充道。“这是一个非常麻烦的系统。”
Jeppson 在他之前的工作中使用过容器，并将这项技术作为解决这些问题的方案向 Nav 管理层提出了建议。他在 2017 年初获得了批准。他说：“我们希望我们的云环境使用率能更紧密地与我们实际所需挂钩，所以我们开始研究容器化和编排，以帮助我们能够运行彼此独立但可以共享相似资源池的工作负载。”
在评估了许多编排解决方案后，公司决定采用在 AWS 上运行的 Kubernetes。Kubernetes 社区的力量以及其来自谷歌的出身是极具吸引力的因素。此外，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 来改进系统的指标和日志记录。Jeppson 说：“Prometheus 为指标创建了一个标准，开发者非常容易采用。他们可以自由地展示他们想要的东西，做他们需要做的事情，并保持代码库的整洁，这对我们来说是绝对必须的。”
Nav 未来一年的下一步计划包括：研究追踪（tracing）、存储和服务网格（service mesh）。他们在参加 KubeCon 与其他公司交流后，目前正在评估 Envoy、OpenTracing 和 Jaeger。Jeppson 说：“社区是绝对至关重要的：能够交流想法，讨论我们都面临的许多相似挑战，并获得帮助。我喜欢我们能够出于不同的原因解决相同的问题，并在此过程中互相帮助。”他补充道：“在可扩展性以及真正全面采用云原生解决方案方面，还有很多很多工作要做。”
当然，这一切都始于 Kubernetes。Jeppson 说，有了这项技术，他的团队构建了一个平台，使 Nav 能够扩展，“通过赋予我们前所未有的自由，为 Nav 带来了巨大的价值。”
过去讨论新产品常常因为需要等待六个月才能建立具有隔离性的环境，然后还要弄清楚如何处理流量高峰而陷入困境。Jeppson 说：“但现在对我们来说这根本不是问题。我们现在处理的流量是以前的四到十倍，而且感觉就像，‘哦，是的。我们很好。Kubernetes 为我们处理了这一切。’”