1. 为什么vLLM服务需要网络策略：vLLM架构特点、暴露端口分析、常见攻击面
说实话，我第一次在生产环境部署vLLM的时候，差点翻车。
那时候我习惯性地把服务往K8s里一丢，配个Service就完事了。结果第二天一查日志，发现有人在疯狂扫我的API端口。嗯，从那以后，我再也不敢轻视网络策略了。
今天我们就来聊聊，为什么vLLM服务特别需要网络策略的保护。
1.1 vLLM的架构特点
vLLM本质上是一个高性能推理引擎。它把大模型加载到GPU显存里，然后对外提供API接口。你想想看，一个能跑Llama 3 70B的服务，显存占用少说也得140GB起步。
它的架构大概长这样：
从图上你能看到，vLLM对外暴露了好几个端口。每个端口都有不同的用途，也对应着不同的风险。
1.2 暴露端口分析
我整理了一份端口清单，你在部署的时候一定要对照着看：
| 端口 | 用途 | 风险等级 | 说明 |
|---|---|---|---|
| 8000 | OpenAI 兼容 API | 高 | 推理接口，可被直接调用 |
| 8001 | Prometheus 指标 | 中 | 暴露模型性能数据 |
| 8002 | 内部通信 | 中 | 多GPU节点间通信 |
| 8080 | 健康检查 | 低 | K8s探针使用 |
我个人习惯把8000端口视为最高风险点。为什么呢？因为它是直接面向用户的推理入口。一旦暴露在公网，任何人都可以调用你的模型，消耗你的GPU资源。
1.3 常见攻击面分析
说白了，vLLM服务面临的攻击面主要有这么几类：
1.3.1 API滥用攻击
这是最常见的。攻击者通过你的API接口，无限制地发送推理请求。你想想看，一次推理可能消耗几十GB的显存，并发一上来，GPU直接OOM。
- 无限制调用：没有认证，谁都能用
- 大Token攻击：故意发送超长上下文，耗尽显存
- 并发风暴：短时间内发起大量请求
1.3.2 指标泄露
8001端口暴露的Prometheus指标，看起来人畜无害。但你知道吗？里面包含了模型名称、请求延迟、GPU利用率等信息。这些数据对竞争对手来说，价值连城。
1.3.3 内部通信劫持
如果你部署了多节点vLLM（比如张量并行），节点之间需要通过8002端口通信。这个端口如果暴露，攻击者可以注入伪造的推理结果，或者窃取中间数据。
1.3.4 健康检查接口滥用
虽然风险低，但也不是完全没风险。我记得有一次，有人通过反复调用/health接口，让K8s的探针误判，导致Pod被频繁重启。
1.4 为什么网络策略是必需品
你可能会问：我加个认证不就行了？
嗯，认证确实能挡住一部分攻击。但你想过没有：
- 认证本身也有漏洞（比如JWT泄露）
- 内部服务之间的通信，认证往往被忽略
- 指标端口通常没有认证
网络策略的作用，就是在网络层面做一层隔离。说白了，就是告诉K8s：哪些Pod可以访问vLLM，哪些不行。
- API端口（8000）：只允许Ingress Controller访问
- 指标端口（8001）：只允许Prometheus访问
- 内部通信（8002）：只允许同组vLLM Pod访问
- 健康检查（8080）：只允许Kubelet访问
这样做的好处很明显：即使某个Pod被攻破了，攻击者也无法横向移动到你vLLM的内部端口。
好了，这一章我们分析了vLLM为什么需要网络策略。下一章我会手把手教你写NetworkPolicy的YAML，把刚才说的这些原则落地。
公众号:蓝海资料掘金营，微信deep3321