OpenKruiseGame exists because a game server pod is not a stateless pod

The problem is the pod lifecycle, not the workload type

OpenKruiseGame, OKG, is a multicloud-oriented open source Kubernetes workload specialised for game servers, and it is a sub-project of the OpenKruise workload project of the Cloud Native Computing Foundation in the gaming field.

The reason it exists is stated as a list of things that go wrong when a game server runs as an ordinary Kubernetes pod.

Hot update or hot reload is the first. Many game servers are updated by hot update or hot reload, but for various workloads of Kubernetes the lifecycle of pods is consistent with that of images: when an image is published, pods are recreated. When pods are recreated, issues may occur such as interruptions to player battles and changes in the network metadata of player servers. So the mismatch is that the workload's update mechanism is the wrong granularity for the business operation.

The second is operations on specified game servers. Game servers are stateful in most scenarios. When a player versus player game is updated or goes offline, only game servers without online active players can be changed, and when game servers for a player versus environment game are suspended or merged, you perform operations on game servers with specific IDs.

The third is network models. The network models in Kubernetes are implemented by declaring Services, and in most cases they are applicable to stateless scenarios. For network-sensitive game servers, a solution with high-performance gateways, fixed IP addresses and ports, or lossless direct connections is more suitable for actual business scenarios.

The fourth is orchestration. The architecture of game servers has become increasingly complex, since the player servers for many MMORPGs are combinations of game servers with different features and purposes: a gateway server responsible for network access, a central server for running the game engine, and a policy server responsible for game scripts and gameplay. Different game servers have different capacities and management policies, so it is difficult to describe and quickly deliver all the game servers by using a single workload type.

Each of those four is a different kind of impedance mismatch, and the workload is the abstraction that removes them.

The core features map directly onto the four problems

The feature list is short and each entry answers one of the problems above, which is a good sign about the design.

Hot update based on images and hot reload of configurations is the answer to the update granularity problem. Update, deletion and isolation of specified game servers is the answer to the stateful operations problem, and it is the most distinctive entry on the list, because updating a single instance of a replicated workload is not something the built-in workloads offer.

Multiple built-in network models is the answer to the networking problem, and the list is specific: fixed IP address and port, lossless direct connection, and global acceleration. A fixed IP per game server matters when the game protocol has the address baked into its session state, which is common in games that hand a connection to a client and then route by address rather than by a service discovery name.

Then there is auto scaling, automated operations for service quality, independence of cloud service providers, and complex game server orchestration.

The independence of cloud service providers claim is worth taking seriously as a design goal rather than a marketing line. The dependency list in the manifest shows the AWS and Alibaba cloud SDKs present, and the cloudprovider/ directory at the repository root is where that integration lives. The claim that the project makes is that it is independent of the provider, and the presence of a provider abstraction is what makes that possible, though the reality is that each provider integration is a separate body of work and coverage will differ.

The workload is also designed to be extended rather than only used. It is a fully open source project that allows developers to customise workloads and build release and operations platforms for game servers, and it can use Kubernetes templates or call APIs to use or extend features. It can also connect to delivery systems such as KubeVela to implement orchestration and full lifecycle management of game servers on a graphical interface.

The controller stack is controller-runtime with OpenKruise APIs

The dependency list describes the implementation accurately, and it is a modern one.

The module is `github.com/openkruise/kruise-game` and it requires Go 1.23.0 with the toolchain pinned at go1.23.4. The controller framework is `sigs.k8s.io/controller-runtime` at 0.19.0, with `k8s.io/api`, `apimachinery` and `client-go` at 0.31.0, which is the Kubernetes 1.31 line. `sigs.k8s.io/code-generator` at the same version is how the CRD types and the client code are generated.

The most important dependency for understanding the design is `github.com/openkruise/kruise-api` at 1.8.0, which is the shared API package of the parent OpenKruise project. OpenKruiseGame is not a standalone controller, it builds on the workload abstractions that OpenKruise already provides, which is the point of being a sub-project rather than a fork.

Observability is handled with the OpenTelemetry stack rather than with a homegrown one: the SDK at 1.38.0, the OTLP gRPC exporters for traces and for logs, and the otelzap bridge to connect the OpenTelemetry logging to the Zap logger. `prometheus/client_golang` at 1.19.1 provides the metrics, and `go.uber.org/zap` at 1.27.0 is the logger itself, with `go-logr/logr` and `go-logr/zapr` bridging it to the Kubernetes logging interface.

The API definitions live in `apis/`, and there is a `proto/` directory for the protobuf definitions used by the game server protocol handling, plus `pkg/` for the implementation, `config/` for the deployment manifests and CRDs, and `hack/` for the helper scripts the Makefile calls.

Testing uses both frameworks, with `onsi/ginkgo` and `onsi/gomega` alongside `stretchr/testify`, and the Makefile references envtest with kubebuilder assets at Kubernetes 1.30.0, which is how a controller is tested against a real API server rather than a mock.

Building the manager image is a two stage Go build

The Dockerfile is the standard controller pattern, and the detail worth noting is the base image choice.

The builder stage is `golang:1.23.4`, matching the toolchain directive in go.mod, and the dependency manifests are copied first so that `go mod download` is cached separately from the source.

FROM golang:1.23.4 AS builder
ARG LDFLAGS=" -s -w"

WORKDIR /workspace
COPY go.mod go.mod
COPY go.sum go.sum
RUN go mod download

COPY main.go main.go
COPY apis/ apis/
COPY pkg/ pkg/
COPY cloudprovider/ cloudprovider/

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -ldflags "${LDFLAGS}" -o manager main.go

`CGO_ENABLED=0` produces a static binary, which is what lets the runtime stage be minimal. The final image is `alpine:3.20` with the manager binary copied in and the entrypoint set to it. The comment in the Dockerfile says distroless is used as minimal base images, but the actual FROM line is alpine:3.20, which is a small discrepancy between the comment and the code.

The `COPY` list also tells you what goes into the binary: `main.go`, the `apis/`, `pkg/` and `cloudprovider/` directories. The cloud provider directory is compiled in rather than being a plugin loaded at runtime, which means a build for a different provider set is a different binary.

The Makefile computes the version from git through a helper script, `hack/compute-version.sh`, falling back to `git describe --tags --dirty --always` and then to a plain `dev`, and injects it with `-X github.com/openkruise/kruise-game/pkg/version.Version`. The default image name is `kruise-game-manager:test`.

The Makefile itself is the kubebuilder style, with a help target that parses the `##@` and `##` comments to produce grouped help output, and it sets the shell to bash with pipefail, which the comment explains is required for the setup-envtest script in the test target.

Who uses it, and the state of the project

The README lists the users of OpenKruiseGame with a row of company logos, and it is a notable list: Lilith, Hypergryph, Bilibili, Shangyou, Xingzhe, JJWorld, Juren, Baibian, Chillyroom, Wuduan, Xingchao and Jaco among them.

That is a real signal about who this is for. These are game studios, which fits the workload's intended audience. It also tells you something about the deployment environment, which is mostly public cloud with a mix of providers.

The topic list adds multiplayer and game-server to the Kubernetes and Go topics, and the `okg` tag, which is the abbreviation used inside the project.

The release history shows the project crossing into 1.0 and then continuing. v1.1.0 came on 2026-06-25, v1.0.0 on 2025-07-21 and v0.10.0 on 2025-01-08. The last push to the repository was on 2026-07-24 and the repository is not archived.

The licence is Apache-2.0, which is the right choice for a CNCF-adjacent infrastructure project that vendors want to embed and modify.

There is also a Chinese version of the documentation at `docs/中文/说明文档.md`, with the English README as the primary document, and the project has an `OWNERS` file, a `CODE_OF_CONDUCT.md` adopting the Contributor Covenant v2.0, a `CHANGELOG.md`, a `PROJECT` file and a `.license/` directory.

The honest summary is that this is an infrastructure project with a narrow, well understood purpose, aimed at a specific kind of operator, and the gap between a studio running a handful of game servers and a studio running thousands is exactly the gap the workload closes.

Editorial conclusion

Adopt OpenKruiseGame if you run game servers on Kubernetes and the pod lifecycle is fighting you, specifically because you cannot restart a pod mid-match or you need a stable IP per game server. Do not adopt it as a general workload, since it exists to work around properties that only game servers have, and it introduces its own controller with its own API to learn. Verify first that the game server types you operate fit the workload model, that the network model you need is one of the built-in ones, and that the cloud provider integration covers the regions you deploy into, since the cloud provider layer is where the multicloud claim is either true or not.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openkruise/kruise-game on GitHub
3. Project website
4. README
5. Releases