Hi There,
I have installed the ingress controller using the link:
https://cloud.google.com/community/tutorials/nginx-ingress-gke
which is up and running
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-controller LoadBalancer X.X.X.X X.X.X.X1 80:123/TCP,443:456/TCP 1d
After that I have installed and exposed the application as nodePort, bot app up and running.
Ingress Rules are defined as :
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-resource
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
host: foo.com
http:
paths:
host: faa.com
http:
paths:
To verify I did exec in inginx-controller pod and test the followings
Tests: 1
Input : curl localhost
Output : default backend - 404
Tests: 2
Input : curl localhost -H 'Host:foo.com'
Output : app working properly
Tests: 3
Input : curl localhost -H 'Host:faa.com'
Output : app working properly
Tests: 4 on Browser Chrome
Input : foo.com
Input : faa.com
Output : default backend - 404
I do not able to figureout where am I missing to recheck
Please support me for for the same.
What's the output when you use curl from your PC? curl -v X.X.X.X X.X.X.X1 -H 'Host: foo.com'
Thank you very much for your response aledbf!!!
Please find the result for the asked query.
curl -v http://X.X.X.X -H 'Host: foo.com'
Hello I have a very simular issue but can't resovle it.
I enabled --v=5 logs on nginx side and see the request to my ingress dns entry like:
"GET / HTTP/1.1
Host: foo.com
Connection: close
X-Real-IP: 10.244.5.1
X-Forwarded-For: 10.244.5.1
X-Forwarded-Host: che.bosch-cloudia.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-URI: /
X-Scheme: https
cache-control: max-age=0
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
I can also see in the looks that nginx directly requests the default backend which response 404 for sure.
My ingress is very simple like
- apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/proxy-connect-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
creationTimestamp: 2018-06-09T22:43:51Z
generation: 1
name: ingress
namespace: ingress
resourceVersion: "10329653"
selfLink: /apis/extensions/v1beta1/namespaces/che/ingresses/che-ingress
uid: 94a68b0a-6c36-11e8-9b2d-0a58ac1f1227
spec:
rules:
- host: foo.com
http:
paths:
- backend:
serviceName: foo-host
servicePort: 8080
path: /
And what I don't get is why its not working :). Url reachs the backend and doesn't get routed anyways
Please also find my nginx.conf of the controller attached (i removed a lot boiler plate):
http {
resolver 10.0.0.10 valid=30s;
upstream upstream-default-backend {
least_conn;
keepalive 32;
server 10.244.4.85:8080 max_fails=0 fail_timeout=0;
}
upstream foo-foo-host-8080 {
least_conn;
keepalive 32;
server 10.244.4.84:8080 max_fails=0 fail_timeout=0;
}
## start server _
server {
server_name _ ;
listen 80 default_server backlog=511;
listen [::]:80 default_server backlog=511;
set $proxy_upstream_name "-";
listen 443 default_server backlog=511 ssl http2;
listen [::]:443 default_server backlog=511 ssl http2;
location / {
log_by_lua_block {
}
if ($scheme = https) {
more_set_headers "Strict-Transport-Security: max-age=15724800; includeSubDomains";
}
access_log off;
port_in_redirect off;
set $proxy_upstream_name "upstream-default-backend";
set $namespace "";
set $ingress_name "";
set $service_name "";
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_real_ip;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# Pass the original X-Forwarded-For
proxy_set_header X-Original-Forwarded-For $http_x_forwarded_for;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers to proxied server
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_buffering "off";
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_request_buffering "on";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
# In case of errors try the next upstream server before returning an error
proxy_next_upstream error timeout invalid_header http_502 http_503 http_504;
proxy_next_upstream_tries 0;
proxy_pass http://upstream-default-backend;
proxy_redirect off;
}
# health checks in cloud providers require the use of port 80
location /healthz {
access_log off;
return 200;
}
# this is required to avoid error if nginx is being monitored
# with an external software (like sysdig)
location /nginx_status {
allow 127.0.0.1;
allow ::1;
deny all;
access_log off;
stub_status on;
}
}
## end server _
## start server foo.com
server {
server_name foo.com ;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location / {
log_by_lua_block {
}
port_in_redirect off;
set $proxy_upstream_name "foo-foo-host-8080";
set $namespace "foo";
set $ingress_name "ingress";
set $service_name "foo-host";
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_real_ip;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# Pass the original X-Forwarded-For
proxy_set_header X-Original-Forwarded-For $http_x_forwarded_for;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers to proxied server
proxy_connect_timeout 3600s;
proxy_send_timeout 60s;
proxy_read_timeout 3600s;
proxy_buffering "off";
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_request_buffering "on";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
# In case of errors try the next upstream server before returning an error
proxy_next_upstream error timeout invalid_header http_502 http_503 http_504;
proxy_next_upstream_tries 0;
proxy_pass http://foo-host-8080;
proxy_redirect off;
}
}
any ideas? version is 0.20.1 helm chart
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
same here!! how to solve it?
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
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.
/reopen
@nancy-garg: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
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.
I am facing the same issue, curl is working but explorer is not
/reopen
@nancy-garg: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
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.