在 Kubernetes Engine 中執行專用遊戲伺服器

將伺服器應用程式包裝為容器映像檔的做法正快速襲捲整個科技領域。許多遊戲公司也有興趣使用容器來提高 VM 使用率,以及利用容器所提供的隔離執行階段範例。許多遊戲公司雖然興趣濃厚,但不知要從哪開始。我們建議使用容器自動化調度管理架構 Kubernetes 來部署實際運作規模的專用遊戲伺服器。

本教學課程說明一個在 Google Kubernetes Engine 上執行即時工作階段型多人對戰遊戲專用遊戲伺服器的可擴充架構。資源調度管理員程序會視需要自動啟動和停止虛擬機器執行個體。代管執行個體群組會自動將機器設定為 Kubernetes 節點。

本教學課程介紹一個簡單的線上遊戲結構,以便您瞭解和實作;我們會指出為了讓內容變得實用而增加複雜度的地方。

目標

  • 建立 OpenArena 的容器映像檔。OpenArena 是在 Linux 上使用 Docker 的熱門開放原始碼專用遊戲伺服器 (DGS)。這個容器映像檔只會在基本 Linux 映像檔中新增二進位檔和必要的程式庫。
  • 請將資產儲存在單獨的唯讀永久磁碟區,並在執行階段於容器中掛接這些資產。
  • 使用 Kubernetes 及 Google Cloud Platform API 設定和配置基本排程器程序,配合需求增加或減少節點數量。

費用

本教學課程使用下列 Google Cloud Platform 計費元件:

您可以使用 pricing calculator,根據您的專案用量產生預估費用。

事前準備

本教學課程必須從 Linux 或 macOS 環境中執行。

  1. 選取或建立 Google Cloud Platform 專案。

    前往「Manage resources」(管理資源) 頁面

  2. 請確認您已啟用 Google Cloud Platform 專案的計費功能。

    瞭解如何啟用計費功能

  3. 啟用Compute Engine API。

    啟用 API

  4. 安裝並初始化 Cloud SDK

    注意:在本教學課程中,您無法使用 Cloud Shell。您必須安裝 Cloud SDK。

  5. 安裝 kubectl,這是 Kubernetes 的指令列介面
    gcloud components install kubectl
  6. 從 GitHub 複製本教學課程的存放區:
    git clone https://github.com/GoogleCloudPlatform/gke-dedicated-game-server.git
    
  7. 安裝 Docker

    本教學課程不會以 root 使用者身分執行 Docker 指令,因此請務必遵循以非 root 使用者身分管理 Docker 的安裝後操作說明
  8. (選用) 在本教學課程結束時,如果您想要測試連至遊戲伺服器的連線,請安裝 OpenArena 遊戲用戶端。執行遊戲用戶端需要桌面環境。本教學課程提供使用 Linux 或 macOS 執行測試的操作說明。

架構

遊戲總覽解決方案

雲端遊戲基礎架構總覽頁面說明許多線上遊戲架構都會使用的高階元件。在本教學課程中,您將實作 Kubernetes DGS 叢集前端服務及資源調度管理員後端服務。完整的正式遊戲基礎架構還會包含許多其他前端和後端服務,但都不在本教學課程的範圍內。

本教學課程的設計限制

為了提供既有指導性又易於擴充的簡單範例,本教學課程假設了下列遊戲限制:

  • 這是一款即時對戰遊戲,具有會模擬遊戲狀態的權威 DGS。
  • DGS 會透過 UDP 與用戶端通訊。
  • 每個 DGS 程序會執行 1 場對戰。
  • 所有 DGS 程序會產生大致相同的負載。
  • 對戰有時間長度上限。
  • DGS 啟動時間可以忽略不計,且不需要專用遊戲伺服器暖機程序。
  • 在尖峰後縮減資源時,不會因為要節省費用而提早結束對戰,以避免影響玩家體驗為優先考量。
  • 如果 DGS 程序發生錯誤且無法繼續,則會遺失對戰狀態。玩家必須使用遊戲用戶端加入另一場對戰。
  • DGS 程序會從磁碟載入靜態資產,但不需要資產的寫入權限。

這些限制都是遊戲界的慣例,且代表了真實世界的使用情況。

準備您的 GCP 工作環境

如要更簡便地執行 gcloud 指令,您可以設定屬性,這樣就不需要在每個指令中提供這些屬性的選項。

  1. 設定預設專案,請在 [PROJECT_ID] 使用您的專案 ID:

    gcloud config set project [PROJECT_ID]
  2. 設定預設的 Compute Engine 區域,請在 [ZONE] 使用您偏好的區域:

    gcloud config set compute/zone [ZONE]

容器化專用遊戲伺服器

在本教學課程中,您將使用「社群根據 GPL idTech3 技術建構的死亡競賽 FPS」OpenArena。雖然這個遊戲的技術已有 15 年以上歷史,但仍是常見的 DGS 模式的良好範例:

  • 伺服器二進位檔的程式碼集與遊戲用戶端相同。
  • 伺服器二進位檔只包含伺服器執行模擬所需的資料資產。
  • 遊戲伺服器容器映像檔只會將執行伺服器程序所需的二進位檔和程式庫加入基本 OS 容器映像檔。
  • 資產是從另外一個磁碟區掛接。

這個架構有很多好處:加速映像檔發佈、降低更新負載 (因為只會取代二進位檔),且使用較少磁碟空間。

建立容器映像檔

Dockerfile 說明要建構的映像檔。本教學課程的 Dockerfile 位於 openarena/Dockerfile 的存放區。請在 openarena/ 目錄中執行 Docker 建構指令以產生容器映像檔,並將其標記為 OpenArena 伺服器的 0.8.8 版:

docker build -t openarena:0.8.8 .

產生資產磁碟

在大部分的遊戲中,二進位檔比資產小好幾個數量級。因此,建立只含有二進位檔的容器很合理。資產可以放在永久磁碟中,再連結到執行 DGS 容器的多個 VM 執行個體。這個架構不但省錢,而且還不需要將資產分配到所有 VM 執行個體。

  1. 使用 gcloud 建立小型 Compute Engine VM 執行個體:

    gcloud compute instances create openarena-asset-builder \
        --machine-type f1-micro --image-family debian-9 \
        --image-project debian-cloud
  2. 建立永久磁碟:

    gcloud compute disks create openarena-assets --size=50GB \
        --type=pd-ssd --description="OpenArena data disk. \
        Mount read-only at /usr/share/games/openarena/baseoa/"

    永久磁碟必須與開機磁碟分開,且您必須將永久磁碟設為在移除虛擬機器時不會刪除磁碟。Kubernetes 的 persistentVolume 功能在 GKE 中設定永久磁碟的效果最好。根據 Compute Engine,這些永久磁碟應由不含分區資料表的單一 ext4 檔案系統組成。

  3. openarena-assets 永久磁碟連結到 openarena-asset-builder VM 執行個體:

    gcloud compute instances attach-disk openarena-asset-builder \
        --disk openarena-assets
  4. 格式化新磁碟。

    1. 登入 openarena-asset-builder VM 執行個體並格式化磁碟。

      gcloud compute ssh openarena-asset-builder
    2. 因為下個步驟中的 mkfs.ext4 指令是一種破壞性指令,所以請務必確認 openarena-assets 磁碟的裝置 ID。如果您是從頭開始遵循本教學課程,且您使用的是新專案,則 ID 是 /dev/sdb。請使用 lsblk 指令查看連結的磁碟及其分區來進行確認:

      sudo lsblk

      輸出內容應顯示含 1 個分區 sda1 的 10 GB OS 磁碟 sda,以及不含任何分區的 50 GB openarena-assets 磁碟做為 sdb 裝置:

      NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
      sda 8:0 0 10G 0 disk
      └─sda1 8:1 0 10G 0 part /
      sdb 8:16 0 50G 0 disk
    3. 格式化 openarena-assets 磁碟:

      sudo mkfs.ext4 -m 0 -F -E \
          lazy_itable_init=0,lazy_journal_init=0,discard /dev/[DEVICE_ID]
  5. openarena-asset-builder VM 執行個體上安裝 OpenArena,並將壓縮的資產封存檔複製到 openarena-assets 永久磁碟。

    在這個遊戲中,資產是位於 /usr/share/games/openarena/baseoa/ 目錄中的 .pk3 檔案。為了節省一些工作,下列指令串會在安裝前將資產磁碟掛接到這個目錄,這樣安裝程序就會將所有 .pk3 檔案都放在磁碟上。請務必使用您之前確認過的裝置 ID。

    sudo mkdir -p /usr/share/games/openarena/baseoa/
    
    sudo mount -o discard,defaults /dev/[DEVICE_ID] \
        /usr/share/games/openarena/baseoa/
    
    sudo apt-get update && sudo apt-get -y install openarena-server
  6. 退出執行個體並將其刪除:

    exit
    gcloud compute instances delete openarena-asset-builder

    磁碟已準備好做為 Kubernetes 中的永久磁碟區。

在遊戲開發管道中實作永久磁碟時,請設定建構系統以建立永久磁碟,其中所有資產檔案都位在適當的目錄結構中。這可能會採用執行 gcloud 指令的簡單指令碼形式,或您選擇的建構系統所適用的 GCP 專用外掛程式。另外也建議您建立多份永久磁碟複本,並讓 VM 執行個體平均地連結至這些複本,以取得額外的總處理量及管理故障風險。

設定 Kubernetes 叢集

Kubernetes 是一種開放原始碼社群專案,因此可以設定為在大部分環境中執行,包括內部部署環境。

在 Kubernetes Engine 上建立 Kubernetes 叢集

本教學課程使用配備了 n1-highcpu 機器類型的標準 Kubernetes Engine 叢集,該機器類型符合 OpenArena 的使用設定檔。

  1. 為名為 game 的遊戲建立一個虛擬私人雲端網路:

    gcloud compute networks create game
  2. 為 OpenArena 建立防火牆規則:

    gcloud compute firewall-rules create openarena-dgs --network game \
        --allow udp:27961-28061
  3. 使用 gcloud 建立含有 3 個節點的叢集,每個節點上各有 4 個虛擬 CPU 核心。節點將使用您的 game 網路:

    gcloud container clusters create openarena-cluster \
        --network game --num-nodes 3 --machine-type n1-highcpu-4 \
        --addons KubernetesDashboard
  4. 叢集啟動後,請使用適當的 Kubernetes 驗證憑證設定本機殼層以控制新叢集:

    gcloud container clusters get-credentials openarena-cluster

在正式叢集中,每台機器上執行的 vCPU 數量主要取決於兩個因素:

  • 您預計要執行的並行 DGS Pod 數量上限。 系統已設定 Kubernetes 叢集集區可包含的節點數上限 (雖然 Kubernetes 專案計劃在未來的版本中增加此數量)。例如,如果每個虛擬 CPU (vCPU) 執行 1 個 DGS,則 n1-highcpu-2 機器中由 1000 個節點組成的叢集只能提供 2000 個 DGS Pod 的容量。相較之下,n1-highcpu-32 機器中 1000 個節點組成的叢集最多可提供 32,000 個 Pod 的容量。

  • 您的 VM 執行個體精細程度。 在叢集中新增或移除資源最簡單的方式,是在叢集建立期間增加所選類型的單一 VM 執行個體。因此,如果您想要一次新增或移除小量容量 (小於 32 個 vCPU),請勿選擇 32 vCPU 機器。

GKE 預設使用的代管執行個體群組功能,包含 VM 執行個體自動調度資源和 HTTP 負載平衡功能。但您用來建立 Kubernetes 叢集的指令會透過 --disable-addons HttpLoadBalancing,HorizontalPodAutoscaling 標記停用這些功能。

HTTP 負載平衡不是必要功能,因為 DGS 使用 UDP 而非 TCP 來與用戶端通訊。自動配置器目前只能依據 CPU 使用量來調度執行個體群組的資源,但 CPU 使用量可能是 DGS 負載的誤導指標。許多 DGS 設計成消耗閒置週期,以努力最佳化遊戲模擬。

因此,許多遊戲開發人員會實作 DGS 感知的自訂資源調度管理員程序,以處理這類型工作負載的特定需求。代管執行個體群組還是會提供重要功能,其預設的 GKE 映像檔範本含有所有必要的 Kubernetes 軟體,且會在啟動時在主要執行個體自動註冊節點。

將容器映像檔上傳至 GCP

Google 在 Container Registry (gcr.io) 中提供私人 Docker 映像檔儲存空間。

  1. 選擇離您的 GKE 叢集最近的 gcr.io 地區 (例如 us 代表美國、eu 代表歐洲、asia 代表亞洲,如說明文件所述),然後將地區資訊和您的專案 ID 一起放入環境變數:

    export GCR_REGION=[GCR_REGION] PROJECT_ID=[PROJECT_ID]
  2. 將 gcr.io 註冊資料庫名稱標記到容器映像檔:

    docker tag openarena:0.8.8 \
        ${GCR_REGION}.gcr.io/${PROJECT_ID}/openarena:0.8.8
  3. 將容器映像檔上傳至映像檔存放區:

    gcloud docker -- push \
        ${GCR_REGION}.gcr.io/${PROJECT_ID}/openarena:0.8.8

推送完成後,容器映像檔即可在您的 GKE 叢集中執行。請記下最終的容器映像檔標記,因為您稍後必須在 Pod 規格檔案中放入該標記。

在 Kubernetes 中設定資產磁碟

一般 DGS 不需要遊戲資產的寫入權限,所以您可以讓每一個 DGS Pod 掛接含有唯讀資產的同一個永久磁碟。您可以在 Kubernetes 中使用 persistentVolumepersistentVolumeClaim 資源完成此工作。

  1. 套用 asset-volume.yaml,其中含有 Kubernetes persistentVolume 資源的定義,該資源將繫結至您之前建立的資產磁碟:

    kubectl apply -f openarena/k8s/asset-volume.yaml
  2. 套用 asset-volumeclaim.yaml,其中含有 Kubernetes persistentVolumeClaim 資源的定義,該資源將允許 Pod 掛接資產磁碟:

    kubectl apply -f openarena/k8s/asset-volumeclaim.yaml

    執行下列指令,確認磁碟區處於 Bound 狀態:

    kubectl get persistentVolume

    預期輸出:

    NAME           CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                      STORAGECLASS   REASON    AGE
    asset.volume   50Gi       ROX           Retain          Bound     default/asset.disk.claim   assets                   3m

    同樣地,請確認請求處於繫結狀態:

    kubectl get persistentVolumeClaim

    預期輸出:

    NAME               STATUS    VOLUME         CAPACITY   ACCESSMODES   STORAGECLASS   AGE
    asset.disk.claim   Bound     asset.volume   50Gi       ROX           assets         25s

設定 DGS Pod

因為排程和網路工作是由 Kubernetes 處理,且 DGS 容器的啟動和關機時間可以忽略,所以在本教學課程中,DGS 執行個體會依照需求增加。

每個 DGS 執行個體只能支援一場遊戲對戰,且 OpenArena DGS 伺服器設定檔案指定了遊戲對戰的時間限制。對戰完成時,容器即會成功結束。如果玩家想要再玩一次,則需要求進行另一場對戰。這樣的設計簡化了 Pod 生命週期的許多部分,並形成自動調度資源政策的基礎。稍後我們將在資源調度管理員一節提供相關說明。

雖然這個流程在 OpenArena 中並不完美,這只是因為本教學沒有 fork,也沒有變更遊戲用戶端程式碼。在商業發行的遊戲中,系統會將另一場對戰的要求隱藏在前一場對戰結果畫面和載入時間後面,讓使用者看不到。要求用戶端在兩次對戰間連結至新伺服器執行個體的程式碼不需要額外的開發時間,因為在處理用戶端重新連線以解決網路問題或伺服器當機等意外狀況時,還是需要使用該程式碼。

為了簡單起見,本教學課程假設 GKE 節點有預設網路配置,會為每個節點指派一個公開 IP 位址並允許用戶端連線。

管理專用遊戲伺服器程序

在商業製造的遊戲伺服器中,所有可以讓 DGS 在容器中順利執行的其他非 DGS 功能,都應盡可能地直接整合至 DGS 二進位檔案。

最佳做法是 DGS 應避免與遊戲配對者或資源調度管理員直接通訊,而應在 Kubernetes API 中公佈其狀態。外部程序應從適當的 Kubernetes 端點讀取 DGS 狀態,而非直接查詢伺服器。如要進一步瞭解直接存取 Kubernetes API,請參閱 Kubernetes 說明文件。

乍看之下,在容器中執行,生命週期有限並有成功標準的單一程序似乎可以使用 Kubernetes 工作,但實際上您不需要使用工作。DGS 程序不需要工作的平行執行功能,這些工作也不需要透過自動重新啟動來保證成功 (通常,當工作階段型的 DGS 因某些原因而失效時,狀態會遺失,玩家只需加入另一個 DGS 即可)。基於這些因素,我們建議在這個使用案例中為各個 Kubernetes Pod 排程。

在實際工作環境中,DGS Pod 應由遊戲配對者透過 Kubernetes API 直接啟動。為達到本教學課程的目的,教學課程存放區提供使用者能理解的 YAML 檔案 openarena/k8s/openarena-pod.yaml,說明 DGS Pod 資源。建立專用遊戲伺服器 Pod 的設定時,請密切注意磁碟區屬性,確保可以在多個 Pod 中以唯讀狀態掛接資產磁碟。

設定資源調度管理員

資源調度管理員是一種簡單的程序,可依據目前的 DGS 負載,調整做為 GKE 節點的虛擬機器數量。您可以使用一組持續執行的指令碼來完成資源調度,這些指令碼會檢查執行中和要求的 DGS Pod 總數,並視需要調整節點集區。指令碼會包裝在含有適當程式庫和 Cloud SDK 的 Docker 容器映像檔中。您可以使用下列程序建立 Docker 映像檔並推送到 gcr.io。

  1. 如果必要,請將 gcr.io GCR_REGION 值和您的 PROJECT_ID 加入建構和推送指令碼中的環境變數。如果您之前在上傳容器映像檔已執行過這項作業,則可略過此步驟。

    export REGION=[GCR_REGION] PROJECT_ID=[PROJECT_ID]
  2. 切換至指令碼目錄:

    cd scaling-manager
  3. 執行建構指令碼以建構所有容器映像檔,並將映像檔推送至 gcr.io:

    ./build-and-push.sh
  4. 使用文字編輯器,在 scaling-manager/k8s/openarena-scaling-manager-deployment.yaml 開啟 Kubernetes 部署檔案。

    資源調度管理員指令碼設計成可以在 Kubernetes 部署中執行,確保發生故障時,這些程序可以重新啟動。

  5. 將環境變數變更為部署的值,如下表所示:

    環境變數 預設值 附註
    REGION [GCR_REGION] 需要變更。 gcr.io 存放區的地區。
    PROJECT_ID [PROJECT_ID] 需要變更。 專案的名稱。
    GKE_BASE_INSTANCE_NAME gke-openarena-cluster-default-pool-[REPLACE_ME] 需要變更。 每個 GKE 叢集的值都不同。若要取得 [REPLACE_ME] 的值,請執行 gcloud compute instance-groups managed list 指令。
    GCP_ZONE [ZONE] 需要變更。 您在本教學課程開始時指定的 GCP 區域名稱。
    K8S_CLUSTER openarena-cluster Kubernetes 叢集名稱。
  6. 回到父項目錄:

    cd ..
  7. 新增部署至 Kubernetes 叢集:

    kubectl apply \
        -f scaling-manager/k8s/openarena-scaling-manager-deployment.yaml

如何調度節點資源

若要調度節點資源,資源調度管理員會使用 Kubernetes API 來查看目前的節點使用情況。必要時,管理員會調整執行基礎虛擬機器的 Kubernetes Engine 叢集的代管執行個體群組大小。

DGS Pod 的資源調度問題

DGS 資源調度的常見問題包括:

  • 標準 CPU 和記憶體使用量指標通常無法擷取到足夠的資訊來推動遊戲伺服器執行個體資源調度。
  • 保持可用且未充份利用節點這樣的緩衝非常重要,因為在現有節點上排程最佳化的 DGS 容器只需要幾秒鐘的時間。但新增節點可能需要幾分鐘的時間,這樣的延遲對等待中的玩家而言是無法接受的。
  • 許多自動配置器無法正常處理 Pod 關閉。請務必從要移除的節點中清空 Pod。即使節點上只有一場對戰正在執行,關閉這個節點通常也是無法接受的。

雖然本教學課程提供的指令碼很基本,但因為設計簡單,所以可以輕鬆新增其他邏輯。典型的 DGS 具有易於理解的效能特性,將這些特性轉換成指標,就可以決定何時要新增或移除 VM 執行個體。常見的資源調度指標有每個 CPU 的 DGS 執行個體數 (本教學課程使用此指標),或可用的玩家運算單元數。

擴充

在本教學課程中,擴充不需要任何特殊處理。為了簡單說明,本教學課程會在 Pod 的 YAML 檔案 (openarena/k8s/openarena-pod.yaml) 中設定 limitsrequests Pod 資源,為每個 DGS 保留約 1 個 vCPU,這對 OpenArena 而言已經足夠。

因為叢集是使用 n1-highcpu 執行個體系列建立,這些執行個體具有 600 MB 記憶體對 1 個 vCPU 的固定比率,因此如果每個 vCPU 安排 1 個 DGS Pod,則記憶體應已足夠。因此,您可以將叢集中 Pod 數量與叢集中所有節點的 CPU 數量進行比較,依據比較結果進行資源擴充。這個比率決定了剩餘的可用資源,讓您可以在值低於門檻時新增更多節點。本教學課程會在目前配置給 Pod 的 vCPU 超過 70% 時新增節點。

我們建議您在正式版線上遊戲後端中精確剖析 DGS CPU、記憶體和網路使用量,然後設定適當的 limitsrequests Pod 屬性。對許多遊戲而言,針對使用設定檔不同 (例如遊戲類型、特定地圖或玩家運算單元數量) 的各種 DGS 情境建立多種 Pod 類型很重要。這類注意事項不在本教學課程的討論範圍內。

縮減

不同於擴充,縮減程序有多個步驟,其中一個主要原因是要執行自訂的 Kubernetes 感知 DGS 資源調度管理員。在本教學課程中,scaling-manger.sh 會自動處理下列步驟:

  1. 選取適當節點進行移除。因為完全自訂的遊戲感知 Kubernetes 排程器不在本教學課程的討論範圍內,請按照 API 的回傳順序選取節點。

  2. 在 Kubernetes 中將選取的節點標示為無法使用。這樣可避免在節點上啟動額外的 Pod。

  3. 使用 abandon-instance 指令,從代管執行個體群組中移除選取的節點。這樣可防止代管執行個體群組嘗試重建執行個體。

另外,node-stopper.sh 指令碼會監控已捨棄且未排程的節點是否缺少 DGS Pod。當節點上的所有對戰均已完成且 Pod 結束後,指令碼會關閉 VM 執行個體。

調整 DGS Pod 數量

在一般的正式版遊戲後端中,遊戲配對者可控制何時新增 DGS 執行個體。因為 DGS Pod 設定為在對戰完成時結束 (請參閱之前的設計限制),所以不需要採取任何明確動作來縮減 DGS Pod 的數量。如果送到遊戲配對者系統的玩家要求數不足以產生新對戰,則 DGS Pod 會在對戰完成時慢慢地從 Kubernetes 叢集中自行移除。

測試設定

到目前為止,您已建立 OpenArena 容器映像檔,並將映像檔推送到 Container Registry,且已啟動 DGS Kubernetes 叢集。此外,您還產生了遊戲資產磁碟、將該磁碟設定用於 Kubernetes,並啟動了資源調度管理員部署。是時候啟動 DGS Pod 來進行測試。

要求新的 DGS 執行個體

在一般的實際運作系統中,當遊戲配對者程序有適當的對戰玩家時,會使用 Kubernetes API 直接要求執行個體。為了測試本教學課程的設定,您可以直接向執行個體發出要求。

  1. 在文字編輯器中開啟 openarena/k8s/openarena-pod.yaml,然後找出指定了要執行的容器映像檔的指令列。

  2. 執行 docker tag 指令,變更值以配合您的 openarena 容器映像檔標記,如本教學課程稍早所述

  3. 執行 kubectl apply 指令,指定 openarena-pod.yaml 檔案:

    kubectl apply -f openarena/k8s/openarena-pod.yaml
  4. 等一下,然後確認 Pod 的狀態:

    kubectl get pods

    輸出內容看起來應該像這樣:

    NAME             READY     STATUS    RESTARTS   AGE
    openarena.dgs    1/1       Running   0          25s

連結至 DGS

啟動 Pod 之後,您可以驗證是否能透過啟動 OpenArena 用戶端連結至 DGS。

從 macOS 或 Linux 桌面:

export NODE_NAME=$(kubectl get pod openarena.dgs \
    -o jsonpath="{.spec.nodeName}")
export DGS_IP=$(gcloud compute instances list \
    --filter="name=( ${NODE_NAME} )" \
    --format='table[no-heading](EXTERNAL_IP)')
openarena +connect ${DGS_IP}

測試資源調度管理員

資源調度管理員會依據 DGS Pod 的數量,調整 Kubernetes 叢集中的 VM 執行個體數。因此,測試資源調度管理員需要在一段時間內要求一些 Pod,並檢查節點數量是否適當調整。如要看到節點數縮減回去,伺服器設定檔案中的對戰長度必須有時間限制。位於 openarena/single-match.cfg 的教學課程伺服器設定檔將對戰時間限制設為 5 分鐘。本教學課程 DGS Pod 預設為使用此設定檔。若要進行測試,請執行下列指令碼,以每 5 分鐘的固定間隔新增 DGS Pod:

./scaling-manager/tests/test-loader.sh

您可以固定的間隔執行 kubectl get nodes 觀察節點數的增加和減少狀況。

清除所用資源

如何避免系統向您的 Google Cloud Platform 帳戶收取在本教學課程中使用資源的相關費用:

刪除專案

如要避免付費,最簡單的方法就是刪除您為了本教學課程所建立的專案。

如要刪除專案,請執行以下操作:

  1. 前往 GCP 主控台的「Projects」(專案) 頁面。

    前往「Projects」(專案) 頁面

  2. 在專案清單中,找到您要刪除的專案並按一下「刪除」圖示 delete
  3. 在對話方塊中輸入專案 ID,按一下 [Shut down] (關閉) 即可刪除專案。

刪除 GKE 叢集

如果您不想刪除整個專案,請執行下列指令以刪除 GKE 叢集:

gcloud container clusters delete openarena-cluster

刪除永久磁碟

如何刪除永久磁碟:

  1. 在 GCP 主控台中,前往「Compute Engine Disks」(Compute Engine 磁碟) 頁面。

    前往「Compute Engine Disks」(Compute Engine 磁碟) 頁面

  2. 選取您要刪除的磁碟。

  3. 點選頁面頂端的 [Delete] (刪除) 按鈕。

後續步驟

本教學課程所述的基本架構可用來在容器中執行專用遊戲伺服器,並依據遊戲負載自動調度 Kubernetes 叢集資源。您可以透過程式編寫一些基本的用戶端支援來新增許多功能,例如將玩家從某工作階段完美移轉到另一工作階段。若要新增其他功能 (例如,允許玩家組隊以及將團隊從某伺服器移至另一伺服器),您可以建立個別的平台服務,與遊戲配對服務一起提供。然後,您可以使用此服務來組隊;傳送、接受或拒絕組隊邀請;以及將玩家團隊一起傳送至專用遊戲伺服器執行個體。

另一個常見功能是自訂 Kubernetes 排程器,能夠以更聰明且以遊戲為中心的方式選擇 DGS Pod 的節點。大部分的遊戲都非常需要將 Pod 封裝在一起的自訂排程器,讓您輕鬆設定尖峰後縮減資源時應移除的節點優先順序。

更多在 GCP 上執行 DGS 的指南:

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
解決方案