作者：Christian Hüning，Finleap Connect 云技术与 Switchkit 总监
在Finleap Connect[1]，我们运营多个高密度裸金属 Kubernetes 集群，最多可达 5000 个 pod——确保客户高度敏感的金融数据的安全对业务至关重要。不用说，安全是第一位的。
在这篇博客文章中，我将分享 Connect 的云团队如何将其整个平台迁移到云原生架构，同时对所有服务进行 mTLS（"mTLSing"），以符合严格的监管要求。这是一个巨大的任务，特别是考虑到我们五个月的紧迫期限！令我们惊讶的是，mTLS 方面相当简单。Linkerd 在一个小时内安装好，在一周内运行到产品中，而没有影响到我们的开发团队。
赋能下一代金融服务
我是欧洲领先的独立开放银行平台 Finleap Connect 的云团队负责人。我们的全栈平台使银行、会计和贷款机构能够为客户提供下一代、移动优先的金融服务。服务包括丰富数据和分析，默认财务数据的可访问性，跨一系列应用程序的无缝支付等等。
在 Connect，我们了解客户是如何交易和互动的，并且这些知识已经嵌入到我们的平台中。此外，该平台允许我们的客户访问他们的客户的金融交易，并通过分析工具丰富数据，同时提供高质量的数字银行服务，数字产品和服务。
工程团队
我们的团队包括少数云工程师和分布在多个较小团队的大约 60 名工程师。我的团队——云团队——负责分布在 10 个 Kubernetes 集群的 50 多个微服务，分布在 GCP、AWS 和裸金属私有云的三个地理区域。我们最大的集群运行着 52 个节点和 5000 个 pod。
为了操作 Connect cloud——我们的云无感私有设置——我们使用SAP Gardener[2]。Linkerd 部署在所有集群中，是我们基础设施的组成部分。Linkerd[3]，包括它的指标，都是通过Buoyant Cloud[4]集中管理的。
（顺便说一下，我们正在招聘。如果你有兴趣加入一个不断推动技术极限的动态工程团队，请查看我们的工作公告板[5]——我们一直在寻找伟大的人才！）
跨所有服务的 mTLS 是一项监管要求
Connect 是在一个高度监管的环境中运营的，因此，我们必须考虑一些重要的因素——毕竟，我们正在处理高度敏感的金融数据。在 2018 年，这意味着在我们集群中的所有服务中实现 mTLS，独立于实际的业务代码（即在不同的层上解决它）。
为了应对这一挑战，我们评估了各种可用的解决方案。其中一个选择就是 Istio。我们将它安装在我们的测试集群上，虽然它工作得很好，但它也需要相当多的配置。当我们意识到每个服务都需要配置时，Istio 很快变得不那么可行了。这是在 2018 年（早期）。我们在一个雄心勃勃的路线图上将整个堆栈迁移到云原生架构（迁移必须在 5 个月内完成）。我们的开发团队已经处理了大量的转换任务。我们认为 Istio 将成为额外的配置负担，并决定不使用它。
我们研究的另一个服务网是 Linkerd（当时被称为 Conduit）。它的简单性、路线图以及我们与项目维护人员进行的各种 Slack 讨论，让我们有信心采用这个项目。
Linkerd：一小时内安装，一周内生产
Linkerd 安装不到一个小时；整个生产过程大概需要一周的时间。一些更新，包括对 Linkerd 的证书管理功能的贡献，花费了额外的几个星期（更多在下面提到）。
总的来说，Linkerd 的整个体验非常棒。当我们开始大规模运行 Linkerd 时遇到了一些麻烦，这主要归结为需要 scale-up 和 scale-out 扩展 Linkerd 组件。
Linkerd 路线图上有一些东西还没有实现。证书管理就是其中之一。证书在一年后到期，我们有一年的时间来解决这个问题。我们决定为 Linkerd 项目做出贡献，以帮助开发该特性。今天，证书轮换是完全自动化的，我们不需要担心任何事情。使用 server-spoke-first 协议的应用程序是另一个例子，但从 Linkerd 2.10 开始，它也得到了支持。
对开发人员生产力影响最小的端到端加密
我们能够大规模地跨所有服务实现 mTLS，同时最大限度地减少对开发人员生产力的影响。整个过程相当迅速，让我们能够在最初的关键期限内完成新平台的上线。没有 Linkerd，我们不可能做到这一点。
此外，Linkerd 的四个黄金信号指标对于统一通用的平台级调试和服务运行状况可观察性特别有用。当我们将工作负载迁移到 Kubernetes 时，这些指标为我们提供了即时的洞察。云团队无需太深入地挖掘应用程序的细节就能获得所有这些信息——这为团队节省了大量时间，也是开始新开发的云原生应用程序管理的好方法。
我们还通过 Linkerd 和Flagger[6]实现了灰度（canary/金丝雀）发布，现在可以更快地交付特性，而且信心大增。
所有这一切几乎都是通过在我们的应用程序中部署和激活 Linkerd 而自动实现的。Linkerd 帮助我们避免了某些服务更复杂的 TLS 设置，为我的团队节省了大量的积压（backlog）时间。这一切都很整洁，这也是我一直对这个项目强烈推荐的原因之一。
Linkerd 社区
Linkerd 社区是最好的！每个人都非常热情。Slack 渠道是获得有价值的意见和与其他人合作的好方法。你可以找到任何问题的解决方案。事实上，你可以经常在那里找到我。我一直活跃在社区中，因为我喜欢抓住任何帮助教育他人的机会，我获邀请成为Linkerd 大使[7]，加入一些其他出色的 Linkerd 最终用户的行列。
Connect 在 CNCF 项目和开源上投入了大量资源
多年来，我们在 CNCF 开源解决方案上投入了大量资源，并将其应用于我们所有的软件堆栈。我们使用Emissary-Ingress[8]（以前的 Ambassador）、Flagger 用于金丝雀部署、cert-manager[9]用于所有的证书处理、Prometheus[10]和 Grafana 用于平台监控、NATS[11]、Rook[12]和 Ceph 用于我们私有云集群中的存储。
其他非 CNCF 开源项目包括用于所有 SQL 数据库的 CockroachDB、NGINX Ingress、Hashicorp Vault 和 RabbitMQ。
零信任并不难
对于像我们这样在金融科技行业运营的公司来说，零信任是必须的。但零信任正日益成为各行各业的必备条件。在微服务的世界里，防火墙不再起作用了。我听到很多同行担心他们可能会给已经很复杂的系统增加复杂性。但零信任并不难。我希望这个博客可以作为证据。
我们能够在 5 个月内 mTLS 了所有服务，同时最大限度地减少对开发人员生产力的影响。此外，平台指标已被证明在调试和保持服务运行状况时可以节省时间。
我们选择 Linkerd 是因为它的配置非常简单，同时几乎可以自动提供关键特性。当时还没有可用的功能，我们帮助构建。今天，没有理由不 mTLS 你所有的服务。
参考资料
[1]Finleap Connect: https://connect.finleap.com/
[2]SAP Gardener: https://github.com/gardener/gardener
[3]Linkerd: https://linkerd.io/
[4]Buoyant Cloud: https://buoyant.io/cloud
[5]工作公告板: https://connect.finleap.com/finleap-connect-open-positions-jobs/
[6]Flagger: https://github.com/fluxcd/flagger
[7]Linkerd 大使: https://linkerd.io/community/ambassadors/
[8]Emissary-Ingress: https://github.com/emissary-ingress/emissary
[9]cert-manager: https://cert-manager.io/
[10]Prometheus: https://prometheus.io/
[11]NATS: https://nats.io/
[12]Rook: https://rook.io/
