2. 环境准备：部署Kubernetes集群、安装Helm、配置kubectl
好，咱们正式开始动手。这一章的目标很明确——把Kubernetes集群跑起来，装上Helm，配好kubectl。说白了，就是给vLLM模型部署搭好舞台。我个人习惯先用minikube做本地验证，再考虑生产环境用kubeadm。你想想看，如果本地都跑不通，上生产也是白搭。
2.1 选择集群部署方式：kubeadm vs minikube
这两种方式我都用过，说说我的感受。
| 特性 | kubeadm | minikube |
|---|---|---|
| 适用场景 | 生产环境、多节点集群 | 本地开发、单节点测试 |
| 资源消耗 | 较高，需要多台机器 | 较低，一台笔记本就能跑 |
| 安装复杂度 | 中等，需要手动配置网络插件 | 简单，一条命令启动 |
| 持久化存储支持 | 原生支持，需配置StorageClass | 支持，但需要额外驱动 |
我在项目中遇到过这样的情况：用minikube验证好的PV/PVC配置，到了kubeadm集群上因为StorageClass没配好，折腾了半天。所以我的建议是——本地用minikube快速迭代，生产环境老老实实用kubeadm。
2.2 使用minikube部署本地集群
如果你只是想快速体验vLLM的持久化存储，minikube是最省事的。嗯，这里要注意：minikube的版本和Kubernetes版本要匹配，否则会出一些莫名其妙的错。
# 安装minikube（Linux/macOS）
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
# 启动集群，指定Kubernetes版本和资源
minikube start --kubernetes-version=v1.28.0 --cpus=4 --memory=8192
# 验证集群状态
kubectl get nodes我曾经因为没给minikube分配足够的内存，导致vLLM模型加载时直接OOM。8GB内存是底线，如果你要跑7B以上的模型，建议16GB起步。
kubectl config use-context minikube 切换。
2.3 使用kubeadm部署生产级集群
生产环境我推荐kubeadm。它不花哨，但稳定。说白了，Kubernetes官方维护的工具，社区支持最好。
先在所有节点上安装容器运行时和kubeadm：
# 安装containerd（所有节点）
sudo apt-get update
sudo apt-get install -y containerd
# 安装kubeadm、kubelet、kubectl（所有节点）
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl然后初始化控制平面节点：
# 在master节点执行
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
# 配置kubectl
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config接下来安装网络插件。我习惯用Flannel，简单可靠：
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml--pod-network-cidr 和你的物理网络不重叠。
2.4 安装Helm——Kubernetes的包管理器
Helm这东西，说白了就是Kubernetes的apt-get。没有它，你部署vLLM得写几十个YAML文件，有了它，一条命令搞定。
# 安装Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# 验证安装
helm version
# 添加常用仓库
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add stable https://charts.helm.sh/stable
helm repo update我个人习惯把Helm的版本和Kubernetes版本对应起来。Helm 3.x兼容Kubernetes 1.16以上版本，但如果你用Kubernetes 1.28，建议Helm 3.12+。
2.5 配置kubectl——你的集群遥控器
kubectl配置好了，你才能跟集群对话。这里有几个我常用的配置技巧：
- 自动补全——省时间利器
- 别名设置——少敲几个字母
- 多集群切换——本地测试和生产环境来回切
# 启用kubectl自动补全
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc
# 设置别名
alias k='kubectl'
alias kg='kubectl get'
alias kd='kubectl describe'
alias kdel='kubectl delete'
# 查看当前上下文
kubectl config current-context
# 切换上下文
kubectl config use-context minikubekubectl cluster-info 验证集群连通性。如果返回了集群信息，说明环境准备就绪。
2.6 验证环境——确保一切就绪
环境搭好了，咱们跑个快速验证：
# 检查节点状态
kubectl get nodes
# 检查系统Pod
kubectl get pods -n kube-system
# 测试Helm
helm list
# 创建一个测试Pod
kubectl run test-pod --image=nginx --restart=Never
kubectl get pods如果所有节点都是Ready状态，系统Pod都在运行，Helm能正常列出chart，那恭喜你——环境准备完成了。
我记得有一次帮同事排查问题，他卡在kubectl命令报错上，最后发现是KUBECONFIG环境变量指向了错误的文件。所以，如果你遇到类似问题，先检查 echo $KUBECONFIG 和 cat ~/.kube/config。
2.7 本章知识体系
下面这张图帮你理清本章的核心逻辑：
环境准备是基础中的基础。集群没搭好，后面所有关于持久化存储、vLLM模型部署的讨论都是空中楼阁。我个人建议你花点时间把这一步做扎实，后面会省很多事。