接受范围｜中度
基于Kubernetes构建混有云的优势主要包括：
可扩展性：Kubernetes可以通过自动扩展容器来满足应用程序的流量需求，这使得用户可以更加灵活地满足业务增长的需求。
可移植性：Kubernetes可以跨多个云环境和硬件平台运行，这使得用户可以更加方便地在不同的云环境中部署应用程序，并且可以根据自己的需要来选择最合适的云服务提供商。
高可用性：Kubernetes可以通过负载均衡和自动故障转移来确保应用程序的高可用性，这使得用户可以避免因应用程序故障而导致的损失。
操作简单：Kubernetes提供了丰富的API和工具，可以帮助用户更加方便地管理和操作容器，减少人工干预的需求。
Kubernetes纵有千般好，但在管理云成本方面也存在一系列挑战。在本文中，我们将分享在Kubernetes云成本优化的五个最佳实践。
以下是优化Kubernetes云成本的五个最佳实践:
Pod 合理资源分配
节点合理资源分配（或虚拟机合理资源分配）
自动伸缩（ Pod vpa、Pod hpa和cluster autoscaler）
节点碎片整理
利用云折扣（预留实例、折扣、节省计划等）
通过运用这些实践，可以提高应用程序的性能，同时降低成本。
云成本最佳实践
在配置Kubernetes集群时，可以合理的配置资源的request和limits，开发人员通过设置配置文件中的request和limits来控制每个pod中容器的CPU和内存资源的数量。
为了帮助降低Kubernetes集群的成本，需要合理的设置资源request和limits并维持应用性能。Kubernetes提供了Pod vpa工具，VPA 使用户无需为 pod 中的容器设置资源请求。配置后，它将根据资源（cpu 与内存）使用情况自动设置 requests。在对 pod 的调度过程中，使得每个 pod 都可以使用适当的资源量从而分配到适合的节点上，从而提升集群资源的利用率，同时可以最大限度地降低容器内存或 CPU 不足的风险。关于vpa更多介绍可以参看：K8s降本增效之VPA上篇
节点调整
类似于调整 Pod 资源配置，需要确保 Kubernetes 集群中使用合适类型与资源配比的节点，以运行工作负载。举个例子，假设一个节点，它有 10 个 CPU 和 10 GB 的 RAM，每月的费用为 $100，同时有一个工作负载，需要 4 个 CPU 和 4 GB 的 RAM 来运行。在这种情况下，使用这个节点就会浪费计算和内存资源，最终导致成本的上升。相反，如果使用一个小的节点来运行这个工作负载，就可以节省资源，达到降低成本的目的。
确保测量您的应用程序所需的资源，并在可能的情况下减少节点的数量和大小。这样可以通过提升分配率，帮助您更有效地利用集群中的资源，减少计算和存储资源的浪费，从而达到降低成本的目的。但是，就性能而言，如果节点上的 Pod 数量过多，可能会导致性能下降，操作可能会变慢，甚至会变得不可靠。因此，托管的 Kubernetes 服务通常会对节点的 Pod 数量施加限制。以下是主要云提供商的每个节点 Pod 数量限制：
在 Amazon Elastic Kubernetes Service（EKS）中，每个节点的最大 Pod 数量取决于节点类型，范围在 4 到 737 之间。
在 Google Kubernetes Engine（GKE）中，无论节点类型如何，每个节点的限制都是 110 个 Pod。
在 Azure Kubernetes Service（AKS）中，默认限制是每个节点 30 个 Pod，但可以增加到 250 个。
自动扩缩
通过调整 Pod 和节点的资源，可以通过提高 Kubernetes 集群的分配率，从而降低成本。但是，要知道最适合运行的 Pod 的资源配置或节点类型及相应的数量，并能够快速跟进集群的变化是一项重大挑战。手动伸缩云容量既困难又耗时，除了要注意跟踪系统中所发生的一切外，你通常还需要注意：
优雅地处理流量高峰和低谷——并在你使用的所有服务中为每个虚拟机垂直伸缩资源；
确保应用于一个工作负载的更改不会对其他工作负载造成任何问题；
自行配置并管理资源组，以确保它们包含适合你的工作负载的资源。
为了克服这一挑战，Kubernetes 提供了自动扩展功能，以确保使用适合的 Pod、节点的大小和数量。Kubernetes 社区提供了一些工具可以管理活动 Pod 和节点的大小和数量：
Horizontal Pod Autoscaling：根据工作负载的 CPU 或内存使用率自动扩展 Pod 的数量。
Cluster Autoscaler：根据集群中 Pod 的需求自动扩展或缩小节点的数量。
使用这些工具，可以确保集群的资源使用率达到最优，并且可以快速适应变化，从而保障性能的同时降低成本。确保应用程序不仅在必要时扩展，而且在适当的时候收缩，可以节省大量成本。
随着时间的推移，任何活动的 Kubernetes 集群都会经历一系列重复的部署和周期性的扩展，这就意味着会不断添加和删除 Pod 和节点。这个周期通常会在集群中产生一些效率低下的情况。我们已经讨论过的上述三个措施中，往常可以通过调整 Pod 的大小、调整节点的大小以及自动扩展来解决大多数问题，但是需要特别注意的问题之一是 Kubernetes 集群中的节点资源碎片化，
由于 Kubernetes 调度程序无法预测未来的 Pod 大小和节点添加，随着时间的推移，许多不一致性会出现在 Pod 的调度中。最终，Pod 会被调度到各个节点上，导致任何新的 Pod 无法在任何单个节点上满足所需的资源，使 Pod 无法调度，即使在节点上可能有更多的容量，但仍然需要扩展。这样就产生一个假的资源紧张现象，可以通过整合这些可用资源片段来避免。
这可以通过识别和迁移节点间的特定 Pod 来实现，以整合可用的资源。在大型集群中，重新平衡未优化的 Kubernetes 集群尤为重要，以避免浪费资源，节省不必要的开支。
总而言之， Kubernetes 集群的再平衡需要长期并持续的执行（Pod 配置优化、节点配置优化和自动扩展）措施，其次，需要考虑的是如何工具化、智能化的执行上述策略。
合理利用采购选项
云服务商提供不同的资源购买选项，可以通过修改服务合同条款提供几种折扣价格选项。这些资源购买选项与非容器化基础架构一样，均适用于 Kubernetes，例如：
On-demand Instances：按小时或按秒支付启动的实例
Savings Plans：通过对使用量做出的承诺（每小时美元）并签署一年或三年的期限，降低 Amazon 节点成本（EC2 或 Fargate）（仅适用于 AWS）
Reserved Instances：通过承诺一年或三年支付资源获得折扣价格（Azure 称之为“Reservations”，Google Cloud 称之为“Committed Use Discounts”）
Spot Instances：与 on-demand 价格相比，折扣力度更大的竞价实例（Azure 称之为“Azure Spot VMs”，Google 称之为“Preemptible VMs”）
提供商对资源购买选项的命名方式可能有所不同，并且有些选项可能仅适用于特定的提供商。因此，最好仔细研究各提供商的选项，并选择适合您应用程序的选项。
抢占式实例在容器化环境中特别适用。抢占式实例在不同的云提供商中有不同的名称。Amazon 称之为“Spot Instances”，Azure 称之为“Spot VMs”，Google Cloud 称之为“Preemptible VMs”。无论您选择哪个云提供商，抢占式实例的目的都是一样的：用户可以从云提供商请求未使用的资源，并以比 on-demand 价格更低的成本使用这些资源。
关于抢占式资源额使用，需要注意，如果云提供商需要将其撤回以供 on-demand 或预留客户使用，则实例可能随时丢失，许多关键应用程序不适合该场景，但对于可以容忍轻微中断的应用程序来说非常适合，因此需要合理的配置spot与on-demand比例，是业务稳定性与成本优化的关键之一。
由于笔者时间、视野、认知有限，本文难免出现错误、疏漏等问题，期待各位读者朋友、业界专家指正交流。
1.https://cast.ai/blog/6-top-cloud-cost-optimization-issues-to-avoid-in-2022-and-how-to-deal-with-them
2. https://blogs.vmware.com/cloudhealth/best-practices-optimize-kubernetes-cloud-costs/
真诚推荐你关注
