跳到主要内容
博客容器(Kubernetes、Docker)如何(正确)确定 Kubernetes 集群的规模以提高效率

如何(正确)确定 Kubernetes 集群的规模以提高效率

如何(正确)确定 Kubernetes 集群的规模以提高效率

简要说明:在本文章中,您将了解如何在编写任何代码之前为 Kubernetes 集群选择最佳节点。

当你创建 Kubernetes 集群时,你可能会遇到的第一个问题是:"我应该使用哪种类型的工作节点?"我应该使用哪种类型的工作节点?

或者,如果您使用的是 Linode Kubernetes Engine (LKE) 这样的 Kubernetes 托管服务,您应该使用 8 个 Linode 2 GB 还是 2 个 Linode 8 GB 实例来实现所需的计算能力?

首先,并非工作节点中的所有资源都能用于运行工作负载。

Kubernetes 节点预订

在 Kubernetes 节点中,CPU 和内存被划分为

  1. 操作系统
  2. Kubelet、CNI、CRI、CSI(和系统守护进程)
  3. 豆荚
  4. 驱逐门槛
节点中的资源分配

让我们举一个简单的例子。

想象一下,您有一个集群,其中有一个Linode 2GB 计算实例,或 1 个 vCPU 和 2GB 内存。 

为 kubelet 和操作系统保留了以下资源:

  • -500MB 内存。
  • 中央处理器 -60 米。

此外,还为驱逐阈值预留了 100MB 的空间。

预留资源图像

总共有30%的内存和6%的 CPU 无法使用。

每个云提供商都有自己定义限制的方式,但对于 CPU 而言,他们似乎都同意以下值:

  • 占第一个核心的 6%;
  • 下一个内核的 1%(最多 2 个内核);
  • 下两个核心(最多 4 个)的 0.5%;以及
  • 四个以上核心的 0.25%。

至于内存限制,不同提供商之间有很大差异。

但总的来说,保留是按照这个表格进行的:

  • 前 4 GB 内存的 25%;
  • 以下内存的 20% 4 GB(最多 8 GB);
  • 以下内容的 10% 8 GB 内存(最多 16 GB);
  • 下一个 112 GB 内存的 6%(最多 128 GB);以及
  • 128 GB 以上内存的 2%。

既然知道了工作节点内的资源是如何重新分配的,那么就该问一个棘手的问题了:应该选择哪个实例?

由于正确答案可能有很多,因此我们将重点放在最适合您工作负载的工作节点上,以限制我们的选择范围。

剖析应用程序

在 Kubernetes 中,有两种方法可以指定容器可以使用多少内存和 CPU:

  1. 请求 通常与应用程序正常运行时的消耗量相匹配。
  2. 限制 设置了允许的最大资源数量。

Kubernetes 调度器使用请求来确定 pod 在集群中的分配位置。由于调度程序不知道消耗量(pod 尚未启动),因此需要一个提示。这些 "提示 "就是请求;你可以有一个用于内存,一个用于 CPU。

Kubernetes 计划映像

当进程使用的内存超过允许值时,kubelet 会使用限制来停止进程。如果进程占用的 CPU 时间超过允许值,它还会对进程进行节流。

但是,如何为请求和限制选择正确的值呢?

您可以测量您的工作负载性能(即平均值、第 95 和 99 百分位数等),并将其作为限制请求。为了简化这一过程,有两个方便的工具可以加快分析速度:

  1. 垂直吊舱自动定标器
  2. Kubernetes 资源推荐器

VPA 会收集内存和 CPU 利用率数据,并运行一种回归算法,为你的部署提出请求和限制。它是 Kubernetes 的官方项目,也可以通过仪器自动调整值--你可以让控制器直接在 YAML 中更新请求和限制。

内存请求由垂直 pod 自动调节器调整

KRR 的工作原理类似,但它利用您通过 Prometheus.第一步,应该对工作负载进行检测,以便将指标导出到Prometheus 。存储所有指标后,就可以使用 KRR 分析数据并提出请求和限制。

KRR 图片

了解了(大致的)资源需求后,最后就可以选择实例类型了。

选择实例类型

假设您估计您的工作负载需要 2GB 的内存请求,并且您估计至少需要 ~10 个副本。

您已经可以排除大多数小于 "2GB * 10 = 20GB "的小型实例。此时,您可以猜测一个可以很好运行的实例:让我们选择 Linode 32GB。

然后,将内存和 CPU 除以该实例上可部署的最大 pod 数量(即 LKE 中的 110),即可得到一个离散的内存和 CPU 单位。

例如,Linode 32 GB 的 CPU 和内存单元为

  • 内存单元 257MB(即(32GB - 3.66GB 保留)/110)
  • 中央处理器单元 71 米(即(8000 米-预留 90 米)/110)
示例图 #1

非常好在最后一步(也是最后一步),您可以使用这些单位来估算节点可以容纳多少工作负载。

假设您要部署一个请求为 6GB 和 1 个 vCPU 的 Spring Boot,这就意味着

  • 适合 6GB 的最小单元数是 24 单元(24 * 257MB = 6.1GB)
  • 适合 1 个 vCPU 的最小单元数为 15 个单元(15 * 71m = 1065m)

这些数字表明,在 CPU 用完之前,内存就会用完,而群集中最多只能部署 (110/24) 4 个应用程序。

示例图 #2

当您在该实例上运行四个工作负载时,您可以使用

  • 24 个内存单元 \* 4 = 96 个单元,还有 14 个单元未使用(~12%)。
  • 15 个 vCPU 单元 \* 4 = 60 个单元,50 个单元未使用(~45%)。

<Diagram>

不错,但我们能做得更好吗?

让我们用 Linode 64 GB 实例(64GB/16 vCPU)来试试。

假设您要部署相同的应用程序,数字将变为

  • 一个内存单位约为 527MB(即(64GB - 6.06GB 保留)/110)。
  • 一个 CPU 单元约为 145 米(即(16000 米-预留 110 米)/110)。
  • 适合 6GB 的最小单位数是 12 单位(12 * 527MB = 6.3GB)。
  • 适合 1 个 vCPU 的最小单元数为 7 个单元(7 * 145m = 1015m)。
图片示例 #3

这个实例可以容纳多少工作负载?

由于内存将达到最大值,而每个工作负载需要 12 个单元,因此应用程序的最大数量为 9 个(即 110/12)。

图片 #4 示例

如果计算一下效率/损耗,你会发现

  • 12 个内存单元 \* 9 = 108 个单元,2 个单元未使用(~2%)。
  • 7 个 vCPU 单元 \* 9 = 63 个单元,还有 47 个单元未使用(~42%)。

虽然浪费 CPU 的数据与之前的实例几乎相同,但内存利用率却大幅提高。

图片 #5 示例

我们终于可以比较成本了:

  • Linode 32 GB 实例最多可容纳 4 个工作负载。按总容量计算,每个 pod 的成本为 48 美元/月(即 192 美元的实例成本除以 4 个工作负载)。
  • *Linode 64 GB 实例最多可容纳 9 个工作负载。按总容量计算,每个 pod 的成本为 42.6 美元/月(即 384 美元的实例成本除以 9 个工作负载)。
图片 #6 示例

换句话说,选择较大的实例大小,每个工作量每月最多可节省 6 美元。好极了!

使用计算器比较节点

但如果要测试更多实例怎么办?进行这些计算需要大量的工作。

使用learnk8s计算器加快进程。

使用计算器的第一步是输入您的内存和 CPU 请求。系统会自动计算预留资源,并建议使用率和成本。还有一些其他有用的功能:根据应用程序的使用情况分配 CPU 和内存请求。如果应用程序偶尔会突然出现较高的 CPU 或内存使用率,也没关系。

但是,如果所有的 "花苞 "都把资源用到了极限,会发生什么呢?

这可能会导致超量使用。中间的小部件会显示 CPU 或内存超量占用的百分比。

过度承诺会发生什么?

  • 如果超量使用内存,kubelet 会驱逐 pod 并将其转移到集群中的其他地方。
  • 如果超量使用 CPU,工作负载将按比例使用可用的 CPU。

最后,您可以使用 DaemonSets 和 Agent widget,这是一种方便的机制,可以为在所有节点上运行的 pod 建模。例如,LKE 将 Cilium 和 CSI 插件部署为 DaemonSets。这些 pod 使用的资源不能用于工作负载,因此应从计算中减去。这个小工具可以让你做到这一点!

摘要

在本文中,您将深入了解为 LKE 集群定价和确定工作节点的系统过程。

您了解了 Kubernetes 如何为节点储备资源,以及如何优化集群以利用这些资源。还想了解更多?注册参加我们与Akamai云计算服务公司合作举办的网络研讨会,了解Kubernetes的实际应用。

注释

留下回复

您的电子邮件地址将不会被公布。 必须填写的字段被标记为*