3

I have a couple of NodeJS backends running as pods in a Kubernetes setup, with Ingress-managed nginx over it.

These backends are API servers, and can return 400, 404, or 500 responses during normal operations. These responses would provide meaningful data to the client; besides the status code, the response has a JSON-serialized structure in the body informing about the error cause or suggesting a solution.

However, Ingress will intercept these error responses, and return an error page. Thus the client does not receive the information that the service has tried to provide.

There's a closed ticket in the kubernetes-contrib repository suggesting that it is now possible to turn off error interception: https://github.com/kubernetes/contrib/issues/897. Being new to kubernetes/ingress, I cannot figure out how to apply this configuration in my situation.

For reference, this is the output of kubectl get ingress <ingress-name>: (redacted names and IPs)

Name:             ingress-name-redacted
Namespace:        default
Address:          127.0.0.1
Default backend:  default-http-backend:80 (<none>)
Rules:
  Host                                Path  Backends
  ----                                ----  --------
  public.service.example.com
                                      /   service-name:80 (<none>)
Annotations:
  rewrite-target:         /
  service-upstream:       true
  use-port-in-redirects:  true
Events:                   <none>
Tomas Kohl
  • 1,388
  • 1
  • 19
  • 27

1 Answers1

4

I have solved this on Tectonic 1.7.9-tectonic.4.

In the Tectonic web UI, go to Workloads -> Config Maps and filter by namespace tectonic-system.

In the config maps shown, you should see one named "tectonic-custom-error".

Open it and go to the YAML editor.

In the data field you should have an entry like this:

custom-http-errors: '404, 500, 502, 503'

which configures which HTTP responses will be captured and be shown with the custom Tectonic error page.

If you don't want some of those, just remove them, or clear them all.

It should take effect as soon as you save the updated config map.

Of course, you could to the same from the command line with kubectl edit:

$> kubectl edit cm tectonic-custom-error --namespace=tectonic-system

Hope this helps :)

Niq
  • 56
  • 5
  • That helped a lot, thanks! For some reason, if you use reactive functional endpoints with Spring Boot 2, and the request includes a body, and the response code is one of these errors handled by Ingress, then the correct response is never actually returned, the client just hangs and eventually some kind of timeout occurs. – Fletch Nov 12 '18 at 14:52