How to fix "503 Service Temporarily Unavailable"

Viewed 25057

FYI:

  1. I run Kubernetes on docker desktop for mac
  2. The website based on Nginx image

I run 2 simple website deployments on Kubetesetes and use the NodePort service. Then I want to make routing to the website using ingress. When I open the browser and access the website, I get an error 503 like images below. So, how do I fix this error?

### Service
apiVersion: v1
kind: Service
metadata:
  name: app-svc
  labels:
    app: app1
spec:
  type: NodePort
  ports:
  - port: 80
  selector:
    app: app1
---
apiVersion: v1
kind: Service
metadata:
  name: app2-svc
  labels:
    app: app2
spec:
  type: NodePort
  ports:
  - port: 80
  selector:
    app: app2

### Ingress-Rules
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /app1
        backend:
          serviceName: app-svc
          servicePort: 30092
      - path: /app2
        backend:
          serviceName: app2-svc
          servicePort: 30936


enter image description here

5 Answers

Yes, i end up with same error. once i changed the service type to "ClusterIP", it worked fine for me.

Found this page after searching for a solution to nginx continually returning 503 responses despite the service names all being configured correctly. The issue for me was that I had configured the kubernetes service in a specific namespace, but did not update the ingress component to be in the same namespace. Despite being such a simple solution it was not at all obvious!

I advise you to use service type ClusterIP Take look on this useful article: services-kubernetes.

If you use Ingress you have to know that Ingress isn’t a type of Service, but rather an object that acts as a reverse proxy and single entry-point to your cluster that routes the request to different services. The most basic Ingress is the NGINX Ingress Controller, where the NGINX takes on the role of reverse proxy, while also functioning as SSL. On below drawing you can see workflow between specific components of environment objects.

Ingress is exposed to the outside of the cluster via ClusterIP and Kubernetes proxy, NodePort, or LoadBalancer, and routes incoming traffic according to the configured rules.

Example of service definition:

---
apiVersion: v1
kind: Service
metadata:
  name: app-svc
  labels:
    app: app1
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: app1
---
apiVersion: v1
kind: Service
metadata:
  name: app2-svc
  labels:
    app: app2
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: app2

Let me know if it helps.

First, You need to change the service type of your app-service to ClusterIP, because the Ingress object is going to access these Pods(services) from inside the cluster. (ClusterIP service is used when you want to allow accessing a pod inside a cluster).

Second, Make sure the services are running by running kubectl get services and check the running services names against the names in backend section in Ingress routing rules

Little late to this journey but here is my comment on the issue. I was having the same issue and having the same environment. (Docker Desktop-based Kubernetes with WSL2)

a couple of items probably can help.

  1. add the host entry in the rules section. and the value will be kubernetes.docker.internal like below

rules:
    - host: kubernetes.docker.internal
    http:
      paths:
      - path....

  1. check the endpoints using kubectl get services to confirm that the same port is in your ingress rule definition for each of those backend services.

backend:
  service:
    name: my-apple-service
      port:
        number: 30101

kubectl get services

NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
my-apple-service    ClusterIP   10.106.121.95   <none>        30101/TCP   9h
my-banada-service   ClusterIP   10.99.192.112   <none>        30101/TCP   9h

Related