Deploy Consistent Global Game Servers with ACK One, Kubernetes, and GitOps

Background and Challenge

In today’s globally integrated economy, the digital entertainment industry is expanding rapidly, and many game publishers are launching games worldwide using a single‑server architecture that serves players across regions. While this model increases market reach, it also introduces technical challenges such as low‑latency requirements, heterogeneous infrastructure, and the need for consistent deployment across multiple data‑center locations.

Deployment Architecture Overview

The example deploys game servers in three regions—Shanghai, Tokyo, and Frankfurt—using independent Kubernetes clusters for each region. By leveraging cloud‑native declarative APIs, the underlying resource differences are abstracted away, allowing operations engineers to focus on the application itself.

Choosing the Platform

Alibaba Cloud Distributed Cloud Container Platform (ACK One) is used to manage multi‑region Kubernetes clusters. ACK One can register any on‑premise or public‑cloud cluster, providing a unified control plane for application, traffic, security, storage, and observability management.

Cluster Registration and Fleet Creation

Create a registered cluster in ACK One and obtain the agent.yaml configuration.

Apply the configuration with kubectl apply -f agent.yaml to register the target cluster (e.g., the Japan cluster).

Enable a multi‑cluster fleet in the ACK One console, linking registered clusters via public network and configuring a NAT gateway for the fleet VPC.

After these steps, a ready fleet spanning all regions is available.

Game Server Deployment with GitOps

Cloud‑native delivery relies on declarative YAML definitions rather than procedural scripts. Storing these YAML files in a Git repository enables versioned, auditable changes and supports GitOps workflows.

Because different regions may require distinct values (e.g., replica counts, images, autoscaling), the solution abstracts these differences using Helm charts. The chart extracts variable fields such as:

Main container image per region

Sidecar image per region

Replica count per region

Autoscaling enablement per region

All other fields remain identical across regions.

ArgoCD Integration

Connect the Git repository to ArgoCD via the ACK One GitOps console (login with ALIYUN). After adding the repository, create Applications for each region either manually through the ArgoCD UI or automatically using an ApplicationSet resource.

Manual Application Creation (PvE Example)

In ArgoCD, navigate to Applications → + NEW APP and fill in the repository URL, target revision, and path to the Helm chart.

Select the appropriate destination cluster and namespace (e.g., game-server).

Choose Manual sync policy and click SYNC to deploy.

The application status should show Healthy and Synced .

ApplicationSet for One‑Click Deployment

Define an ApplicationSet that lists each cluster with its specific parameters (URL, replica count). Deploy the ApplicationSet to the fleet cluster; ArgoCD will generate separate Applications for each region.

apiVersion: argoproj.io/v1alpha1</code>
<code>kind: ApplicationSet</code>
<code>metadata:</code>
<code>  name: minecraft</code>
<code>spec:</code>
<code>  generators:</code>
<code>  - list:</code>
<code>      elements:</code>
<code>      - cluster: shanghai-dev</code>
<code>        url: https://47.100.237.xxx:6443</code>
<code>        replicas: '1'</code>
<code>      - cluster: shanghai-prod</code>
<code>        url: https://47.101.214.xxx:6443</code>
<code>        replicas: '3'</code>
<code>      - cluster: frankfurt-prod</code>
<code>        url: https://8.209.103.xxx:6443</code>
<code>        replicas: '2'</code>
<code>      - cluster: japan-prod</code>
<code>        url: https://10.0.0.xxx:6443</code>
<code>        replicas: '2'</code>
<code>  template:</code>
<code>    metadata:</code>
<code>      name: '{{cluster}}-minecraft'</code>
<code>    spec:</code>
<code>      project: default</code>
<code>      source:</code>
<code>        repoURL: 'https://github.com/AliyunContainerService/gitops-demo.git'</code>
<code>        targetRevision: HEAD</code>
<code>        path: manifests/helm/open-game</code>
<code>        helm:</code>
<code>          valueFiles:</code>
<code>          - values.yaml</code>
<code>          parameters:</code>
<code>          - name: replicas</code>
<code>            value: '{{replicas}}'</code>
<code>          - name: scaled.enabled</code>
<code>            value: 'false'</code>
<code>      destination:</code>
<code>        server: '{{url}}'</code>
<code>        namespace: game-server</code>
<code>      syncPolicy:</code>
<code>        syncOptions:</code>
<code>          - CreateNamespace=true

Additional parameters (e.g., image versions) can be added similarly.

Publishing PvP Games

For PvP games, room servers scale automatically, so the scaled.enabled flag must be true. To avoid conflicts between ArgoCD and the autoscaler, configure ignoreDifferences for the GameServerSet replica field.

apiVersion: argoproj.io/v1alpha1</code>
<code>kind: ApplicationSet</code>
<code>metadata:</code>
<code>  name: pvp</code>
<code>spec:</code>
<code>  generators:</code>
<code>  - list:</code>
<code>      elements:</code>
<code>      - cluster: shanghai-dev</code>
<code>        url: https://47.100.237.xxx:6443</code>
<code>      - cluster: shanghai-prod</code>
<code>        url: https://47.101.214.xxx:6443</code>
<code>      - cluster: frankfurt-prod</code>
<code>        url: https://8.209.103.xxx:6443</code>
<code>      - cluster: japan-prod</code>
<code>        url: https://10.0.0.xxx:6443</code>
<code>  template:</code>
<code>    metadata:</code>
<code>      name: '{{cluster}}-pvp'</code>
<code>    spec:</code>
<code>      project: defaultminecraft</code>
<code>      ignoreDifferences:</code>
<code>      - group: game.kruise.io</code>
<code>        kind: GameServerSet</code>
<code>        name: minecraft</code>
<code>        namespace: game</code>
<code>        jsonPointers:</code>
<code>        - /spec/replicas</code>
<code>      source:</code>
<code>        repoURL: 'https://github.com/AliyunContainerService/gitops-demo.git'</code>
<code>        targetRevision: HEAD</code>
<code>        path: manifests/helm/open-game</code>
<code>        helm:</code>
<code>          valueFiles:</code>
<code>          - values.yaml</code>
<code>      destination:</code>
<code>        server: '{{url}}'</code>
<code>        namespace: pvp-server</code>
<code>      syncPolicy:</code>
<code>        syncOptions:</code>
<code>          - CreateNamespace=true

Conclusion

The article demonstrates a best‑practice workflow for globally consistent game server delivery using ACK One, multi‑cluster Kubernetes, Helm‑based abstraction, and GitOps automation. While the example covers four clusters and a simple game server YAML, real‑world scenarios may involve more clusters and more complex application definitions, making proper abstraction essential.