2、Kubernetes核心概念速览：Pod、Deployment、Service、ConfigMap、Secret、Namespace、PV/PVC、Node与Cluster
好，咱们直接进入正题。在把vLLM塞进Kubernetes之前，你得先认识一下这群“零件”。说白了，Kubernetes就是一个管理容器的操作系统，而下面这些概念，就是它的核心API对象。我刚开始接触K8s时，也被这一堆名词搞得头大，但后来发现，只要搞懂它们各自管什么，其实很简单。
一句话总结：Pod是“进程”，Deployment是“管家”，Service是“门牌”，ConfigMap/Secret是“配置文件”，Namespace是“隔间”，PV/PVC是“硬盘”，Node是“工位”，Cluster是“整间办公室”。
2.1 Pod：最小调度单元
Pod是Kubernetes里你能直接操作的最小单位。它里面可以跑一个或多个容器，共享网络和存储。我个人的习惯是，一个Pod只跑一个主容器，除非有sidecar（比如日志收集、网络代理）才放一起。
举个例子，你部署vLLM时，vLLM的推理进程就跑在一个Pod里。如果Pod挂了，Kubernetes会重新拉起来——但前提是你得用Deployment来管它。
💡 我的经验：Pod的IP是动态的，重启就会变。所以千万别在代码里写死Pod IP，要用Service来访问。
2.2 Deployment：声明式管理
Deployment是Kubernetes最常用的工作负载控制器。你告诉它“我要跑3个vLLM副本”，它就会一直维持3个。如果某个Pod挂了，它会自动再起一个。
我记得有一次生产环境，模型推理服务突然变慢，排查后发现是某个Pod内存泄漏。Deployment自动重启了那个Pod，服务很快就恢复了。这就是声明式的好处——你只管描述期望状态，K8s负责执行。
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-deployment
spec:
replicas: 3
selector:
matchLabels:
app: vllm
template:
metadata:
labels:
app: vllm
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
ports:
- containerPort: 80002.3 Service：稳定的网络入口
Pod会生会灭，IP会变。那客户端怎么访问？Service就是干这个的——它提供一个固定的Cluster IP或DNS名称，把请求转发到后端的Pod上。
说白了，Service就是一个“反向代理+负载均衡”。你访问Service的IP，它自动把流量分到健康的Pod上。
⚠️ 注意：Service默认是ClusterIP，只能在集群内部访问。如果需要外部访问，要用NodePort或LoadBalancer类型。我在部署vLLM对外提供API时，通常用LoadBalancer，配合Ingress做域名和HTTPS。
2.4 ConfigMap & Secret：配置与敏感信息
这两个都是用来给Pod注入配置的。区别很简单：ConfigMap存明文配置（比如模型路径、日志级别），Secret存敏感信息（比如API密钥、数据库密码）。
我曾经犯过一个错——把数据库密码直接写在了Dockerfile里。后来改用Secret挂载，安全多了。记住，Secret在etcd里是base64编码的，但这不是加密，只是编码。生产环境一定要开启etcd加密。
apiVersion: v1
kind: ConfigMap
metadata:
name: vllm-config
data:
model_name: "llama-3-8b"
max_model_len: "4096"
---
apiVersion: v1
kind: Secret
metadata:
name: vllm-secret
type: Opaque
data:
api_key: bXktc2VjcmV0LWtleQ== # base64编码的"my-secret-key"2.5 Namespace：逻辑隔离
Namespace就像一个大房子里的不同房间。你可以把开发、测试、生产环境放在不同的Namespace里，资源互不干扰。Kubernetes默认有default、kube-system等Namespace。
我个人习惯，每个项目或每个团队一个Namespace。比如vLLM推理服务放在ai-inference命名空间，日志收集放在logging命名空间。这样管理起来清晰很多。
2.6 PV & PVC：持久化存储
Pod是有生命周期的，重启后数据就没了。但大模型的权重文件、推理日志这些数据需要持久化。PV（PersistentVolume）是集群管理员提供的存储资源，PVC（PersistentVolumeClaim）是用户对存储的申请。
你想想看，vLLM加载一个70B的模型，光权重文件就上百GB。如果每次Pod重启都重新下载，那效率太低了。所以我会用PVC挂载一个共享存储（比如NFS或Ceph），模型文件放在上面，所有Pod都能访问。
🚨 避坑指南：我曾经遇到过PVC和Pod不在同一个节点，导致Pod启动失败。后来加了节点亲和性（nodeAffinity）才解决。另外，PV的回收策略要选对，Retain模式最安全。
2.7 Node & Cluster：基础设施
Node就是集群里的物理机或虚拟机，每个Node上运行着kubelet（K8s的代理）。Cluster就是一组Node的集合，加上控制平面（Master节点）。
在部署vLLM时，Node的选择很关键。大模型推理需要GPU，所以Node必须带有NVIDIA GPU，并且要安装好NVIDIA驱动和nvidia-docker。我一般会用nvidia.com/gpu这个资源来调度。
| 概念 | 一句话解释 | vLLM场景中的角色 |
|---|---|---|
| Pod | 最小运行单元 | 运行vLLM推理进程 |
| Deployment | 管理Pod的声明式控制器 | 保证vLLM副本数，支持滚动更新 |
| Service | 稳定的网络入口 | 对外暴露vLLM的API接口 |
| ConfigMap | 明文配置注入 | 配置模型参数、环境变量 |
| Secret | 敏感信息注入 | 存储API密钥、HuggingFace Token |
| Namespace | 逻辑隔离空间 | 区分不同环境或项目 |
| PV/PVC | 持久化存储 | 存储模型权重文件、日志 |
| Node | 集群中的工作节点 | 提供GPU算力 |
| Cluster | 整个K8s集群 | 所有资源的集合 |
好了，这些概念你心里有个谱就行。后面我们部署vLLM时，会一个个用到它们。到时候你会发现，原来K8s也没那么神秘，对吧？