Mejores prácticas de ACK One x OpenKruiseGame para la entrega consistente de servidores de juegos globales en múltiples regiones

El equipo de la comunidad de código abierto de China realizó su primera transmisión en vivo, contando la historia detrás de la comunidad de código abierto de China en nombre de compartir".

Autor: Liu Qiuyang, Cai Jing

Prefacio

En el actual entorno económico globalmente integrado, la industria del entretenimiento digital se está convirtiendo cada vez más en un poderoso representante de los intercambios culturales y comerciales. En este contexto, un gran número de fabricantes de juegos han intentado llevar sus juegos al extranjero y han logrado resultados notables. Muchos juegos han atraído a una amplia gama de grupos de jugadores en todo el mundo con una estructura de servidores global. El despliegue global de juegos no sólo amplía el tamaño del mercado de productos individuales, sino que también aumenta la influencia global de los fabricantes de juegos, pero al mismo tiempo también plantea muchos desafíos técnicos:

La interacción de alta frecuencia y la baja latencia que requieren los servicios de juegos requieren que los servidores de juegos se implementen en múltiples regiones bajo el marco de servidores global. En operaciones reales, generalmente necesitamos planificar la ubicación del servidor con anticipación en función de la ubicación geográfica del grupo de usuarios objetivo y la tolerancia a la latencia. En términos generales, las siguientes áreas son nuestras direcciones de servidores prioritarias: el este de los Estados Unidos está densamente poblado y puede brindar servicios a una gran cantidad de jugadores norteamericanos; el área de Frankfurt es la intersección de Internet europea y puede servir de manera efectiva a la experiencia de red de; jugadores en toda Europa; Singapur La región cubre ampliamente la base de jugadores en el sudeste asiático; la región de Tokio brinda soporte principalmente a jugadores en Japón y Corea del Sur;

Ante posibles diferencias de configuración, actualizaciones de versiones de juegos e inconsistencias en la cantidad de servidores en diferentes regiones, cómo lograr de manera efectiva una entrega consistente de servidores de juegos a escala global se ha convertido en un desafío central que debemos enfrentar y resolver al diseñar el servidor global. arquitectura. . Este artículo utilizará un ejemplo para explicar las mejores prácticas para la entrega de coherencia multiregional de servidores de juegos globales.

Arquitectura de implementación

En el ejemplo, planeamos abrir servidores en Shanghai, Tokio y Frankfurt, por lo que necesitamos recursos de infraestructura en estas tres regiones. Frente a escenarios de infraestructura heterogéneos y complejos, la API declarativa y las funciones de entrega consistentes que ofrece la nube nativa pueden proteger completamente las diferencias en los recursos subyacentes, lo que permite a los ingenieros de operación y mantenimiento del juego concentrarse en la aplicación en sí y mejorar en gran medida la eficiencia de la entrega del servidor del juego. . Desde la perspectiva de la estabilidad de la autonomía regional y la complejidad de la programación de los usuarios, creemos que la implementación independiente de clústeres de Kubernetes en cada región de servidores y la gestión unificada de operación y mantenimiento a través de capacidades de múltiples clústeres es la mejor manera de ofrecer servidores de juegos consistentes.

En esta práctica, elegimos la plataforma de contenedores en la nube distribuida ACK One de Alibaba Cloud para administrar clústeres de Kubernetes multirregionales. Como plataforma nativa de nube de clase empresarial de Alibaba Cloud para nube híbrida, múltiples clústeres, recuperación de desastres y otros escenarios, ACK One puede conectar y administrar clústeres de Kubernetes en cualquier región y en cualquier infraestructura, y proporciona una gestión consistente para soportar aplicaciones y tráfico. , seguridad, almacenamiento, observabilidad, etc. están bajo control unificado.

La arquitectura de implementación de este ejemplo se muestra en la figura, incluidos 3 entornos de producción en diferentes regiones y 1 entorno de desarrollo y prueba. En términos generales, al verificar y confirmar que la versión es estable en el entorno de prueba de I+D antes de implementarla en el entorno de producción, este proceso ayuda a garantizar la estabilidad general del proyecto y previene eficazmente riesgos potenciales.

El ejemplo utiliza una arquitectura de nube híbrida de múltiples clústeres. Específicamente, el clúster de Shanghai, el clúster de Frankfurt y el clúster de ShangHai Dev son clústeres de Alibaba Cloud ACK, mientras que el clúster de Japón es un clúster de Kubernetes que no es de Alibaba Cloud y se integra y administra registrando el clúster. Dentro de cada clúster, utilizamos GameServerSet para implementar servidores de juegos. GameServerSet es una carga de trabajo específica para juegos proporcionada por OpenKruise, un proyecto de código abierto incubado por Cloud Native Computing Foundation (CNCF). En comparación con las cargas de trabajo nativas Deployment y StatefulSet, GameServerSet tiene semántica de juego y está más cerca de la escena del juego, lo que hace que la gestión de operación y mantenimiento del servidor de juegos sea más conveniente y eficiente.

Gestión de clústeres

Una vez completada la preparación del clúster de Kubernetes, utilizamos la flota ACK One para gestionar de manera uniforme los clústeres dentro y fuera de la nube:

Primero, registre el IDC o el clúster de nube pública de terceros en Alibaba Cloud a través del clúster de registro ACK One [ 1] , específicamente:

Cree un grupo de registro [ 2] y haga clic en Detalles debajo de la columna de operación en el lado derecho del grupo de registro creado .
Haga clic en la pestaña Información de conexión en la página de información del clúster .
En el área de configuración del agente de importación de clúster , seleccione red pública o red privada según sea necesario , luego haga clic en Copiar a la derecha para copiar el contenido de la etiqueta de red pública o de red privada en un archivo y ejecute el comando kubectl para registrar el clúster de destino en el nuevo grupo medio. Por ejemplo, cree un nuevo archivo agent.yaml, copie el contenido anterior en el archivo agent.yaml y ejecute el comando kubectl apply -f agent.yaml en el clúster de destino.

A través de este paso, el clúster de Japón se registró en Alibaba Cloud.

En segundo lugar, abra la flota de múltiples clústeres de ACK One [ 3] y asocie el clúster registrado con el clúster de nube en la consola de ACK One [ 4] . Dado que el clúster abarca varias regiones, la flota ACK One utilizará la red pública para asociarse con el clúster, y la VPC donde se encuentra la flota debe configurarse con una puerta de enlace NAT de red pública.

En este punto, una flota de múltiples clústeres está lista. El diagrama esquemático correspondiente al ejemplo es el siguiente:

Lanzamiento del servidor de juegos

Antes de ejecutar la operación de lanzamiento específica del ejemplo, conozcamos la idea de entrega nativa de la nube: declarativa en lugar de orientada a procesos, lo que significa que la entrega de aplicaciones nativas de la nube no se centra en el proceso de implementación de la aplicación sino en la definición de la aplicación. La definición de una aplicación es Yaml, que describe cómo debería verse la aplicación a través de parámetros de configuración. Por lo tanto, todos los cambios y lanzamientos relacionados con la aplicación son en realidad cambios en la descripción de la aplicación (Yaml).

Hasta ahora hemos descubierto que necesitamos un almacén para almacenar Yaml, registrar la descripción actual de la aplicación y poder rastrear y auditar cambios anteriores de Yaml. Habiendo dicho esto, creo que todos encontrarán que el repositorio de git cumple naturalmente con esta característica. Los ingenieros de operación y mantenimiento pueden cargar y poner Yaml en el disco enviando solicitudes de confirmación y fusión, y la auditoría sigue las especificaciones de git. En un mundo ideal, solo necesitamos mantener un conjunto de descripciones YAML de los servidores de juegos y activar el lanzamiento de servidores de juegos en múltiples regiones del mundo con un solo clic. No es necesario operar el clúster uno por uno para realizar la implementación. comportamiento. Ésta es la idea de GitOps.

Lo más desafiante en el proceso de implementación de GitOps es en realidad la descripción abstracta de la aplicación del servidor del juego. Como se mencionó al principio del artículo, existen más o menos diferencias en los servidores de juegos en cada región, y parece difícil resumir todos los servidores de juegos en un Yaml. Por ejemplo, en Shanghai quiero lanzar 10 servidores regionales de juegos, pero en Frankfurt solo quiero lanzar 3 servidores regionales. De esta manera, un Yaml no puede describir servidores de juegos en diferentes regiones debido a diferencias en el campo de réplicas. ¿Necesitamos mantener un Yaml para cada región? Esto tampoco es razonable. Al realizar cambios de campos no diferenciados (por ejemplo, etiquetar servidores de juegos en todas las regiones), necesitamos realizar múltiples cambios de Yaml cuando la cantidad de clústeres es grande, lo que puede causar omisiones o errores. Esto no está en línea con la idea de entrega nativa en la nube.

De hecho, podemos abstraer aún más la aplicación del servidor del juego a través de Helm Chart y extraer las diferentes partes como Valor. En nuestro ejemplo esta vez (ejemplo de Helm Chart del servidor de juegos GitHub [ 5] ), resumimos varios campos diferentes:

Imagen maestra: la imagen maestra de cada región/grupo puede ser diferente
Imagen complementaria: la imagen complementaria de cada región/grupo puede ser diferente
Número de copias: el número de servidores de juegos lanzados por región/clúster puede variar
Ya sea para realizar el escalado automático: cada región/clúster puede tener requisitos diferentes para el escalado automático

Aparte de esto, otros campos siguen siendo consistentes, lo que significa que no hay diferencias regionales.

Después de comprender GitOps y abstraer y describir las aplicaciones del servidor de juegos, utilizamos ACK One GitOps para realizar la entrega práctica de aplicaciones. A continuación iniciamos las operaciones específicas:

Conéctese al repositorio de Git

Inicie sesión en la interfaz de usuario de ArgoCD: vaya a Fleet -> GitOps -> GitOps Console en la barra de navegación izquierda de la consola ACK One y, en la página de inicio de sesión, haga clic en INICIAR SESIÓN A TRAVÉS DE ALIYUN para iniciar sesión en la interfaz de usuario de ArgoCD. Si necesita acceso a una red pública, debe abrir una red pública para acceder a GitOps [ 6] .

Seleccione Configuración en la barra de navegación izquierda de la interfaz de usuario de ArgoCD, luego seleccione Repositorios > + Connect Repo.
Configure la siguiente información en el panel emergente y luego haga clic en CONECTAR para agregar una conexión.

Publicar juegos tipo PvE

Los juegos PvE suelen tener el concepto de servidores regionales. En la mayoría de los casos, los ingenieros de operación y mantenimiento controlan manualmente la cantidad de servidores abiertos en cada región. Para conocer las mejores prácticas de los juegos PvE nativos de la nube, consulte el documento de mejores prácticas de juegos PvE de OKG [ 7] .

Aplicación de gestión de pantalla blanca.

Al probar ArgoCD por primera vez, podemos usar la consola de pantalla blanca para crear Aplicaciones para los clusters en cada región:

Seleccione Aplicaciones en la barra de navegación izquierda de la interfaz de usuario de ArgoCD y luego haga clic en + NUEVA APLICACIÓN.
Configure la siguiente información en el panel emergente y luego haga clic en CREAR para crear. (Tome opengame-demo-shanghai-dev como ejemplo).

Una vez completada la creación, podrá ver el estado de la aplicación opengame-demo-shanghai-dev en la página de la aplicación . Si la POLÍTICA DE SINCRONIZACIÓN selecciona el modo Manual , deberá hacer clic manualmente en SINCRONIZAR para implementar sincrónicamente la aplicación en el clúster de destino. El estado de la aplicación es Saludable y Sincronizada , lo que indica que la sincronización se ha realizado correctamente.

Haga clic en el nombre de la aplicación opengame-demo-shanghai-dev para ver los detalles de la aplicación y mostrar la topología y el estado correspondiente de los recursos de Kubernetes relacionados con la aplicación.

Publique con un clic a través de ApplicationSet

Después de familiarizarnos con ArgoCD, también podemos usar el objeto ApplicationSet para publicar servidores de juegos con un solo clic. Las diferencias de cada clúster se abstraen a través de elementos. Por ejemplo, en el Yaml siguiente, se abstraen tres campos de la dimensión del clúster: el nombre del clúster se usa para distinguir la URL de la aplicación para distinguir la dirección del clúster de destino; para distinguir juegos publicados por diferentes grupos.

Después de escribir ApplicationSet Yaml, impleméntelo en el clúster de flota ACK One para crear automáticamente cuatro aplicaciones.

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 #若集群中命名空间不存在则自动创建

En este Yaml, todas las versiones de imágenes son consistentes. Si desea que las versiones de imágenes de cada clúster sean diferentes, puede agregar nuevos parámetros de la misma manera que las réplicas.

Publicar juegos tipo PvP

Para los juegos de tipo PvP, la cantidad de servidores de la sala la asigna su propio escalador en lugar de que los ingenieros de operación y mantenimiento lo especifiquen manualmente. Para conocer las mejores prácticas nativas de la nube para juegos PvP, consulte el documento de mejores prácticas de juegos PvP de OKG [ 8] .

En OKG, implementamos el escalado elástico de los servidores de sala configurando el objeto ScaledObject para GameServerSet. Por lo tanto, es necesario activar scaled.enabled en este escenario. Además, el número de copias del servidor de sala entra en conflicto con dos controladores, ArgoCD y OKG. Esto se puede resolver dejando que ArgoCD ignore los cambios en el número de copias del recurso GameServerSet. Específicamente, configure los campos correspondientes en spec.ignoreDifferences. Teniendo en cuenta lo anterior, pvp.yaml se ve así:

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

Resumir

Este artículo utiliza un ejemplo para presentar las mejores prácticas para la entrega consistente de ACK One en múltiples regiones en servidores de juegos globales. El ejemplo involucra 4 clústeres de Kubernetes y un servidor de juegos simple Yaml. En el entorno de producción real, es probable que la cantidad de clústeres sea mayor y la descripción de la aplicación del servidor del juego sea más compleja. En este momento, la clave es abstraer bien la aplicación.

Bienvenido a unirse al grupo DingTalk de juegos nativos en la nube (número de grupo: 44862615) para comunicarse y discutir con los desarrolladores de OpenKruiseGame y los ingenieros de operaciones e I+D de la industria de los juegos sobre preguntas relacionadas con ACK One. También puede unirse al grupo DingTalk (número de grupo: 35688562); para consulta.

Enlaces relacionados:

[1] ACK Un grupo de registro

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

[2] Crear un grupo de registro

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/create-a-cluster-registration-proxy-and-register-a-kubernetes-cluster- ¿implementado en un centro de datos?spm=a2c4g.11186623.0.0.2f833eb6R1YTOq

[3] Inicie la flota de múltiples clústeres de 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 Una consola

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

[5] Ejemplo de gráfico de timón del servidor de juegos GitHub

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

[6] Necesidad de abrir una red pública para acceder a GitOps