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 l'évolutivité pour des centaines de milliers de joueurs simultanés dans différentes régions du monde 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 charge. L'équipe d'ingénierie de KRAFTON a lourdement investi dans des solutions sur mesure afin de 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 un serveur de jeu à froid en 2 secondes en médiane (octobre 2026, /platform-data/).
Avantages en matière d'efficacité opérationnelle : La conteneurisation a réduit le provisionnement des environnements à moins de 5 minutes et a permis des fonctionnalités en libre-service. Les équipes ont obtenu un accès autonome à l'infrastructure de test sans intervention de l'équipe DevOps.
Impact caché sur les ressources : Le parcours de modernisation a nécessité des années d'efforts d'ingénierie spécialisés qui auraient pu être orientés vers l'amélioration du gameplay. La plupart des studios ne peuvent pas se permettre ce niveau d'investissement dans l'infrastructure tout en maintenant des cycles de développement compétitifs.
Alternative des plateformes gérées : 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. En utilisant une plateforme comme Edgegap, les studios bénéficient d'une infrastructure de niveau entreprise grâce à une intégration simple, plutôt que de passer par des projets de mise en œuvre s'étalant sur plusieurs années.
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.
