大规模服务网格：Xbox云游戏如何使用Linkerd保护22k个pod

CNCF

发布于 2022-06-10 14:17:53

5050

发布于 2022-06-10 14:17:53

文章被收录于专栏：CNCF

客座博文作者：微软 Xbox Cloud Gaming 软件开发工程师 Abereham Wodajie 和 Chris Voss

Xbox Cloud Gaming 是微软的游戏流服务，在全球 26 个市场提供 100 多种游戏。到目前为止，全球已有超过 1000 万人通过 Xbox 云游戏进行游戏。

在这篇博客文章和即将到来的KubeCon + CloudNativeCon 讲座[1]中，我们将分享我们如何利用服务网格及其保护在途通信的能力，将我们的服务扩展到全球数百万玩家，同时降低成本，并为我们的团队节省大量工程时间。

Xbox 云游戏基础设施

推动 Xbox 云游戏的服务是巨大的。我们在几个 Azure 地区拥有 26 个以上的 Kubernetes 集群，每个集群有 50 个以上的微服务和 700 到 1,000 个 pod，总共有 22k 个 pod 受到 Linkerd 的保护。如果你曾经在 xbox.com/play 上玩过游戏（比如《堡垒之夜》，现在可以通过 Xbox Cloud Gaming 免费流式传输到你的浏览器上），你在用 Linkerd。

这一规模不是一夜之间形成的，而是多年来我们不断完善基础设施的艰苦努力的结果。早期，这样的改进之一，是我们对使用渐进式部署来可靠地部署我们的服务的兴趣。随后对如何实现金丝雀发布的研究，开始了我们服务网格的旅程。

评估服务网格

我们的团队在 2018 年北美 KubeCon + CloudNativeCon 上首次接触到服务网格的概念。此后不久，我们对各种服务网格项目的当前状态，以及我们自己的基础设施的成熟度，进行了评估，同时我们很快意识到，这些项目和概念，仍处于开发和采用的初始阶段。我们相信，Kubernetes 中的服务网格，是朝着正确方向迈出的一步，但是团队认为，由于需要所有的移动部件和额外的设置，我们还没有达到通过一个简单过程就能采用服务网格的地步。

然后，我们将重点转移到更熟悉服务网格想要解决的问题，以及这如何帮助我们更好地控制和了解我们集群内部的通信，目的是在重新评估服务网格，并决定哪一个将满足我们的需求和用例时，获得更多知识，并处于更好的位置。

2019 年，Xbox Cloud Gaming 推出了第一次公开预览，我们的团队踏上了继续提高支持这些新游戏体验的基础设施可靠性的旅程。我们知道我们需要一个能够促进渐进式部署的解决方案，并开始研究各种选项。当时，我们的团队参加了在圣地亚哥举行的 2019 年北美 KubeCon + CloudNativeCon，在那里我们了解了更多关于服务网格的路线图、新的 SMI（服务网格接口，Service Mesh Interface）的定义，以及所有项目现在如何有一个明确的范围方向和预期的功能集。我们还深入了解了服务网格如何促进渐进式部署的流量分流，以及其他功能，如相互 TLS（mTLS）和服务级别指标。

采用 Linkerd

快进到 2020 年，此时有多种服务网格解决方案可用，我们的选择过程受需求驱动，具体来说，我们正在寻找一种解决方案：符合 SMI，具有高效的资源利用率（CPU 对于大型部署标记尤为重要），在开源社区中有良好的文档记录并广为人知。该团队的方法是原型和评估最知名的可用解决方案，我们的候选名单包括 Istio、Linkerd、Consul Connect 等。最后，团队决定采用 Linkerd，因为它提供的解决方案的特性集与我们的需求非常匹配，而且它让我们能够将注意力集中在团队想要利用的特性子集上。

简单可用的 mTLS

我们构建了自己内部使用的 mutual TLS（mTLS）解决方案，以确保服务之间的流量即使不离开集群也是安全的。但是维护它越来越耗时，团队意识到我们正在尝试解决已经解决的问题，现有的解决方案不仅更强大，而且被更广泛地采用，这也意味着更好的支持。采用 Linkerd 使我们节省了宝贵的工程时间，提高了可靠性，并将团队的努力集中在我们产品的更多功能上。

有 50 多项微服务和一个必须重新设计和重组的部署基础架构，准备进行切换需要一些时间，但这是值得的。一旦服务准备就绪，由于有大量的文档可用，安装和配置 Linkerd 变得非常简单。我们使用 Kustomize 来配置一些 Linkerd 组件，包括 Prometheus、Linkerd 控制器和 Linkerd 目的地。设置代理自动注入也很简单，并且可以在需要时从特定的服务轻松地启用和禁用服务网格。

更多的 CNCF 项目：Flagger、Prometheus、fluentd 和 Grafana

除了 Linkerd，我们还使用其他 CNCF 项目，如 Flagger、Prometheus 和 Grafana 项目。目前，我们有两个 Prometheus 实例，一个专用于 Linkerd，另一个用于我们自己的定制指标——我们最终打算将它们整合到一个实例中以简化管理。我们使用 Grafana 进行按需或实时故障排除，当然，Flagger 用于金丝雀发布——这是项目的最初目标。

Linkerd 和 Flagger 都使用服务网格接口（SMI） API，它支持 Kubernetes 中的高级渐进式部署行为。通过使用 Linkerd 的流量分离器和 Flagger，该团队已经能够自动进行金丝雀发布到我们的 AKS（Azure Kubernetes Service）集群。在此过程中，Flagger 负责管理主部署和金丝雀部署之间的流量路由，评估成功率，并在所有信号看起来正常时缓慢迁移流量，从而显著降低停机风险或客户影响。这使得我们的团队可以更快、更频繁地测试和推出新功能。

每月在监控等方面节省数千元

有了 Linkerd，技术进步对团队的成功产生了重大影响。我们能够使用零配置 mTLS 保护 22k 个 pod 之间的流量。考虑到开发和维护我们的内部 mTLS 解决方案所投入的时间和精力，我们可以说，由于 Linkerd 从团队中卸载了这项工作，我们节省了宝贵的工程时间，这转化为团队有更多的时间，专注于功能工作和我们的服务质量。此外，由于 mTLS 现在发生在代理级别，而不是为某些请求调用特定的 mTLS 服务，我们平均减少了 100ms 的延迟，并且每月在 pod 和容器监控方面节省了数千美元。

除了服务资源利用率指标（CPU 和内存）之外，Linkerd 的遥测和监控还为我们提供了更多的可见性，例如请求量、成功/失败率，以及每个 API 每个服务的延迟分布——是即装即用。我们进一步利用 Linkerd 指标来构建我们自己的仪表板，取代我们的内部解决方案。今天，我们将 Linkerd 生成的指标从 Prometheus 推送到我们自己的商店。它花了一些时间来设置，但它是一件一旦完成就完全免费的事情。

几年前，我们开始了发现服务网格的旅程，由于我们在 KubeCon + CloudNativeCon 的参与以及团队所做的工作，我们很高兴我们找到了一个很好的解决方案，使我们能够继续创造令人惊叹的体验。如果你正在巴伦西亚参加 2022 年欧洲 KubeCon + CloudNativeCon，请参与我们的讨论[2]（虚拟或面对面）。我们将更详细地介绍我们的服务网格之旅，并期待与你聊天、分享经验和回答任何问题。