--> <h1id=troubleshooting>Troubleshooting<aclass=headerlinkhref=#troubleshootingtitle="Permanent link"> ¶</a></h1><h2id=ingress-controller-logs-and-events>Ingress-Controller Logs and Events<aclass=headerlinkhref=#ingress-controller-logs-and-eventstitle="Permanent link"> ¶</a></h2><p>There are many ways to troubleshoot the ingress-controller. The following are basic troubleshooting methods to obtain more information.</p><h3id=check-the-ingress-resource-events>Check the Ingress Resource Events<aclass=headerlinkhref=#check-the-ingress-resource-eventstitle="Permanent link"> ¶</a></h3><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>kubectl<spanclass=w></span>get<spanclass=w></span>ing<spanclass=w></span>-n<spanclass=w></span><namespace-of-ingress-resource>
</code></pre></div><h3id=check-if-used-services-exist>Check if used Services Exist<aclass=headerlinkhref=#check-if-used-services-existtitle="Permanent link"> ¶</a></h3><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>kubectl<spanclass=w></span>get<spanclass=w></span>svc<spanclass=w></span>--all-namespaces
</code></pre></div><h2id=debug-logging>Debug Logging<aclass=headerlinkhref=#debug-loggingtitle="Permanent link"> ¶</a></h2><p>Using the flag <code>--v=XX</code> it is possible to increase the level of logging. This is performed by editing the deployment.</p><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>kubectl<spanclass=w></span>get<spanclass=w></span>deploy<spanclass=w></span>-n<spanclass=w></span><namespace-of-ingress-controller>
</code></pre></div><ul><li><code>--v=2</code> shows details using <code>diff</code> about the changes in the configuration in nginx</li><li><code>--v=3</code> shows details about the service, Ingress rule, endpoint changes and it dumps the nginx configuration in JSON format</li><li><code>--v=5</code> configures NGINX in <ahref=https://nginx.org/en/docs/debugging_log.html>debug mode</a></li></ul><h2id=authentication-to-the-kubernetes-api-server>Authentication to the Kubernetes API Server<aclass=headerlinkhref=#authentication-to-the-kubernetes-api-servertitle="Permanent link"> ¶</a></h2><p>A number of components are involved in the authentication process and the first step is to narrow down the source of the problem, namely whether it is a problem with service authentication or with the kubeconfig file.</p><p>Both authentications must work:</p><divclass=highlight><pre><span></span><code>+-------------+ service +------------+
</code></pre></div><p><strong>Service authentication</strong></p><p>The Ingress controller needs information from apiserver. Therefore, authentication is required, which can be achieved in a couple of ways:</p><ul><li><p><em>Service Account:</em> This is recommended, because nothing has to be configured. The Ingress controller will use information provided by the system to communicate with the API server. See 'Service Account' section for details.</p></li><li><p><em>Kubeconfig file:</em> In some Kubernetes environments service accounts are not available. In this case a manual configuration is required. The Ingress controller binary can be started with the <code>--kubeconfig</code> flag. The value of the flag is a path to a file specifying how to connect to the API server. Using the <code>--kubeconfig</code> does not requires the flag <code>--apiserver-host</code>. The format of the file is identical to <code>~/.kube/config</code> which is used by kubectl to connect to the API server. See 'kubeconfig' section for details.</p></li><li><p><em>Using the flag <code>--apiserver-host</code>:</em> Using this flag <code>--apiserver-host=http://localhost:8080</code> it is possible to specify an unsecured API server or reach a remote kubernetes cluster using <ahref=https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#proxy>kubectl proxy</a>. Please do not use this approach in production.</p></li></ul><p>In the diagram below you can see the full authentication flow with all options, starting with the browser on the lower left hand side.</p><divclass=highlight><pre><span></span><code>Kubernetes Workstation
</code></pre></div><h3id=service-account>Service Account<aclass=headerlinkhref=#service-accounttitle="Permanent link"> ¶</a></h3><p>If using a service account to connect to the API server, the ingress-controller expects the file <code>/var/run/secrets/kubernetes.io/serviceaccount/token</code> to be present. It provides a secret token that is required to authenticate with the API server.</p><p>Verify with the following commands:</p><divclass=highlight><pre><span></span><code><spanclass=gp># </span>start<spanclass=w></span>a<spanclass=w></span>container<spanclass=w></span>that<spanclass=w></span>contains<spanclass=w></span>curl
</code></pre></div><p>If it is not working, there are two possible reasons:</p><ol><li><p>The contents of the tokens are invalid. Find the secret name with <code>kubectl get secrets | grep service-account</code> and delete it with <code>kubectl delete secret <name></code>. It will automatically be recreated.</p></li><li><p>You have a non-standard Kubernetes installation and the file containing the token may not be present. The API server will mount a volume containing this file, but only if the API server is configured to use the ServiceAccount admission controller. If you experience this error, verify that your API server is using the ServiceAccount admission controller. If you are configuring the API server by hand, you can set this with the <code>--admission-control</code> parameter.</p><blockquote><p>Note that you should use other admission controllers as well. Before configuring this option, you should read about admission controllers.</p></blockquote></li></ol><p>More information:</p><ul><li><ahref=https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/>User Guide: Service Accounts</a></li><li><ahref=http://kubernetes.io/docs/admin/service-accounts-admin/>Cluster Administrator Guide: Managing Service Accounts</a></li></ul><h2id=kube-config>Kube-Config<aclass=headerlinkhref=#kube-configtitle="Permanent link"> ¶</a></h2><p>If you want to use a kubeconfig file for authentication, follow the <ahref=../deploy/>deploy procedure</a> and add the flag <code>--kubeconfig=/etc/kubernetes/kubeconfig.yaml</code> to the args section of the deployment.</p><h2id=using-gdb-with-nginx>Using GDB with Nginx<aclass=headerlinkhref=#using-gdb-with-nginxtitle="Permanent link"> ¶</a></h2><p><ahref=https://www.gnu.org/software/gdb/>Gdb</a> can be used to with nginx to perform a configuration dump. This allows us to see which configuration is being used, as well as older configurations.</p><p>Note: The below is based on the nginx <ahref=https://docs.nginx.com/nginx/admin-guide/monitoring/debugging/#dumping-nginx-configuration-from-a-running-process>documentation</a>.</p><ol><li><p>SSH into the worker</p><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>ssh<spanclass=w></span>user@workerIP
</code></pre></div></li><li><p>Obtain the Docker Container Running nginx</p><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>docker<spanclass=w></span>ps<spanclass=w></span><spanclass=p>|</span><spanclass=w></span>grep<spanclass=w></span>ingress-nginx-controller
</code></pre></div></li><li><p>Exec into the container</p><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>docker<spanclass=w></span><spanclass=nb>exec</span><spanclass=w></span>-it<spanclass=w></span>--user<spanclass=o>=</span><spanclass=m>0</span><spanclass=w></span>--privileged<spanclass=w></span>d9e1d243156a<spanclass=w></span>bash
</code></pre></div></li><li><p>Make sure nginx is running in <code>--with-debug</code></p><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>nginx<spanclass=w></span>-V<spanclass=w></span><spanclass=m>2</span>><spanclass=p>&</span><spanclass=m>1</span><spanclass=w></span><spanclass=p>|</span><spanclass=w></span>grep<spanclass=w></span>--<spanclass=w></span><spanclass=s1>'--with-debug'</span>
</code></pre></div></li><li><p>Get list of processes running on container</p><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>ps<spanclass=w></span>-ef
</code></pre></div></li><li><p>Attach gdb to the nginx master process</p><divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>gdb<spanclass=w></span>-p<spanclass=w></span><spanclass=m>21</span>
</code></pre></div></li><li><p>Copy and paste the following:</p><divclass=highlight><pre><span></span><code><spanclass=go>set $cd = ngx_cycle->config_dump</span>
</code></pre></div></li></ol><h2id=image-related-issues-faced-on-nginx-425-or-other-versions-helm-chart-versions>Image related issues faced on Nginx 4.2.5 or other versions (Helm chart versions)<aclass=headerlinkhref=#image-related-issues-faced-on-nginx-425-or-other-versions-helm-chart-versionstitle="Permanent link"> ¶</a></h2><ol><li><p>Incase you face below error while installing Nginx using helm chart (either by helm commands or helm_release terraform provider ) <divclass=highlight><pre><span></span><code>Warning Failed 5m5s (x4 over 6m34s) kubelet Failed to pull image "registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.3.0@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": rpc error: code = Unknown desc = failed to pull and unpack image "registry.k8s.io/ingress-nginx/kube-webhook-certgen@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": failed to resolve reference "registry.k8s.io/ingress-nginx/kube-webhook-certgen@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": failed to do request: Head "https://eu.gcr.io/v2/k8s-artifacts-prod/ingress-nginx/kube-webhook-certgen/manifests/sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47": EOF
</code></pre></div> Then please follow the below steps.</p></li><li><p>During troubleshooting you can also execute the below commands to test the connectivities from you local machines and repositories details</p><p>a. curl registry.k8s.io/ingress-nginx/kube-webhook-certgen@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47 > /dev/null <divclass=highlight><pre><span></span><code>(⎈ |myprompt)➜ ~ curl registry.k8s.io/ingress-nginx/kube-webhook-certgen@sha256:549e71a6ca248c5abd51cdb73dbc3083df62cf92ed5e6147c780e30f7e007a47 > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
</code></pre></div> Redirection in the proxy is implemented to ensure the pulling of the images.</p></li><li><p>This is the solution recommended to whitelist the below image repositories : <divclass=highlight><pre><span></span><code>*.appspot.com
</code></pre></div> More details about the above repos : a. *.k8s.io -> To ensure you can pull any images from registry.k8s.io b. *.gcr.io -> GCP services are used for image hosting. This is part of the domains suggested by GCP to allow and ensure users can pull images from their container registry services. c. *.appspot.com -> This a Google domain. part of the domain used for GCR.</p></li></ol><h2id=unable-to-listen-on-port-80443>Unable to listen on port (80/443)<aclass=headerlinkhref=#unable-to-listen-on-port-80443title="Permanent link"> ¶</a></h2><p>One possible reason for this error is lack of permission to bind to the port. Ports 80, 443, and any other port < 1024 are Linux privileged ports which historically could only be bound by root. The ingress-nginx-controller uses the CAP_NET_BIND_SERVICE <ahref=https://man7.org/linux/man-pages/man7/capabilities.7.html>linux capability</a> to allow binding these ports as a normal user (www-data / 101). This involves two components: 1. In the image, the /nginx-ingress-controller file has the cap_net_bind_service capability added (e.g. via <ahref=https://man7.org/linux/man-pages/man8/setcap.8.html>setcap</a>) 2. The NET_BIND_SERVICE capability is added to the container in the containerSecurityContext of the deployment.</p><p>If encountering this on one/some node(s) and not on others, try to purge and pull a fresh copy of the image to the affected node(s), in case there has been corruption of the underlying layers to lose the capability on the executable.</p><h3id=create-a-test-pod>Create a test pod<aclass=headerlinkhref=#create-a-test-podtitle="Permanent link"> ¶</a></h3><p>The /nginx-ingress-controller process exits/crashes when encountering this error, making it difficult to troubleshoot what is happening inside the container. To get around this, start an equivalent container running "sleep 3600", and exec into it for further troubleshooting. For example: <divclass=highlight><pre><span></span><code><spanclass=nt>apiVersion</span><spanclass=p>:</span><spanclass=w></span><spanclass="l l-Scalar l-Scalar-Plain">v1</span>
</code></pre></div> * update the namespace if applicable/desired * replace <code>##_NODE_NAME_##</code> with the problematic node (or remove nodeSelector section if problem is not confined to one node) * replace <code>##_CONTROLLER_IMAGE_##</code> with the same image as in use by your ingress-nginx deployment * confirm the securityContext section matches what is in place for ingress-nginx-controller pods in your cluster</p><p>Apply the YAML and open a shell into the pod. Try to manually run the controller process: <divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>/nginx-ingress-controller
</code></pre></div> You should get the same error as from the ingress controller pod logs.</p><p>Confirm the capabilities are properly surfacing into the pod: <divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>grep<spanclass=w></span>CapBnd<spanclass=w></span>/proc/1/status
</code></pre></div> The above value has only net_bind_service enabled (per security context in YAML which adds that and drops all). If you get a different value, then you can decode it on another linux box (capsh not available in this container) like below, and then figure out why specified capabilities are not propagating into the pod/container. <divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>capsh<spanclass=w></span>--decode<spanclass=o>=</span><spanclass=m>0000000000000400</span>
</code></pre></div></p><h2id=create-a-test-pod-as-root>Create a test pod as root<aclass=headerlinkhref=#create-a-test-pod-as-roottitle="Permanent link"> ¶</a></h2><p>(Note, this may be restricted by PodSecurityAdmission/Standards, OPA Gatekeeper, etc. in which case you will need to do the appropriate workaround for testing, e.g. deploy in a new namespace without the restrictions.) To test further you may want to install additional utilities, etc. Modify the pod yaml by: * changing runAsUser from 101 to 0 * removing the "drop..ALL" section from the capabilities.</p><p>Some things to try after shelling into this container:</p><p>Try running the controller as the www-data (101) user: <divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>chmod<spanclass=w></span><spanclass=m>4755</span><spanclass=w></span>/nginx-ingress-controller
</code></pre></div> Examine the errors to see if there is still an issue listening on the port or if it passed that and moved on to other expected errors due to running out of context.</p><p>Install the libcap package and check capabilities on the file: <divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>apk<spanclass=w></span>add<spanclass=w></span>libcap
</code></pre></div> (if missing, see above about purging image on the server and re-pulling)</p><p>Strace the executable to see what system calls are being executed when it fails: <divclass=highlight><pre><span></span><code><spanclass=gp>$ </span>apk<spanclass=w></span>add<spanclass=w></span>strace
</code></pre></div></p></article></div></div></main><footerclass=md-footer><divclass="md-footer-meta md-typeset"><divclass="md-footer-meta__inner md-grid"><divclass=md-copyright> Made with <ahref=https://squidfunk.github.io/mkdocs-material/target=_blankrel=noopener> Material for MkDocs </a></div></div></div></footer></div><divclass=md-dialogdata-md-component=dialog><divclass="md-dialog__inner md-typeset"></div></div><scriptid=__configtype=application/json>{"base":"..","features":["navigation.tabs","navigation.tabs.sticky","navigation.instant","navigation.sections"],"search":"../assets/javascripts/workers/search.f886a092.min.js","translations":{"clipboard.copied":"Copied to clipboard","clipboard.copy":"Copy to clipboard","search.result.more.one":"1 more on this page","search.result.more.other":"# more on this page","search.result.none":"No matching documents","search.result.one":"1 matching document","search.result.other":"# matching documents","search.result.placeholder":"Type to start searching","search.result.term.missing":"Missing","select.version":"Select version"}}</script><scriptsrc=../assets/javascripts/bundle.aecac24b.min.js></script></body></html>
