Kubernetes 1.35 引入的原生 Workload API 和 Gang Scheduling 支持，被业界视为云原生 AI 基础设施的一次“内核级重构”。要真正理解这次升级的分量，我们不仅要看它带来了什么，更要看它试图取代（或融合）什么。
在 v1.35 之前，面对 AI 训练任务的“资源死锁”痛点，社区实际上已经演化出了一个庞杂的“第三方调度器动物园”。本文将从原生原语出发，盘点现有生态选择，并揭示生产环境中的架构演进方向。
在 Kubernetes 的经典设计中，Pod 是最小的原子调度单元。调度器采用“贪婪算法”，依次处理队列中的 Pod，只要当前节点满足需求就立即绑定。这种机制在微服务时代运转完美，但在 AI 分布式训练场景下却遭遇了语义冲突：
去年有个典型场景在安全社区引发热议：开发者在Cursor里装了Supabase的MCP插件，为了让AI能直接查数据库，配置了service_role密钥（数据库超级管理员权限）。某天客户在工单里随口问"能看看我们的集成配置吗"，AI把这句话当成了指令，直接在回复里打印出了Token。
这个案例虽然更多作为"风险演示"出现在安全报告中，但它揭示的问题是真实的：MCP协议让AI获得了操作权限，而Prompt注入攻击能让黑客通过自然语言"劫持"这些权限。
Model Context Protocol (MCP) 是Anthropic在2024年末推出的开放标准，用于让大语言模型（如Claude、GPT）调用本地工具和数据源。以前AI只能"动嘴"（生成文本），现在通过MCP，它可以：
随着大语言模型（LLM）从“尝鲜玩具”全面转变为企业的“生产力底座”，一个被所有技术管理者反复拷问的问题浮出水面：当 API 调用黑盒化之后，我们该如何像管理数据库或微服务那样，去管理这些庞大而昂贵的 AI 模型？
如果说 2024 年是大家忙着“跑通 Demo”的一年，那么 2026 年则是“精细化治理”的元年。曾经简单的“调用成功/失败”日志，已无法回答今天复杂的运维问题：“为什么这个 Agent 昨天还很聪明，今天就开始胡说八道？”、“上个月的 Token 费用为什么突然翻倍？”、“有没有用户正在试图通过 Prompt 注入攻击我们的客服机器人？”
本文将基于最新的行业实践，拆解当前主流的三大 LLM 监控体系，并提供一份切实可行的架构选型指南。
LLM 的监控思路正在经历一场从“基础设施层”向“内容语义层”的范式转移。目前的业界解决方案可以清晰地划分为三个层级：
在 AI 和云原生基础设施持续演进的 2026 年，镜像与模型分发正逐渐从“边缘优化点”转变为影响平台效率的重要环节。传统依赖中心化 Registry + CDN 的方式，在面对“大规模节点并发、大体积镜像或模型”的场景时，往往面临速度与成本的双重挑战。Dragonfly 正是在这样的背景下成长为 CNCF 毕业（Graduated）项目，并在 Ant Group、Alibaba、Datadog、DiDi、Kuaishou 等企业的生产环境中被采用，用于支撑容器与 AI 模型的高效分发。
Dragonfly 是一个基于 P2P 技术的云原生镜像与文件分发系统。其核心价值在于利用集群节点的闲置带宽构建自组织网络，解决大规模集群下的带宽瓶颈问题。
在 Kubernetes 的网络世界里，kube-proxy 长期扮演着“守门人”的角色，负责将 Service 的流量分发到后端的 Pod。然而，长久以来，我们一直忍受着 iptables 模式带来的性能折磨，或被迫迁移到维护复杂的 IPVS 模式。
时间来到 2026 年，随着 Kubernetes 1.33 于 2025 年 4 月正式 GA（General Availability），nftables 模式已不再是实验性的选项，而是成为了生产环境的“新标配”。甚至在 2025 年底发布的 v1.35 中，曾经的救火队员 ipvs 模式已被正式标记为 弃用（Deprecated）。这标志着 Linux 内核网络栈在云原生时代的一次彻底“正本清源”。
本文将结合最新的基准测试数据，深入探讨 nftables 对 K8s 的核心意义，并盘点各大云厂商的支持现状与未来路线。
要理解 nftables 的革命性，首先要回顾 iptables 和 IPVS 的痛点。
回望过去几年在可观察性领域的摸爬滚打，尤其是围绕 Metrics 体系的建设，感觉就像是一场漫长的架构修行。从最开始守着单机 Prometheus 还要担心磁盘爆满，到后来引入 Thanos 试图做“无限存储”，再到如今用 Mimir 重构整个监控中枢，这些经历散落在记忆里，甚至有些细节已经开始模糊。
最近静下心来，把这些年踩过的坑、做过的技术决策重新梳理了一遍，忽然发现：这其实并不是一个单纯的技术迭代故事，而是一次次面对不同规模痛点时的哲学抉择。那些曾经以为是“升级版”的方案，实则是完全不同的物种。今天这篇，就当作是对这段遗忘经验的抢救性概括，聊聊我眼中的三种架构形态，以及为什么在特定规模下，Mimir 会成为那个“对”的选择。
最近曝光的 Ingress-NGINX “IngressNightmare” 漏洞，把 nginx‑ingress 再次推上风口浪尖，也给还停留在传统 Ingress 的集群敲了警钟。
下面从漏洞回顾、风险分析、短期修补，到如何借机迁移到 Gateway API，以及迁移前后的优劣对比，做一篇面向工程实践的技术梳理。
nginx -t 进行校验。这个过程中对注解和配置片段的过滤不足，允许攻击者注入任意 NGINX 指令，最终导致在控制器 Pod 上执行任意代码（RCE）。在讨论 Gateway API 迁移之前，所有还在跑 ingress‑nginx 的集群需要立即做两件事：