使用 OpenKruiseGame 与 AWS Global Accelerator 接入全球游戏玩家

摘要：房间型游戏的网络接入，需要同时解决两件事：让不同地区的玩家稳定地连接游戏服，以及让同一局玩家进入匹配系统选定的那台游戏服。AWS Global Accelerator（AGA）提供全球网络入口，Custom Routing 提供到指定后端的端口映射；OpenKruiseGame（OKG）则把入口的配置和回收接入游戏服生命周期。本文介绍这套方案的选型、配置和地址消费方式，并通过功能验证与同后端时延对照说明接入效果。

01一、引言

02二、全球接入与定向路由

03三、OKG 接管的网络工作

04四、接入配置

05五、消费游戏服入口

06六、验证结果

07七、总结

08八、参考资料

一、引言

房间型游戏的网络接入，需要同时解决两件事：让不同地区的玩家稳定地连接游戏服，以及让同一局玩家进入匹配系统选定的那台游戏服。AWS Global Accelerator（AGA）提供全球网络入口，Custom Routing 提供到指定后端的端口映射；OpenKruiseGame（OKG）则把入口的配置和回收接入游戏服生命周期。

本文介绍这套方案的选型、配置和地址消费方式，并通过功能验证与同后端时延对照说明接入效果。OKG 是 OpenKruise 生态中的 Kubernetes 游戏服编排项目，使用 GameServerSet 管理一组游戏服，使用 GameServer 表示单个实例。

二、全球接入与定向路由

多人实时游戏对时延、抖动和丢包都很敏感。玩家跨地区连接同一个游戏集群时，公网路径会经过不同运营商和互联节点，绕路或链路拥塞可能影响对局体验。即使游戏服本身正常，不同地区玩家的连接质量也可能相差很大。

AGA 为加速器分配两个静态 anycast IPv4 地址。玩家连接其中一个地址，流量从就近的 AWS 边缘节点进入，长途段通过 AWS 全球网络到达部署游戏服的区域。这提供了统一的全球入口，但把流量送到哪个游戏服，还取决于路由模式：

Standard Routing：在健康 endpoint 之间选择目标，支持 NLB、ALB、EC2 实例和 Elastic IP，适合客户端可以连接任意健康副本的服务。
Custom Routing：将入口端口确定性地映射到 VPC 子网内的目的 IP 和端口，适合匹配系统已经选定具体游戏服的房间型游戏。它不执行目的地健康检查，也不自动替换目标。

例如，匹配系统为四名玩家分配了同一个 Pod，地址为 10.0.11.23，游戏进程监听 7777。Custom Routing 为这个目的地址提供两个入口：192.0.2.10:50001 和 192.0.2.11:50001。玩家可以从不同入口接入，但最终都到达同一个 Pod 的 7777 端口，客户端切换入口不会迁移房间。

[图 1：Custom Routing：两个全球入口映射到同一个游戏 Pod]

图中的 IP 为示例地址。50001 是客户端使用的映射端口，7777 是 Pod 内的游戏端口。端口映射在子网注册时预先生成；映射存在后，还需要通过 AllowCustomRoutingTraffic 放行对应的目的地址，客户端才能访问。Pod 回收时则通过 DenyCustomRoutingTraffic 关闭访问。

三、OKG 接管的网络工作

如果平台自行集成 Custom Routing，需要跟踪 Pod 的创建和删除，维护 AGA 放行状态，查询映射，并把入口登记到匹配系统。游戏服规模扩大后，这些工作通常需要一套独立的网络控制器和地址状态管理。

[图 2：自建方案：平台维护网络控制器与地址登记]

网络控制器发现 Pod 已获得 VPC IP，放行游戏端口。
控制器查询映射，将两个外部入口写入平台地址库。
匹配系统读取入口并下发给玩家；Pod 删除时，控制器再关闭旧目标的访问。

OKG 插件保留相同的 AWS 调用，但把这部分控制面工作收进 GameServer 生命周期。平台通过 GameServerSet 声明网络配置，插件维护 Allow/Deny、查询映射，并将入口写入 GameServer.status.networkStatus。匹配系统直接读取这份状态，不再为这条接入路径另外实现网络控制器和地址登记逻辑。

[图 3：OKG 方案：插件维护网络入口，匹配系统消费 GameServer 状态]

简化的是平台集成，而不是数据面的跳数。两种方案都使用 AGA Custom Routing；OKG 将”跟踪 Pod → 维护放行 → 查询地址 → 发布状态”合并为声明式网络能力。匹配系统仍负责房间分配和地址下发，客户端仍负责连接与重连。

四、接入配置

4.1 前置资源

插件使用预先创建的 AGA 资源，不创建 accelerator、listener 或 endpoint group。接入前需要准备：

网络资源：Custom Routing accelerator、listener、endpoint group，以及注册到该组的 VPC 子网。集群采用 VPC-CNI，使游戏 Pod 获得这些子网内的 VPC IP。
端口容量：endpoint group 的目的端口和协议与游戏进程一致，listener 的入口端口范围能够容纳子网映射。扩容前检查容量；增加 Pod 副本不会自动扩大 AGA 端口范围。
安全组：允许游戏端口接收真实玩家来源的流量。Custom Routing 保留客户端源 IP，不能只把某个 AGA 地址作为入站来源。
IAM：通过 EKS Pod Identity 或 IRSA 向 OKG controller ServiceAccount 授予 Allow、Deny 和映射查询权限。

AGA 资源和映射容量长期存在；单个 Pod 的放行状态与网络地址随实例创建、变化和回收维护。这样，扩缩容不需要为每台游戏服重新创建加速器。

4.2 GameServerSet

在 GameServerSet 中指定网络类型和预置资源。下面以 UDP 游戏端口 7777、三个可用区子网为例，名字、ARN 和镜像均为示例：

apiVersion: game.kruise.io/v1alpha1
kind: GameServerSet
metadata:
  name: battle
spec:
  replicas: 3
  network:
    networkType: AmazonWebServices-GlobalAcceleratorCustomRouting
    networkConf:
    - name: CustomRoutingEndpointGroupArn
      value: "arn:aws:globalaccelerator::123456789012:accelerator/
        aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/listener/ffffffff/
        endpoint-group/000000000000"
    - name: GamePort
      value: "7777"  # Pod 内游戏端口，不是客户端使用的映射端口
    - name: Protocol
      value: "UDP"   # TCP、UDP 或同端口 TCPUDP
    - name: EndpointIds
      value: "subnet-aaa=10.0.11.0/24,subnet-bbb=10.0.12.0/24,
        subnet-ccc=10.0.13.0/24"
  gameServerTemplate:
    spec:
      containers:
      - name: game
        image: example/game-server:1.0
        ports:
        - name: game
          containerPort: 7777
          protocol: UDP

EndpointIds 将已注册的子网与 CIDR 对应起来，插件按 Pod IP 选择子网。只使用一个子网时，改用 EndpointId，值为 subnet-aaa，两项不能同时配置。

如果游戏在同一个端口上同时使用 TCP 和 UDP，将 Protocol 设置为 TCPUDP，并提前在 endpoint group 配置两种协议。插件发布的状态会分别列出 game-tcp 和 game-udp，它们共用对应的映射端口。

该插件已通过 PR #366 合入 upstream master；截止到发稿，v1.1.0 发布包尚不包含该 PR。部署时需要从源代码自行构建镜像。

五、消费游戏服入口

5.1 匹配系统读取状态

Pod 获得 VPC IP 后，插件放行目的地址并查询映射。入口准备完成时，GameServer.status.networkStatus 的 currentNetworkState 为 Ready，externalAddresses 包含两个 anycast IP 和映射端口：

networkStatus:
  currentNetworkState: Ready
  externalAddresses:
  - ip: 192.0.2.10
    ports:
    - name: game
      port: 50001
      protocol: UDP
  - ip: 192.0.2.11
    ports:
    - name: game
      port: 50001
      protocol: UDP
  internalAddresses:
  - ip: 10.0.11.23
    ports:
    - name: game
      port: 7777
      protocol: UDP

匹配系统在网络 Ready 且房间可以接纳玩家时，将两个外部入口交给客户端。客户端先连接一个入口；如果该路径不可用而目标 Pod 仍在，可以改连另一个入口。Pod 被替换后，应重新获取匹配系统发布的地址，而不是继续使用旧映射。

这里的 Ready 表示网络地址准备完成，不表示游戏进程已经就绪。匹配系统仍需要结合游戏服和房间状态决定是否下发入口。

5.2 游戏进程读取地址

如果由游戏进程或 sidecar 主动向匹配系统登记，可以用 Downward API 卷读取 Pod annotation game.kruise.io/network-status。将下面的卷和挂载加入 gameServerTemplate.spec：

containers:
- name: game
  # 合并到已有 game 容器配置中
  volumeMounts:
  - name: podinfo
    mountPath: /etc/podinfo
    readOnly: true
volumes:
- name: podinfo
  downwardAPI:
    items:
    - path: network-status
      fieldRef:
        fieldPath: metadata.annotations['game.kruise.io/network-status']

/etc/podinfo/network-status 的内容是 JSON，字段与上方状态一致。进程启动时入口可能还未准备完成，因此应等待 currentNetworkState 为 Ready 且 externalAddresses 非空，再登记地址；持续运行时重新读取状态变化并更新登记。

这里使用目录挂载，不使用 subPath。annotation 更新后，kubelet 会将变化同步到卷文件；环境变量只在容器启动时注入一次，subPath 挂载的文件也不会跟随更新。已经由匹配系统直接监视 GameServer 的平台，则不需要这一步。

六、验证结果

我们对同一个 Pod 建立了两个入口，让 AGA Custom Routing 与 regional NLB 指向同一个 Pod，使用固定的 25 个 Globalping 探针做四轮 HTTP 对照。汇总配对差的中位数为 −38.5 ms，即 AGA 路径的 HTTP total 比 NLB 路径低 38.5 ms，95% 区间为 −56.75 到 −11 ms。

[图 4：同探针 HTTP total 配对差：负值表示 AGA 更快]

汇总值按每个探针的四轮差值先取平均，再取这 25 个结果的中位数。测试范围为单 Region、单 AZ、单 Pod 的明文 HTTP，无并发负载；结果说明本次对照中的时延改善，不代表所有玩家或游戏协议都有相同收益。

七、总结

AGA Custom Routing 把全球入口映射到匹配系统指定的游戏 Pod，OKG 则将这条入口的放行、地址发布和回收接入 GameServer 生命周期。平台预置网络资源、声明 GameServerSet 配置后，匹配系统就可以从统一的网络状态中获取入口，把精力留给房间分配和游戏体验。

➡️ 下一步行动：

相关产品：

Amazon VPC — 隔离云网络
Amazon EC2 — 安全且可调整大小的计算容量
Amazon EKS — 托管式 Kubernetes 服务
Amazon IAM — 身份管理和访问权限

相关文章：

八、参考资料

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客