Práticas recomendadas ACK One x OpenKruiseGame para entrega consistente de servidores de jogos globais em múltiplas regiões

A equipe da comunidade de código aberto da China fez sua primeira transmissão ao vivo, contando a história por trás da comunidade de código aberto da China em nome do compartilhamento."

Autor: Liu Qiuyang, Cai Jing

Prefácio

No actual ambiente económico globalmente integrado, a indústria do entretenimento digital está a tornar-se cada vez mais um poderoso representante dos intercâmbios culturais e comerciais. Neste contexto, um grande número de fabricantes de jogos tentaram levar os seus jogos para o estrangeiro e alcançaram resultados notáveis. Muitos jogos atraíram uma vasta gama de grupos de jogadores em todo o mundo com uma estrutura de servidores global. A implantação global de jogos não só expande o tamanho do mercado de produtos individuais, mas também aumenta a influência global dos fabricantes de jogos, mas ao mesmo tempo também traz muitos desafios técnicos:

A interação de alta frequência e a baixa latência exigidas pelos serviços de jogos exigem que os servidores de jogos sejam implantados em múltiplas regiões sob a estrutura global de servidores. Em operações reais, geralmente precisamos planejar a localização do servidor com antecedência com base na localização geográfica do grupo de usuários alvo e na tolerância à latência. De um modo geral, as seguintes áreas são os nossos endereços de servidor prioritários - o leste dos Estados Unidos é densamente povoado e pode fornecer serviços a um grande número de intervenientes norte-americanos; a área de Frankfurt é a intersecção da Internet europeia e pode servir eficazmente a experiência de rede de; jogadores em toda a Europa; Singapura A região cobre amplamente a base de jogadores no Sudeste Asiático; a região de Tóquio fornece suporte principalmente para jogadores no Japão e na Coreia do Sul.

Diante de possíveis diferenças de configuração, atualizações de versões de jogos e inconsistências no número de servidores em diferentes regiões, como conseguir efetivamente uma entrega consistente de servidores de jogos em escala global tornou-se um desafio central que devemos enfrentar e resolver ao projetar o servidor global. arquitetura. Este artigo usará um exemplo para explicar as práticas recomendadas para entrega de consistência multirregional de servidores de jogos globais.

Arquitetura de implantação

No exemplo, planejamos abrir servidores em Xangai, Tóquio e Frankfurt, por isso precisamos de recursos de infraestrutura nessas três regiões. Diante de cenários de infraestrutura heterogêneos e complexos, a API declarativa e os recursos de entrega consistentes trazidos pelo nativo da nuvem podem proteger totalmente as diferenças nos recursos subjacentes, permitindo que os engenheiros de operação e manutenção de jogos se concentrem no próprio aplicativo e melhorem significativamente a eficiência da entrega do servidor de jogos. . Do ponto de vista da estabilidade da autonomia regional e da complexidade do agendamento do usuário, acreditamos que a implantação independente de clusters Kubernetes em cada região de servidor e o gerenciamento unificado de operação e manutenção por meio de recursos de vários clusters são a melhor maneira de fornecer servidores de jogos consistentes.

Nesta prática, escolhemos a plataforma de contêiner em nuvem distribuída ACK One do Alibaba Cloud para gerenciar clusters Kubernetes multirregionais. Como plataforma nativa de nuvem de classe empresarial da Alibaba Cloud para nuvem híbrida, multicluster, recuperação de desastres e outros cenários, o ACK One pode conectar e gerenciar clusters Kubernetes em qualquer região e em qualquer infraestrutura, e fornece gerenciamento consistente para suportar aplicativos e tráfego. , segurança, armazenamento, observabilidade, etc. estão sob controle unificado.

A arquitetura de implantação deste exemplo é mostrada na figura, incluindo 3 ambientes de produção em diferentes regiões e 1 ambiente de desenvolvimento e teste. De modo geral, ao verificar e confirmar se a versão é estável no ambiente de teste de P&D antes de implantá-la no ambiente de produção, esse processo ajuda a garantir a estabilidade geral do projeto e a prevenir eficazmente riscos potenciais.

O exemplo usa uma arquitetura de nuvem híbrida multicluster. Especificamente, o cluster de Xangai, o cluster de Frankfurt e o cluster ShangHai Dev são clusters Alibaba Cloud ACK, enquanto o cluster do Japão é um cluster não Alibaba Cloud Kubernetes, que é integrado e gerenciado pelo registro do cluster; Dentro de cada cluster, usamos GameServerSet para implantar servidores de jogos. GameServerSet é uma carga de trabalho específica de jogo fornecida pelo OpenKruise, um projeto de código aberto incubado pela Cloud Native Computing Foundation (CNCF). Comparado com as cargas de trabalho nativas Deployment e StatefulSet, GameServerSet possui semântica de jogo e está mais próximo do cenário do jogo, tornando o gerenciamento de operação e manutenção do servidor de jogo mais conveniente e eficiente.

Gerenciamento de cluster

Após a conclusão da preparação do cluster Kubernetes, usamos a frota ACK One para gerenciar uniformemente os clusters dentro e fora da nuvem:

Primeiro, registre o cluster de nuvem pública IDC ou de terceiros no Alibaba Cloud por meio do cluster de registro ACK One [ 1] , especificamente:

Crie um cluster de registro [ 2] e clique em Detalhes na coluna de operação no lado direito do cluster de registro criado .
Clique na guia Informações de conexão na página de informações do cluster .
Na área de configuração do agente de importação de cluster , selecione rede pública ou rede privada conforme necessário e clique em Copiar à direita para copiar o conteúdo da rede pública ou tag de rede privada para um arquivo e execute o comando kubectl para registrar o cluster de destino para o novo meio do cluster. Por exemplo, crie um novo arquivo agent.yaml, copie o conteúdo acima para o arquivo agent.yaml e execute o comando kubectl apply -f agent.yaml no cluster de destino.

Através desta etapa, o cluster do Japão foi registrado no Alibaba Cloud.

Em segundo lugar, abra a frota multi-cluster ACK One [ 3] e associe o cluster registrado ao cluster de nuvem no console ACK One [ 4] . Como o cluster abrange várias regiões, a frota ACK One usará a rede pública para se associar ao cluster, e a VPC onde a frota está localizada precisa ser configurada com um gateway NAT de rede pública.

Neste ponto, uma frota multicluster está pronta. O diagrama esquemático correspondente ao exemplo é o seguinte:

Lançamento do servidor de jogo

Antes de executar a operação de lançamento específica do exemplo, vamos conhecer a ideia de entrega nativa da nuvem - declarativa em vez de orientada a processos, o que significa que a entrega de aplicativos nativos da nuvem não se concentra no processo de implantação do aplicativo, mas na definição do aplicativo. A definição de um aplicativo é Yaml, que descreve a aparência do aplicativo por meio de parâmetros de configuração. Portanto, todas as alterações e lançamentos relacionados ao aplicativo são, na verdade, alterações na descrição do aplicativo (Yaml).

Até agora, descobrimos que precisamos de um warehouse para armazenar o Yaml, registrar a descrição atual do aplicativo e ser capazes de rastrear e auditar alterações anteriores do Yaml. Dito isso, acredito que todos descobrirão que o repositório git atende naturalmente a essa característica. Os engenheiros de operação e manutenção podem fazer upload e colocar o Yaml no disco enviando solicitações de gerenciamento de confirmação e mesclagem e auditando todas as especificações do git. Em um mundo ideal, precisamos apenas manter um conjunto de descrições YAML de servidores de jogos e acionar o lançamento de servidores de jogos em várias regiões ao redor do mundo com um clique. Não há necessidade de operar o cluster um por um para realizar a implantação. ações. Essa é a ideia do GitOps.

A coisa mais desafiadora no processo de implementação do GitOps é, na verdade, a descrição abstrata do aplicativo do servidor de jogo. Conforme mencionado no início do artigo, existem mais ou menos diferenças nos servidores de jogos em cada região e parece difícil resumir todos os servidores de jogos por meio de um Yaml. Por exemplo, em Xangai quero lançar 10 servidores regionais de jogos, mas em Frankfurt quero lançar apenas 3 servidores regionais. Desta forma, um Yaml não pode descrever servidores de jogos em regiões diferentes devido a diferenças no campo de réplicas. Precisamos manter um Yaml para cada região? Isso também não é razoável ao fazer alterações de campo não diferenciadas (por exemplo, rotular servidores de jogos em todas as regiões), precisamos realizar várias alterações no Yaml repetidamente. Quando o número de clusters é grande, é fácil causar omissões ou erros. Isso não está de acordo com a ideia de entrega nativa em nuvem.

Na verdade, podemos abstrair ainda mais o aplicativo do servidor de jogo por meio do Helm Chart e extrair as diferentes partes como Valor. Desta vez, em nosso exemplo (exemplo Helm Chart do servidor de jogos GitHub [ 5] ), abstraímos vários campos diferentes:

Imagem mestre - a imagem mestre de cada região/cluster pode ser diferente
Imagem lateral - a imagem lateral de cada região/cluster pode ser diferente
Número de cópias - o número de servidores de jogos lançados por região/cluster pode variar
Seja para escalonamento automático - cada região/cluster pode ter requisitos diferentes para escalonamento automático

Fora isso, outros campos permanecem consistentes, o que significa que não há diferenças regionais.

Depois de entender o GitOps e abstrair e descrever os aplicativos de servidor de jogos, usamos o ACK One GitOps para realizar a entrega prática de aplicativos. A seguir iniciamos as operações específicas:

Conecte-se ao repositório Git

Faça login na interface do ArgoCD: Vá para Fleet -> GitOps -> GitOps Console na barra de navegação esquerda do console ACK One e, na página de login, clique em LOG IN VIA ALIYUN para fazer login na interface do ArgoCD. Se precisar de acesso à rede pública, você precisará abrir uma rede pública para acessar o GitOps [ 6] .

Selecione Configurações na barra de navegação esquerda da IU do ArgoCD e selecione Repositórios > + Conectar Repo.
Configure as informações a seguir no painel pop-up e clique em CONNECT para adicionar uma conexão.

Publique jogos do tipo PvE

Os jogos PvE geralmente possuem o conceito de servidores regionais. Na maioria dos casos, os engenheiros de operação e manutenção controlam manualmente o número de servidores abertos em cada região. Para obter as melhores práticas de jogos PvE nativos da nuvem, consulte o documento de práticas recomendadas para jogos PvE da OKG [ 7] .

Aplicativo de gerenciamento de tela branca

Ao experimentar o ArgoCD pela primeira vez, podemos usar o console de tela branca para criar aplicativos para os clusters em cada região:

Selecione Aplicativos na barra de navegação esquerda da UI do ArgoCD e clique em + NOVO APP.
Configure as seguintes informações no painel pop-up e clique em CRIAR para criar. (Tome opengame-demo-shanghai-dev como exemplo).

Após a conclusão da criação, você poderá ver o status do aplicativo opengame-demo-shanghai-dev na página do aplicativo . Se a SYNC POLICY selecionar o modo Manual , será necessário clicar manualmente em SYNC para implementar de forma síncrona o aplicativo no cluster de destino. O status do aplicativo é Healthy e Synced , indicando que a sincronização foi bem-sucedida.

Clique no nome do aplicativo opengame-demo-shanghai-dev para visualizar os detalhes do aplicativo e exibir a topologia e o status correspondente dos recursos do Kubernetes relacionados ao aplicativo.

Publique com um clique através do ApplicationSet

Depois de nos familiarizarmos com o ArgoCD, também podemos usar o objeto ApplicationSet para publicar servidores de jogos com um clique. As diferenças de cada cluster são abstraídas por meio de elementos. Por exemplo, no Yaml abaixo, três campos são abstraídos da dimensão do cluster: o nome do cluster é usado para distinguir o nome do aplicativo; para distinguir jogos publicados por diferentes clusters.

Depois de escrever o ApplicationSet Yaml, implante-o no cluster da frota ACK One para criar automaticamente quatro aplicativos.

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

Neste Yaml, todas as versões de imagem são consistentes. Se desejar que as versões de imagem de cada cluster sejam diferentes, você pode adicionar novos parâmetros da mesma forma que as réplicas.

Publique jogos do tipo PvP

Para jogos do tipo PvP, o número de servidores de sala é alocado por seu próprio escalonador, em vez de especificado manualmente pelos engenheiros de operação e manutenção. Para conhecer as práticas recomendadas nativas da nuvem para jogos PvP, consulte o documento de práticas recomendadas para jogos PvP da OKG [ 8] .

No OKG, implementamos o escalonamento elástico de servidores de sala configurando o objeto ScaledObject para GameServerSet. Portanto, scaled.enabled precisa ser ativado neste cenário. Além disso, o número de cópias do servidor da sala entra em conflito com dois controladores, ArgoCD e OKG. Isso pode ser resolvido deixando o ArgoCD ignorar as alterações no número de cópias do recurso GameServerSet Especificamente, defina os campos correspondentes em spec.ignoreDifferences. Considerando o acima exposto, o pvp.yaml se parece com isto:

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 artigo usa um exemplo para apresentar as melhores práticas para entrega consistente de ACK One em múltiplas regiões em servidores de jogos globais. O exemplo envolve 4 clusters Kubernetes e um servidor de jogo simples Yaml. No ambiente de produção real, é provável que o número de clusters seja maior e a descrição do aplicativo do servidor de jogo seja mais complexa. Neste momento, a chave é abstrair bem o aplicativo.

Bem-vindo ao grupo DingTalk de jogos nativos da nuvem (número do grupo: 44862615) para se comunicar e discutir com desenvolvedores OpenKruiseGame e engenheiros de operação e pesquisa e desenvolvimento da indústria de jogos para questões relacionadas ao ACK One. Você também pode ingressar no grupo DingTalk (número do grupo: 35688562); para consulta.

Links Relacionados:

[1] Cluster de registro 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] Crie um cluster 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- implantado em um data center?spm=a2c4g.11186623.0.0.2f833eb6R1YTOq

[3] Iniciar frota multi-cluster 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 Um console

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

[5] Exemplo de Helm Chart do servidor de jogos GitHub

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

[6] Necessidade de abrir uma rede pública para acessar GitOps