simple-deploy | development machine only you can create a file | FTP library

Chris,

I haven't used linode or kong and don't know what your frontend actually does, so I'll just point out what I can see:

• The simplest dns check is to curl (or ping, dig, etc.):

  • http://[dataapi's pod ip]:80 from a host node
  • http://[kong-proxy svc's internal ip]/dataapi/api/values from a host node (or another pod - see below)

• default path matching on nginx ingress controller is pathPrefix, so your nginx ingress with path: / and nginx.ingress.kubernetes.io/rewrite-target: / actually matches everything and rewrites to /. This may not be an issue if you properly specify all your ingresses so they take priority over "/".

• you said 'using a kong ingress as a proxy to redirect incoming', just want to make sure you're proxying (not redirecting the client).

• Is chrome just relaying its upstream error from frontend-service? An external client shouldn't be able to resolve the cluster's urls (unless you've joined your local machine to the cluster's network or done some other fancy trick). By default, dns only works within the cluster.

• cluster dns generally follows [service name].[namespace name].svc.cluster.local. If dns cluster dns is working, then using curl, ping, wget, etc. from a pod in the cluster and pointing it to that svc will send it to the cluster svc ip, not an external ip.

• is your dataapi service configured to respond to /dataapi/api/values or does it not care what the uri is?

If you don't have any network policies restricting traffic within a namespace, you should be able to create a test pod in the same namespace, and curl the service dns and the pod ip's directly: