Elkjøp在北欧，挪威，瑞典，芬兰，丹麦和冰岛，格陵兰和法罗群岛拥有超过400个零售点，并在冰岛，格陵兰和法罗群岛拥有特许经营权，是北欧最大的电子产品零售商。它还在所有这些市场中都有大型的电子商务业务。
在本文中，我们将讨论北欧最大的电子零售商Elkjøp如何构建内部Kubernetes平台，该平台现在已成功托管生产中的200多种微服务，以提高开发速度，同时又不影响安全性或可见性。该平台使组织能够将托管成本降低约80％。
Elkjøp的历史始于1962年。Elkjøp已经拥有强大的实体零售业务和物流基础设施。长期以来，IT部门规模很小，主要致力于集成第三方产品和外部开发的解决方案。六年前，当引入微服务以在系统之间提供共享功能时，该策略开始发生变化。其中包括电子商务平台和店内销售点系统都使用的高级支付API。
事实证明，内部开发的微服务是提高开发速度的绝佳解决方案，并迅速成为昂贵的企业软件包的首选替代方案。前一百个微服务托管在单独的Azure Web Apps中，但是随着环境的发展和API成为主要且很快成为唯一实现销售的方式，需要一种新的方法。
经过简短的可行性研究后，Elkjøp团队决定从挪威IT咨询公司Aurum AS获得帮助，以帮助Elkjøp建立新的，现代的，企业就绪的微服务托管平台。
该平台最终托管了将近200种微服务，所有这些微服务都进行了升级和调整，以适应Elkjøp客户在网上，社交媒体，移动或商店中使用的任何渠道的24/7全天候无缝购买体验的需求。
从一开始，该平台就具有特定的目标和原则：
- 第一次平台迭代至少需要与Azure App Service相同的功能，但是成本较低且易于操作。
- 还需要自动或手动扩展规模，并集中管理不同的应用程序。
- 移动工作负载或启动新应用程序后，开发人员的工作效率应提高。
我们还希望将跨领域的关注点从库包转移到平台上。我们需要通过将应用程序部署到平台上来为开发人员提供一组基本的功能和安全性。换句话说，我们希望采用一种更加面向方面的模型。我们需要为单个团队提供完全的自治权，但要确保存在防止错误的界限。
我们通过将应用程序码头化并将其部署到Kubernetes上开始了迁移。但是，我们很快意识到我们错过了由PaaS产品（例如Azure App Service）提供的现成的指标和见解。此外，由于我们在入口控制器处终止了TLS，因此应用程序之间的所有通信均未加密。我们需要引入可以解决这两个问题的东西，这就是服务网格的作用。
我们选择了Linkerd，这是轻量级，超快速的Cloud Native Computing Foundation（CNCF）服务网格。在较高水平上，Linkerd会为每种应用注入超轻量的微代理作为辅助工具。代理可以减轻许多跨领域的关注，例如加密，并提供有价值的指标，这正是我们需要解决的问题。
微型代理形成数据平面，而Linkerd的其他组件构成控制平面。Linkerd控制平面具有可与自己的CLI或仪表板一起使用的API。它还有其他一些应用程序可以帮助发布mTLS证书，代理注入器可以将代理服务器注入到Kubernetes部署中，这是一个名为“ tap”的应用程序，它可以设置流以监视来自代理服务器的实时流量。
为什么选择Linkerd？
我们的指导原则之一是引入技术，以最小的复杂性解决特定问题。毕竟，Kubernetes非常复杂。从高层次的抽象来看，服务网格的范围从完整的API管理到单个应用程序上的微型Sidecar代理。我们倾向于后者。
出于几个原因，Linkerd是我们的选择。
Linkerd的代理是用Rust编写的，性能开销较低。在内存和CPU使用率方面，它击败了其他服务网格。虽然我们认为Istio不会带来额外的性能成本，但对于我们来说，这是一个问题，但我们会尽力获得所有的性能提升。
另外，我们希望有一个由CNCF支持的项目，它具有所有优点。
微软在2019年巴塞罗那Kubecon大会上介绍了服务网格接口（SMI）。简而言之，SMI是服务网格可以具有和实现的接口的开源规范。我们喜欢由一个委员会评估规范的想法。由于Linkerd实现了SMI，因此它为我们提供了将来在保持相同接口的情况下切换到其他服务网格的灵活性。
一旦开始实施和使用Linkerd，我们了解到社区的文档和对问题的回答是首屈一指的。
它易于安装，启动和运行。它会自动注入微代理，这意味着平台团队可以标记名称空间以自动在服务网格上进行部署。开发人员无需担心Linkerd。如果他们确实需要覆盖默认值，则可以使用批注轻松地做到这一点。
在撰写本文时，我们正在所有国家/地区推出新的销售点系统。到2021年底，每笔交易（每年400亿挪威克朗（47亿美元））将通过这些新的Kubernetes环境进行交易。我们相信Linkerd能够帮助我们保持公司运营并帮助客户享受令人赞叹的技术。