使用K8S云服务器常见问题FAQ：从Pod调度到服务暴露全解答

K8S云服务器作为容器化部署的核心基础设施，在支撑微服务架构时能显著提升资源利用率，但实际使用中从Pod调度到服务暴露环节常遇到各类问题。本文整理了高频问题的现象、诊断逻辑与解决方法，帮你快速排查故障。

Pod调度常见问题与应对

Pod长时间卡在Pending状态

创建Pod后，状态长时间卡在Pending，迟迟无法调度到节点上——这是新手用户最常遇到的问题之一。可能的原因有两个方向：一是集群资源不足，当节点剩余CPU、内存无法满足Pod的资源请求（Requests）时，调度器就会找不到合适节点；二是节点选择器（NodeSelector）配置错误，比如Pod指定需要标签为"disk=ssd"的节点，但实际集群中没有节点打这个标签，调度自然失败。

解决方法分两步走：先用`kubectl describe pod `查看事件（Events），如果看到"0/3 nodes are available"类似提示，说明资源不足，可通过添加节点或调整Pod的Requests参数（如降低内存请求值）解决；若事件显示"node(s) didn't match node selector"，则检查Pod的nodeSelector字段，确保与节点标签（可用`kubectl get nodes --show-labels`查看）完全匹配。

Pod频繁被驱逐（Evicted）

运行中的Pod突然被标记为Evicted，甚至反复重启，这种情况多与节点资源压力有关。当节点内存使用率超过90%、磁盘可用空间低于10%（默认阈值），或进程数达到上限时，kubelet会触发资源回收，优先驱逐QoS（Quality of Service，服务质量）等级低的Pod（如BestEffort类型）。

建议通过`kubectl top nodes`监控节点资源，及时清理无用的镜像或日志释放磁盘空间；同时调整Pod的QoS等级，将关键业务的Pod设置为Guaranteed类型（需同时设置Requests和Limits且值相等），这类Pod在资源紧张时被驱逐的优先级更低。

服务暴露：从Service到Ingress的常见故障

Service创建后无法访问

创建Service后，用它的IP和端口尝试访问，始终连不通服务？可能有两种情况：一是Service类型选不对，比如用了默认的ClusterIP类型，这种服务仅在集群内部可访问，外部请求会被拦截；二是后端Endpoints异常，当关联的Pod未就绪（ReadinessProbe失败）或全部宕机时，Service不会转发流量。

排查时先确认Service类型：需要外部访问选NodePort（节点IP+随机端口）或LoadBalancer（需云服务商支持）；再用`kubectl get endpoints `检查是否有可用端点，若显示"none"，说明后端Pod有问题，需排查Pod的健康检查配置。

Ingress规则配置不生效

配置了Ingress规则，输入域名却提示"无法访问"，问题常出在控制器或规则细节。Ingress本身不处理流量，依赖Ingress Controller（如Nginx Controller）实际转发请求，若控制器未正确部署（如镜像拉取失败）或未绑定公网IP，规则自然无法生效。另外，路径匹配（Path）配置错误（如多写了一个斜杠）、域名解析未指向集群节点IP，也会导致访问失败。

解决步骤：先用`kubectl get pods -n ingress-nginx`检查控制器Pod状态（假设用Nginx Controller）；再通过`kubectl describe ingress `查看事件，确认是否有"no endpoint"等错误；最后检查域名DNS记录，确保指向集群节点或负载均衡器IP。

服务暴露方式对比与避坑指南

在选择服务暴露方式时，需结合业务场景权衡：

• ClusterIP：仅集群内部访问，适合微服务间通信，安全性高但无法对外提供服务；


• NodePort：通过节点IP+30000-32767端口访问，配置简单但端口有限，适合测试环境；


• LoadBalancer：由云服务商提供外部负载均衡器，支持公网访问且性能稳定，是生产环境首选，但需要额外付费。

最后提醒一个常见陷阱：很多用户在配置网络策略（NetworkPolicy）时，可能误将服务间通信的流量阻断。部署后若发现Pod能ping通但服务连不上，记得检查是否有未放行的网络策略规则。

使用K8S云服务器时，关键是要提前规划资源、细致检查配置，遇到问题按"现象-诊断-解决"的逻辑逐步排查，才能保障容器化应用稳定运行。