AI驱动的云原生应用激增导致云成本飙升！传统GitOps在Kubernetes资源优化方面捉襟见肘。ScaleOps等平台通过自动化垂直/水平扩展和Pod放置，实现多云/混合云环境下的资源优化，降低YAML配置负担，让开发者专注于业务，提升CI/CD效率。免费试用走起！
译自：How to Slash Cloud Waste Without Annoying Developers
作者：B Cameron Gain
伦敦 - 借助 AI 生成的大量且不断增长的软件正在导致云成本飞涨。它也呈指数级地增加了对额外计算资源的需求，以管理云原生基础设施中的所有代码。这些因素使得云成本优化对企业来说比以往任何时候都更加重要。
Kubernetes 增加了大规模的复杂性。通常，对于资源的使用方式和支出情况的可见性有限——对于成本优化来说，这是一个困难的环境。但是，由 Flux 和 Argo CD 编排的现有 GitOps practices，基于传统的 GitHub 或 Git 类型操作，不足以进行适当的资源优化。
所需的是专门针对资源优化的抽象。它必须自动化分析，涵盖每个 pod 内部的基础设施细节，并在可能跨多个集群以及云和本地环境中进行大规模分析。除了自动化基础设施管理的操作方面之外，这样的平台还应消除对资源配置的任何担忧，否则可能会涉及手动 YAML configuration 或其他与操作相关的任务。
云支出中的浪费不一定是因为疏忽或缺乏资源；通常是由于对如何优化成本和资源分配的可见性和理解不足。具有讽刺意味的是，Kubernetes 和 GitOps 的设计初衷是通过提供构建块来促进运营团队和开发人员之间的协作，从而实现 DevOps 实践，Gartner 的 Tony Iams 在“Cost Optimization for Containers and Kubernetes in the Cloud”中写道。
Iams 写道：“但是，虽然运营团队仅负责某些规模调整方面，但指定应用程序所需资源的责任最终落在了开发团队身上。” “实施优化的关键是促进开发和运营团队之间的协作。通过适当的工具和实践，并通过共同努力，这些团队可以控制在云中运行容器的成本，并最终对其进行优化。”
许多在 Kubernetes 上运行大规模甚至中等规模生产环境的组织都面临一个常见问题：工作负载要么严重过度配置，要么严重配置不足。开发人员设置 CPU 和内存的资源请求，但由于集群的动态不断变化，他们被迫过度配置。过度配置意味着分配了资源但仍未使用，但另一种选择，配置不足，会对性能产生负面影响。现代软件开发（包括 CI/CD 和 AI）的日益增长的工作负载和复杂性加剧了这种低效率。
主要挑战是 Kubernetes 集群内调度决策的多维特性。一方面，开发人员设置高资源限制并为高峰需求配置资源，而管理员缺乏关于实际资源需求的准确数据，TechTarget 的 Enterprise Strategy Group 的分析师 Torsten Volk 告诉我。与此同时，通常基于简单的静态标签设置亲和性规则，这些标签没有被应用程序的实际性能要求所告知。资源请求仅考虑 CPU 和内存，而无法定义网络吞吐量和延迟。高优先级应用程序可能会不必要地驱逐低优先级应用程序，尽管实际上并不需要更多资源，Volk 说。
Volk 说：“所有这些都会导致一个多层次的猜测游戏，开发人员希望确保构建一个静态缓冲区，以证明他们的应用程序适用于最坏的情况，而运营商无法减少由此产生的浪费，因为他们不了解应用程序可能如何反应。” “简而言之，Kubernetes 对应用程序的实际资源需求一无所知，而应用程序 pod 完全不知道底层集群硬件的性能。”
从历史上看，资源分配策略在 YAML 文件中静态指定，并由使用 Flux 或 Argo CD 的人工管理员同步。虽然 Flux 和 Argo CD 供应商和用户试图将资源优化集成到他们的功能集中，但他们常常达不到要求。 几年前，基于 Git 的工作流程是资源调配的标准。然而，随着软件开发和 CI/CD 管道的加速，以及 AI 生成代码的兴起，ScaleOps 的 CTO 兼联合创始人 Guy Baron 在四月份的 KubeCon+CloudNativeCon Europe 上与我交谈时指出，“这些传统方法正在崩溃”。
取而代之的是，需要实时自动化资源分配，以及优化垂直和水平扩展以及 Pod 放置。这样的平台会根据工作负载需求和集群健康状况持续调整资源分配，从而确保在相关的多云和混合基础设施中实现效率和成本节约。
优化应包括：
- 垂直扩展：调整分配给每个 Pod 的 CPU 和内存量。
- 水平扩展：优化 Horizontal Pod Autoscaler (HPA) 或 Argo 支持的工作负载中的副本数量。
- 放置优化：智能地调度 Pod 以最大化集群效率。
ScaleOps 的平台就是一个抽象和自动化该过程的选项示例。它的定位不是用于分析和可见性的平台，而是用于资源自动化的平台。ScaleOps 通过消除手动分析和干预的需要来自动化决策，从而帮助资源管理成为基础设施地图的持续优化。
然后，实时做出扩展决策，例如确定如何垂直扩展、水平扩展以及将 Pod 调度到集群上以最大化性能和成本节约。此功能构成了 ScaleOps 平台的核心。
通过实时使用数据和预测算法来实现节省和扩展效率，这些算法确定在正确的时间在 Pod 级别所需的正确资源量。Baron 说，该平台是“完全上下文感知的”，会自动识别工作负载是否涉及 MySQL 数据库、无状态 HTTP 服务器或关键的 Kafka 代理，并将此信息纳入扩展决策中。
使用 ScaleOps，集群状态会持续监控。如果 Pod 调度在具有影响性能或健康检查的嘈杂邻居的节点上，它会自动迁移到具有更多可用资源的更合适的节点。
认识到 WordPress 网站、Kafka 代理、MySQL 数据库和 Airflow 管道具有不同的可用性要求和关键级别，因此每个工作负载都得到独特的处理。资源分配和扩展决策会动态调整以满足这些需求。
该平台还会实时响应集群内的变化，支持自动修复并适应使用高峰。
在实践中，开发人员不再需要担心运营责任，例如成本跟踪和资源分配，并且有更多时间编写代码和设计软件，以更直接地解决业务需求。运营团队不再被视为通过施加扼杀敏捷性的严格约束来阻碍软件开发和部署。他们也不必过多担心过度配置和为冗余资源支付过高的费用，以应对开发人员未来需求的激增，而首席技术官（尤其是首席财务官）并不喜欢在云成本上涨的情况下这样做。
该平台通过自动化资源分配和请求来为开发人员提供服务。平台引入了一个负责处理这些任务的基础设施层，而不是由开发人员手动处理这些任务。与此同时，它使开发人员可以了解和洞察他们的工作负载和资源在生产中的使用情况，Baron 说。“最终，这是关于找到平衡点——自动化重复性任务，同时让开发人员了解情况并获得授权。”
ScaleOps 有一个 免费试用选项，这是一个很好的入门平台，因为该平台提供了一种将 ScaleOps 直接链接到您的集群的直接方法。例如，我轻松地将 ScaleOps 连接到 Helm，然后 ScaleOps 开始寻找要管理的集群。
界面本身非常简单，您可以轻松地在不同的时间段（无论是 70 天、30 天等）之间导航，时间序列图显示了 CPU 使用率和内存随时间的变化。优化请求、使用率和浪费等指标是时间序列图中显示的关键指标。
为了进行更详细的分析，每个工作负载都提供了一系列功能和数据分析，这些功能和数据分析既简单又易于访问。这包括为每个工作负载实现的成本节省。也可以更改策略——无论是批处理、成本、高可用性、生产或其他策略——这意味着系统提供了根据需要动态更改或更新策略的余地。
为了获得积极的开发者体验，该平台旨在自动化资源分配和扩展的单调和动态方面，同时让开发者“参与其中”，从而深入了解他们的工作负载和资源在生产中的表现，Baron 说。
该平台通过自动化资源分配和请求为开发者提供服务。平台引入了一个基础设施层来处理这些任务，而无需开发者手动处理。与此同时，它让开发者可以了解和洞悉他们的工作负载和资源在生产中的利用情况，Baron 说。“最终，这是为了找到一个平衡点——在自动化重复性任务的同时，让开发者了解情况并获得授权。”