79,503
社区成员
发帖
与我相关
我的任务
分享大规模服务网格：Xbox Cloud Gaming 如何使用 Linkerd 保护 22k pod
作者：Abereham Wodajie + Chris Voss2022 年 5 月 10 日
Abereham Wodajie 和 Chris Voss 的客座文章，微软Xbox 云游戏的软件开发工程师
Xbox Cloud Gaming 是 Microsoft 的游戏流媒体服务，在全球 26 个市场提供 100 款游戏目录。迄今为止，全球已有超过 1000 万人通过 Xbox Cloud Gaming 流式传输游戏。
在这篇博文和即将到来的KubeCon + CloudNativeCon 演讲中，我们将分享我们如何利用服务网格及其保护传输中通信的能力来将我们的服务扩展到全球数百万玩家，同时降低成本并为我们的团队节省大量的工程时间.
Xbox 云游戏基础架构
为 Xbox 云游戏提供支持的服务非常庞大。我们在多个 Azure 区域拥有 26 多个 Kubernetes 集群，每个集群都有 50 多个微服务和 700 到 1,000 个 Pod——总共有 22k 的 Pod 由 Linkerd 保护。如果您曾经在 xbox.com/play 上玩过游戏（例如Fortnite，现在可以通过 Xbox Cloud Gaming 免费流式传输到您的浏览器），那么您使用的是 Linkerd。
这种规模不是一夜之间形成的，而是多年艰苦工作的结果，我们的基础设施逐渐成熟。早期，其中一项改进是我们对使用渐进式部署来可靠地部署我们的服务感兴趣。随后对如何实施金丝雀版本的调查开始了我们的服务网格之旅。
评估服务网格
我们团队在 KubeCon + CloudNativeCon NA (North America) 2018 上第一次接触到服务网格的概念。不久之后，我们对各种服务网格项目的现状以及我们自己的基础设施的成熟度进行了评估，同时这样做我们很快意识到这些项目和概念仍处于开发和采用的初始阶段。我们相信 Kubernetes 中的服务网格是朝着正确方向迈出的一步，但团队认为我们还没有到采用服务网格是一个简单的过程，因为需要所有移动部件和额外的设置。
然后，我们将重点转移到更熟悉服务网格打算解决的问题以及如何帮助我们更好地控制和了解集群内部的通信，目标是在适当的时候变得更有知识和更好的地方开始重新评估服务网格并决定哪一个可以满足我们的要求和用例。
2019 年，Xbox Cloud Gaming 推出了第一个公开预览版，我们的团队开始着手继续提高为这些新游戏体验提供动力的基础设施的可靠性。我们知道我们需要一个可以促进渐进式部署的解决方案，并开始研究各种选项。当时，我们的团队参加了在圣地亚哥举行的 KubeCon + CloudNativeCon NA 2019，在那里我们更多地了解了服务网格的路线图、新服务网格接口的定义以及所有项目现在如何对范围和功能有了明确的方向对他们的期望。我们还深入了解了服务网格如何促进渐进式部署的流量拆分以及相互 TLS (mTLS) 和服务级别指标等其他功能。
采用 Linkerd
快进到 2020 年，此时有多种服务网格解决方案可用，我们的选择过程是由需求驱动的，特别是我们正在寻找一种解决方案：符合服务网格接口，具有高效的资源利用率（CPU 对大型部署图章），有据可查，在开源社区中广为人知。该团队的方法是对可用的最知名的解决方案进行原型设计和评估，我们的候选名单包括 Istio、Linkerd、Consul Connect 等。最后，团队决定采用 Linkerd，因为它提供的功能集与我们的需求非常匹配，它让我们将注意力集中在团队想要利用的功能子集上。
简单有效的 mTLS
我们构建了自己的内部双向 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 服务）集群。在此过程中，Flagger 负责管理主部署和金丝雀部署之间的流量路由，评估成功率，并在所有信号看起来都正常时缓慢迁移流量，从而显着降低停机风险或影响客户。这使我们的团队能够自信地更快、更频繁地测试和推出新功能。
每月在监控等方面节省数千美元
有了 Linkerd，技术上的进步对团队的成功产生了重大影响。我们能够使用零配置 mTLS 保护 22k pod 之间的流量。考虑到在开发和维护我们的内部 mTLS 解决方案方面投入的时间和精力，我们可以说，感谢 Linkerd 将这些工作从团队中分担，我们节省了宝贵的工程时间，这意味着团队有更多时间专注于特色工作和我们的服务质量。此外，由于 mTLS 现在发生在代理级别，而不是为某些请求调用特定的 mTLS 服务，我们将延迟平均减少了 100 毫秒，并且每月在 Pod 和容器监控上节省了数千美元。
除了服务资源利用率指标（CPU 和内存）之外，Linkerd 的遥测和监控还为我们提供了更多关于请求量、成功/失败率和每个服务每个 API 的延迟分布等领域的可见性——开箱即用。我们进一步利用 Linkerd 指标来构建我们自己的仪表板，取代我们的内部解决方案。今天，我们将 Linkerd 生成的指标从 Prometheus 推送到我们自己的商店。设置需要一些时间，但一旦完成，它就会完全免费。
几年前，我们开始了探索服务网格的旅程，感谢我们在 KubeCon + CloudNativeCon 的参与以及团队所做的工作，我们很高兴找到了一个很好的解决方案，可以更好地让我们继续创造令人惊叹的体验。如果您正在瓦伦西亚参加 KubeCon + CloudNativeCon Europe 2022，请加入我们的谈话（虚拟或面对面）。我们将更详细地介绍我们的服务网格之旅，并期待聊天、分享经验和回答任何问题。
...全文
请发表友善的回复…
发表回复
