​让游戏云原生化别再「左右为难」

原创
01/26 11:57
阅读数 216

作者:云原生游戏社区

当下,游戏行业正在经历云原生架构转型期,不少游戏厂商纷纷投入游戏服容器化改造。在此现象的背后,是云原生技术带来的先进生产力推动着行业向前发展:容器化提升了游戏交付的效率;声明一致性带来游戏开服效率、更新效率、以及可用性的提升;弹性伸缩使得资源可自动化地应对游戏高峰期与波谷期,在保证游戏服务质量的同时提高资源利用率。

2024 年 1 月 18 日,OpenKruiseGame (OKG) 社区与 KubeSphere 联合举办了议题为「用 OKG Dashboard 解锁云原生游戏运维之道」的技术直播。本文将与大家一起回顾分享内容。

OpenKruiseGame:游戏云原生化的理想路径

尽管云原生带来了众多优势,但作为容器编排管理事实标准的 Kubernetes,其原生工作负载并不能很好地支持游戏场景,因此 OpenKruiseGame 在此背景下诞生。

1)OpenKruiseGame 是 CNCF 顶级开源云原生负载 OpenKruise 在游戏领域下的最佳实践抽象,项目由多家一线游戏公司共同贡献维护;

2)内置多云/混合云场景的适配,推出了 Cloud Provider 的模型,便于开发者在多种不同云环境下实现游戏的一致性交付;

3)可以通过无侵入式的声明方式与云上能力,例如:透明无损网络、极致秒级弹性、低成本资源供给、全生命周期可观测性等能力无感打通;

4)将游戏场景下的版本热更新、网络 IP 端口固定、区服管理、自动伸缩等通用能力进行抽象,并通过语义化的配置进行透出,降低学习和二次开发的成本;

5)覆盖 PVP/PVE/H5类/MMORPG 等多种常见的游戏类型的差异化容器需求,白屏化支持复杂游戏架构的游戏服编排能力。

下面来介绍不同类型的游戏如何通过 OpenKruiseGame 完成云原生改造。

PvP 游戏最佳实践

会话类(session based)游戏,是指在有限的时间内,将玩家汇聚到特定游戏场景下的游戏类型。在通常意义下,会话等同对局,一局结束后,玩家间的游戏关系也在此结束,该会话也同时结束。因此,在业界也会将会话类游戏通俗的理解为“开房间游戏”,一个房间承载了对应的游戏会话。这类游戏往往存在着以下特点:

1)游戏时间非连续,存在明显的起停时间节点。

2)会话中至少存在 2 个及以上的玩家,相互战斗、交互。

3)常见于 MOBA、FPS 类游戏,对时延要求较高。

4)业务波峰与波谷时,对局数量差距明显。因此,一个理想的 PvP 游戏的云原生架构应具有以下能力:

  • 提供网络直连功能,为每个房间提供独立的公网访问地址,玩家客户端可直接访问。
  • 提供游戏匹配功能,为玩家找到合适的队友与对手组成会话对局,并为其分配合适的游戏房间。
  • 提供状态管理功能,自动化管理游戏房间的业务状态与生命周期。
  • 提供弹性伸缩功能,根据业务波峰与波谷自动申请和释放基础设施资源,控制成本。
  • 可高效地进行游戏交付及运维管理,自动化水平高。

有关 PvP 游戏最佳实践阅读 OpenKruiseGame 官方文档:

https://openkruise.io/zh/kruisegame/best-practices/session-based-game

PvE 游戏最佳实践

与 PvP 会话类游戏不同,PvE 游戏的特点如下:

  • 单个区服运行时间较长,应尽量避免停服操作,利于玩家游戏体验。
  • 开服时(或)存在配置差异。
  • 单区服容器中(或)存在多进程,区服服务质量需由用户定义。
  • 随着时间推移,各区服状态存在差异,需定向管理,如更改资源规格、镜像版本、定向合服等。

该类游戏在落地 Kubernetes 通常遇到左右为难的困境:

若使用 Kubernetes 原生 workload,则无法进行游戏服精细化管理,具体地:

    • 若使用 Deployment 管理:
    • 生成的 pod 没有类似序号的状态标识,导致:1)无法基于序号进行有状态的服务发现了;2)无法区别游戏服之间状态差异性;3)异常重启时状态丢失,配置/存储等无法自动重定向。
    • 若使用 StatefulSet 管理:
    • 生成的 pod 虽然有序号作为状态标识,但是:1)只能从序号大到小进行更新或删除,无法定向管理游戏服;2)无法感知游戏服之间的状态差异特性。

若不使用 Kubernetes 原生 workload,则无法利用上 K8s 的编排能力:

    • 若使用脚本程序批量开服:
    • 属于面向过程的方式,参数无法落盘,出错率高。
    • 若使用 gitops 管理:
    • 区服数量较多时需要维护大量有着相同字段的 yaml 文件,有时甚至超过文件长度限制;批量发布时也十分复杂。
    • 若通过自建 PaaS 平台管理:
    • 需要引入大量开发工作,且与业务属性耦合较重,导致后续迭代复杂

有关 PvE 游戏最佳实践阅读 OpenKruiseGame 官方文档:

https://openkruise.io/zh/kruisegame/best-practices/pve-game

云原生游戏交付与运维管理最佳实践

对于游戏应用来说,一个云原生的交付流程应该如此:

游戏开发者提交业务代码至代码仓库,自动触发 CI 流程打包容器镜像,通过 ArgoCD 自动化部署至测试环境中。游戏开发者可以快速测试业务逻辑是否符合预期,无需运维同事介入,保证与生产环境一致性的同时也提高了研发效率。 而在正式/灰度的环境下,运维工程师维护游戏应用部署仓库,提交编排的游戏服 Yaml,即可完成游戏服开服、更新等动作。部署后,可通过 KubeSphere OKG Dashboard 来可视化观察集群中所有游戏服的状态,并针对性地进行运维管理。

游戏应用交付与运维管理最佳实践

KubeSphere OKG Dashboard 是 OpenKruiseGame 基于 KubeSphere 4.0 LuBan 架构提供了游戏服白屏化管理控制台,支持用户基于 KubeSphere 可视化地管理 OpenKruiseGame 涉及的对象,如 GameServerSet 与 GameServer。

当前通过 OKG Dashboard 可以查看当前集群中游戏服整体统计数据、所有游戏服部署集与游戏服的运行情况。此外,还可以定向对游戏服进行更改运维状态等操作。

查看当前集群中游戏服整体统计数据

查看所有游戏服部署集的运行情况

查看所有游戏服的运行情况

参考资料:

[1] OpenKruiseGame 的官方文档

https://openkruise.io/zh/kruisegame/introduction

[2] OpenKruiseGame GitHub 仓库

https://github.com/openkruise/kruise-game

[3] OKG Dashboard

https://kubesphere.com.cn/marketplace/extensions/kruise-game-dashboard/

对于云原生游戏感兴趣的同学可以加入云原生游戏交流群。(钉钉群号:44862615

点击此处,访问 OpenKruiseGame 仓库。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部