OpenKruiseGame (OKG) is a Kubernetes workload for teams running multiplayer game servers on Kubernetes who need hot updates, per-server operations, and game-specific networking that built-in workloads do not provide.

What it is

OpenKruiseGame, often abbreviated OKG, is a multicloud-oriented, open source Kubernetes workload specialised for game server scenarios. It is a sub-project of OpenKruise, a workload project of the Cloud Native Computing Foundation, in the gaming field, and it is written in Go under the Apache-2.0 licence. Rather than replacing Kubernetes, it extends the platform with a custom workload designed specifically for game server scenarios, and it connects game servers to cloud service providers, matchmaking services, and O&M platforms while integrating logging, monitoring, network, storage, elasticity, and matching through low-code or zero-code techniques.

The concrete problem it addresses is that built-in Kubernetes workloads such as Deployment and StatefulSet tie a pod's lifecycle to its image, so publishing an image recreates pods and can interrupt player battles or change network metadata on player servers. Game servers are also stateful in most scenarios, so operations such as PVP updates and offline changes may only touch servers without online active players, and PVE suspension or merging may target servers with specific IDs. Standard Service-based networking suits stateless cases, while network-sensitive game servers need high-performance gateways, fixed IP addresses and ports, or lossless direct connections.

Key capabilities

• Hot update and in-place update of running game servers without recreating pods, keeping player sessions intact across an image release.
• Management of specified game servers by ID, so only servers without online active players are changed during a PVP update, and PVE servers with particular IDs are targeted during suspension or merging.
• Network models suited to game traffic, including high-performance gateways, fixed IP addresses and ports, and lossless direct connections rather than plain Service declaration.
• Game server orchestration that composes gateway servers and other specialised servers into the complex topologies used by MMORPG player servers.
• Automatic integration of logging, monitoring, network, storage, elasticity, and matching through low-code or zero-code technologies during cloud-native transformation.
• Centralised management of clusters across multiple clouds and hybrid clouds using the consistent delivery standard of Kubernetes.
• Extension through Kubernetes templates or API calls, custom workload development, and connection to delivery systems such as KubeVela for GUI-based orchestration and full lifecycle management.

Who uses it and how

• Game server teams migrating existing game servers onto Kubernetes who must preserve player sessions through hot updates and hot reloads rather than pod restarts.
• O&M teams performing targeted operations on stateful servers, updating only servers without active players during PVP releases and operating on specific IDs during PVE suspension or server merges.
• Operators running across multiple clouds and hybrid clouds who want one consistent Kubernetes delivery standard for clusters in different environments.
• Teams integrating game servers with matchmaking, cloud service providers, and O&M platforms, or building custom release and O&M platforms on top of the workload.
• Organisations that want a GUI-driven workflow by connecting OKG to delivery systems such as KubeVela for lifecycle management.

Getting started

The project documentation lives at https://openkruise.io/kruisegame/introduction, and the repository provides installation instructions for deploying OpenKruiseGame onto a Kubernetes cluster, after which workloads are defined through Kubernetes templates or API calls.

How it compares

OpenKruiseGame sits alongside the built-in Kubernetes workloads it extends — Deployment and StatefulSet — rather than substituting for them, since it adds game-specific behaviour such as hot update, in-place update, and per-server operations that those workloads do not offer. Among the tools named in these facts, KubeVela is a complementary delivery system OKG connects to for GUI-based orchestration, not a competing workload. No comparable standalone alternatives are named in the project materials.

When to use it — and when not

You should pick it when game servers need pod-lifecycle-independent updates, targeted operations on named servers, or game-shaped networking on Kubernetes; teams whose workloads are stateless, or who are satisfied with plain Deployment and Service behaviour, gain little from it. It is a Kubernetes custom workload, so a self-hoster or operator must run a Kubernetes cluster with CRDs installed and take responsibility for the surrounding integrations — logging, monitoring, storage, elasticity, and matching are described as integrated rather than bundled. The README also notes that game server architectures grow complex, so the operational surface extends beyond the workload itself, and there are 47 open issues to weigh against adoption.