探索使用Kubernetes扩展专用游戏服务器：第2部分-管理CPU和内存

最新推荐文章于 2025-11-04 16:24:34 发布

转载最新推荐文章于 2025-11-04 16:24:34 发布 · 365 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：https://cloud.tencent.com/developer/article/1829110?from=article.detail.1829109

文章标签：

#kubernetes #游戏 #服务器

运维人生同时被 2 个专栏收录

290 篇文章

订阅专栏

容器技术

56 篇文章

订阅专栏

原创科普整理

油管视频：GCAP 2017: Scaling Multiplayer Games with Open Source
- https://www.youtube.com/watch?v=a08WrvIPKMw
Scaling Dedicated Game Servers with Kubernetes: Part 2 – Managing CPU and Memory
- https://www.compoundtheory.com/scaling-dedicated-game-servers-with-kubernetes-part-2-managing-cpu-and-memory/
示例项目：paddle-soccer
- https://github.com/markmandel/paddle-soccer

在本系列的第 1 部分中，我们讨论了如何使用专用游戏服务器，将其与 Docker 打包，然后在Kubernetes 上托管和管理它，这是一个很好的开始。然而，由于我们的 Kubernetes 集群通常是固定大小的，我们可能会耗尽所有可用容量来运行我们需要的所有游戏服务器容器，以匹配所有想玩我们的游戏的玩家——这将是一件非常糟糕的事情。

Kubernetes 集群有很多伸缩选项，我们将在以后的文章中深入介绍一个定制的 Kubernetes 节点伸缩器。首先，我们必须解决一个非常重要的事情:我的游戏服务器实际上占用了多少 CPU 和内存?

没有这些知识，就无法将游戏服务器的 CPU 和/或内存利用率与 Kubernetes 集群中的可用资源进行匹配，因此无法知道在给定大小的集群中可以运行多少个游戏服务器。当我们的游戏人数增加时，我们也将无法计算要添加的节点数（因为它自然会是?），并且我们要确保集群足够大以容纳所有节点。如果流量开始下降，我们还希望缩小集群规模，以便通过删除不使用的集群节点来节省成本。

Kubernetes Dashboard

很棒的是，CPU 和内存使用率的可视化是 Kubernetes 开箱即用提供的另一个功能。 Kubernetes 捆绑有一个仪表板，该仪表板使我们可以很好地直观了解集群内部发生的事情，例如列出Pod 和 Services，为我们提供 CPU，内存使用情况等图表。

为了安全地连接到 Kubernetes 仪表板，Kubernetes 的命令行工具具有以下命令：

kubectl proxy

复制

运行时将返回以下内容：

Starting to serve on 127.0.0.1:8001

复制

这将创建到 Kubernetes 主服务器的代理连接（假设您有权访问该集群），该主机托管 Kubernetes 集群的 API 和上面显示的仪表板。

如果现在将浏览器指向 http://localhost:8001/ui ，我们将看到仪表板。

确定 CPU 和内存使用率

您可能已经注意到，仪表板为我们提供了整个集群的 CPU 和内存的汇总统计信息，但它也可以在 Pod 级别为我们提供相同的信息！因此，我们需要确定游戏服务器正在使用多少 CPU 和内存的所有工作，就是部署一个包含游戏服务器的 Pod（我们在上一篇文章中进行了设置），并通过在其上运行多个游戏会话来进行一些负载测试，并查看提供的图表。

我是在 Paddle Soccer 游戏中这样做的，您可以看到以下结果之一：

在上面的测试中，这个简单的专用游戏服务器的使用峰值是 0.08 个 CPU 核和略高于 34M 内存。这是我们在专用游戏服务器上进行负载测试时看到的最大使用量，所以我们会在这里画一条线，说明这是我们的服务器使用的上限，添加一些缓冲区，并据此制定计划。

限制CPU和内存的使用

诸如 Docker 之类的软件容器的非常有用的功能之一是，它能够对正在运行的容器的 CPU 和内存使用情况以及其中的进程施加约束。Kubernetes 通过其 Pod 配置向我们展示了这一点，这意味着我们可以明确确保 CPU 和内存使用率不会超过某个阈值，并且不会对在同一节点上运行的其他游戏服务器产生不利影响。考虑到游戏服务器对 CPU 波动的敏感程度，这是非常有用的！

因此，如果我们想限制包含游戏服务器的 Pod 的 CPU 使用率，可以通过更新以前的 Pod 定义来做到这一点：

apiVersion: v1
kind: Pod
metadata:
  generateName: "game-"
spec:
  hostNetwork: true
  restartPolicy: Never
  containers:
    - name: soccer-server
      image: gcr.io/soccer/soccer-server:0.1
      env:
        - name: SESSION_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
resources: # This section limits the cpu usage
  limits:
    cpu: "0.1"