使用 OpenKruiseGame 与 AWS Global Accelerator 接入全球游戏玩家
内容提要
本文介绍如何利用 AWS Global Accelerator 的 Custom Routing 为全球玩家提供统一入口，将流量定向到匹配系统指定的游戏服 Pod。OpenKruiseGame 插件将入口放行、地址查询与回收接入 GameServer 生命周期，入口信息写入 networkStatus 供匹配系统消费。同后端对照测试显示，AGA 路径时延中位数比 NLB 低约 38.5 毫秒。
延伸解读
为什么房间型游戏需要 Custom Routing
Standard Routing 会在健康 endpoint 之间选择目标，适合客户端可连接任意副本的服务；但房间型游戏要求同一局玩家进入匹配系统选定的那台游戏服。Custom Routing 将入口端口确定性地映射到 VPC 子网内的目的 IP 和端口，不执行目的地健康检查，也不自动替换目标，因此匹配系统必须自行保证目标可用。
OKG 简化的是平台集成，不是数据面
自建方案需要独立网络控制器跟踪 Pod 创建删除、维护 AGA 放行状态、查询映射并登记地址。OKG 插件保留相同的 AWS 调用，但把 Allow/Deny、映射查询和入口发布收进 GameServer 生命周期，结果写入 status.networkStatus。匹配系统直接读取该状态，无需另建网络控制器和地址库。
接入前必须确认的容量与权限
插件使用预先创建的 AGA 资源，不创建 accelerator、listener 或 endpoint group。扩容前需检查 endpoint group 目的端口和 listener 入口端口范围能否容纳子网映射，增加 Pod 副本不会自动扩大 AGA 端口范围。安全组需允许游戏端口接收真实玩家来源流量，因为 Custom Routing 保留客户端源 IP。IAM 需通过 EKS Pod Identity 或 IRSA 授予 Allow、Deny 和映射查询权限。
消费入口时注意 Ready 的含义与更新方式
networkStatus 的 currentNetworkState 为 Ready 仅表示网络地址准备完成，不表示游戏进程已就绪，匹配系统仍需结合游戏服和房间状态决定是否下发入口。Pod 被替换后应重新获取匹配系统发布的地址，而不是继续使用旧映射。若由游戏进程或 sidecar 读取地址，应使用 Downward API 目录挂载而非 subPath，并等待 Ready 且 externalAddresses 非空再登记。
Q&A
房间型游戏接入全球玩家时，为什么需要 AGA Custom Routing 而不是 Standard Routing？
Standard Routing 在健康 endpoint 之间选择目标，适合客户端可以连接任意健康副本的服务；而 Custom Routing 将入口端口确定性地映射到 VPC 子网内的目的 IP 和端口，适合匹配系统已经选定具体游戏服的房间型游戏。它不执行目的地健康检查，也不自动替换目标，能确保同一局玩家进入匹配系统选定的那台游戏服。
OKG 插件如何把 AGA Custom Routing 的入口接入 GameServer 生命周期？
OKG 插件保留相同的 AWS 调用，但把控制面工作收进 GameServer 生命周期。平台通过 GameServerSet 声明网络配置，插件维护 Allow/Deny、查询映射，并将入口写入 GameServer.status.networkStatus。匹配系统直接读取这份状态，不再为这条接入路径另外实现网络控制器和地址登记逻辑。
使用 OKG 的 AGA Custom Routing 插件前需要准备哪些前置资源？
需要准备：预先创建的 AGA 资源（Custom Routing accelerator、listener、endpoint group，以及注册到该组的 VPC 子网），集群采用 VPC-CNI 使游戏 Pod 获得子网内 VPC IP；检查端口容量，确保 endpoint group 的目的端口和协议与游戏进程一致，listener 入口端口范围能容纳子网映射；安全组允许游戏端口接收真实玩家来源流量；通过 EKS Pod Identity 或 IRSA 向 OKG controller ServiceAccount 授予 Allow、Deny 和映射查询权限。
匹配系统如何从 GameServer 状态中获取游戏服入口地址？
当 Pod 获得 VPC IP 后，插件放行目的地址并查询映射。入口准备完成时，GameServer.status.networkStatus 的 currentNetworkState 为 Ready，externalAddresses 包含两个 anycast IP 和映射端口。匹配系统在网络 Ready 且房间可以接纳玩家时，将两个外部入口交给客户端。客户端先连接一个入口；如果该路径不可用而目标 Pod 仍在，可以改连另一个入口。Pod 被替换后，应重新获取匹配系统发布的地址。
游戏进程如何主动读取自己的网络入口地址？
如果由游戏进程或 sidecar 主动向匹配系统登记，可以用 Downward API 卷读取 Pod annotation game.kruise.io/network-status。将卷和挂载加入 gameServerTemplate.spec，挂载路径为 /etc/podinfo/network-status，内容是 JSON，字段与 GameServer 状态一致。进程启动时入口可能还未准备完成，应等待 currentNetworkState 为 Ready 且 externalAddresses 非空，再登记地址；持续运行时重新读取状态变化并更新登记。注意使用目录挂载，不使用 subPath。
AGA Custom Routing 与 NLB 相比，时延改善效果如何？
同后端对照测试显示，使用固定的 25 个 Globalping 探针做四轮 HTTP 对照，汇总配对差的中位数为 −38.5 ms，即 AGA 路径的 HTTP total 比 NLB 路径低 38.5 ms，95% 区间为 −56.75 到 −11 ms。测试范围为单 Region、单 AZ、单 Pod 的明文 HTTP，无并发负载；结果说明本次对照中的时延改善，不代表所有玩家或游戏协议都有相同收益。
