4、K8s核心概念：Pod、Deployment、Service、ConfigMap、Secret、Namespace、持久卷（PV/PVC）的基本概念与关系
说实话，刚接触K8s的时候，我也被这一堆名词搞得头大。Pod、Deployment、Service……它们到底谁管谁？别急，我带你捋一遍。这些概念搞清楚了，后面部署vLLM才会顺手。
4.1 Pod：最小的调度单元
Pod是K8s里你能直接操作的最小单位。你可以把它理解成「一组容器的集合」。这些容器共享网络、存储，以及一些生命周期管理。
我习惯把Pod比作「豆荚」——里面可以有一颗豆子（一个容器），也可以有多颗豆子（多个容器）。但实际生产中，我建议一个Pod里只跑一个主容器。除非你有边车模式（Sidecar）的需求，比如日志收集、网络代理等。
4.2 Deployment：声明式管理Pod
你不可能手动一个个创建Pod吧？Deployment就是用来管理Pod的「控制器」。你告诉它「我要3个Pod，镜像用vllm:v0.4.0」，它就会帮你搞定。
Deployment的核心能力包括：
- 滚动更新：新版本上线，逐个替换Pod，不影响服务
- 回滚：出问题了？一键回到上一个版本
- 扩缩容：流量大了，把Pod从3个变成10个
- 自愈：Pod挂了？Deployment会自动再起一个
我曾经在生产环境遇到过一个问题：Deployment的滚动更新策略没配好，导致新Pod还没就绪，旧Pod就被删了，服务中断了几秒。嗯，这里要注意——minReadySeconds和maxSurge这两个参数一定要调好。
4.3 Service：稳定的网络入口
Pod是动态的，随时可能被重建，IP也会变。那客户端怎么访问？Service就是干这个的——它提供一个固定的虚拟IP和DNS名称，把请求转发到后端的Pod上。
Service的类型有几种：
| 类型 | 说明 | 适用场景 |
|---|---|---|
| ClusterIP | 集群内部可访问 | 内部服务调用 |
| NodePort | 通过节点IP+端口访问 | 开发测试环境 |
| LoadBalancer | 云厂商提供负载均衡器 | 生产环境对外暴露 |
部署vLLM时，我一般用ClusterIP让内部服务调用，再用Ingress对外暴露API。这样更安全，也更好管理。
4.4 ConfigMap & Secret：配置与敏感信息
应用需要配置吧？比如模型路径、日志级别。这些可以放在ConfigMap里。那API密钥、数据库密码呢？这些敏感信息放Secret里。
两者的区别很简单：
- ConfigMap：明文存储，适合非敏感配置
- Secret：Base64编码（注意不是加密），适合敏感信息
4.5 Namespace：逻辑隔离
一个K8s集群可以给多个团队用。怎么隔离？Namespace就是干这个的。每个Namespace里的资源是独立的，比如dev、test、prod三个环境各一个Namespace。
我个人的习惯是：每个项目一个Namespace，资源配额（ResourceQuota）也配上，防止某个项目把集群资源吃光。
4.6 持久卷（PV/PVC）：数据不丢失
Pod是临时的，但数据不能丢。比如vLLM的模型文件、推理日志。这时候就需要持久化存储。
K8s用PV（PersistentVolume）和PVC（PersistentVolumeClaim）来管理存储：
- PV：集群管理员提供的存储资源，比如NFS、Ceph、云硬盘
- PVC：用户对存储的请求，比如「我要10GB，读写一次」
PVC绑定到PV后，Pod就可以挂载使用了。Pod删了，数据还在。
4.7 它们之间的关系
说了这么多，它们到底怎么配合？我画了一张图，你看一眼就明白了：
你看，Deployment管理Pod的创建和更新，Service为Pod提供稳定的访问入口，ConfigMap和Secret给Pod注入配置和密钥，PV/PVC为Pod提供持久化存储。所有这些资源都运行在Namespace的逻辑隔离边界内。
说白了，K8s就是一套「声明式」的资源编排系统。你告诉它你想要什么状态，它自己会想办法达到。这个思想贯穿始终，后面部署vLLM的时候你会深有体会。
公众号:蓝海资料掘金营，微信deep3321