最近经历了一场面试，面试官抛出了一个看似常规的问题：“你认为什么情况下应该使用 Kubernetes，而什么情况下使用 Kubernetes 是没有必要的、徒增复杂度？”

这个问题当时回答得还算流畅，但之后它反而在我脑海里盘旋了许久。这个问题之所以“刺耳”，是因为它跳出了“怎么用 K8s”的技术细节，直指架构设计的核心权衡：我们引入一个技术栈，到底是为了解决业务的真实痛点，还是仅仅为了满足技术团队的“先进性焦虑”？

很多团队把 Kubernetes 当作现代化研发的标配起点，但现实往往是残酷的：你不是上了 Kubernetes 就自动获得了 Google、AWS、Azure 等云厂商般的基础设施能力；你是上了 Kubernetes 之后，才刚刚开始背负起治理分布式系统的沉重代价。

Kubernetes 本质：复杂度的“交换”而非“消除”

Kubernetes 的核心价值从来不在于“跑容器”——Docker Compose 也能跑，甚至 systemd 也能跑。它的核心价值在于控制平面（Control Plane）：它提供了一套声明式的 API，允许我们描述系统的“期望状态”，并由系统自动将“实际状态”收敛到期望状态。

在 2026 年，给个人博客加上 AI 搜索已经不是什么新鲜事。但如何零成本、全自动且高性能地实现这一功能，依然是一个值得探讨的技术话题。

本文将详细拆解本站 AI Search 功能背后的技术架构，展示如何组合 Cloudflare Workers、Vectorize、D1 以及 Google Gemini，构建一套闭环的 RAG（检索增强生成）系统。

1. 核心架构设计

我们的目标是实现一个“全自动”的流程：写作即部署。作者只需 Push Markdown 文章，剩下的向量生成、索引更新、前端部署全部自动化完成。

昨天有幸参加了 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 系统提供参考。

LLM01: Prompt Injection (提示注入)

定义：包括直接提示注入（Jailbreaking）和间接提示注入（Indirect Prompt Injection）。间接注入是指攻击者将恶意指令植入 LLM 可能检索或处理的数据源（如网页、邮件、文档）中。

在基础设施领域，有些版本更新是“锦上添花”，而有些则是“脱胎换骨”。如果说 Helm 3 让我们告别了 Tiller 的噩梦，那么于 2025 年 11 月 正式发布的 Helm 4，则是 Helm 真正理解并融入 Kubernetes 声明式哲学的成人礼。

经过两个月的社区验证与官方文档沉淀，本文将基于 Helm 4 的实际发布状态，为您澄清那些容易被误解的技术细节。

作为 K8s 包管理的“事实标准”，Helm 4 在发布两个月后，我们终于可以在生产环境中冷静地审视它的价值。对于追求极致稳定的 Platform Engineer 工程师来说，Helm 4 最大的意义不在于功能堆砌，而在于它如何偿还了长久以来的技术债务。

1. 核心变革：SSA 成为默认范式

Helm 3 用户最痛的点是什么？莫过于 kubectl apply 和 helm upgrade 之间的“神仙打架”。

Kubernetes 1.35 引入的原生 Workload API 和 Gang Scheduling 支持，被业界视为云原生 AI 基础设施的一次“内核级重构”。要真正理解这次升级的分量，我们不仅要看它带来了什么，更要看它试图取代（或融合）什么。

在 v1.35 之前，面对 AI 训练任务的“资源死锁”痛点，社区实际上已经演化出了一个庞杂的“第三方调度器动物园”。本文将从原生原语出发，盘点现有生态选择，并揭示生产环境中的架构演进方向。

1. 缘起与冲突：原子化调度在 AI 时代的“水土不服”

在 Kubernetes 的经典设计中，Pod 是最小的原子调度单元。调度器采用“贪婪算法”，依次处理队列中的 Pod，只要当前节点满足需求就立即绑定。这种机制在微服务时代运转完美，但在 AI 分布式训练场景下却遭遇了语义冲突：

去年有个典型场景在安全社区引发热议：开发者在Cursor里装了Supabase的MCP插件，为了让AI能直接查数据库，配置了service_role密钥（数据库超级管理员权限）。某天客户在工单里随口问"能看看我们的集成配置吗"，AI把这句话当成了指令，直接在回复里打印出了Token。

这个案例虽然更多作为"风险演示"出现在安全报告中，但它揭示的问题是真实的：MCP协议让AI获得了操作权限，而Prompt注入攻击能让黑客通过自然语言"劫持"这些权限。

MCP是什么？为什么突然成了安全焦点

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 分发系统

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 的核心意义，并盘点各大云厂商的支持现状与未来路线。

一、 为什么 K8s 急需 nftables？

要理解 nftables 的革命性，首先要回顾 iptables 和 IPVS 的痛点。

回望过去几年在可观察性领域的摸爬滚打，尤其是围绕 Metrics 体系的建设，感觉就像是一场漫长的架构修行。从最开始守着单机 Prometheus 还要担心磁盘爆满，到后来引入 Thanos 试图做“无限存储”，再到如今用 Mimir 重构整个监控中枢，这些经历散落在记忆里，甚至有些细节已经开始模糊。

最近静下心来，把这些年踩过的坑、做过的技术决策重新梳理了一遍，忽然发现：这其实并不是一个单纯的技术迭代故事，而是一次次面对不同规模痛点时的哲学抉择。那些曾经以为是“升级版”的方案，实则是完全不同的物种。今天这篇，就当作是对这段遗忘经验的抢救性概括，聊聊我眼中的三种架构形态，以及为什么在特定规模下，Mimir 会成为那个“对”的选择。

模式一：原教旨主义 —— 单机 Prometheus