十、eureka pod启动成功但是访问https://eureka.test.com:9443/ 报503 服务正常，但是无法通过ingress网关访问的情况

根据您提供的两张截图，这是一个典型的 “服务正常运行但无法通过网关访问” 的场景。两张图的信息结合起来，清晰地指明了问题的方向和排查步骤。

问题现状分析

您的两张图展示了两个看似矛盾的现象：

图1（Pod状态）：所有微服务（包括 eureka-service）的 Pod 均已处于健康的 Running状态，且稳定运行了数分钟。这表明应用层面的启动和基本运行没有问题。
图2（浏览器访问）：通过 Ingress（域名 eureka.test.com:9443）访问时，收到 503 Service Unavailable 错误，且由 nginx直接返回。

结论：问题出在 流量从 Nginx Ingress Controller 到后端 eureka-servicePod 的通路上。Pod本身是好的，但网关（Ingress）无法正确将请求送达。

核心问题诊断

当 Pod 状态为 Running但 Ingress 返回 503 时，最可能的原因有：

Kubernetes Service 没有正确的 Endpoints：Ingress 规则指向名为 eureka-service-svc的 Service，但该 Service 可能没有关联到对应的 Pod。
Pod 的就绪探针（Readiness Probe）失败：虽然容器进程在运行，但内部的健康检查未通过，导致 Kubernetes 未将其 IP 加入 Service 的 Endpoints 列表。
Ingress 规则配置错误：可能主机名、路径或后端端口指定有误。

排查步骤与解决方案

请按顺序执行以下命令，定位并修复问题：

步骤1：检查 Service 与 Endpoints 状态

这是最可能的故障点。运行以下命令检查流量入口是否畅通：

# 1. 查看 eureka-service 对应的 Service 详情，重点关注它的选择器（Selector）和端口
kubectl describe svc eureka-service-svc -n gongsi-dev

# 2. 查看该 Service 背后是否有健康的 Endpoints
kubectl get endpoints eureka-service-svc -n gongsi-dev

关键判断：

如果 Endpoints列为空，说明Service没有找到Pod。请检查Service的 Selector（例如 app: eureka-service）是否与 eureka-servicePod的标签（kubectl get pod eureka-service-xxx -n gongsi-dev --show-labels）完全匹配。
如果 Endpoints列有IP:端口（如192.168.0.10:8888），则表示服务发现层面正常，问题可能在网络策略或应用内部健康状态。

步骤2：检查 Pod 的就绪状态和健康端点

从Pod内部验证应用是否真正就绪：

# 1. 进入 eureka-service 的 Pod 内部，测试其健康检查接口
kubectl exec -it eureka-service-5578784dbb-vg4fd -n gongsi-dev -- curl -v http://localhost:8888/actuator/health

# 2. 检查Pod事件，确认是否有健康检查失败的记录
kubectl describe pod eureka-service-5578784dbb-vg4fd -n gongsi-dev

关键判断：

如果curl返回HTTP 200和{"status":"UP"}，说明应用健康。
如果返回其他状态码或连接失败，则需查看应用日志 (kubectl logs ...) 来修复应用自身的启动问题（如数据库连接失败）。

步骤3：验证 Ingress 规则配置

检查Ingress规则的路径、主机名和端口是否正确指向了Service：

# 查看 Ingress 规则的详细配置
kubectl get ingress -n gongsi-dev
kubectl describe ingress -n gongsi-dev

确保您的 ingress-domain-eureka-service.yaml配置了正确的规则。根据您之前的文件，规则应为：

host: eureka.test.com
path: /
backend serviceName: eureka-service-svc
backend servicePort: 80

总结与下一步

当前情况是 “最后一公里” 的连通性问题。您的应用（Pod）已经运行，但网络流量没有正确路由到它。

建议您立即执行：

运行命令：kubectl get endpoints eureka-service-svc -n gongsi-dev
根据结果判断：
- 如果Endpoints为空：检查并确保Service的 selector与Pod的labels完全一致。这是最常见的原因。
- 如果Endpoints正常：在Pod内部执行 curl http://localhost:8888/actuator/health，检查应用是否真的健康。

执行后，请将以上关键命令的输出结果提供给我，我可以帮您做进一步精确的分析。

根据您提供的终端截图，问题已明确诊断：Kubernetes 集群内存资源严重不足，导致所有新 Pod 无法调度，这是造成服务中断和 503 错误的根本原因。

问题诊断结果

从 kubectl describe pod的事件日志中，可以看到调度失败的三重原因：

内存不足：1 Insufficient memory（1个节点内存不足）
节点污点：
- node-role.kubernetes.io/master：Master 节点有污点，默认不调度普通 Pod
- node.kubernetes.io/unreachable：有节点处于不可达状态
无可用节点：0/3 nodes are available（3个节点中0个可用）

内存使用情况显示：2520Mi (118%)，这意味着内存使用已超负荷（超过100%），Kubernetes 无法为新的 Pod 分配所需内存。

解决方案

紧急恢复措施（立即执行）

方案A：清理节点内存，释放资源

# 1. 查看哪个节点内存压力最大
kubectl top nodes

# 2. 查看节点详细资源分配
kubectl describe nodes | grep -A 10 "Allocated resources"

# 3. 清理不必要的Pod（谨慎操作）
# 查找非核心的Pod
kubectl get pods --all-namespaces | grep -v Running

# 4. 重启kubelet释放缓存（在内存压力大的节点上执行）
sudo systemctl restart kubelet

方案B：调整Pod资源请求（快速恢复）

修改各个微服务 Deployment 的 resources.requests.memory，降低内存请求值：

# 在 deployment.yaml 中调整
resources:
  requests:
    memory: "256Mi"  # 从512Mi或更高降低到256Mi
    cpu: "200m"
  limits:
    memory: "512Mi"  # 保持适当的限制
    cpu: "500m"

方案C：移除不可达节点的污点

# 查看所有节点状态
kubectl get nodes

# 如果节点确实不可用，考虑移除
kubectl cordon <node-name>  # 标记为不可调度
kubectl drain <node-name> --ignore-daemonsets  # 驱逐该节点上的Pod

# 如果节点应该可用，移除unreachable污点
kubectl taint nodes <node-name> node.kubernetes.io/unreachable-

中期优化方案

增加节点资源

# 如果是云环境，扩容节点
# 如果是物理机，考虑增加内存或添加新节点

优化应用内存使用
- 调整 JVM 参数：-Xms256m -Xmx512m
- 启用容器内存压缩
- 使用内存更小的基础镜像

配置资源配额和限制

# 创建ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-quota
  namespace: gongsi-dev
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi

长期预防措施

配置HPA（自动水平扩展）

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: eureka-hpa
  namespace: gongsi-dev
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: eureka-service
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70

设置优先级和抢占

# 创建PriorityClass
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "用于关键服务"

验证恢复

执行上述操作后，验证集群状态：

# 1. 检查节点资源状态
kubectl describe nodes | grep -A 5 "Allocatable"

# 2. 查看Pod调度状态
kubectl get pods -n gongsi-dev -o wide

# 3. 查看调度事件
kubectl get events -n gongsi-dev --sort-by='.lastTimestamp'

# 4. 测试服务恢复
curl -H "Host: eureka.test.com" http://<节点IP>:9080

总结

根本原因：集群内存资源耗尽（118%使用率），导致新Pod无法调度。

解决优先级：

立即执行：清理内存或重启kubelet释放资源
短期方案：降低Pod内存请求，移除不可达节点污点
中期方案：增加节点或优化应用内存使用
长期方案：配置自动扩缩容和资源配额

建议操作顺序：

执行 kubectl top nodes确认具体内存使用
清理不必要的Pod或重启kubelet
暂时降低Deployment的内存请求
重新部署服务，观察Pod是否能够调度

请立即处理内存不足问题，这是当前服务不可用的直接原因。

posted on 2026-03-16 21:28 luzhouxiaoshuai 阅读(41) 评论(0) 收藏举报

刷新页面返回顶部

luzhouxiaoshuai