在本系列的第 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"
值得注意的是，在示例代码中，我使用 Kubernetes API 提供了与上述配置相同的配置，但是 yaml 版本更易于理解，这是在本系列文章中一直使用的格式。
在上面的示例中，我们将限制设置为 “0.1”，以确保我们的游戏服务器只能访问其所运行的节点上的 CPU 的十分之一。为此，我们在 yaml 中为游戏服务器容器定义添加了带有相应限制的资源部分和cpu 部分。
我选择将最大 CPU 使用率设置为 0.1，以为我们在上面看到的 0.08 内核游戏服务器使用率提供一些填充，同时仍然让我在每个 Kubernetes 集群节点上每个核容纳 10 个游戏服务器，这应该可以很好地满足我们的需求。
我们还可以对内存使用量进行类似的限制，但为简单起见，我们将仅限制 CPU 使用量，最终也仅将 CPU 用于我们的扩展指标。
