原文作者：Lunar首席平台架构师 Kasper Borg Nissen
原文译自：CNCF（云原生基金会）

Kubernetes 和 Linkerd 如何成为 Lunar 的多云通信主干

北欧数字银行 Lunar，在很早便采用了云原生技术。自 2017 年以来，Lunar一直在运行 Kubernetes，如今已经有超过 250 个微服务分布在三朵云中。

本文将共同探讨Lunar是如何集中管理所有云平台及应用服务的。无论是从更好地整合新收购的公司，还是提高开发人员的研发效率，多云集中管理所带来的收益都是巨大的。

关于Lunar

Lunar 成立于 2015 年，旨在通过构建用户与金融互动的方式来改善银行业现状。Lunar 适合那些希望将与金钱相关的一切都集中在一个地方的人——100%实现数字化。

对Lunar来说，这意味着为客户提供一种更智能的方式来管理他们的资金，实现更多的控制权、更快地储蓄、更容易的投资，而且没有额外多余的费用。这也是Lunar对银行业未来的展望。

2021年，Lunar收购瑞典借贷公司Lendify，以及丹麦金融科技初创公司 PayLike。这都是 Lunar 实现进一步的发展和实现规模战略的一部分。这也意味着Lunar必须整合所有这些应用系统，这样各套系统之间才能顺利协同。

Lunar 贯彻云原生理念

Lunar 150 多名全职工程师的团队每天都有大约 40 个版本的应用将推向生产。在这 150 人中，其中有 10 人是平台工程师，这就是我所领导的团队。

我们在多个可用区上跨多云（AWS、Microsoft Azure 和 Google Cloud Platform）运行九个 Kubernetes 集群。我们还运行 250 多个微服务以及一系列平台服务，这些服务是我们自助式开发人员平台的一部分。我们希望我们的团队，或者我们称之为小队，能够自主和自我驱动。为了支持这种“shift left”行动，一组平台小队构建了抽象概念和工具，以确保开发人员能够快速、安全、合规和高效地改进他们的功能。

收购 Lendify 意味着Lunar现在有了一个基于Azure的平台，所以我们必须对其进行集成和调整，因此它需要符合 Lunar 现有的云原生理念。我们目前正在努力无缝连接我们的 AWS 和 Azure 环境。

我们选择云原生路径的原因有很多。首先，我们需要一个平台，让我们的团队能够管理他们的服务并实现完全自主开发。其次，作为一家开创基于云的银行业务的金融科技公司，我们必须为云厂商提供明确的退出策略——这是丹麦金融服务管理局的监管要求。

Kubernetes 非常适合，作为云厂商之上的一个抽象概念，Kubernetes帮助Lunar实现了以下两个目标：

一是这种自主性使我们能够轻松扩展，因为大多数依赖项都被删除了。Squad 还受到多种开源工具的支持，包括 Backstage、Prometheus 和 Jaeger，以及一些我们已经开源的定制解决方案，例如Shuttle和release-manager。

二是这种多云战略和工作方式助力企业实现员工拓充和企业并购扩展的目标。它还能保障技术安全，并选择最适合我们需求的技术。

Lunar 的生产日志在哪里？

集中平台服务的想法始于我们的日志管理系统 Humio。当时，我们正在为生产 Kubernetes 集群开发故障转移流程。事实证明，这导致我们的日志管理系统中丢失了日志。那时我们意识到，在生产中执行任何故障转移之前，我们必须从生产集群中删除系统并将其集中起来。

从日志分散到集中所有平台服务

在成功集中我们的日志管理系统后，我们决定在每次公司收购之前开始平台服务集中之旅。虽然我们有多个环境，但我们的许多平台服务，例如可观察性堆栈，都在每个环境中进行了复制。这些服务需要大量资源并且相当复杂。Humio、Prometheus 和 Jaeger（使用 Elasticsearch）等服务是有状态的服务。在“workload”集群中拥有状态服务会使故障转移和灾难恢复变得更加困难。因此，我们决定在这些环境中尽量减少有状态服务的数量。此外，运行九个复制的设置根本无法扩展，所以我们需要一个集中的解决方案。

此外，拥有多个端点来访问 Grafana 之类的东西会导致大量重复用户、仪表板等。这给我们的开发人员造成了一些麻烦，他们必须在多个地方进行更改，从而导致环境之间的漂移以及带来其他挑战。在一个系统中管理用户比在九个（或更多）系统中管理用户效率高得多。

这就是为什么我们决定创建一个由平台团队拥有的集中式集群，该集群最终将运行整个可观察性堆栈、发布管理、开发人员工具和集群 API。

今天，我们的日志和发布管理作为平台团队提供的集中式服务运行。此外，Backstage 是在集中式环境之外提供的，以及一些其他工具。接下来是我们的监控设置，混合了 Buoyant Cloud 和 Prometheus/Grafana。

多集群管理的探索

一旦我们开始集中平台服务，我们就需要连接我们的集群。当时，我们只在 AWS 中运行集群，并考虑跨我们的账户进行 VPC 对等互连。由于 CIDR 范围冲突，这样做有些困难。我们还评估了 VPN，但不喜欢使用两端各有两个静态框的技术。此外，我们希望遵循 Google BeyondProd 的原则，向零信任网络迈进。

服务网格最终满足了我们的需求！

在 5 年多的生产中运行 Kubernetes ，我们不断评估服务网格。2017 年，我们让 Linkerd 作为 PoC 运行，但最终决定放弃。它仍然是基于 JVM 的 Linkerd 1，而且相当复杂。我们一直在关注服务网格的发展和演变，当我们看到 Linkerd 2.8 版本及其多集群功能时，我们意识到是时候再给服务网格一个机会了。

我们在 gRPC 负载平衡（Kubernetes 本身不支持）方面遇到的一些问题以及所有内部通信都需要切换到 mTLS 的问题进一步强化了我们的决定。服务网格现在变得更有意义了。

虽然我们同时评估了 Linkerd 和 Istio，但我们一直是 Linkerd 所采用方法的忠实拥护者：从基础开始并使其运作良好。我们给了自己一周的时间：两名工程师；一个尝试部署 Istio，另一个尝试部署Linkerd 。

我们在一小时内启动并运行了 Linkerd 多集群！经过几天与 Istio 的斗争，我们放弃了它。（事实证明，基于Istio自建落地企业服务网格，实现微服务治理，Lunar也很难搞定）Linkerd 快速轻松地完成了这项工作——对我们来说是完美的网格。它具有我们当时需要的所有功能；易于操作，拥有强大的社区和可靠的文档。

自上线以来，我们还开始使用Buoyant Cloud来更好地了解我们所有的环境。

Lunar 致力于 CNCF 协议栈

Lunar是 CNCF 项目的忠实拥护者并使用其中的许多项目（事实上，我是 CNCF 大使，并且喜欢在这些很棒的项目上对社区进行传播！）。Lunar 也是CNCF 最终用户成员。

我们的堆栈包括 Kubernetes、Prometheus、cert-manager、Jaeger、Core DNS、Fluent-bit、Flux、Open Policy Agent、Backstage、gRPC 和 Envoy 等。我们在所有集群中构建了一个基于 Envoy 的入口/出口网关，以便为开发人员提供一个很好的抽象来在不同的云中公开服务。

准备扩大我们的业务并撼动欧洲银行市场

从技术的角度来看，我们现在已经实现了一种相当简单的方法来管理多云集群。Kubernetes 允许我们在任何地方运行，Linkerd 使我们能够无缝连接我们的集群，GitOps 提供了一种经过审计的方式来使用相同的工具和流程跨多个云管理我们的环境。从开发人员的角度来看，无论您是在 GCP 还是 AWS 上部署，流程都是相同的。

与新收购的初创公司无缝集成

业务影响是巨大的。借助我们新的多云通信主干，我们能够更好地支持即将到来的并购——这是我们业务战略的关键部分。拥有一种与云无关的方式来扩展 Lunar 平台，无论它们在哪里运行，都非常强大。它还允许我们为每个用例选择最适合我们需求的提供商。

在遵守政府法规的同时为灾难恢复做好充分准备

在故障转移期间我们不再丢失日志这一事实是巨大的。我们很快将为我们的生产集群实施季度故障转移。我们需要确保我们确切地知道我们的系统在发生故障时的行为以及如何恢复它。从监管角度和业务角度来看，这都很重要。如果我们的客户无法访问他们的帐户信息，这将对我们的业务造成灾难性的后果。这就是为什么我们会主动针对最坏的情况进行训练。如果发生了什么事，我们将确切地知道该做什么以及如何避免问题。

我们非常相信宠物与牛的想法，但更进一步。我们也不想拥有宠物服务器或宠物集群。想象一下，每次我们执行故障转移时都会丢失日志。如果没有审计日志，我们就会立即脱离法规遵从性。

集中式服务和简化流程提高了开发人员的生产力

集中我们的大部分平台服务已经简化了许多流程并提高了开发人员的生产力。我们确保所有版本、指标、日志、跟踪等都正确标记了小队名称、环境等字段，使开发人员可以轻松找到他们正在寻找的内容。它还确保了该特定部分的明确所有权。

管理团队也简单得多。对我来说，这意味着我不必设置仪表板、帮助搜索日志等——我们的小队是真正独立的。因为我们的平台基于自助服务，所以它与组织分离，使我们的团队能够专注于实施下一个将帮助我们的开发人员更快、更安全或确保更好质量的事情。

轻松审核，让管理层高枕无忧

然后是简单的审计。由于一切都是集中的，我们可以跨组和环境运行所有云和服务的审计报告。这对我们有好处，让我们在高度监管的金融服务行业中高枕无忧。

虽然我们还没有做到这一点，但我们希望通过不必操作和维护即将完全集中的堆栈的九个版本来节省大量的工程资源时间。

定位良好，可快速平稳地扩展

总体而言，我们为即将到来的收购和有机增长做好了准备。借助能够在任何地方扩展的平台，我们已经成为一个真正具有弹性的组织。

--------------------

更多云原生实战故事，请加入“云原生交流社区”，每周更新云原生技术好文。