L'utilisation de Kubernetes Agones a-t-elle un sens économique ?

Vous voudrez probablement y réfléchir à deux fois si vous envisagez d'utiliser Kubernetes Agones pour gérer vos serveurs de jeu multijoueurs. Voici pourquoi. Agones est né des exigences de gestion des serveurs de jeu à l'aide de Kubernetes. C'est devenu le CRD que nous connaissons et qui peut être appliqué à un cluster Kubernetes existant, vous donnant un ensemble de méthodes et de capacités spécifiques aux jeux. La principale caractéristique est la capacité d'« allouer » un pod en cours d'exécution, ce que vous ne pouvez pas faire avec un Kubernetes standard.

Pour obtenir Agones, vous devrez d'abord faire fonctionner Kubernetes. Si vous n'avez jamais fait cela, ce n'est pas une tâche mineure. Plusieurs composants sont nécessaires, et de nombreuses exigences réseau l'accompagnent. Faire fonctionner une version autonome sur votre ordinateur portable en utilisant Kubeadm est probablement à quelques lignes de commandes près, mais installer un environnement de production réel avec mise à l'échelle automatique et résilience est une toute autre histoire. Sans même parler de l'aspect Ops (que vous auriez à faire avec une solution « open source gratuite » comme celle-ci), installer Kubernetes de la bonne manière et tirer le meilleur parti de la solution nécessite des mois de formation et plusieurs ingénieurs pour l'exploiter une fois opérationnelle. Vous devrez payer pour le matériel d'hébergement et le trafic réseau. Économisez-vous avec une solution gratuite et open source en ajoutant des ressources d'ingénierie ?

Voyons maintenant le CRD d'Agones. Une fois que vous avez Kubernetes en fonctionnement, vous installerez le CRD d'Agones, qui permet ces nouvelles possibilités. Cela ajoute un niveau de complexité supplémentaire avec des appels qui ne seront peut-être pas pris en charge par vos outils externes pour gérer Kubernetes. Vous devrez également configurer un proxy d'entrée, ce qui n'est pas trivial. La plupart sont encore en phase bêta et nécessitent plus de main-d'œuvre pour comprendre, installer et gérer. Le principal problème avec Agones et Kubernetes, en général, est qu'il vous obligera, en tant que studio de jeux, à décider où vous souhaitez exécuter vos serveurs de jeu (en raison de la notion fortement centralisée de Kubernetes), et vous devrez commencer à mettre en attente des instances en attendant que des joueurs rejoignent. Ce qui semblait être une solution bon marché deviendra rapidement un coût de 15 000 à 20 000 dollars par mois même si vous n'avez pas un seul joueur. Cela est dû à 3 à 4 ingénieurs pour gérer la réponse, au moins trois serveurs en tant que contrôleur trio et un « minion » par emplacement, et le soutien d'équipes QA et de joueurs dans le monde entier nécessitera au moins six sites, sinon plus. Nous envisageons donc 6 emplacements x 4 serveurs + 4 salaires d'ingénieurs.

Vous vous rendrez compte de cela une fois que vous et votre équipe aurez dépensé six mois de beaucoup d'argent à enquêter sur cette voie. Il existe des alternatives.

Une solution de conteneurs gérée en tant que service est probablement le meilleur chemin à suivre. Par exemple, AWS Fargate, ECS ou Google Cloud Run vous permettront de connecter automatiquement votre CI/CD pour pousser une nouvelle image de serveur de jeu et démarrer des serveurs de jeu à la demande. Vous pourriez construire une simple orchestration pour démarrer et arrêter des instances et gérer les allocations de votre système de matchmaking. Une autre alternative serait de regarder des services similaires à Fargate mais adaptés aux serveurs de jeu, comme Edgegap.

Edgegap supprime le besoin de votre système de matchmaking pour gérer les allocations, et vous n'auriez plus besoin d'une orchestration puisque l'orchestrateur est intégré à la plateforme d'hébergement.