Meilleures pratiques ACK One x OpenKruiseGame pour une livraison cohérente de serveurs de jeux mondiaux dans plusieurs régions

L'équipe de la communauté open source chinoise a réalisé sa première diffusion en direct, racontant l'histoire de la communauté open source chinoise au nom du partage.

Auteur : Liu Qiuyang, Cai Jing

Préface

Dans l'environnement économique mondial intégré d'aujourd'hui, l'industrie du divertissement numérique devient de plus en plus un puissant représentant des échanges culturels et commerciaux. Dans ce contexte, un grand nombre de fabricants de jeux ont tenté de commercialiser leurs jeux à l'étranger et ont obtenu des résultats remarquables. De nombreux jeux ont attiré un large éventail de groupes de joueurs à travers le monde avec une structure de serveurs mondiale. Le déploiement mondial des jeux augmente non seulement la taille du marché des produits individuels, mais augmente également l'influence mondiale des fabricants de jeux, mais en même temps, il entraîne également de nombreux défis techniques :

L'interaction à haute fréquence et la faible latence requises par les services de jeux nécessitent que les serveurs de jeux soient déployés dans plusieurs régions dans le cadre du cadre de serveur mondial. Dans les opérations réelles, nous devons généralement planifier l'emplacement du serveur à l'avance en fonction de l'emplacement géographique du groupe d'utilisateurs cible et de la tolérance de latence. D'une manière générale, les zones suivantes sont nos adresses de serveurs prioritaires : l'est des États-Unis est densément peuplé et peut fournir des services à un grand nombre d'acteurs nord-américains ; la région de Francfort est l'intersection de l'Internet européen et peut servir efficacement l'expérience réseau de joueurs dans toute l'Europe ; Singapour La région couvre largement la base de joueurs d'Asie du Sud-Est ; la région de Tokyo fournit principalement un soutien aux joueurs du Japon et de Corée du Sud.

Face aux éventuelles différences de configuration, aux mises à jour des versions de jeu et aux incohérences dans le nombre de serveurs dans différentes régions, comment parvenir efficacement à une livraison cohérente des serveurs de jeu à l'échelle mondiale est devenu un défi majeur que nous devons relever et résoudre lors de la conception du serveur mondial. architecture. . Cet article utilisera un exemple pour expliquer les meilleures pratiques en matière de fourniture de cohérence multirégionale des serveurs de jeux mondiaux.

Architecture de déploiement

Dans l'exemple, nous prévoyons d'ouvrir des serveurs à Shanghai, Tokyo et Francfort, nous avons donc besoin de ressources d'infrastructure dans ces trois régions. Face à des scénarios d'infrastructure hétérogènes et complexes, l'API déclarative et les fonctionnalités de livraison cohérentes apportées par le cloud natif peuvent entièrement masquer les différences dans les ressources sous-jacentes, permettant aux ingénieurs d'exploitation et de maintenance des jeux de se concentrer sur l'application elle-même et d'améliorer considérablement l'efficacité de la livraison des serveurs de jeux. . Du point de vue de la stabilité de l'autonomie régionale et de la complexité de la planification des utilisateurs, nous pensons que le déploiement indépendant de clusters Kubernetes dans chaque région de serveur et la gestion unifiée de l'exploitation et de la maintenance grâce à des capacités multiclusters sont le meilleur moyen de fournir des serveurs de jeux cohérents.

Dans cette pratique, nous avons choisi la plate-forme de conteneurs cloud distribués d'Alibaba Cloud, ACK One, pour gérer les clusters Kubernetes multirégionaux. En tant que plateforme cloud native d'entreprise d'Alibaba Cloud pour le cloud hybride, le multicluster, la reprise après sinistre et d'autres scénarios, ACK One peut connecter et gérer des clusters Kubernetes dans n'importe quelle région et sur n'importe quelle infrastructure, et fournit une gestion cohérente pour prendre en charge les applications et le trafic. , la sécurité, le stockage, l'observabilité, etc. sont sous contrôle unifié.

L'architecture de déploiement de cet exemple est illustrée dans la figure, comprenant 3 environnements de production dans différentes régions et 1 environnement de développement et de test. De manière générale, en vérifiant et confirmant que la version est stable dans l'environnement de test R&D avant de la déployer dans l'environnement de production, ce processus permet d'assurer la stabilité globale du projet et de prévenir efficacement les risques potentiels.

L'exemple utilise une architecture cloud hybride multicluster. Plus précisément, le cluster de Shanghai, le cluster de Francfort et le cluster ShangHai Dev sont des clusters Alibaba Cloud ACK ; tandis que le cluster du Japon est un cluster non-Alibaba Cloud Kubernetes, qui est intégré et géré en enregistrant le cluster. Au sein de chaque cluster, nous utilisons GameServerSet pour déployer des serveurs de jeux. GameServerSet est une charge de travail spécifique au jeu fournie par OpenKruise, un projet open source incubé par la Cloud Native Computing Foundation (CNCF). Par rapport aux charges de travail natives Deployment et StatefulSet, GameServerSet a une sémantique de jeu et est plus proche de la scène de jeu, ce qui rend la gestion de l'exploitation et de la maintenance du serveur de jeu plus pratique et efficace.

Gestion des clusters

Une fois la préparation du cluster Kubernetes terminée, nous utilisons la flotte ACK One pour gérer uniformément les clusters sur et hors du cloud :

Tout d'abord, enregistrez l'IDC ou le cluster de cloud public tiers sur Alibaba Cloud via le cluster d'enregistrement ACK One [ 1] , en particulier :

Créez un cluster d'enregistrement [ 2] et cliquez sur Détails sous la colonne d'opération sur le côté droit du cluster d'enregistrement créé .
Cliquez sur l'onglet Informations de connexion sur la page d'informations sur le cluster .
Dans la zone de configuration de l'agent d'importation de cluster , sélectionnez le réseau public ou le réseau privé selon vos besoins , puis cliquez sur Copier à droite pour copier le contenu de la balise de réseau public ou de réseau privé dans un fichier et exécutez la commande kubectl pour enregistrer le cluster cible dans le nouveau cluster. Par exemple, créez un nouveau fichier agent.yaml, copiez le contenu ci-dessus dans le fichier agent.yaml et exécutez la commande kubectl apply -f agent.yaml dans le cluster cible.

Grâce à cette étape, le cluster japonais a été enregistré auprès d'Alibaba Cloud.

Deuxièmement, ouvrez la flotte multi-cluster ACK One [ 3] et associez le cluster enregistré au cluster cloud sur la console ACK One [ 4] . Étant donné que le cluster s'étend sur plusieurs régions, la flotte ACK One utilisera le réseau public pour s'associer au cluster, et le VPC où se trouve la flotte doit être configuré avec une passerelle NAT de réseau public.

À ce stade, une flotte multicluster est prête. Le schéma de principe correspondant à l'exemple est le suivant :

Sortie du serveur de jeu

Avant d'exécuter l'opération de publication spécifique de l'exemple, apprenons à connaître l'idée de livraison native dans le cloud - déclarative plutôt que orientée processus, ce qui signifie que la livraison d'applications cloud natives se concentre non pas sur le processus de déploiement d'application mais sur la définition de l'application. La définition d'une application est Yaml, qui décrit à quoi doit ressembler l'application via des paramètres de configuration. Par conséquent, toutes les modifications et versions liées à l’application sont en fait des modifications apportées à la description de l’application (Yaml).

Jusqu'à présent, nous avons découvert que nous avions besoin d'un entrepôt pour stocker Yaml, enregistrer la description actuelle de l'application et être capable de retracer et d'auditer les modifications passées de Yaml. Cela dit, je pense que tout le monde constatera que le dépôt git répond naturellement à cette caractéristique. Les ingénieurs d'exploitation et de maintenance peuvent télécharger et mettre Yaml sur le disque en soumettant une demande de validation et de fusion et en auditant toutes les spécifications de git. Dans un monde idéal, il nous suffit de conserver un ensemble de descriptions YAML des serveurs de jeux et de déclencher la sortie de serveurs de jeux dans plusieurs régions du monde en un seul clic. Il n'est pas nécessaire d'exploiter le cluster un par un pour effectuer le déploiement. Actions. C'est l'idée de GitOps.

La chose la plus difficile dans le processus de mise en œuvre de GitOps est en fait la description abstraite de l'application serveur de jeu. Comme mentionné au début de l'article, il existe plus ou moins de différences dans les serveurs de jeux dans chaque région, et il semble difficile de résumer tous les serveurs de jeux via un seul Yaml. Par exemple, à Shanghai, je souhaite publier 10 serveurs régionaux de jeux, mais à Francfort, je souhaite uniquement publier 3 serveurs régionaux. De cette façon, un Yaml ne peut pas décrire les serveurs de jeux dans différentes régions en raison des différences dans le champ des répliques. Devons-nous maintenir un Yaml pour chaque région ? Cela est également déraisonnable.Lorsque nous apportons des modifications de champ non différenciées (par exemple, étiquetant les serveurs de jeu dans toutes les régions), nous devons effectuer plusieurs modifications Yaml à plusieurs reprises. Lorsque le nombre de clusters est important, il est facile de provoquer des omissions ou des erreurs. Cela n’est pas conforme à l’idée d’une livraison native dans le cloud.

En fait, nous pouvons extraire davantage l'application du serveur de jeu via Helm Chart et extraire les différentes parties sous forme de valeur. Dans notre exemple cette fois (exemple Helm Chart du serveur de jeu GitHub [ 5] ), nous avons abstrait plusieurs champs différents :

Image principale - l'image principale de chaque région/cluster peut être différente
Image side-car - l'image side-car de chaque région/cluster peut être différente
Nombre de copies : le nombre de serveurs de jeu publiés par région/cluster peut varier
S'il faut procéder à une mise à l'échelle automatique : chaque région/cluster peut avoir des exigences différentes en matière de mise à l'échelle automatique.

En dehors de cela, les autres domaines restent cohérents, ce qui signifie qu’il n’y a pas de différences régionales.

Après avoir compris GitOps et résumé et décrit les applications de serveur de jeux, nous avons utilisé ACK One GitOps pour effectuer une livraison pratique d'applications. Ensuite, nous commençons les opérations spécifiques :

Connectez-vous au référentiel Git

Connectez-vous à l'interface utilisateur d'ArgoCD : accédez à Fleet -> GitOps -> GitOps Console dans la barre de navigation de gauche de la console ACK One , et sur la page de connexion, cliquez sur CONNEXION VIA ALIYUN pour vous connecter à l'interface utilisateur d'ArgoCD. Si vous avez besoin d'un accès au réseau public, vous devez ouvrir un réseau public pour accéder à GitOps [ 6] .

Sélectionnez Paramètres dans la barre de navigation gauche de l'interface utilisateur ArgoCD, puis sélectionnez Dépôts > + Connect Repo.
Configurez les informations suivantes dans le panneau contextuel, puis cliquez sur CONNECT pour ajouter une connexion.

Publier des jeux de type PvE

Les jeux PvE ont généralement le concept de serveurs régionaux. Dans la plupart des cas, les ingénieurs d'exploitation et de maintenance contrôlent manuellement le nombre de serveurs ouverts dans chaque région. Pour les meilleures pratiques des jeux PvE cloud natifs, veuillez vous référer au document sur les meilleures pratiques des jeux OKG PvE [ 7] .

Application de gestion d'écran blanc

Lors du premier essai d'ArgoCD, nous pouvons utiliser la console à écran blanc pour créer des applications pour les clusters de chaque région :

Sélectionnez Applications dans la barre de navigation gauche de l'interface utilisateur d'ArgoCD , puis cliquez sur + NOUVELLE APPLICATION.
Configurez les informations suivantes dans le panneau contextuel, puis cliquez sur CRÉER pour créer. (Prenez opengame-demo-shanghai-dev comme exemple).

Une fois la création terminée, vous pouvez voir l'état de l'application d'opengame-demo-shanghai-dev sur la page Application . Si la POLITIQUE DE SYNC sélectionne le mode Manuel , vous devez cliquer manuellement sur SYNC pour déployer l'application de manière synchrone sur le cluster cible. L'état de l'application est Healthy et Synced , indiquant que la synchronisation a réussi.

Cliquez sur le nom de l'application opengame-demo-shanghai-dev pour afficher les détails de l'application et afficher la topologie et l'état correspondant des ressources Kubernetes liées à l'application.

Publiez en un clic via ApplicationSet

Après s'être familiarisé avec ArgoCD, nous pouvons également utiliser l'objet ApplicationSet pour publier des serveurs de jeux en un clic. Les différences de chaque cluster sont résumées à travers des éléments. Par exemple, dans le Yaml ci-dessous, trois champs sont extraits de la dimension du cluster : le nom du cluster est utilisé pour distinguer le nom de l'application ; l'URL est utilisée pour distinguer l'adresse du cluster cible ; pour distinguer les jeux publiés par différents clusters.

Après avoir écrit l'ApplicationSet Yaml, déployez-le sur le cluster de flotte ACK One pour créer automatiquement quatre applications.

kubectl apply -f pve.yaml -n argocd

# pve.yaml 内容如下：
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: minecraft
spec:
  generators:
  - list:
      elements:
      - cluster: shanghai-dev
        url: <https://47.100.237.xxx:6443>
        replicas: '1'
      - cluster: shanghai-prod
        url: <https://47.101.214.xxx:6443>
        replicas: '3'
      - cluster: frankfurt-prod
        url: <https://8.209.103.xxx:6443>
        replicas: '2'
      - cluster: japan-prod
        url: <https://10.0.0.xxx:6443>
        replicas: '2'
  template:
    metadata:
      name: '{{cluster}}-minecraft'
    spec:
      project: default
      source:
        repoURL: '<https://github.com/AliyunContainerService/gitops-demo.git>'
        targetRevision: HEAD
        path: manifests/helm/open-game
        helm:
          valueFiles:
          - values.yaml
          parameters: #对应helm chart中提取的value参数
          - name: replicas
            value: '{{replicas}}'
          - name: scaled.enabled 
            value: 'false'
      destination:
        server: '{{url}}'
        namespace: game-server #部署到对应集群的game-server命名空间下
      syncPolicy:
        syncOptions:
          - CreateNamespace=true #若集群中命名空间不存在则自动创建

Dans ce Yaml, toutes les versions d'image sont cohérentes. Si vous souhaitez que les versions d'image de chaque cluster soient différentes, vous pouvez ajouter de nouveaux paramètres de la même manière que les réplicas.

Publier des jeux de type PvP

Pour les jeux de type PvP, le nombre de serveurs de salle est alloué par son propre scaler plutôt que spécifié manuellement par les ingénieurs d'exploitation et de maintenance. Pour connaître les meilleures pratiques cloud natives pour les jeux PvP, veuillez vous référer au document sur les meilleures pratiques de jeu OKG PvP [ 8] .

Dans OKG, nous implémentons la mise à l'échelle élastique des serveurs de salle en configurant l'objet ScaledObject pour GameServerSet. Par conséquent, scaled.enabled doit être activé dans ce scénario. De plus, le nombre de copies du serveur de salle est en conflit avec deux contrôleurs, ArgoCD et OKG. Cela peut être résolu en laissant ArgoCD ignorer les modifications du nombre de copies de la ressource GameServerSet. Plus précisément, définissez les champs correspondants dans spec.ignoreDifferences. Compte tenu de ce qui précède, le pvp.yaml ressemble à ceci :

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

Résumer

Cet article utilise un exemple pour présenter les meilleures pratiques pour une livraison cohérente d'ACK One dans plusieurs régions sur des serveurs de jeux mondiaux. L'exemple implique 4 clusters Kubernetes et un simple serveur de jeu Yaml. Dans l'environnement de production actuel, il est probable que le nombre de clusters soit plus grand et que la description de l'application du serveur de jeu soit plus complexe. À ce stade, la clé est de bien faire abstraction de l'application.

Bienvenue à rejoindre le groupe DingTalk de jeux natifs cloud (numéro de groupe : 44862615) pour communiquer et discuter avec les développeurs d'OpenKruiseGame et les ingénieurs R&D et opérationnels de l'industrie du jeu ; pour les questions liées à ACK One, vous pouvez également rejoindre le groupe DingTalk (numéro de groupe : 35688562) pour consultation.

Liens connexes:

[1] Cluster d'enregistrement ACK One

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/overview-9?spm=a2c4g.11186623.0.0.3e4157eb3o9J3v

[2] Créer un cluster d'enregistrement

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/create-a-cluster-registration-proxy-and-register-a-kubernetes-cluster- déployé dans un centre de données?spm=a2c4g.11186623.0.0.2f833eb6R1YTOq

[3] Démarrez la flotte multicluster ACK One

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/enable-fleet-management?spm=a2c4g.11186623.0.0.8cc462853sti0H

[4] ACK One console

https://account.aliyun.com/login/login.htm?oauth_callback=https%3A%2F%2Fcs.console.aliyun.com%2Fone

[5] Exemple de Helm Chart du serveur de jeu GitHub

https://github.com/AliyunContainerService/gitops-demo/tree/main/manifests/helm/open-game

[6] Besoin d'ouvrir un réseau public pour accéder à GitOps