I have an issues where I deployed kong ingress controller and kong ingress resource in kubernetes and certificates using cert manager but why website fails to load and shows no routes matches though the ingress shows all routes.
kubectl get ingress -n staging
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
https-webapp stg .us-east-1.elb.amazonaws.com 80, 443 22h
Could you provide the complete Ingress YAML and an example request?
Do your ingress controller logs indicate that it encountered any errors pushing configuration?
If you send a GET /routes request to the admin API (you’ll probably need to use kubectl port-forward to reach it), do you see your routes configured as expected?
The complete Ingress YAML manifest is what we’re looking for–that’s what we’d need to actually replicate the same configuration locally.
Is your request indeed curl https://networks?lang=en? If so, networks is a hostname, not a path, so it won’t match. You’d need to send a request for something like https://example.com/networks to match that Ingress.
That said, a blank page probably indicates that the service isn’t returning visible content in its response. If actually you’re failing to match a route, you’ll see the browser render the {“message”:”no Route matched with those values”} JSON string you originally mentioned.
Where hostname is actual route53 url pointing to ELB of ingress controller hostname. It shows 404 page not found or no routes matched with those values even after providing below ingress resource.
so far only laanc-approvals and echo-service ( added for testing) has worked
That appears to work fine. Using a simplified version (I also had to convert to v1 since I don’t have easy access to test clusters that still use v1beta1) I did get a request from a test upstream httpbin service:
$ curl -sv http://stg.intra.com/networks?lang=en --resolve stg.intra.com:80:192.168.16.0
* Added stg.intra.com:80:192.168.16.0 to DNS cache
* Hostname stg.intra.com was found in DNS cache
* Trying 192.168.16.0:80...
* Connected to stg.intra.com (192.168.16.0) port 80 (#0)
> GET /networks?lang=en HTTP/1.1
> Host: stg.intra.com
> User-Agent: curl/7.84.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 NOT FOUND
< Content-Type: text/html; charset=UTF-8
< Content-Length: 233
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Date: Tue, 23 Aug 2022 21:46:12 GMT
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< X-Kong-Upstream-Latency: 10
< X-Kong-Proxy-Latency: 1
< Via: kong/2.8.1
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>
Although that’s a 404, it’s from httpbin, which doesn’t recognize the /networks path, so Kong did successfully route the request. Again, you probably want to review what your service is actually returning and/or check if you’re seeing an X-Kong-Upstream-Latency response header–if you are, the request matched a route and was proxied upstream.
You probably do want to use ImplementationSpecific for any regex paths. We handle Prefix by wrapping provided paths in another regex, to account for slight differences between Kong’s native behavior and what the Ingress spec says. We do use prefix matching normally (including in ImplementationSpecific, unless you provide a $-terminated regex). That additional regex doesn’t appear to cause issues here, but can result in unexpected behavior.
It could be any number of reasons. Only the application actually generating the response can say for sure why it’s generating something different depending on the environment, so you’d want to review its logs for discrepancies. Common examples could be that your proxy configuration sends a different hostname than what you’re sending in the compose environment, or that it’s sending a different path because your strip_path and/or service path isn’t what you need, but ultimately you need to determine why the application is behaving differently so you know what needs to change in that configuration.