How to Enable Direct Player Connections to Game Servers with Cloud‑Native Solutions

Introduction

The second part of the "Cloud Gaming" practical series introduces the architecture and cloud‑native solution for direct player connections to game servers, following the first article on cloud‑native deployment of session‑based games.

Scenario Analysis

In session‑based games, each match creates a new room, and players must connect to a specific game‑server pod rather than a randomly load‑balanced instance. Therefore, each pod needs a fixed external address that can be exposed to players.

Public services such as login or store can be load‑balanced, but room‑based game servers require direct, non‑balanced access. After a game server pod is created, a unique address must be allocated and reported to other services.

Volcengine Cloud‑Native Solution

The solution uses Volcengine Container Service (VKE) with Elastic Container Instances (VCI) and combines OKG, CLB, EIP, and API Gateway to allocate specific access addresses for each game server and expose them to players.

Cloud‑Native Technology Stack

Container Service VKE: https://www.volcengine.com/product/vke

Elastic Container Instance VCI: https://www.volcengine.com/docs/6460/76908

Load Balancer CLB: https://www.volcengine.com/product/clb

Public IP EIP: https://www.volcengine.com/product/eip

API Gateway APIG: https://www.volcengine.com/docs/6569/

4‑Layer Direct Connection

Based on CLB

Each game‑server pod shares a CLB but receives a distinct port, allowing players to reach a specific pod via the CLB’s port. OKG’s GameServerSet uses a Volcengine‑CLB network plugin to assign non‑conflicting ports to each replica, preserving the address even after pod recreation.

GameServerSet writes the assigned address to the pod annotation

game.kruise.io/network-status

, which can be mounted inside the pod for the game server to read.

<code>apiVersion: v1
kind: Pod
metadata:
  annotations:
    game.kruise.io/network-status: '{"internalAddresses":[{"ip":"192.168.0.64","ports":[{"name":"80","protocol":"TCP","port":80}]}],"externalAddresses":[{"ip":"101.xxx.xxx.xxx","ports":[{"name":"80","protocol":"TCP","port":677}]}],"currentNetworkState":"Ready"}'
    game.kruise.io/network-type: Volcengine-CLB
</code>

Based on EIP

VKE’s

vpc‑cni‑controlplane

component can bind an Elastic IP to each pod. Adding the following annotations to a deployment triggers automatic EIP creation and binding:

<code>vke.volcengine.com/primary-eip-allocate: '{"type": "Elastic"}'
vke.volcengine.com/primary-eip-attributes: '{"name":"eip-demo","description":"demo for pods eip","isp":"BGP","billingType":3,"projectName":"default","bandwidth":200}'
</code>

The controller watches pod creation, creates the EIP, binds it, and writes the EIP information back to the pod annotation

vke.volcengine.com/allocated-eips

, which can be mounted for the game server to discover its external address.

<code>vke.volcengine.com/allocated-eips: '[{"EipId":"eip-13fx60maj7jls3n6nu52f2znx","EipAddress":"1xx.xxx.xx.xx","EniId":"eni-13fdawbnw97gg3n6nu3y2dnfm","EniIp":"1xx.xxx.x.xx"}]'
</code>

7‑Layer Direct Connection

For web‑based games, a Layer‑7 load balancer is needed. Volcengine API Gateway (APIG) can map a specific pod’s name or label to a backend entry. By adding an

x‑target‑pod‑name

header with the pod name, the request is routed to that pod; without the header, traffic is load‑balanced.

APIG also supports label‑based routing, allowing requests to be directed to any pod within a labeled group.

Conclusion

The article presented cloud‑native approaches for solving the direct‑connection problem of game servers, offering both Layer‑4 (CLB/EIP) and Layer‑7 (API Gateway) solutions that require no changes to game server code and are non‑intrusive. All components are available in VKE’s marketplace for one‑click installation, helping game companies adopt cloud‑native practices for agility and cost efficiency.