Kubernetes
Kubernetes est un système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion d'applications conteneurisées. Il a été conçu pour des services web de longue durée plutôt que pour des serveurs de match éphémères, c'est pourquoi des couches spécifiques au jeu comme Agones existent par-dessus. Puissant, polyvalent et conséquent à exploiter.
Aussi appelé
k8s
,
À quoi sert Kubernetes dans un backend Multiplay ?
La majeure partie d'un backend multijoueur est constituée de services web : connexion, salons, boutiques, inventaires, classements, API de matchmaking. Ils ne conservent aucun état propre, répondent aux requêtes en quelques millisecondes et peuvent être arrêtés et remplacés à tout moment. C'est précisément la charge de travail pour laquelle Kubernetes a été conçu, et c'est là que les studios l'utilisent le plus souvent. En 2024, KRAFTON a décrit le fonctionnement du salon de PUBG: BATTLEGROUNDS sous forme de microservices .NET sur Amazon EKS (AWS re:Invent 2024, GAM311).
Le match en lui-même est différent. Un serveur de jeu héberge l'état en direct de toute la session et ne peut pas être déplacé ou redémarré sans mettre fin à la partie. Pour en exécuter un en toute sécurité, Kubernetes a besoin d'une couche supplémentaire spécifique au jeu, et c'est ce qu'apporte Agones.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
Objectif de modernisation de l’infrastructure : KRAFTON visait à éliminer les goulots d’étranglement opérationnels et à améliorer la scalabilité pour des centaines de milliers de joueurs simultanés dans des régions mondiales en passant d’un serveur de jeu basé sur les sessions à une orchestration moderne de serveurs de jeu basée sur des conteneurs.
Limites de mise à l’échelle d’Agones : La plateforme open source d’orchestration de serveurs de jeu souffrait de délais d’amorçage de 15 minutes lors des pics de mise à l’échelle. L’équipe d’ingénierie de KRAFTON a fortement investi dans des solutions personnalisées pour réduire ce délai à 3-4 minutes grâce à des proxys de registre de conteneurs et à l’adoption de Karpenter. Alors que les développeurs peuvent simplement utiliser une solution entièrement gérée comme Edgegap, qui démarre les serveurs de jeu à partir d’un démarrage à froid en 3 secondes en moyenne.
Avantages en efficacité opérationnelle : La conteneurisation a réduit le provisionnement des environnements à moins de 5 minutes et a permis des capacités de libre-service. Les équipes ont obtenu un accès autonome à l’infrastructure de test sans intervention DevOps.
Impact caché sur les ressources : Le parcours de modernisation a consommé des années d’efforts d’ingénierie spécialisés qui auraient pu être consacrés à l’amélioration du gameplay. La plupart des studios ne peuvent pas se permettre ce niveau d’investissement en infrastructure tout en maintenant des cycles de développement compétitifs.
Alternative de plateforme gérée : Les solutions entièrement gérées offrent des performances et des capacités de mise à l’échelle équivalentes, voire supérieures, sans complexité interne. Les studios obtiennent une infrastructure de niveau entreprise grâce à une intégration simple plutôt qu’à des projets de mise en œuvre sur plusieurs années en utilisant une plateforme comme Edgegap.
Qu'implique l'auto-hébergement de Kubernetes pour les serveurs de jeux ?
Mettre sur pied un cluster est la partie la plus rapide. Les services gérés tels qu'Amazon EKS, Google GKE et Azure AKS gèrent le plan de contrôle pour vous. Ce qui incombe au studio se développe selon trois axes.
Par région. Kubernetes est conçu pour qu'un seul cluster s'étende sur les zones d'une seule région (documentation Kubernetes). Les joueurs ne se trouvent pas dans une seule région, donc un jeu mondial gère un cluster par région, chacun avec ses propres nœuds, flottes, réserve de capacité et modes de défaillance.
Par version. Kubernetes maintient ses trois versions mineures les plus récentes, chacune corrigée pendant environ un an (kubernetes.io ; la version 1.37.1 a été publiée le 15 septembre 2026). Chaque version d'Agones prend en charge trois versions de Kubernetes (documentation Agones), de sorte que les deux évoluent ensemble, dans chaque cluster régional, selon un calendrier que ni l'un ni l'autre n'attend.
Par nœud. Les nœuds doivent démarrer assez rapidement pour répondre à la demande, et les images de serveur doivent les atteindre promptement. Chaque nœud a besoin d'une adresse IP publique que les joueurs peuvent atteindre, ce qui l'expose également aux attaques DDoS. Ajoutez à cela les correctifs de sécurité, la surveillance et une personne d'astreinte. Sur bare metal, le plan de contrôle et le matériel vous appartiennent également.
Rien de tout cela n'est un travail inhabituel. C'est un processus continu, et il se multiplie avec chaque région que vous exploitez.
Quand est-il logique de gérer son propre cluster ?
Cela est logique lorsque le cluster est déjà en place : un studio qui fait fonctionner ses services backend sur Kubernetes, dispose de personnes pour le gérer et souhaite avoir les serveurs de jeu sur la même plateforme. Cela convient également aux studios qui ont besoin que leurs serveurs restent au sein de leur propre compte cloud.
Pour tous les autres, la question est de savoir de combien de régions vous avez besoin et qui s'occupe de les maintenir à jour. Un réseau partagé répartit ce travail entre de nombreux studios : celui d'Edgegap s'étend sur plus de 615 sites auprès de plus de 17 fournisseurs (données de la plateforme, au 18 septembre 2026). Pour comparer l'orchestration auto-hébergée avec une plateforme gérée, consultez Edgegap vs Agones.
Un mot de notre sponsor (nous-mêmes !)
Une région est une supposition quant à l'endroit où se trouveront vos joueurs. L'Edge Cloud d'Edgegap est un réseau distribué et multi-cloud de plus de 615 emplacements répartis sur plus de 17 fournisseurs, disponible sur demande. Chaque serveur se lance au meilleur emplacement disponible sur le réseau au début du match, et non dans la région la plus proche parmi une poignée d'options.
