昨天有幸参加了 Acronis 公司的 Sergey Saburov 的关于 “Agentic Engineering & LLM Security” 的分享。Sergey 深入剖析了现代 LLM 应用面临的安全威胁，并结合 OWASP LLM Top 10 框架提供了大量实战案例。
现结合 OWASP LLM Top 10 v2.0 (2025) 最新官方标准，对分享内容进行了梳理与总结。针对原分享中部分术语的偏差（如 LLM06、LLM10 等）做了必要的修正，并整理了面向 Kubernetes 平台工程师的 Python 代码 PoC（概念验证）与防御脚本，希望能为大家构建安全的 AI 系统提供参考。
定义：包括直接提示注入（Jailbreaking）和间接提示注入（Indirect Prompt Injection）。间接注入是指攻击者将恶意指令植入 LLM 可能检索或处理的数据源（如网页、邮件、文档）中。
在基础设施领域，有些版本更新是“锦上添花”，而有些则是“脱胎换骨”。如果说 Helm 3 让我们告别了 Tiller 的噩梦，那么于 2025 年 11 月 正式发布的 Helm 4，则是 Helm 真正理解并融入 Kubernetes 声明式哲学的成人礼。
经过两个月的社区验证与官方文档沉淀，本文将基于 Helm 4 的实际发布状态，为您澄清那些容易被误解的技术细节。
作为 K8s 包管理的“事实标准”，Helm 4 在发布两个月后，我们终于可以在生产环境中冷静地审视它的价值。对于追求极致稳定的 Platform Engineer 工程师来说，Helm 4 最大的意义不在于功能堆砌，而在于它如何偿还了长久以来的技术债务。
Helm 3 用户最痛的点是什么？莫过于 kubectl apply 和 helm upgrade 之间的“神仙打架”。
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 会成为那个“对”的选择。
