ACK One x Лучшие практики OpenKruiseGame для последовательной доставки глобальных игровых серверов в несколько регионов

Команда китайского сообщества открытого исходного кода провела свою первую прямую трансляцию, рассказывая историю китайского сообщества открытого исходного кода во имя обмена».

Автор: Лю Цюян, Цай Цзин

Предисловие

В сегодняшней глобально интегрированной экономической среде индустрия цифровых развлечений все больше становится мощным представителем культурных и коммерческих обменов. В этом контексте большое количество производителей игр попытались вывести свои игры за границу и добились замечательных результатов. Многие игры привлекли широкий круг групп игроков по всему миру благодаря глобальной структуре серверов. Глобальное внедрение игр не только расширяет размер рынка отдельных продуктов, но и увеличивает глобальное влияние производителей игр, но в то же время порождает множество технических проблем:

Высокочастотное взаимодействие и низкая задержка, необходимые игровым сервисам, требуют развертывания игровых серверов в нескольких регионах в рамках глобальной серверной структуры. В реальных операциях нам обычно необходимо заранее планировать расположение сервера, исходя из географического положения целевой группы пользователей и допуска к задержкам. Вообще говоря, следующие области являются нашими приоритетными адресами серверов: восточная часть Соединенных Штатов густонаселена и может предоставлять услуги большому количеству игроков в Северной Америке. Область Франкфурта является пересечением европейского Интернета и может эффективно обслуживать сетевую среду; игроки по всей Европе; Сингапур. Регион широко охватывает базу игроков в Юго-Восточной Азии. Регион Токио в основном обеспечивает поддержку игроков из Японии и Южной Кореи;

Столкнувшись с возможными различиями в конфигурации, обновлениями версий игр и несоответствием количества серверов в разных регионах, вопрос о том, как эффективно добиться согласованной доставки игровых серверов в глобальном масштабе, стал основной проблемой, с которой мы должны столкнуться и решить при проектировании глобального сервера. архитектура. В этой статье на примере будут объяснены лучшие практики обеспечения межрегиональной согласованности глобальных игровых серверов.

Архитектура развертывания

В примере мы планируем открыть серверы в Шанхае, Токио и Франкфурте, поэтому нам нужны инфраструктурные ресурсы в этих трех регионах. Столкнувшись с гетерогенными и сложными инфраструктурными сценариями, декларативный API и согласованные функции доставки, реализованные в облачных средах, могут полностью скрыть различия в базовых ресурсах, позволяя инженерам по эксплуатации и обслуживанию игры сосредоточиться на самом приложении и значительно повысить эффективность доставки игрового сервера. . С точки зрения стабильности региональной автономии и сложности планирования пользователей мы считаем, что независимое развертывание кластеров Kubernetes в каждом серверном регионе и унифицированное управление эксплуатацией и обслуживанием с помощью возможностей нескольких кластеров — лучший способ обеспечить согласованность игровых серверов.

В этом примере мы выбрали распределенную облачную контейнерную платформу ACK One от Alibaba Cloud для управления многорегиональными кластерами Kubernetes. Являясь облачной платформой корпоративного класса Alibaba Cloud для гибридных облаков, мультикластеров, аварийного восстановления и других сценариев, ACK One может подключаться и управлять кластерами Kubernetes в любом регионе и в любой инфраструктуре, а также обеспечивает согласованное управление для поддержки приложений и трафика. , безопасность, хранение, наблюдаемость и т. д. находятся под единым контролем.

Архитектура развертывания этого примера показана на рисунке, включая 3 производственные среды в разных регионах и 1 среду разработки и тестирования. Вообще говоря, проверяя и подтверждая стабильность версии в тестовой среде исследований и разработок перед ее развертыванием в производственной среде, этот процесс помогает обеспечить общую стабильность проекта и эффективно предотвратить потенциальные риски.

В примере используется многокластерная гибридная облачная архитектура. В частности, кластер Шанхая, кластер Франкфурта и кластер ShangHai Dev являются кластерами Alibaba Cloud ACK, а кластер Японии — это кластер, не принадлежащий Alibaba Cloud Kubernetes, который интегрируется и управляется путем регистрации кластера. Внутри каждого кластера мы используем GameServerSet для развертывания игровых серверов. GameServerSet — это рабочая нагрузка для конкретной игры, предоставляемая OpenKruise, проектом с открытым исходным кодом, созданным Cloud Native Computing Foundation (CNCF). По сравнению с собственными рабочими нагрузками Deployment и StatefulSet, GameServerSet имеет игровую семантику и находится ближе к игровой сцене, что делает управление эксплуатацией и обслуживанием игрового сервера более удобным и эффективным.

Управление кластером

После завершения подготовки кластера Kubernetes мы используем парк ACK One для единообразного управления кластерами в облаке и за его пределами:

Сначала зарегистрируйте IDC или сторонний кластер общедоступного облака в Alibaba Cloud через регистрационный кластер ACK One [ 1] , а именно:

Создайте кластер регистрации [ 2] и нажмите «Подробнее» в столбце «Операция» в правой части созданного кластера регистрации .
Откройте вкладку «Информация о соединении» на странице информации о кластере .
В области конфигурации агента импорта кластера выберите общедоступную или частную сеть по мере необходимости , затем нажмите «Копировать» справа, чтобы скопировать содержимое тега общедоступной или частной сети в файл, и выполните команду kubectl, чтобы зарегистрировать целевой кластер в новый кластер средний. Например, создайте новый файл Agent.yaml, скопируйте указанное выше содержимое в файл Agent.yaml и выполните команду kubectl apply -f Agent.yaml в целевом кластере.

На этом этапе японский кластер был зарегистрирован в Alibaba Cloud.

Во-вторых, откройте мультикластерный парк ACK One [ 3] и свяжите зарегистрированный кластер с облачным кластером на консоли ACK One [ 4] . Поскольку кластер охватывает несколько регионов, группа ACK One будет использовать общедоступную сеть для связи с кластером, а VPC, в котором находится группа, необходимо настроить с помощью шлюза NAT общедоступной сети.

На данный момент мультикластерный флот готов. Принципиальная схема, соответствующая примеру, выглядит следующим образом:

Релиз игрового сервера

Прежде чем приступить к конкретной операции выпуска из примера, давайте познакомимся с идеей собственной доставки в облаке — скорее декларативной, чем ориентированной на процессы, что означает, что доставка собственных облачных приложений фокусируется не на процессе развертывания приложения, а на его определении. Определение приложения — это Yaml, который описывает, как приложение должно выглядеть с помощью параметров конфигурации. Поэтому все изменения и релизы, связанные с приложением, на самом деле являются изменениями описания приложения (Yaml).

На данный момент мы обнаружили, что нам нужно хранилище для хранения Yaml, записи текущего описания приложения и возможности отслеживать и проверять прошлые изменения Yaml. Сказав это, я считаю, что каждый обнаружит, что git repo естественным образом соответствует этой характеристике. Инженеры по эксплуатации и техническому обслуживанию могут загружать и помещать Yaml на диск, отправляя управление разрешениями на фиксацию и слияние и проверяя все требования git. В идеальном мире нам нужно только поддерживать набор YAML-описаний игровых серверов и запускать выпуск игровых серверов в нескольких регионах по всему миру одним щелчком мыши. Нет необходимости управлять кластером один за другим для выполнения развертывания. действия. В этом идея GitOps.

Самое сложное в процессе реализации GitOps — это абстрактное описание приложения игрового сервера. Как уже говорилось в начале статьи, игровые серверы в каждом регионе имеют более или менее различия, и обобщить все игровые серверы через один Yaml кажется затруднительным. Например, в Шанхае я хочу выпустить 10 игровых региональных серверов, а во Франкфурте — только 3 региональных сервера. Таким образом, Yaml не может описывать игровые серверы в разных регионах из-за различий в поле реплик. Нужно ли нам поддерживать Yaml для каждого региона? Это также неразумно. При внесении недифференцированных изменений полей (например, маркировке игровых серверов во всех регионах) нам необходимо многократно выполнять несколько изменений Yaml. Когда количество кластеров велико, легко вызвать пропуски или ошибки. Это не соответствует идее нативной облачной доставки.

Фактически, мы можем дополнительно абстрагировать приложение игрового сервера с помощью Helm Chart и извлекать различные части как значения. В нашем примере на этот раз (пример Helm Chart игрового сервера GitHub [ 5] ) мы абстрагировали несколько разных полей:

Мастер-образ — мастер-образ каждого региона/кластера может быть разным.
Сопутствующее изображение — дополнительное изображение каждого региона/кластера может быть разным.
Количество копий - количество выпущенных игровых серверов в каждом регионе/кластере может различаться.
Использовать ли автоматическое масштабирование — в каждом регионе/кластере могут быть разные требования к автоматическому масштабированию.

Помимо этого, другие поля остаются неизменными, то есть региональных различий нет.

После понимания GitOps, абстрагирования и описания приложений игрового сервера мы использовали ACK One GitOps для практической доставки приложений. Далее приступаем к конкретным операциям:

Подключиться к репозиторию Git

Войдите в пользовательский интерфейс ArgoCD: перейдите в Fleet -> GitOps -> Консоль GitOps в левой панели навигации консоли ACK One и на странице входа нажмите ВОЙТИ ЧЕРЕЗ ALIYUN, чтобы войти в пользовательский интерфейс ArgoCD. Если вам нужен доступ к общедоступной сети, вам необходимо открыть общедоступную сеть для доступа к GitOps [ 6] .

Выберите «Настройки» на левой панели навигации пользовательского интерфейса ArgoCD, затем выберите «Репозитории» > «+ Подключить репо».
Настройте следующую информацию во всплывающей панели, а затем нажмите ПОДКЛЮЧИТЬСЯ, чтобы добавить соединение.

Публикация игр типа PvE

В PvE-играх обычно используется концепция региональных серверов. В большинстве случаев инженеры по эксплуатации и техническому обслуживанию вручную контролируют количество серверов, открытых в каждом регионе. Рекомендации по использованию облачных PvE-игр можно найти в документе OKG по лучшим практикам PvE-игр [ 7] .

Приложение для управления белым экраном

При первом запуске ArgoCD мы можем использовать консоль с белым экраном для создания приложений для кластеров в каждом регионе:

Выберите «Приложения» на левой панели навигации пользовательского интерфейса ArgoCD , а затем нажмите «+ НОВОЕ ПРИЛОЖЕНИЕ».
Настройте следующую информацию во всплывающей панели, а затем нажмите СОЗДАТЬ, чтобы создать. (В качестве примера возьмите opengame-demo-shanghai-dev).

После завершения создания вы можете увидеть статус приложения opengame-demo-shanghai-dev на странице приложения . Если в ПОЛИТИКЕ СИНХРОНИЗАЦИИ выбран ручной режим, вам необходимо вручную нажать СИНХРОНИЗАЦИЯ, чтобы синхронно развернуть приложение в целевом кластере. Статус приложения — «Исправно» и «Синхронизировано» , что указывает на то, что синхронизация прошла успешно.

Щелкните имя приложения opengame-demo-shanghai-dev, чтобы просмотреть сведения о приложении и отобразить топологию и соответствующий статус ресурсов Kubernetes, связанных с приложением.

Публикуйте одним щелчком мыши через ApplicationSet.

Познакомившись с ArgoCD, мы также можем использовать объект ApplicationSet для публикации игровых серверов одним щелчком мыши. Различия каждого кластера абстрагируются через элементы. Например, в приведенном ниже Yaml три поля абстрагируются от измерения кластера: имя кластера используется для различения имени приложения; URL-адрес используется для различения адреса целевого кластера; различать игры, выпущенные разными кластерами. Количество порций.

После написания Yaml ApplicationSet разверните его в кластере парка ACK One, чтобы автоматически создать четыре приложения.

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

В этом Yaml все версии образов согласованы. Если вы хотите, чтобы версии образов каждого кластера были разными, вы можете добавлять новые параметры так же, как и реплики.

Публикация игр типа PvP

Для игр типа PvP количество серверов комнат выделяется собственным масштабатором, а не задается вручную инженерами по эксплуатации и техническому обслуживанию. Рекомендации по использованию облачных технологий для PvP-игр см. в документе OKG «Рекомендации по использованию PvP-игр» [ 8] .

В OKG мы реализуем эластичное масштабирование серверов комнат, настроив объект ScaledObject для GameServerSet. Поэтому в этом сценарии необходимо включить Scaled.enabled. Кроме того, количество копий рум-сервера конфликтует с двумя контроллерами, ArgoCD и OKG. Это можно решить, разрешив ArgoCD игнорировать изменения количества копий ресурса GameServerSet. В частности, установите соответствующие поля в spec.ignoreDifferences. Учитывая вышесказанное, pvp.yaml выглядит следующим образом:

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

Подведем итог

В этой статье на примере представлены рекомендации по последовательной доставке ACK One в несколько регионов на глобальных игровых серверах. В примере задействованы 4 кластера Kubernetes и простой игровой сервер Yaml. В реальной производственной среде количество кластеров, вероятно, будет больше, а описание приложения игрового сервера будет более сложным. На данный момент ключевым моментом является хорошее абстрагирование приложения.

Добро пожаловать в группу DingTalk для облачных игр (номер группы: 44862615), чтобы общаться и обсуждать с разработчиками OpenKruiseGame, а также инженерами по исследованиям и разработкам игровой индустрии; по вопросам, связанным с ACK One, вы также можете присоединиться к группе DingTalk (номер группы: 35688562). для консультации.

Ссылки по теме:

[1] ACK Один регистрационный кластер

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

[2] Создайте регистрационный кластер

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/create-a-cluster-registration-proxy-and-register-a-kubernetes-cluster- развернуто-в-центре обработки данных?spm=a2c4g.11186623.0.0.2f833eb6R1YTOq

[3] Запуск мультикластерного парка 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 Одна консоль

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

[5] Пример диаграммы Helm игрового сервера GitHub

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

[6] Необходимо открыть общедоступную сеть для доступа к GitOps.