K8s在VPS服务器部署常见问题FAQ

用Kubernetes（K8s）在VPS服务器部署应用时，网络不通、资源分配不均、存储异常这些问题常让人头疼。本文整理高频问题的诊断思路和解决方法，帮你快速排查故障，保障集群稳定运行。

网络问题：Pod连不上外网，Service暴露失败

最近有位客户部署微服务集群时，发现新创建的Pod始终无法调用外部API。排查过程中，我们先检查了Pod的IP地址和路由表，确认内部网络正常；接着查看VPS服务器的防火墙日志，发现iptables规则里误将10.244.0.0/16网段（K8s默认Pod子网）的出站流量全部拦截了。原来客户为了安全临时加强了防火墙策略，却忽略了K8s集群的内部网段。调整防火墙规则允许该网段访问外网后，问题立刻解决。

另一个常见现象是Service无法通过NodePort暴露。上周有用户反馈，配置了NodePort类型的Service后，用VPS公网IP加端口始终连不上。检查发现，用户将Service端口设为30080，但VPS服务器上的Nginx刚好占用了这个端口。关闭Nginx服务并修改Service端口为30081后，外部请求顺利接入。需要注意：VPS的安全组规则也要同步放行NodePort的端口范围（默认30000-32767）。

资源管理：Pod总崩溃，节点负载不均衡

某电商客户大促前扩容时，新部署的订单服务Pod频繁OOM（内存溢出）。查看资源配置发现，Pod的limits.memory仅设置了512Mi，但实际压测时内存峰值达到800Mi。调整为limits.memory=1Gi并设置requests.memory=768Mi后，Pod稳定运行。这里的关键是：requests要接近实际使用量，limits略高于峰值，既能保证调度公平，又能防止资源滥用。

节点负载不均的问题在3节点集群中最常见。之前有用户的集群里，一个节点CPU使用率长期90%，另外两个却不到30%。查看调度日志发现，K8s默认的调度器优先选择资源剩余多的节点，但用户的Pod有特定的亲和性要求。通过添加反亲和性规则"podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution"，强制将同类型Pod分散到不同节点，负载很快趋于平衡。

存储问题：PVC绑定失败，数据意外丢失

某技术团队搭建日志系统时，PVC一直处于Pending状态。检查发现，他们创建的PV是HostPath类型（基于VPS本地磁盘），但PVC声明的storageClassName是"nfs"，两者不匹配。修改PVC的storageClassName为""（使用默认存储类）后，PV和PVC顺利绑定。如果使用云存储（如Ceph、NFS），一定要确保PV的存储类、容量、访问模式（ReadWriteOnce/ReadWriteMany）与PVC完全一致。

数据丢失的情况多发生在存储后端故障时。曾有用户使用VPS本地磁盘作为存储卷，某次VPS重启后，Pod里的配置文件全部丢失。原来他们用了emptyDir类型的临时存储，数据不会持久化。更换为HostPath并设置定期备份策略后，问题彻底解决。建议关键数据优先使用网络存储（如NFS），并开启存储快照功能。

实际部署中，遇到问题先别急着重装集群。可以通过"kubectl describe pod"看事件日志，用"kubectl logs"查容器输出，结合VPS的系统监控（如top、df -h）定位瓶颈。掌握这些排查技巧，90%的K8s部署问题都能快速解决，让VPS服务器真正成为高效稳定的应用承载平台。