如何为 PostgreSQL 设置 Kubernetes CPU 和内存

Question

我有一个带有 Patroni 的三个节点的 PostgreSQL 集群。集群管理着非常高的工作负载，因此，它在裸机机器上运行在生产环境中。 我们需要将此基础架构迁移到 Kubernetes（出于多种原因），并且我正在使用 PgBench 执行一些性能测试。首先，我比较了 Baremetal 和 Virtual Machine，降级非常小。然后我比较了 VSI 和 Kubernetes 来了解 K8s 增加的开销。

现在我正在尝试微调 CPU 和内存。 K8s 在具有 48 个 vCPU 和 192 Gb 的 Worker 节点上运行。但是，一旦部署了 PostgreSQL，我仍然可以看到：

NAME                                     CPU(cores)   MEMORY(bytes)   
postgresql-deployment-5c98f5c949-q758d   2m           243Mi           

即使我将以下内容分配给 PostgreSQL 容器：

resources:
  requests:
    memory: 64Gi
  limits:
    memory: 64Gi

如果我跑步：

kubectl top pod <pod name> -n <namespace>

我得到了以下信息：

NAME                                     CPU(cores)   MEMORY(bytes)   
postgresql-deployment-5c98f5c949-q758d   2m           244Mi           

即使出现以下结果，K8s 仪表板也会出现相同的结果：

kubectl describe pod <pod name> -n <namespace>

显示 Pod 以 Guarantee QoS 和 64Gi 的 RAM 用于请求和限制运行。

这应该如何工作？

我不明白的另一件事是 CPU limit 和 requested。我希望输入这样的内容：

resources:
  requests:
    cpu: 40
    memory: 64Gi
  limits:
    cpu: 40
    memory: 64Gi

我希望为我的容器保留 40 个 vCPU，但在部署过程中，当我运行 kubectl describe pod <pod name> -n <namespace> 时，我发现节点上的 CPU 不足。我可以使用的最大值是 1。

这应该如何工作？

显然，我阅读了文档并搜索了不同的示例，但是当我将事情付诸实践时，我看到的测试结果与理论不同。我知道我错过了什么。

Answer 1

这是一个很好的问题，今年早些时候我也花了一些时间通过经验找到答案。

请务必了解请求对容器的资源使用没有实际影响。您可以通过连接到您的服务器并像您一样运行htop 或kubectl top 来检查，您会看到即使您定义了requests: memory: 64Gi，也只使用了244Mi。

请求的主要目的是影响调度行为。当 Kubernetes 调度程序寻找合适的节点以在其上放置新 Pod 时，它会检查节点当前请求的 CPU 和内存。您可以通过运行以下命令自己检查节点的当前状态。

$ kubectl describe node worker01
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                200m (10%)   1100m (55%)
  memory             506Mi (13%)  2098Mi (54%)
  ephemeral-storage  0 (0%)       0 (0%)
  hugepages-1Gi      0 (0%)       0 (0%)
  hugepages-2Mi      0 (0%)       0 (0%) 

如果（CPU 或内存的）请求超过 100%，则 Pod 无法调度并进入 Pending 状态。

设置正确的请求可能非常棘手，如果将它们设置为高，您将无法有效地使用节点的资源，因为您无法调度那么多 pod，如果您将它们设置为低，您就有可能拥有应用程序在性能峰值期间不断崩溃或油门。

limits 的主要目的是控制 Pod 的最大 Resource 使用量。

因为 CPU 可以被压缩，Kubernetes 会确保你的 容器获得它们请求的 CPU 并将限制其余的。 内存无法压缩，需要Kubernetes开始制作 如果节点用完，决定终止哪些容器 记忆[1]

因此，如果容器超过其限制，它将被终止或限制。这导致我公司的最佳实践是不对集群中的数据库进行限制。

参考的博客文章帮助我获得了一些很好的见解：
[1] https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits
[2]https://sysdig.com/blog/kubernetes-limits-requests/