2. K8s环境准备与检查：kubectl与集群连通性检查、节点状态与资源查看、kube-system核心组件健康检查
说实话，很多人在部署vLLM推理集群时，一上来就急着调模型参数、搞显存优化。结果呢？跑着跑着Pod起不来，或者节点莫名其妙NotReady。我见过太多这样的案例了——最后查了一圈，发现是K8s环境本身就有问题。
所以这一章，咱们先把地基打牢。K8s环境准备与检查，说白了就是三件事：能不能连上集群、节点是不是活的、核心组件有没有在好好干活。这三步走完，你才能放心地往上堆vLLM推理服务。
2.1 kubectl与集群连通性检查
先问个问题：你确定你的kubectl能跟集群正常通信吗？
我个人的习惯是，拿到一个新集群，第一件事不是看节点，而是先跑这个命令：
kubectl cluster-info这个命令会返回控制平面的地址和核心组件的健康状态。如果返回类似这样的信息：
Kubernetes control plane is running at https://192.168.1.100:6443
CoreDNS is running at https://192.168.1.100:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy嗯，说明连通性没问题。但如果报错：
The connection to the server 192.168.1.100:6443 was refused那就得排查了。我在项目中遇到过好几次这种情况，最后发现是kubeconfig文件里的证书过期了，或者API Server的防火墙规则没放行。
另一个常用的检查命令是：
kubectl version --short它会同时显示客户端和服务端的版本。如果两边版本差太多（比如客户端1.20，服务端1.28），虽然大部分功能还能用，但某些新特性可能不支持。我建议尽量保持大版本一致。
2.2 节点状态与资源查看
连通性没问题之后，下一步就是看节点了。命令很简单：
kubectl get nodes输出大概长这样：
| NAME | STATUS | ROLES | AGE | VERSION |
|---|---|---|---|---|
| node-1 | Ready | control-plane | 30d | v1.28.2 |
| node-2 | Ready | <none> | 30d | v1.28.2 |
| node-3 | NotReady | <none> | 2d | v1.28.2 |
看到NotReady的节点了吗？这就是问题所在。为什么会这样？我教你一个排查思路：
kubectl describe node node-3在输出的末尾，你会看到Conditions部分，里面会告诉你具体原因。常见的有：
- 内存压力（MemoryPressure）：节点内存不够了
- 磁盘压力（DiskPressure）：根分区快满了
- PID压力（PIDPressure）：进程数太多
- 网络不可用（NetworkUnavailable）：网络插件没装好
我个人习惯，在部署vLLM之前，一定会先看每个节点的资源情况：
kubectl top nodes这个命令会显示CPU和内存的使用率。对于vLLM推理来说，GPU才是关键。所以我会再加一句：
kubectl describe node node-2 | grep -A 10 "Capacity"或者直接看GPU资源：
kubectl get nodes -o json | jq '.items[].status.capacity'你想想看，如果节点上只有2张A100，但你部署了3个需要独占GPU的Pod，那肯定有一个起不来。所以提前摸清家底很重要。
kubectl get nodes -o wide 来查看节点的内网IP和内核版本。有时候节点之间网络不通，就是因为IP段配置错了。
2.3 kube-system核心组件健康检查
节点都Ready了，不代表集群就稳了。核心组件才是K8s的大脑和血管。kube-system命名空间里住着这些关键角色：
- kube-apiserver：集群的入口，所有请求都经过它
- kube-controller-manager：负责维持期望状态
- kube-scheduler：决定Pod往哪个节点上放
- kube-proxy：负责网络代理和负载均衡
- CoreDNS：服务发现的核心
- etcd：集群的数据库，存着所有状态
检查方法很简单：
kubectl get pods -n kube-system理想情况下，所有Pod都应该是Running状态，而且READY列显示的是1/1或2/2。如果看到CrashLoopBackOff或Pending，那就得深入看看了。
举个例子，CoreDNS如果挂了，集群内的服务名解析就会失效。vLLM推理服务如果依赖其他微服务（比如模型下载器），那就会连不上。我曾经遇到过CoreDNS因为ConfigMap配置错误一直重启，排查了半天才发现是YAML里缩进写错了。
对于etcd，我建议额外检查一下它的健康状态：
kubectl exec -n kube-system etcd-$(hostname) -- etcdctl endpoint health如果返回healthy，那就没问题。如果超时或者报错，说明etcd集群可能有问题。etcd是K8s的命根子，它一挂，整个集群就瘫了。
- 所有节点都是Ready状态
- kube-system下的核心Pod都在Running
- etcd健康，CoreDNS正常工作
- 节点上有足够的GPU资源（用
kubectl describe node确认）
好了，环境检查这一步走完，你的K8s集群才算真正准备好了。下一节我们会聊怎么给节点打标签、配置GPU驱动——这些都是vLLM推理集群能跑起来的前提条件。
公众号:蓝海资料掘金营，微信deep3321