-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
External Postman to Pod 404 not found (new to k8) #10292
Comments
This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-kind bug
|
Sorry for the delay in response, I have updated the original post to fix the formatting. The log for the failed CURL on the ingress controller:
Here is a working example of the ability to CURL a pod in another namespace which is on dotnet6:
|
That 404 error message shows the routing was not a problem. But because the failing curl request, in full, as it is, raw, from outside the cluster needs to be compared to a working exact same curl request, originating from a adjacent pod, inside the cluster, that returns response 200, its hard to know more from the data posted. |
This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach |
Closing, I believe this is not an nginx issue. |
What happened:
We have a k8 cluster which contains apis that run in pods. Each API has its own namespace and pod.
The deployment for the pods is done with Terraform and Azure CI/D Pipelines.
The src files for previous API deployments that run in pods all run on dotnet6, they have no routing issues.
The devs have created a new set of source files on dotnet7 for a new API. They can reach the health endpoint locally in Visual Studio.
Once the pod is deployed to our cluster, we can connect to generic-dotnet7-api pod, curl the health endpoint, 200 ok return.
We can curl the same endpoint from a pod in another namespace, 200 ok return.
We can also curl the same endpoint from the ingress-nginx-controller, 200 ok return.
When we run an external (internet) postman request to the same endpoint, 404 not found.
We can see the request reach the ingress-nginx-controller via log analytics workspace logs for the ingress-nginx-controller pod.
We can reach other endpoints on other pods in different namespaces via postman. We do not believe this to be an Azure Front Door issue.
What you expected to happen:
From postman, making an external request to the endpoint receive an ok 200 response.
We currently believe there is a routing issue or some kind of problem once the external request is received by the ingress-nginx-controller it cannot route the request to the pod.
It is possible there is a misconfiguration in the src files when going from dotnet6 to dotnet7, I cant say I am not a dev.
NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
Kubernetes version (use
kubectl version
):Environment:
AKS
Alpine Linux v3.17
uname -a
):Linux ingress-nginx-controller-6c5dcd58d-bsksw 5.15.0-1041-azure #48-Ubuntu SMP Tue Jun 20 20:34:08 UTC 2023 x86_64 Linux
CI/CD pipeline in Azure Devops
kubectl version 1.25
kubectl get nodes -o wide
helm ls -A | grep -i ingress
helm -n <ingresscontrollernamepspace> get values <helmreleasename>
if you have more than one instance of the ingress-nginx-controller installed in the same cluster, please provide details for all the instances
Just the one ingress controller
Current State of the controller:
kubectl describe ingressclasses
kubectl -n <ingresscontrollernamespace> get all -A -o wide
kubectl -n <ingresscontrollernamespace> describe po <ingresscontrollerpodname>
kubectl -n <ingresscontrollernamespace> describe svc <ingresscontrollerservicename>
kubectl -n <appnnamespace> get all,ing -o wide
kubectl -n <appnamespace> describe ing <ingressname>
kubectl describe ...
of any custom configmap(s) created and in useHow to reproduce this issue:
Unfortunately I cannot show how to reproduce the issue.
I am new to K8 and this role.
Anything else we need to know:
The text was updated successfully, but these errors were encountered: