Closed Yelijah closed 8 months ago
Hi @Yelijah I see the following error in the nginx gateway logs:
{"level":"error","ts":"2024-03-12T02:21:19Z","logger":"eventLoop.eventHandler","msg":"Failed to update NGINX configuration","batchID":1,"error":"failed to reload NGINX: failed to send the HUP signal to NGINX main: operation not permitted"
This error would cause the problem you are seeing where the nginx-gateway Pod isn't reporting as ready.
To resolve you will need to tweak the security context of the nginx-gateway Pod. See this troubleshooting guide for details: https://docs.nginx.com/nginx-gateway-fabric/how-to/monitoring/troubleshooting/.
Hi @Yelijah I see the following error in the nginx gateway logs:
{"level":"error","ts":"2024-03-12T02:21:19Z","logger":"eventLoop.eventHandler","msg":"Failed to update NGINX configuration","batchID":1,"error":"failed to reload NGINX: failed to send the HUP signal to NGINX main: operation not permitted"
This error would cause the problem you are seeing where the nginx-gateway Pod isn't reporting as ready.
To resolve you will need to tweak the security context of the nginx-gateway Pod. See this troubleshooting guide for details: https://docs.nginx.com/nginx-gateway-fabric/how-to/monitoring/troubleshooting/.
Thank you for your help
Describe the bug After I deploy nginx gateway fabric by the helm, the nginx-gateway-fabric pod's container - nginx-gateway can't be ready.
To Reproduce Steps to reproduce the behavior:
helm install ngf oci://ghcr.io/nginxinc/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway
Expected behavior My nginx-gateway pod can be ready
Your environment
kubectl -n nginx-gateway exec <gateway-pod> -c nginx -- nginx -T
worker_processes auto;
pid /var/run/nginx/nginx.pid; error_log stderr info;
events { worker_connections 1024; }
http { include /etc/nginx/conf.d/*.conf; include /etc/nginx/mime.types; js_import /usr/lib/nginx/modules/njs/httpmatches.js;
default_type application/octet-stream;
proxy_headers_hash_bucket_size 512; proxy_headers_hash_max_size 1024; server_names_hash_bucket_size 256; server_names_hash_max_size 1024; variables_hash_bucket_size 512; variables_hash_max_size 1024;
sendfile on; tcp_nopush on;
server { listen unix:/var/run/nginx/nginx-status.sock; access_log off;
} }
configuration file /etc/nginx/conf.d/config-version.conf:
server { listen unix:/var/run/nginx/nginx-config-version.sock; access_log off;
}
configuration file /etc/nginx/conf.d/http.conf:
upstream invalid-backend-ref { random two least_conn; zone invalid-backend-ref 512k;
}
server { listen unix:/var/lib/nginx/nginx-502-server.sock; access_log off;
}
server { listen unix:/var/lib/nginx/nginx-500-server.sock; access_log off;
}
Set $gw_api_compliant_host variable to the value of $http_host unless $http_host is empty, then set it to the value
of $host. We prefer $http_host because it contains the original value of the host header, which is required by the
Gateway API. However, in an HTTP/1.0 request, it's possible that $http_host can be empty. In this case, we will use
the value of $host. See http://nginx.org/en/docs/http/ngx_http_core_module.html#var_host.
map $http_host $gw_api_compliant_host { '' $host; default $http_host; }
Set $connection_header variable to upgrade when the $http_upgrade header is set, otherwise, set it to close. This
allows support for websocket connections. See https://nginx.org/en/docs/http/websocket.html.
map $http_upgrade $connection_upgrade { default upgrade; '' close; }
configuration file /etc/nginx/mime.types:
types { text/html html htm shtml; text/css css; text/xml xml; image/gif gif; image/jpeg jpeg jpg; application/javascript js; application/atom+xml atom; application/rss+xml rss;
}