在Redpoint，我们正在构建支持多人在线第一人称射击游戏Minute of Mayhem所需的基础设施。
对我们来说，正确配置基础架构非常重要； 我们不希望在凌晨3点被唤醒，因为我们的服务提供商已关闭并且玩家无法访问我们的游戏。 我们也不想让自己处于成功发布游戏成倍增加我们的服务成本超出承受能力的位置。
- Pare de perder节奏！ 使用软件livre
- 类似于Ein Rogue的MIT蟒蛇和龟（第3阶段）
- 灵魂收割者：下周即将发布的Unreap Commander Prototype 1.1！
- 太空侵略者将蟒蛇与乌龟
- 2Dimensions会员计划和新功能
为此，我们一直在构建基于Google Cloud的在线多人即服务在线解决方案，称为Hive。 我们不仅要为自己，而且要为其他人提供构建多人游戏的经济高效，高度可扩展的解决方案。 随着Hive接近公开Alpha，我们将宣布有关Hive的更多详细信息。
在我们构建这些服务时，我们注意到您可以采取一些步骤来大幅度降低在Google Container Engine上运行微服务的成本，尤其是在负载平衡器，SSL和入口规则的使用方面。
第一次迭代
当我们开始构建Hive时，我们只有几项服务，即：
- 临时会话服务，提供临时会话以进行测试
- NAT穿透服务，它允许客户端执行NAT穿透并检索游戏中其他玩家的外部地址，以及
- 游戏大厅服务，用于管理游戏的大厅的创建和成员资格
当您的服务很少时，您可以负担得起低效使用Kubernetes的费用。 毕竟，Google Cloud Load Balancers的定价意味着您要支付相同的负载平衡费用，直到您超过5条全局负载平衡规则为止。 但是，除此之外，事情开始变得昂贵。
我们在Google Cloud上的初始基础架构看起来像这样，每个微服务都有自己的入站负载平衡器IP地址：
如您所见，这已经存在一个经济的可扩展性问题：每个容器都有自己的负载均衡器，超过5个负载均衡器时，Google会对每个入站规则收取$ 7.20的费用。 如果您打算拥有大量微服务，那么这个成本将开始增加，并且可能无法使您的负载平衡成本超过计算实例的成本。
我们从这种初始架构开始，主要是因为Kubernetes通过--load-balancer-ip的使用使在此处结束变得如此容易，这是在Kubernetes上创建或更新服务时可以传递的参数。
--load-balancer-ip的替代方法
Kubernetes提供了这种说法的替代方法，称为ingresses 。 入口允许您指定入站负载平衡器的配置，与群集提供的服务分开。 这样，您就可以通过单个Google Cloud Load Balancer将所有入站流量路由到您的集群，从而大大降低了成本。
如果您通过SSL提供服务（应该如此），您会很快注意到Google Cloud Load Balancer不支持SNI。 这意味着您不能通过负载平衡器为每个微服务提供不同的SSL证书。 如果通配符证书不在您的价格范围内，则需要像我们一样找到其他解决方案。
对我们来说幸运的是，已经有人建立了一个名为Kube Lego的解决方案。 这是一个可以部署到Kubernetes集群的Pod; 它会监视群集中的入口，并自动配置入站负载平衡器以进行Let’s Encrypt的验证，颁发证书并为新证书启用SSL。 它还使用Let’s Encrypt自动处理续订。
下面显示了用于将Kube Lego部署到集群中的部署YAML文件。
现在，我们只有两个负载均衡器，并且可以通过同一个负载均衡器路由任意数量的微服务。 做对了吗？ 不太完全是，这是由于Google价格负载均衡器的方式有些奇怪。
一个项目来统治所有人
还记得我们说过Google对前5个负载均衡器收取统一费用吗？
好吧，如果您像我一样，请阅读此书，并假设这些“前5条转发规则”是针对每个结算帐户的。 也就是说，每个项目中都有一个负载均衡器这一事实并不重要，我们应该为这两个项目收取18美元的费用。
但这是不正确的。 Google对前5个负载均衡器收取的最低服务费适用于每个项目。 因此，我们拥有一个完全独立的登台环境，并拥有自己的负载均衡器，这意味着我们需要支付两次费用； $ 36美元，而非我们原先的$ 18美元。
这使我们处于尴尬的境地。 我们真的很想将这两个环境完全分开，但是我们在开发/登台环境中的实例成本仅为7.70美元，因此支付两倍于价格的负载平衡是没有道理的（我们在抢占阶段使用抢占式实例）减少该环境的正常运行时间的成本）。 我们也不能只移动负载均衡器，因为Kubernetes入口路由将始终在同一项目中配置负载均衡器。
因此，为了降低成本，我们需要重新布置模型：
由于明显的原因，这并不理想。 现在，我们的开发集群与生产位于同一个项目中，但是除非Google更改围绕负载均衡器的定价模型，否则必须这样做。
摘要
目前，我们正在生产中运行10种前端微服务，随着我们扩展Hive提供的服务，还有更多的计划。 通过采取上述步骤，我们成功地将Google Cloud上的负载平衡成本降低了83％，从目前每月需要支付的108美元降至18美元。
综上所述，在Google Cloud上使用Kubernetes设置微服务时，请记住以下几点：
- 使用单个入口配置，避免使用
--load-balancer-ip。 - 使用具有多个域的SSL证书来解决没有SNI的限制。 Kube Lego是一个很好的工具，可以帮助您完成此任务，并且还可以自动为您管理证书更新。
- 将您的计算资源组合到一个项目中，以避免多次向负载均衡器收取最低服务费。
June Rhodes是Redpoint Games的技术总监。 她目前正在努力开发Hive，以支持Mayhem of Mayhem的发展。 您可以在 Twitter 和 Facebook 上关注Redpoint Games， 以获取将来的更新。
