云服务器K8s服务不可达：Service与Ingress配置排查实战

在云服务器上部署Kubernetes（K8s）应用时，最让人头疼的问题之一就是服务不可达——客户端访问域名或IP时要么超时，要么返回404。这类问题往往与Service（服务发现组件）和Ingress（流量入口控制器）的配置密切相关。作为多年云架构运维的实践者，本文将结合实战经验，带你一步步排查这两大组件的配置问题。

先看现象：服务不可达的典型表现

在云服务器环境中，K8s服务不可达通常有几种直观表现：浏览器访问提示"连接超时"、Postman调用返回"404 Not Found"、curl命令长时间无响应。这些现象可能由网络策略、Pod故障等因素引起，但超70%的案例与Service或Ingress配置错误直接相关，因此优先检查这两个组件能快速缩小排查范围。

Service配置检查：四步定位核心问题

Service是K8s暴露应用的"门面"，负责将请求路由到后端Pod。若配置不当，即使Pod运行正常，外部也无法访问服务。

1. 确认Service是否存活

首先用命令验证Service是否存在：

kubectl get svc -n 你的命名空间

如果列表中没有目标Service，可能是创建时YAML文件路径错误，或`kubectl apply`命令执行失败。这时候需要检查部署日志（`kubectl describe svc 服务名 -n 命名空间`），确认是否有"NotFound"或"InvalidSpec"等错误提示。

2. 核对Service类型与访问需求

Service有三种常用类型：

• ClusterIP（默认）：仅集群内部可访问，适合微服务间调用；


• NodePort：通过节点IP+随机端口暴露，适合测试环境；


• LoadBalancer：由云服务器提供外部负载均衡器（需云厂商支持），适合生产环境。

曾遇到过开发团队用ClusterIP类型暴露前端服务，导致外部始终无法访问的案例。通过`kubectl describe svc 服务名`查看Type字段，就能快速判断是否与访问需求匹配。

3. 检查Selector标签匹配度

Service通过Selector（标签选择器）关联Pod，若标签不匹配，即使Pod运行正常也无法被路由。例如Service的Selector是`app: myapp`，但Pod的标签是`app: my-app`（多了短横线），就会导致无法关联。
可通过以下命令验证：

查看Service的Selector

kubectl get svc 服务名 -o jsonpath='{.spec.selector}'

检查匹配的Pod数量

kubectl get pods -l app=myapp -n 命名空间

若返回空列表，说明标签配置存在偏差。

4. 确认端口映射正确性

Service的port（服务对外端口）和targetPort（Pod内部端口）必须严格对应。例如Pod容器暴露的是8080端口，但Service的targetPort写成了80，就会导致请求无法到达正确进程。通过`kubectl describe svc`查看Ports字段，对比Pod的容器端口（`kubectl get pod pod名 -o jsonpath='{.spec.containers[0].ports}'`）即可验证。

Ingress配置检查：流量入口的四大关卡

如果Service配置正常但外部仍无法访问，问题大概率出在Ingress——这个负责集群外部流量路由的关键组件。

1. 确认Ingress资源已创建

执行`kubectl get ingress -n 命名空间`，若看不到目标Ingress，可能是YAML文件中`apiVersion`错误（如用了过时的`extensions/v1beta1`而不是`networking.k8s.io/v1`），或RBAC权限不足导致创建失败。

2. 检查路由规则是否准确

Ingress的核心是`rules`字段，需重点核对：

• host：域名是否与实际访问的一致（如配置的是`app.example.com`，但测试用了`example.com`）；


• paths：路径匹配是否正确（如配置`/api/*`，但请求路径是`/v1/api`）；


• backend：指向的Service名称、端口是否与实际部署的一致。

曾遇到过运维人员将backend的serviceName写错字母（如`user-service`写成`uesr-service`），导致流量无法转发的情况。

3. 验证Ingress Controller状态

Ingress规则需要Ingress Controller（如Nginx Controller、Traefik）来落地执行。若Controller未部署或异常，所有Ingress规则都是无效的。通过`kubectl get pods -n ingress-nginx`（假设用Nginx Controller）检查Pod状态，确保有`Running`状态的实例。

4. 检查域名解析是否生效

若通过域名访问，需确认域名已解析到Ingress Controller的公网IP（云服务器LoadBalancer类型Service的EXTERNAL-IP）。可通过`nslookup 域名`或`dig 域名`命令验证解析结果，若返回的IP与Ingress Controller的IP不一致，需联系DNS服务商修正。

实战修复：从诊断到验证

根据上述检查结果，针对性调整配置：
- 若Service类型错误，用`kubectl edit svc 服务名`修改`spec.type`字段；
- 若Ingress规则路径不匹配，通过`kubectl apply -f ingress.yaml`重新应用正确配置；
- 若Ingress Controller异常，尝试重启Pod（`kubectl delete pod 控制器Pod名 -n ingress-nginx`）或重新部署。

修改后，建议通过`curl http://Ingress公网IP/路径`或浏览器直接访问验证，确保服务可达。

在云服务器上运行K8s应用时，Service与Ingress就像"门"和"路"——门没装好（Service配置错）进不去，路没修通（Ingress配置错）到不了。掌握这套配置检查方法，能帮你快速定位90%以上的服务不可达问题，让云服务器上的K8s应用始终保持"在线状态"。