这篇文章展示了优化Kubernetes成本的挑战和一些最佳实践。
例如：1. 为Pod设置服务质量(QoS)，2. LimitRanges，3. ResoureQuotas。云容器具有灵活性，可以将应用程序无缝迁移到任何环境，包括云环境、虚拟环境或裸机环境，而无需担心虚拟操作系统、虚拟化软件等。简化的管理、快速的交付和敏捷性使云开发人员倾向于采用容器化。Kubernetes(也称为k8s，如果你想知道k8是什么意思，它只是替代了“Kubernetes”这八个字母)是一种广泛采用的流行开源容器化平台，被云开发人员广泛采纳。根据CNCF最近的报告，全球范围内Kubernetes开发人员增加了67%，这表明其受欢迎程度。
不幸的消息是，Kubernetes的采用和使用激增导致公司IT基础设施预算上的妥协。企业可能会将近80%的Kubernetes开销浪费在无意识的资源上，这些资源并没有帮助组织按计划实现目标。让我们在这篇博客中看看有哪些挑战和优化方式。
Kubernetes成本优化的挑战整体计费一个集群包含多个节点。每个节点又包含不同数量的容器。并不是每个存在于一个集群中的节点都属于同一个应用程序。每个节点可能由不同的团队处理，用于不同的应用程序。但是云服务提供商按照整个集群或多个集群进行计费。当容器部署到节点上时，计费就开始了。额外的费用每天为Kubernetes集群维护、软件许可、灾难恢复等方面收取2.4美元。
Showback和Chargeback几乎是不可能的这两个过程对企业来说至关重要，可以实现财务上的责任。Showback是一种过程，为特定时间段内的云资源使用给出业务单元的支出可见性，但不收费。而Chargeback则是在根据使用情况通知业务单元并按照其使用情况收费的过程。在Kubernetes集群中，不可能使用有助于工程师跟踪成本的标签。
当我们投资每一分钱时，只有当它符合我们计划的功能/产出清单时才是有价值的。当它们仅停留在支出方面，与生产无关时，就应该找出造成这种异常的根源。但对于Kubernetes集群来说，事情并不像听起来那么简单。因为每个容器可能由企业中不同团队使用，而这些团队可能在开展不同的工作。同时，每个团队的基础设施预算和资源成本分配也有所不同。
多云采用根据Gartner最近的一项调查，81%的受访者表示他们使用2个或更多的云服务提供商以获取各种好处，如克服供应商锁定、资源折扣、灾难恢复等。Kubernetes集群将包含来自不同云服务提供商(如AWS、Azure、GCP等)的工作负载，进一步增加了成本异常检测和Kubernetes成本优化过程的复杂性。
动态自动伸缩云工程师选择Kubernetes集群的一个关键原因是其自动伸缩功能。根据使用需求，Kubernetes会进行伸缩，使资源在高峰和低谷期间满足计算需求。在水平自动伸缩中，容器数量可能在一天内从2个增加到20个。由于这种不可预测的自动伸缩，Kubernetes成本优化变得复杂。
Kubernetes成本优化的最佳实践让我们来看看如何最优化地削减意外开销。
Pods的服务质量(QoS)Kubernetes集群为云从业者提供了灵活性，可以为Pod设置不同的QoS类别。基于此，对Pod的调度和移除对于云从业者来说更加容易。它有三种类型 - Guaranteed(保证)、Burstable(可扩展)和Best-Effort(尽力而为)。
Guaranteed(保证)：当云工程师需要一个能够处理高度关键应用程序的Pod时，可以将其配置为保证型QoS类别。因此，CPU和内存的限制和需求是相同且设置好的。正如名称所示，它保证提供最小资源(需求是最小资源数量，限制是其可以使用的最大资源数量)。
Burstable(可扩展)：当vCPU或内存限制超过需求或不完全相同时，将为Pod分配可扩展的QoS类别。因此，当需要增加计算需求时，可以利用这些资源。
Best-Effort(尽力而为)：当限制和需求都没有设置时，它被归类为最适合型QoS类别。云工程师可以将其用于非关键应用程序。
正如我们可以清楚地看到的那样，首选删除Best-Effort pods，其次是Burstable pods，然后是Guaranteed pods。
ResourceQuotas和LimitRange正如我们之前所看到的，Kubernetes集群由各个团队共享。一个团队可能使用大部分Pods，导致其他团队资源紧张。命名空间级别的Pod限制可以缓解此问题(命名空间是一个虚拟集群)。资源配额是我们可以在命名空间内限制Pod使用的方法。
Kubernetes管理员为每个命名空间创建一个资源配额。每当用户在命名空间内创建或更新Pod时，资源配额系统会检查是否超过了限制。如果超过了限制，它将返回一个"403 FORBIDDEN"错误，拒绝该操作。
LimitRange是另一种可以帮助实现资源限制的策略。顾名思义，它限制了命名空间内"limits & requests"的范围。
