时间戳

首页 > 解决方案 > 调整 Kubernetes 节点规模 | 当我们从虚拟机切换到容器时，我们节省了多少成本

kubernetes - 调整 Kubernetes 节点规模 | 当我们从虚拟机切换到容器时，我们节省了多少成本

问题描述

我们在 4 个不同的 ec2 自动缩放组上运行 4 个不同的微服务：

service-1 - vcpu:4, RAM:32 GB, VM 数量:8

service-2 - vcpu:4, RAM:32 GB, VM 数量:8

service-3 - vcpu:4, RAM:32 GB, VM 数量:8

service-4 - vcpu:4, RAM:32 GB, VM 数量:16

我们计划在 EKS 上迁移此工作负载（在容器中）

我们需要帮助来决定正确的节点配置（在 EKS 中）。我们可以从一台小型机器 vcpu:4, RAM:32 GB 开始，但不会节省任何成本，因为每个容器都需要一个单独的 vm。我们可以使用大型机器 vcpu:16, RAM: 128 GB，但是当这些机器横向扩展时，横向扩展的机器会很大，因此可能没有得到充分利用。或者我们可以使用像 vcpu: 8, RAM:64 GB 这样的中型机器。

除了这个建议之外，我们还在评估迁移到容器的成本节约。根据我们的理解，每台 VM 机器都有以下开销

注意：在公共云上，一台大型 VM 与许多小型 VM 的成本相同，因为成本基于 vCPU + RAM 的数量。

管理程序/虚拟化成本仅在我们在本地运行时才有效，因此无需考虑这一点。第二点，一台典型的 linux 机器可以占用多少资源来运行一个操作系统？如果我们配置一台小型机器（vcpu:2, RAM:4GB），cpu 使用率约为 0.2%，内存消耗（用户空间除外）为 500Mb。因此，运行大型实例（计数：5 个实例与小型实例计数：40 相比）可以节省 35 倍的 CPU 和 RAM，这似乎并不重要。

标签： kubernetescontainersmicroservices

解决方案

当您从直接在 VM 上运行的应用程序迁移到 EKS 中的容器时，您不太可能看到任何资源成本节约。

Linux Container 只是一个具有特定资源限制的隔离 Linux 进程，在资源消耗方面与普通进程没有区别。EKS 仍使用虚拟机为集群提供计算，因此无论是否容器化，您仍将在 VM 上运行进程，并且从资源的角度来看，它是平等的。（有关VM 和容器的更详细比较，请参阅此答案）

当您将 Kubernetes 添加到混合中时，与直接在 VM 上运行相比，您实际上增加了更多开销。Kubernetes 控制平面在一组专用 VM 上运行。在 EKS 中，这些都是在 PaaS 中完全托管的，但 Amazon 会为每个集群按小时收取少量费用。

除了专用的控制平面节点外，集群中的每个工作节点都需要一组程序（系统 pod）才能正常运行（kube-proxy、kubelet 等），您还可以定义必须在每个节点上运行的容器（守护进程集），如日志收集器和安全代理。

在调整节点大小时，您需要在扩展和成本优化之间找到平衡。

  • 工作节点越大，系统 pod 和守护程序集的相对开销就越小。理论上，与节点上的支持应用程序相比，足以容纳所有容器的工作节点将最大化应用程序消耗的资源。
  • 工作节点越小，水平扩展的步长就越小，这可能会减少扩展时的浪费。它还提供了更好的弹性，因为节点故障会影响更少的容器。

我倾向于更喜欢小的节点，以便可以有效地处理缩放。它们应该比最大容器所需的稍大，以便系统 pod 和守护程序集也可以容纳。

推荐阅读