AI 资源库 · 已整理 2 项

自动扩缩

查看与自动扩缩相关的 AI 资讯、工具、Skill、工作流和开源项目。

Agent 与工作流

为什么 Kubernetes 自动扩缩容器会互相打架（以及为什么解决方案必须是自主的）

Kubernetes 里管“该开几个副本”和“每个副本该给多少 CPU/内存”的其实是好几套独立工具：HPA 按 CPU 百分比增减副本，VPA 按历史用量调整资源申请，KEDA 按 Kafka 队列积压决定副本数，Karpenter 按声明资源申请新机器。问题是它们各自跑各自的循环，看到的都是局部信息，还同时改同一批配置字段。比如 VPA 把 CPU 申请调小，HPA 的分母就跟着变小，同样的流量会被算成利用率超高，于是猛加副本，结果副本越来越多、每个越来越小，互相把对方越推越远；KEDA 加副本、HPA 又按低 CPU 减回来；GitOps 看到副本数和 Git 不一致还会把它改回去。作者认为水平和垂直扩缩本来就是一道联立方程，应该由一个统一控制面同时看 CPU、队列、延迟、节点价格和 Git 配置，一起给出副本数和资源申请。文中也提到生产集群 CPU 平均利用率只有约 8%，但这些方案的落地细节和可用性文中没有说明。

文中可用工具

  • HPA根据 CPU 等运行时指标增减 Pod 副本数
  • VPA根据历史用量调整容器的 CPU/内存申请
  • KEDA根据 Kafka 等外部事件源的队列积压决定副本数
  • Karpenter为 Pending 的 Pod 按声明资源申请节点
  • Cluster Autoscaler在有 Pod 无法调度时扩缩节点池
  • Argo CD按 Git 仓库内容同步集群状态并检测漂移
  • FluxGitOps 工具，按版本控制强制集群基线状态
  • Helm用 values 声明副本数和资源规格
# Kubernetes# GitOps# 自动扩缩# Agent 上下文# 工作流自动化
☆ 收藏查看来源 ↗
评论 · 分享第一个看法
Agent 与工作流

AI 任务排队等候，GPU 却闲置：Kubernetes 有了新方案

这篇文章是 KubeCon 前瞻专栏，讲 Kubernetes 社区怎么让 GPU 更好地服务 AI。问题在于：负责把任务分配到现有机器的调度器和负责加机器的自动扩缩器各干各的，结果任务卡在排队，昂贵的 GPU 却闲着。目前有几个方向：HPE 用开源工具自动收集 Pod 重启信息并推送到 Slack，减少人工排查；AWS 提出让扩缩器更懂调度器，并用动态资源分配、工作负载感知调度和 provisioning requests 衔接两边；SIG-Autoscaling 已有公开提案，让两个环节直接对话。另外 CNCF 沙箱项目 llm-d 发布 v1.0，IBM 测试中智能体任务推理成本降低 11.5 倍、缓存复用约 98%。这些多数是提案或演示，尚未说明何时默认可用。

文中可用工具

  • HPE Private Cloud AIHPE 的私有云 AI 平台，用于托管长时间运行的 AI/ML 任务
  • k8s-pod-restart-info-collector开源 Kubernetes 排障工具，自动收集 Pod 重启信息并发送到 Slack
  • llm-dCNCF 沙箱项目，用于在云原生环境分布式部署 AI 推理，已发布 v1.0
  • dynamic resource allocation (DRA)Kubernetes 的动态资源分配机制，让扩缩器更了解 GPU 等资源需求
  • provisioning requests连接调度器和扩缩器的配套机制，原文未说明具体用法
# Kubernetes# 推理部署# GPU 调度# 自动扩缩# llm-d
☆ 收藏查看来源 ↗
评论 · 分享第一个看法