共计 3230 个字符，预计需要花费 9 分钟才能阅读完成。
客座文章最后由 Robert Brennan 在 Fairwinds 博客发表
预计你在特定的 Kubernetes 工作负载上破费（或节约）多少是艰难的。好消息是，有一些正当的策略能够估算给定工作负载的老本。
在这篇文章中，咱们将探讨影响老本估算的五个次要问题，并在 Fairwinds Insights 的老本仪表盘中谈及咱们用来克服这些问题的策略。咱们将在行将公布的博客中对正确的大小进行更深刻的探讨。
问题 1：装箱（Bin Packing）
假如咱们有一个节点，破费咱们 20 美元 / 月。假如它有 5GB 的内存和 5 个 CPU 可供使用。（留神：这不是一个十分事实的节点，然而它使图和数学进去难看点????）
这里有一个工作负载，须要 2GB 的内存和 2 个 CPU 能力运行：
咱们能够在一个节点中包容多达两个 Pod 的工作负载：
然而，如果咱们想为工作负载增加第三个 Pod，就没有足够的空间了。所以咱们须要增加（并付费）一个新节点：
留神，在第一个节点上有一点空间节约 – 咱们有 1GB 内存和 1CPU。而咱们的第二个节点没有被充分利用 – 不到一半的资源被投入使用。
这是老本估算的首要问题：Kubernetes 不能在多个节点上拆分一个 Pod。因而，如果一个节点不能包容整个 Pod，就会有肯定数量的容量被节约。
解决方案：这里的一种解决方案是“适当大小”节点。如果咱们应用一个领有 4GB 内存和 4CPU 的节点，咱们的工作负载将十分适合，并且没有容量会节约：
问题 #2：资源不对称（Resource Asymmetry）
让咱们思考一种不同的工作负载：一种 CPU 十分密集的工作负载。它须要 3 个 CPU 能力运行，但内存只有 1GB。
当初咱们只能将 1 个 Pod 值的工作负载放入一个节点（应用咱们的 4CPU/4GB 示例）：
这里会节约大量未应用的容量 – 不仅是 1 个 CPU，还有 3 GB 内存。咱们只应用了一半的节点，但如果咱们想增加第二个 Pod，咱们将须要第二个节点，但节约的量是一样的！
解决方案：同样，咱们须要调整节点的大小 – 云提供商提供 CPU 密集型和内存密集型的节点来解决这个问题。
问题 3：老本归属（Cost Attribution）
咱们假如较小的节点（4 个 CPU 和 4 GB）破费 16 美元 / 月。应用这些数字，咱们能够粗略预计出每个 CPU 和每个 GB 内存的老本。16 美元中，8 美元进了 CPU，8 美元进了内存。这样咱们就能够推断出，咱们为每 CPU 和每 GB 内存领取了 2 美元。
那么咱们最后的工作量是多少呢？
依据下面的计算，咱们能够说 $2/CPU * 2CPU + $2/GB * 2GBs = $8。这是有意义的 – 咱们能够在一个 16 美元的节点上恰好满足两个这样的工作负载。咱们将在上面探讨的起因，咱们称之为老本估算的乐观办法。
然而咱们的第二个工作负载，CPU 密集型的工作负载呢？
让咱们做同样的计算：$2/CPU * 3CPU + $2/GB * 1GB = $8。乐观的办法是这个工作量破费 8 美元。但正如咱们在下面看到的，每个节点只能包容一个。所以在事实中，它破费了咱们 16 美元 / 月，乐观的办法仿佛不那么精确。
有没有其余的老本估算办法能够给咱们一个更正当的答案？有！
咱们不必把 CPU 老本和内存老本加在一起，而是取两者的最大值。这有助于咱们思考内存密集型或 CPU 密集型的工作负载，这可能导致额定的容量被节约。（留神，咱们还须要将后果乘以 2，因而咱们也计算失落的资源。）
所以计算结果就是 MAX（$2/CPU * 3CPU，$2/GB 1GB） 2 = $12。这曾经很靠近 16 美元的指标了。残余的局部归因于齐全未应用的节点容量（即，只管节点承载了 CPU 密集型的工作负载，但仍有 1 个 CPU 将被节约）。
咱们称之为激进预计法。依据 Kubernetes 将工作负载装箱到节点上的能力，它为最坏的状况做了筹备。
对于许多工作负载，激进办法和乐观办法会给出相似的预计，然而对于 CPU 或内存密集型的工作负载，它们会有所不同。最根本的区别是乐观办法假如最优装箱，而激进办法假设会有一些节约。例如，咱们也运行一个内存密集型的工作负载，它只须要一个 CPU，但须要 3 GB 内存：
Kubernetes 很聪慧，它将这些性能与 CPU 密集型的工作负载联合在一起，为咱们节俭了未应用的容量：
激进的办法会说，每个工作负载的老本为 12 美元，总成本为 24 美元。然而 Kubernetes 找到了一种办法将它们装箱到一个 16 美元的节点中！这就是为什么它被称为激进。
乐观办法思考到了奇妙的装箱，它认为每个工作负载老本为 8 美元，总成本为 16 美元，这是一个完满的预计，因为它们正好适宜一个 16 美元的节点。
解决方案：那么应该应用哪一种呢？答案是看状况而定。如果你曾经花了工夫优化实例类型，或者如果你的节点比均匀工作负载大得多，那么 Kubernetes 很有可能找到一种以经济无效的形式将工作负载装箱在一起的办法，你能够平安地抉择乐观的办法。否则，咱们举荐激进的办法。
问题 #4：资源范畴（Resource Ranges）
另一个问题是，Kubernetes 工作负载不仅仅应用固定数量的 CPU 和内存。资源应用状况可能会随着工夫而变动，为了响应这些稳定，Pods 可能会被杀死或在节点之间挪动。
为了帮忙解决这个问题，Kubernetes 的配置为工程师提供了两个字段来治理资源：
- requests 设置工作负载的最小资源应用。在节点上调度工作负载时，你能够确保至多有这么多可用
- limits 设置工作负载的最大资源应用状况。当工作负载的一个 Pod 尝试应用超过这个数量时，该 Pod 将被杀死，并启动一个新的 Pod。
给定工作负载的理论资源使用量介于这两个数字之间，并且会随着工夫的变动而激烈稳定（只有查看一下你的 macbook 上的流动监视器就会晓得变动有多大！）
解决方案：预计工作负载老本的一种办法是查看稳定的数字，并在一段时间内取平均值。预计工作负载老本的另一种办法是查看 requests 和 limits，以提供一系列可能性，或者取两者的平均值。
因为 Fairwinds Insights 次要关注配置验证，所以咱们抉择了第二种策略 – 咱们想通知你，给定你以后的配置，这个工作负载的预期老本是多少。
问题 5：吵闹的街坊（Noisy Neighbors）
Kubernetes 只能利用它所有的信息做到最好。这就是为每个工作负载指定 requests 和 limits 如此重要的起因。
例如，如果你的一个工作负载适当地申请 1GB 内存，然而同一节点上的另一个工作负载没有设置 requests 或 limits，那么第二个工作负载很容易开始吞噬该节点上的所有可用资源。这能够避免咱们的原始工作负载取得所需的所有内存，从而侵害其性能。
因为拨入这些设置可能会很辣手，一些团队基本不会设置 requests 或 limits，而另一些团队则在初始测试期间将其设置得过高，而后就永远不做正确批改。为了适当地估算老本，咱们须要设定正确的 requests 和 limits。Fairwinds Insights 应用收费开源工具 Goldilocks 来剖析理论的资源应用状况，并为 requests 和 limits 举荐“刚刚好”的设置。
总结
了解组织中每个应用程序影响的财务老本是很重要的，然而当它们都在 Kubernetes 中运行时，这就相当艰难了。侥幸的是，有一些正当的办法能够解决 Kubernetes 老本估算的每个问题。
通过组合应用适当的规模，采纳正确的办法（例如，激进与乐观），并应用配置验证工具，如 Fairwinds Insights 和 Goldilocks，你能够确保 Kubernetes 部署无效运行。
点击浏览网站原文。
CNCF (Cloud Native Computing Foundation) 成立于 2015 年 12 月，隶属于 Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。
