现有EKS集群部署Metabase服务出现503临时不可用问题求助

问题描述 #

在正常运行的AWS EKS集群中部署Metabase后，Pod状态正常、端口配置看似正确，且已通过Application Load Balancer（ALB）转发流量，但访问Metabase域名时持续收到503错误。集群内其他服务运行正常，Metabase Pod日志无报错。

相关配置 #

Service配置 #

apiVersion: v1
kind: Service
metadata:
  name: metabase-service
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 3000
  selector:
    app: metabase
  type: ClusterIP

Deployment配置 #

apiVersion: apps/v1
kind: Deployment
metadata:
  generation: 1
  labels:
    deployment: metabase
  name: metabase
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: metabase
  template:
    metadata:
      labels:
        app: metabase
    spec:
      containers:
      - name: metabase
        image: metabase/metabase
        imagePullPolicy: Always
        ports:
        - containerPort: 3000
          protocol: TCP

Ingress配置 #

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: default
spec:
  ingressClassName: alb
  rules:
  - host: staging.my-app.nl
    http:
      paths:
      - backend:
          service:
            name: my-app-service
            port:
              number: 80
        path: /
        pathType: Prefix
  - host: metabase.my-app.nl
    http:
      paths:
      - backend:
          service:
            name: metabase-service
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - staging.my-app.nl
    secretName: myapp-certs-2022
  - hosts:
    - metabase.my-app.nl
    secretName: myapp-certs-2022

集群资源状态输出 #

kubectl get ingress输出

my-ingress   alb     staging.my-app.nl,metabase.my-app.nl   k8s-default-my-app-12334444444.eu-central-1.elb.amazonaws.com   80, 443   206d

kubectl get svc输出

metabase       ClusterIP   10.100.127.227   <none>        80/TCP   56m

排查方向 #

• 验证Service与Pod的关联：执行kubectl describe svc metabase-service，查看Endpoints字段是否显示Pod的IP和端口。如果为空，说明标签选择器存在匹配问题（当前配置中selector为app: metabase，Pod标签一致，但需确认实际状态）。
• 集群内测试服务可达性：启动临时Pod测试集群内访问：

  kubectl run -it --rm busybox --image=busybox:1.28 -- sh
  wget -qO- metabase-service.default.svc.cluster.local:80
  

  如果访问失败，问题出在Service到Pod的链路；如果成功，问题聚焦在Ingress/ALB层面。
• 检查ALB目标组健康状态：登录AWS控制台，找到对应ALB的目标组：
  • 确认目标组中是否有健康的后端实例
  • 检查健康检查配置：Metabase建议使用/api/health路径进行健康检查，而非默认的/（初始化阶段/可能返回非200状态码），同时验证端口、响应码配置是否正确。
• 确认Metabase初始化完成：Metabase启动后需要时间完成初始化，即使Pod状态为Running，服务可能未就绪。执行以下命令验证：

  kubectl exec <metabase-pod-name> -- curl localhost:3000/api/health
  

  若返回{"status":"ok"}则说明服务就绪，否则等待初始化完成或排查启动异常。
• 检查ALB控制器日志：查看ALB控制器是否正确处理Ingress规则：

  kubectl logs -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller
  

  搜索与metabase-service相关的报错信息，确认规则是否正常同步。
• 验证DNS解析：本地执行nslookup metabase.my-app.nl或dig metabase.my-app.nl，确认域名是否正确解析到ALB的公网域名。

内容的提问来源于stack exchange，提问作者Gijsriet