客座文章最初由Robert Brennan在Fairwinds博客发表
https://www.fairwinds.com/blog/5-problems-with-kubernetes-cost-estimation-strategies
估计你在特定的Kubernetes工作负载上花费（或浪费）多少是困难的。好消息是，有一些合理的策略可以估算给定工作负载的成本。
在这篇文章中，我们将讨论影响成本估算的五个主要问题，并在Fairwinds Insights的成本仪表盘中谈及我们用来克服这些问题的策略。我们将在即将发布的博客中对正确的大小进行更深入的讨论。
https://www.fairwinds.com/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推荐“刚刚好”的设置。
https://github.com/FairwindsOps/goldilocks/
总结
理解组织中每个应用程序影响的财务成本是很重要的，但是当它们都在Kubernetes中运行时，这就相当困难了。幸运的是，有一些合理的方法可以解决Kubernetes成本估算的每个问题。
通过组合使用适当的规模，采用正确的方法（例如，保守与乐观），并使用配置验证工具，如Fairwinds Insights和Goldilocks，你可以确保Kubernetes部署有效运行。
点击【阅读原文】阅读网站原文。
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。
本文分享自微信公众号 - CNCF（lf_cncf）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/4254704/blog/4642836