Case Study: Deploying Pandora Marketing Solution on Tencent Cloud Kubernetes for Game Operations

Background : In the interactive entertainment business, many services support game operations. Pandora provides a professional marketing solution that embeds native UI experiences into games and pushes marketing services to players, boosting activity, retention, and revenue. Over 40 Tencent games have adopted Pandora, which relies on various cloud resources, especially for overseas marketing activities that experience high traffic spikes and require elastic scaling.

Current Status : The Pandora module for the overseas version of King of Glory has been successfully migrated to a Tencent Cloud Kubernetes (K8s) cluster, integrating the Spider project management platform with Tencent Cloud K8s APIs. The system has been stable for nearly six months.

Platform Selection Process :

1. Tencent Cloud Container Service : Purchase virtual machines (CVM) and run a managed K8s cluster on them. Requires pre‑purchasing VMs; resources are dedicated.

2. Tencent Cloud Container Instance Service : Use serverless containers directly without VM provisioning. No orchestration support; resources are shared and cost‑effective.

3. Build a custom cluster on purchased VMs: Full control over the K8s stack, suitable for deep technical exploration.

For validation, four standard CentOS 7 VMs were provisioned and a single‑master multi‑node cluster was set up using kubeasz’s AllinOne deployment.

Performance Test Comparison :

Environment

VM

Self‑built K8s

Container Instance

Container Service

Score

841

646

1173

1268

The higher scores of the container‑based services are mainly due to better cgroup isolation. Overall, the four platforms show comparable performance.

System Architecture :

(1) The container image includes overseas basic components such as L5 (Tencent’s internal service‑discovery/load‑balancing system) and the tnm2 agent. An overseas version of L5 was developed to ease code migration.

(2) Integration with the Spider system and Tencent Cloud image repository replaces the old "file‑push → restart" workflow with "build image → push to repository → update container". Configuration items are injected as environment variables via the Spider API.

(3) Configuration files are stored in Tencent Cloud Object Storage instead of being distributed to machines. The application pulls the config at startup and caches it locally.

(4) Logging: originally planned to use container‑front‑log → Kafka → Elasticsearch, but due to missing Kafka nodes, BlueKing’s data platform was used for log collection. Logs are collected from the host’s overlay2 filesystem (e.g., /var/lib/docker/overlay2/.../merged/data/log/nginx/*.log ).

Experience & Insights :

1. Docker Philosophy – Build a new image for every change; avoid mutating running containers.

2. Pay‑as‑you‑go – Pay‑as‑you‑go means billing is based on actual usage time; if not used, there is no charge. Marketing activities have distinct peak‑valley patterns with regularity.

3. Monitoring – Used Prometheus, BlueKing, and overseas tnm2 for metrics and log collection.

4. Image Version Control – Tencent Cloud retains up to 100 image versions; manual cleanup or automated rotation is required.

5. OS Choice – Started with minimal CentOS 7, later switched to Tlinux 2.2 (2.2 GB image).

6. Auto‑Scaling – Configured CPU‑based horizontal pod autoscaling to keep average CPU usage around 70%. Example: 14 nodes at 50% CPU trigger scaling to ~10 nodes (14 × 50 ÷ 70).

7. Operational Tips – Set CPU requests, keep reasonable target utilization, ensure pods are healthy, use load balancers instead of direct container IPs, account for a 10% fluctuation factor, and avoid scaling when replica count is zero.

Conclusion : The project demonstrates how Kubernetes blurs the line between development and operations. Developers must understand the full stack, while ops engineers need to grasp code-level details, leading to tighter collaboration.

Author: An Xinhai Source: IEG Value‑Added Services – Technical Library