diff --git a/README.md b/README.md index 6c604ddba3..3fec178e5c 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# NGINX Ingress Controller +# Ingress NGINX Controller [![Go Report Card](https://goreportcard.com/badge/github.com/kubernetes/ingress-nginx)](https://goreportcard.com/report/github.com/kubernetes/ingress-nginx) [![GitHub license](https://img.shields.io/github/license/kubernetes/ingress-nginx.svg)](https://github.com/kubernetes/ingress-nginx/blob/main/LICENSE) @@ -28,7 +28,7 @@ For detailed changes on the `ingress-nginx` helm chart, please check the followi ### Support Versions table -| Ingress-nginx version | k8s supported version | Alpine Version | Nginx Version | +| Ingress-NGINX version | k8s supported version | Alpine Version | Nginx Version | |-----------------------|------------------------------|----------------|---------------| | v1.1.1 | 1.23, 1.22, 1.21, 1.20, 1.19 | 3.14.2 | 1.19.9† | | v1.1.0 | 1.22, 1.21, 1.20, 1.19 | 3.14.2 | 1.19.9† | diff --git a/docs/e2e-tests.md b/docs/e2e-tests.md index 552a11f1e4..29ef071614 100644 --- a/docs/e2e-tests.md +++ b/docs/e2e-tests.md @@ -1,6 +1,6 @@ -# e2e test suite for [NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx/tree/main/) +# e2e test suite for [Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx/tree/main/) diff --git a/docs/examples/affinity/cookie/README.md b/docs/examples/affinity/cookie/README.md index a37bef6f1a..891f828a21 100644 --- a/docs/examples/affinity/cookie/README.md +++ b/docs/examples/affinity/cookie/README.md @@ -14,13 +14,13 @@ Session affinity can be configured using the following annotations: |nginx.ingress.kubernetes.io/session-cookie-name|Name of the cookie that will be created|string (defaults to `INGRESSCOOKIE`)| |nginx.ingress.kubernetes.io/session-cookie-secure|Set the cookie as secure regardless the protocol of the incoming request|`"true"` or `"false"`| |nginx.ingress.kubernetes.io/session-cookie-path|Path that will be set on the cookie (required if your [Ingress paths][ingress-paths] use regular expressions)|string (defaults to the currently [matched path][ingress-paths])| -|nginx.ingress.kubernetes.io/session-cookie-samesite|SameSite attribute to apply to the cookie|Browser accepted values are `None`, `Lax`, and `Strict`| +|nginx.ingress.kubernetes.io/session-cookie-samesite|`SameSite` attribute to apply to the cookie|Browser accepted values are `None`, `Lax`, and `Strict`| |nginx.ingress.kubernetes.io/session-cookie-conditional-samesite-none|Will omit `SameSite=None` attribute for older browsers which reject the more-recently defined `SameSite=None` value|`"true"` or `"false"` |nginx.ingress.kubernetes.io/session-cookie-max-age|Time until the cookie expires, corresponds to the `Max-Age` cookie directive|number of seconds| |nginx.ingress.kubernetes.io/session-cookie-expires|Legacy version of the previous annotation for compatibility with older browsers, generates an `Expires` cookie directive by adding the seconds to the current date|number of seconds| |nginx.ingress.kubernetes.io/session-cookie-change-on-failure|When set to `false` nginx ingress will send request to upstream pointed by sticky cookie even if previous attempt failed. When set to `true` and previous attempt failed, sticky cookie will be changed to point to another upstream.|`true` or `false` (defaults to `false`)| -You can create the [example Ingress](ingress.yaml) to test this: +You can create the [session affinity example Ingress](ingress.yaml) to test this: ```console kubectl create -f ingress.yaml @@ -66,13 +66,15 @@ Accept-Ranges: bytes ``` In the example above, you can see that the response contains a `Set-Cookie` header with the settings we have defined. -This cookie is created by NGINX, it contains a randomly generated key corresponding to the upstream used for that request (selected using [consistent hashing][consistent-hashing]) and has an `Expires` directive. -If the user changes this cookie, NGINX creates a new one and redirects the user to another upstream. +This cookie is created by the NGINX Ingress Controller, it contains a randomly generated key corresponding to the upstream used for that request (selected using [consistent hashing][consistent-hashing]) and has an `Expires` directive. +If a client sends a cookie that doesn't correspond to an upstream, NGINX selects an upstream and creates a corresponding cookie. If the backend pool grows NGINX will keep sending the requests through the same server of the first request, even if it's overloaded. When the backend server is removed, the requests are re-routed to another upstream server. This does not require the cookie to be updated because the key's [consistent hash][consistent-hashing] will change. +## Caveats + When you have a Service pointing to more than one Ingress, with only one containing affinity configuration, the first created Ingress will be used. This means that you can face the situation that you've configured session affinity on one Ingress and it doesn't work because the Service is pointing to another Ingress that doesn't configure this. diff --git a/docs/examples/auth/basic/README.md b/docs/examples/auth/basic/README.md index ffd8495f37..5e890df809 100644 --- a/docs/examples/auth/basic/README.md +++ b/docs/examples/auth/basic/README.md @@ -3,6 +3,8 @@ This example shows how to add authentication in a Ingress rule using a secret that contains a file generated with `htpasswd`. It's important the file generated is named `auth` (actually - that the secret has a key `data.auth`), otherwise the ingress-controller returns a 503. +## Create htpasswd file + ```console $ htpasswd -c auth foo New password: @@ -11,11 +13,15 @@ Re-type new password: Adding password for user foo ``` +## Convert htpasswd into a secret + ```console $ kubectl create secret generic basic-auth --from-file=auth secret "basic-auth" created ``` +## Examine secret + ```console $ kubectl get secret basic-auth -o yaml apiVersion: v1 @@ -28,8 +34,10 @@ metadata: type: Opaque ``` +## Using kubectl, create an ingress tied to the basic-auth secret + ```console -echo " +$ echo " apiVersion: networking.k8s.io/v1 kind: Ingress metadata: @@ -57,6 +65,8 @@ spec: " | kubectl create -f - ``` +## Use curl to confirm authorization is required by the ingress + ``` $ curl -v http://10.2.29.4/ -H 'Host: foo.bar.com' * Trying 10.2.29.4... @@ -84,6 +94,8 @@ $ curl -v http://10.2.29.4/ -H 'Host: foo.bar.com' * Connection #0 to host 10.2.29.4 left intact ``` +## Use curl with the correct credentials to connect to the ingress + ``` $ curl -v http://10.2.29.4/ -H 'Host: foo.bar.com' -u 'foo:bar' * Trying 10.2.29.4... diff --git a/docs/examples/auth/client-certs/README.md b/docs/examples/auth/client-certs/README.md index a60aa14e7e..94cf6c697e 100644 --- a/docs/examples/auth/client-certs/README.md +++ b/docs/examples/auth/client-certs/README.md @@ -1,11 +1,12 @@ # Client Certificate Authentication It is possible to enable Client-Certificate Authentication by adding additional annotations to your Ingress Resource. -Before getting started you must have the following Certificates Setup: -1. CA certificate and Key(Intermediate Certs need to be in CA) -2. Server Certificate(Signed by CA) and Key (CN should be equal the hostname you will use) -3. Client Certificate(Signed by CA) and Key +Before getting started you must have the following Certificates configured: + +1. CA certificate and Key (Intermediate Certs need to be in CA) +2. Server Certificate (Signed by CA) and Key (CN should be equal the hostname you will use) +3. Client Certificate (Signed by CA) and Key For more details on the generation process, checkout the Prerequisite [docs](../../PREREQUISITES.md#client-certificate-authentication). @@ -15,13 +16,13 @@ You can have as many certificates as you want. If they're in the binary DER form openssl x509 -in certificate.der -inform der -out certificate.crt -outform pem ``` -Then, you can concatenate them all in only one file, named 'ca.crt' as the following: +Then, you can concatenate them all into one file, named 'ca.crt' with the following: ```bash cat certificate1.crt certificate2.crt certificate3.crt >> ca.crt ``` -**Note:** Make sure that the Key Size is greater than 1024 and Hashing Algorithm(Digest) is something better than md5 +**Note:** Make sure that the Key Size is greater than 1024 and Hashing Algorithm (Digest) is something better than md5 for each certificate generated. Otherwise you will receive an error. ## Creating Certificate Secrets @@ -29,7 +30,7 @@ for each certificate generated. Otherwise you will receive an error. There are many different ways of configuring your secrets to enable Client-Certificate Authentication to work properly. -1. You can create a secret containing just the CA certificate and another +* You can create a secret containing just the CA certificate and another Secret containing the Server Certificate which is Signed by the CA. ```bash @@ -37,14 +38,14 @@ Authentication to work properly. kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key ``` -2. You can create a secret containing CA certificate along with the Server - Certificate, that can be used for both TLS and Client Auth. +* You can create a secret containing CA certificate along with the Server + Certificate that can be used for both TLS and Client Auth. ```bash kubectl create secret generic ca-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key --from-file=ca.crt=ca.crt ``` -3. If you want to also enable Certificate Revocation List verification you can +* If you want to also enable Certificate Revocation List verification you can create the secret also containing the CRL file in PEM format: ```bash kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt --from-file=ca.crl=ca.crl diff --git a/docs/examples/auth/external-auth/README.md b/docs/examples/auth/external-auth/README.md index 62ae72e2cf..ad3ee8b099 100644 --- a/docs/examples/auth/external-auth/README.md +++ b/docs/examples/auth/external-auth/README.md @@ -1,6 +1,6 @@ # External Basic Authentication -### Example 1: +### Example 1 Use an external service (Basic Auth) located in `https://httpbin.org` @@ -44,7 +44,7 @@ status: $ ``` -Test 1: no username/password (expect code 401) +## Test 1: no username/password (expect code 401) ```console $ curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com' @@ -74,7 +74,8 @@ $ curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com' * Connection #0 to host 172.17.4.99 left intact ``` -Test 2: valid username/password (expect code 200) +## Test 2: valid username/password (expect code 200) + ``` $ curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com' -u 'user:passwd' * Rebuilt URL to: http://172.17.4.99/ @@ -121,7 +122,8 @@ BODY: -no body in request- ``` -Test 3: invalid username/password (expect code 401) +## Test 3: invalid username/password (expect code 401) + ``` curl -k http://172.17.4.99 -v -H 'Host: external-auth-01.sample.com' -u 'user:user' * Rebuilt URL to: http://172.17.4.99/ diff --git a/docs/examples/auth/oauth-external-auth/README.md b/docs/examples/auth/oauth-external-auth/README.md index f6e21f488e..a08928720e 100644 --- a/docs/examples/auth/oauth-external-auth/README.md +++ b/docs/examples/auth/oauth-external-auth/README.md @@ -6,7 +6,7 @@ The `auth-url` and `auth-signin` annotations allow you to use an external authentication provider to protect your Ingress resources. !!! Important - This annotation requires `ingress-nginx-controller v0.9.0` or greater.) + This annotation requires `ingress-nginx-controller v0.9.0` or greater. ### Key Detail @@ -32,45 +32,47 @@ metadata: ### Example: OAuth2 Proxy + Kubernetes-Dashboard This example will show you how to deploy [`oauth2_proxy`](https://github.com/pusher/oauth2_proxy) -into a Kubernetes cluster and use it to protect the Kubernetes Dashboard using github as oAuth2 provider +into a Kubernetes cluster and use it to protect the Kubernetes Dashboard using GitHub as the OAuth2 provider. #### Prepare 1. Install the kubernetes dashboard -```console -kubectl create -f https://raw.githubusercontent.com/kubernetes/kops/master/addons/kubernetes-dashboard/v1.10.1.yaml -``` + ```console + kubectl create -f https://raw.githubusercontent.com/kubernetes/kops/master/addons/kubernetes-dashboard/v1.10.1.yaml + ``` -2. Create a [custom Github OAuth application](https://github.com/settings/applications/new) +2. Create a [custom GitHub OAuth application](https://github.com/settings/applications/new) -![Register OAuth2 Application](images/register-oauth-app.png) + ![Register OAuth2 Application](images/register-oauth-app.png) -- Homepage URL is the FQDN in the Ingress rule, like `https://foo.bar.com` -- Authorization callback URL is the same as the base FQDN plus `/oauth2/callback`, like `https://foo.bar.com/oauth2/callback` + - Homepage URL is the FQDN in the Ingress rule, like `https://foo.bar.com` + - Authorization callback URL is the same as the base FQDN plus `/oauth2/callback`, like `https://foo.bar.com/oauth2/callback` -![Register OAuth2 Application](images/register-oauth-app-2.png) + ![Register OAuth2 Application](images/register-oauth-app-2.png) 3. Configure oauth2_proxy values in the file [`oauth2-proxy.yaml`](https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/docs/examples/auth/oauth-external-auth/oauth2-proxy.yaml) with the values: -- OAUTH2_PROXY_CLIENT_ID with the github `` -- OAUTH2_PROXY_CLIENT_SECRET with the github `` -- OAUTH2_PROXY_COOKIE_SECRET with value of `python -c 'import os,base64; print(base64.b64encode(os.urandom(16)).decode("ascii"))'` + - OAUTH2_PROXY_CLIENT_ID with the github `` + - OAUTH2_PROXY_CLIENT_SECRET with the github `` + - OAUTH2_PROXY_COOKIE_SECRET with value of `python -c 'import os,base64; print(base64.b64encode(os.urandom(16)).decode("ascii"))'` 4. Customize the contents of the file [`dashboard-ingress.yaml`](https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/docs/examples/auth/oauth-external-auth/dashboard-ingress.yaml): -Replace `__INGRESS_HOST__` with a valid FQDN and `__INGRESS_SECRET__` with a Secret with a valid SSL certificate. + Replace `__INGRESS_HOST__` with a valid FQDN and `__INGRESS_SECRET__` with a Secret with a valid SSL certificate. 5. Deploy the oauth2 proxy and the ingress rules running: -```console -$ kubectl create -f oauth2-proxy.yaml,dashboard-ingress.yaml -``` + ```console + $ kubectl create -f oauth2-proxy.yaml,dashboard-ingress.yaml + ``` + +### Test -Test the oauth integration accessing the configured URL, like `https://foo.bar.com` +Test the oauth integration accessing the configured URL, e.g. `https://foo.bar.com` ![Register OAuth2 Application](images/github-auth.png) -![Github authentication](images/oauth-login.png) +![GitHub authentication](images/oauth-login.png) ![Kubernetes dashboard](images/dashboard.png) diff --git a/docs/examples/customization/configuration-snippets/README.md b/docs/examples/customization/configuration-snippets/README.md index d60a3d1a05..5ef230ff1f 100644 --- a/docs/examples/customization/configuration-snippets/README.md +++ b/docs/examples/customization/configuration-snippets/README.md @@ -2,13 +2,16 @@ ## Ingress -The Ingress in [this example](ingress.yaml) adds a custom header to Nginx configuration that only applies to that specific Ingress. If you want to add headers that apply globally to all Ingresses, please have a look at [this example](../custom-headers/README.md). +The Ingress in [this example](ingress.yaml) adds a custom header to Nginx configuration that only applies to that specific Ingress. If you want to add headers that apply globally to all Ingresses, please have a look at [an example of specifying customer headers](../custom-headers/README.md). ```console -$ kubectl apply -f ingress.yaml +kubectl apply -f ingress.yaml ``` ## Test Check if the contents of the annotation are present in the nginx.conf file using: -`kubectl exec ingress-nginx-controller-873061567-4n3k2 -n kube-system -- cat /etc/nginx/nginx.conf` + +```console +kubectl exec ingress-nginx-controller-873061567-4n3k2 -n kube-system -- cat /etc/nginx/nginx.conf +``` diff --git a/docs/examples/customization/custom-headers/README.md b/docs/examples/customization/custom-headers/README.md index 378f2aa874..499bfc3863 100644 --- a/docs/examples/customization/custom-headers/README.md +++ b/docs/examples/customization/custom-headers/README.md @@ -1,5 +1,15 @@ # Custom Headers +## Caveats + +Changes to the custom header config maps do not force a reload of the ingress-nginx-controllers. + +### Workaround + +To work around this limitation, perform a rolling restart of the deployment. + +## Example + This example demonstrates configuration of the nginx ingress controller via a ConfigMap to pass a custom list of headers to the upstream server. @@ -29,4 +39,4 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main ## Test Check the contents of the ConfigMaps are present in the nginx.conf file using: -`kubectl exec ingress-nginx-controller-873061567-4n3k2 -n ingress-nginx -- cat /etc/nginx/nginx.conf` \ No newline at end of file +`kubectl exec ingress-nginx-controller-873061567-4n3k2 -n ingress-nginx -- cat /etc/nginx/nginx.conf` diff --git a/docs/examples/customization/external-auth-headers/README.md b/docs/examples/customization/external-auth-headers/README.md index 9aaf6864b6..946088b4bc 100644 --- a/docs/examples/customization/external-auth-headers/README.md +++ b/docs/examples/customization/external-auth-headers/README.md @@ -1,7 +1,7 @@ # External authentication, authentication service response headers propagation This example demonstrates propagation of selected authentication service response headers -to backend service. +to a backend service. Sample configuration includes: @@ -37,7 +37,7 @@ public-demo-echo-service public-demo-echo-service.kube.local 80 secure-demo-echo-service secure-demo-echo-service.kube.local 80 1m ``` -Test 1: public service with no auth header +## Test 1: public service with no auth header ```console $ curl -H 'Host: public-demo-echo-service.kube.local' -v 192.168.99.100 @@ -60,7 +60,7 @@ $ curl -H 'Host: public-demo-echo-service.kube.local' -v 192.168.99.100 UserID: , UserRole: ``` -Test 2: secure service with no auth header +## Test 2: secure service with no auth header ```console $ curl -H 'Host: secure-demo-echo-service.kube.local' -v 192.168.99.100 @@ -89,7 +89,7 @@ $ curl -H 'Host: secure-demo-echo-service.kube.local' -v 192.168.99.100 * Connection #0 to host 192.168.99.100 left intact ``` -Test 3: public service with valid auth header +## Test 3: public service with valid auth header ```console $ curl -H 'Host: public-demo-echo-service.kube.local' -H 'User:internal' -v 192.168.99.100 @@ -113,7 +113,7 @@ $ curl -H 'Host: public-demo-echo-service.kube.local' -H 'User:internal' -v 192. UserID: 1443635317331776148, UserRole: admin ``` -Test 4: secure service with valid auth header +## Test 4: secure service with valid auth header ```console $ curl -H 'Host: secure-demo-echo-service.kube.local' -H 'User:internal' -v 192.168.99.100 diff --git a/docs/examples/customization/ssl-dh-param/README.md b/docs/examples/customization/ssl-dh-param/README.md index 9029b834bf..2eae67ce21 100644 --- a/docs/examples/customization/ssl-dh-param/README.md +++ b/docs/examples/customization/ssl-dh-param/README.md @@ -1,7 +1,7 @@ # Custom DH parameters for perfect forward secrecy This example aims to demonstrate the deployment of an nginx ingress controller and -use a ConfigMap to configure custom Diffie-Hellman parameters file to help with +use a ConfigMap to configure a custom Diffie-Hellman parameters file to help with "Perfect Forward Secrecy". ## Custom configuration @@ -27,7 +27,7 @@ $ kubectl create -f configmap.yaml ## Custom DH parameters secret ```console -$> openssl dhparam 4096 2> /dev/null | base64 +$ openssl dhparam 4096 2> /dev/null | base64 LS0tLS1CRUdJTiBESCBQQVJBTUVURVJ... ``` @@ -52,4 +52,6 @@ $ kubectl create -f ssl-dh-param.yaml ## Test Check the contents of the configmap is present in the nginx.conf file using: -`kubectl exec ingress-nginx-controller-873061567-4n3k2 -n kube-system -- cat /etc/nginx/nginx.conf` +```console +$ kubectl exec ingress-nginx-controller-873061567-4n3k2 -n kube-system -- cat /etc/nginx/nginx.conf +``` diff --git a/docs/examples/customization/sysctl/README.md b/docs/examples/customization/sysctl/README.md index b285808b55..54fbe4355d 100644 --- a/docs/examples/customization/sysctl/README.md +++ b/docs/examples/customization/sysctl/README.md @@ -1,6 +1,6 @@ # Sysctl tuning -This example aims to demonstrate the use of an Init Container to adjust sysctl default values using `kubectl patch` +This example aims to demonstrate the use of an Init Container to adjust sysctl default values using `kubectl patch`. ```console kubectl patch deployment -n ingress-nginx ingress-nginx-controller \ diff --git a/docs/examples/docker-registry/README.md b/docs/examples/docker-registry/README.md index 102c8d39dc..8ba230f2ca 100644 --- a/docs/examples/docker-registry/README.md +++ b/docs/examples/docker-registry/README.md @@ -1,6 +1,6 @@ # Docker registry -This example demonstrates how to deploy a [docker registry](https://github.com/docker/distribution) in the cluster and configure Ingress enable access from Internet +This example demonstrates how to deploy a [docker registry](https://github.com/docker/distribution) in the cluster and configure Ingress to enable access from the Internet. ## Deployment diff --git a/docs/examples/grpc/README.md b/docs/examples/grpc/README.md index 7a9c2aef27..2d1929b663 100644 --- a/docs/examples/grpc/README.md +++ b/docs/examples/grpc/README.md @@ -1,28 +1,28 @@ # gRPC -This example demonstrates how to route traffic to a gRPC service through the nginx controller. +This example demonstrates how to route traffic to a gRPC service through the Ingress-NGINX controller. ## Prerequisites 1. You have a kubernetes cluster running. -2. You have a domain name such as `example.com` that is configured to route traffic to the ingress controller. +2. You have a domain name such as `example.com` that is configured to route traffic to the Ingress-NGINX controller. 3. You have the ingress-nginx-controller installed as per docs. -4. You have a backend application running a gRPC server and listening for TCP traffic. If you want, you can use as an example. -5. You're also responsible for provisioning an SSL certificate for the ingress. So you need to have a valid SSL certificate, deployed as a Kubernetes secret of type tls, in the same namespace as the gRPC application. +4. You have a backend application running a gRPC server listening for TCP traffic. If you want, you can use as an example. +5. You're also responsible for provisioning an SSL certificate for the ingress. So you need to have a valid SSL certificate, deployed as a Kubernetes secret of type `tls`, in the same namespace as the gRPC application. ### Step 1: Create a Kubernetes `Deployment` for gRPC app - Make sure your gRPC application pod is running and listening for connections. For example you can try a kubectl command like this below: - ``` + ```console $ kubectl get po -A -o wide | grep go-grpc-greeter-server ``` - If you have a gRPC app deployed in your cluster, then skip further notes in this Step 1, and continue from Step 2 below. -- As an example gRPC application, we can use this app . +- As an example gRPC application, we can use this app . - To create a container image for this app, you can use [this Dockerfile](https://github.com/kubernetes/ingress-nginx/blob/5a52d99ae85cfe5ef9535291b8326b0006e75066/images/go-grpc-greeter-server/rootfs/Dockerfile). -- If you use the Dockerfile mentioned above, to create a image, then given below is an example of a Kubernetes manifest, to create a deployment resource, that uses that image. If needed, then edit this manifest to suit your needs. Assuming the name of this yaml file is `deployment.go-grpc-greeter-server.yaml` ; +- If you use the Dockerfile mentioned above, to create a image, then you can use the following example Kubernetes manifest to create a deployment resource that uses that image. If necessary edit this manifest to suit your needs. ``` cat < https://proto.stack.build, a protocol buffer / gRPC build service that can use > to help make it easier for your users to consume your API. -> See also the specific GRPC settings of NGINX: https://nginx.org/en/docs/http/ngx_http_grpc_module.html +> See also the specific gRPC settings of NGINX: https://nginx.org/en/docs/http/ngx_http_grpc_module.html ### Notes on using response/request streams -1. If your server does only response streaming and you expect a stream to be open longer than 60 seconds, you will have to change the `grpc_read_timeout` to accommodate for this. -2. If your service does only request streaming and you expect a stream to be open longer than 60 seconds, you have to change the +1. If your server only does response streaming and you expect a stream to be open longer than 60 seconds, you will have to change the `grpc_read_timeout` to accommodate this. +2. If your service only does request streaming and you expect a stream to be open longer than 60 seconds, you have to change the `grpc_send_timeout` and the `client_body_timeout`. 3. If you do both response and request streaming with an open stream longer than 60 seconds, you have to change all three timeouts: `grpc_read_timeout`, `grpc_send_timeout` and `client_body_timeout`. diff --git a/docs/examples/multi-tls/README.md b/docs/examples/multi-tls/README.md index 198bc6d388..cc990151b1 100644 --- a/docs/examples/multi-tls/README.md +++ b/docs/examples/multi-tls/README.md @@ -2,9 +2,8 @@ This example uses 2 different certificates to terminate SSL for 2 hostnames. -1. Deploy the controller by creating the rc in the parent dir -2. Create tls secrets for foo.bar.com and bar.baz.com as indicated in the yaml -3. Create [multi-tls.yaml](multi-tls.yaml) +1. Create tls secrets for foo.bar.com and bar.baz.com as indicated in the yaml +2. Create [multi-tls.yaml](multi-tls.yaml) This should generate a segment like: ```console diff --git a/docs/examples/psp/README.md b/docs/examples/psp/README.md index 4d5f317fbe..f8426baf25 100644 --- a/docs/examples/psp/README.md +++ b/docs/examples/psp/README.md @@ -1,17 +1,17 @@ # Pod Security Policy (PSP) -In most clusters today, by default, all resources (e.g. Deployments and ReplicatSets) +In most clusters today, by default, all resources (e.g. `Deployments` and `ReplicatSets`) have permissions to create pods. Kubernetes however provides a more fine-grained authorization policy called [Pod Security Policy (PSP)](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). PSP allows the cluster owner to define the permission of each object, for example creating a pod. If you have PSP enabled on the cluster, and you deploy ingress-nginx, -you will need to provide the Deployment with the permissions to create pods. +you will need to provide the `Deployment` with the permissions to create pods. Before applying any objects, first apply the PSP permissions by running: ```console kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/docs/examples/psp/psp.yaml ``` -Note: PSP permissions must be granted before to the creation of the Deployment and the ReplicaSet. +Note: PSP permissions must be granted before the creation of the `Deployment` and the `ReplicaSet`. diff --git a/docs/examples/rewrite/README.md b/docs/examples/rewrite/README.md index fbe9f30c70..c529c34ef6 100644 --- a/docs/examples/rewrite/README.md +++ b/docs/examples/rewrite/README.md @@ -1,6 +1,6 @@ # Rewrite -This example demonstrates how to use the Rewrite annotations +This example demonstrates how to use `Rewrite` annotations. ## Prerequisites @@ -15,9 +15,9 @@ Rewriting can be controlled using the following annotations: |Name|Description|Values| | --- | --- | --- | |nginx.ingress.kubernetes.io/rewrite-target|Target URI where the traffic must be redirected|string| -|nginx.ingress.kubernetes.io/ssl-redirect|Indicates if the location section is accessible SSL only (defaults to True when Ingress contains a Certificate)|bool| +|nginx.ingress.kubernetes.io/ssl-redirect|Indicates if the location section is only accessible via SSL (defaults to True when Ingress contains a Certificate)|bool| |nginx.ingress.kubernetes.io/force-ssl-redirect|Forces the redirection to HTTPS even if the Ingress is not TLS Enabled|bool| -|nginx.ingress.kubernetes.io/app-root|Defines the Application Root that the Controller must redirect if it's in '/' context|string| +|nginx.ingress.kubernetes.io/app-root|Defines the Application Root that the Controller must redirect if it's in `/` context|string| |nginx.ingress.kubernetes.io/use-regex|Indicates if the paths defined on an Ingress use regular expressions|bool| ## Examples diff --git a/docs/examples/static-ip/README.md b/docs/examples/static-ip/README.md index f74be5757d..992839a24b 100644 --- a/docs/examples/static-ip/README.md +++ b/docs/examples/static-ip/README.md @@ -1,6 +1,6 @@ # Static IPs -This example demonstrates how to assign a static-ip to an Ingress on through the Nginx controller. +This example demonstrates how to assign a static-ip to an Ingress on through the Ingress-NGINX controller. ## Prerequisites @@ -11,15 +11,15 @@ and that you have an ingress controller [running](../../deploy/) in your cluster ## Acquiring an IP -Since instances of the nginx controller actually run on nodes in your cluster, +Since instances of the ingress nginx controller actually run on nodes in your cluster, by default nginx Ingresses will only get static IPs if your cloudprovider supports static IP assignments to nodes. On GKE/GCE for example, even though -nodes get static IPs, the IPs are not retained across upgrade. +nodes get static IPs, the IPs are not retained across upgrades. To acquire a static IP for the ingress-nginx-controller, simply put it behind a Service of `Type=LoadBalancer`. -First, create a loadbalancer Service and wait for it to acquire an IP +First, create a loadbalancer Service and wait for it to acquire an IP: ```console $ kubectl create -f static-ip-svc.yaml @@ -30,7 +30,7 @@ NAME CLUSTER-IP EXTERNAL-IP PORT(S) ingress-nginx-lb 10.0.138.113 104.154.109.191 80:31457/TCP,443:32240/TCP 15m ``` -then, update the ingress controller so it adopts the static IP of the Service +Then, update the ingress controller so it adopts the static IP of the Service by passing the `--publish-service` flag (the example yaml used in the next step already has it set to "ingress-nginx-lb"). @@ -42,7 +42,7 @@ deployment "ingress-nginx-controller" created ## Assigning the IP to an Ingress From here on every Ingress created with the `ingress.class` annotation set to -`nginx` will get the IP allocated in the previous step +`nginx` will get the IP allocated in the previous step. ```console $ kubectl create -f ingress-nginx.yaml @@ -65,7 +65,7 @@ request_uri=http://104.154.109.191:8080/ ## Retaining the IP -You can test retention by deleting the Ingress +You can test retention by deleting the Ingress: ```console $ kubectl delete ing ingress-nginx @@ -85,16 +85,16 @@ ingress-nginx * 104.154.109.191 80, 443 13m ## Promote ephemeral to static IP -To promote the allocated IP to static, you can update the Service manifest +To promote the allocated IP to static, you can update the Service manifest: ```console $ kubectl patch svc ingress-nginx-lb -p '{"spec": {"loadBalancerIP": "104.154.109.191"}}' "ingress-nginx-lb" patched ``` -and promote the IP to static (promotion works differently for cloudproviders, -provided example is for GKE/GCE) -` +... and promote the IP to static (promotion works differently for cloudproviders, +provided example is for GKE/GCE): + ```console $ gcloud compute addresses create ingress-nginx-lb --addresses 104.154.109.191 --region us-central1 Created [https://www.googleapis.com/compute/v1/projects/kubernetesdev/regions/us-central1/addresses/ingress-nginx-lb]. @@ -114,4 +114,3 @@ users: Now even if the Service is deleted, the IP will persist, so you can recreate the Service with `spec.loadBalancerIP` set to `104.154.109.191`. - diff --git a/docs/how-it-works.md b/docs/how-it-works.md index 1e530d0454..b7d48b00ce 100644 --- a/docs/how-it-works.md +++ b/docs/how-it-works.md @@ -1,6 +1,6 @@ # How it works -The objective of this document is to explain how the NGINX Ingress controller works, in particular how the NGINX model is built and why we need one. +The objective of this document is to explain how the Ingress-NGINX controller works, in particular how the NGINX model is built and why we need one. ## NGINX configuration diff --git a/docs/index.md b/docs/index.md index b061418143..bda45d3175 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,6 +1,6 @@ # Overview -This is the documentation for the NGINX Ingress Controller. +This is the documentation for the Ingress NGINX Controller. It is built around the [Kubernetes Ingress resource](https://kubernetes.io/docs/concepts/services-networking/ingress/), using a [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) to store the controller configuration. @@ -26,7 +26,7 @@ Its important because until now, a default install of the Ingress-NGINX controll On clusters with more than one instance of the Ingress-NGINX controller, all instances of the controllers must be aware of which Ingress objects they serve. The `ingressClassName` field of an Ingress is the way to let the controller know about that. -``` +```console kubectl explain ingressclass ``` ``` @@ -67,7 +67,9 @@ FIELDS: There are 2 reasons primarily. -_(Reason #1)_ Until K8s version 1.21, it was possible to create an Ingress resource using deprecated versions of the Ingress API, such as: +### Reason #1 + +Until K8s version 1.21, it was possible to create an Ingress resource using deprecated versions of the Ingress API, such as: - `extensions/v1beta1` - `networking.k8s.io/v1beta1` @@ -76,7 +78,9 @@ You would get a message about deprecation, but the Ingress resource would get cr From K8s version 1.22 onwards, you can **only** access the Ingress API via the stable, `networking.k8s.io/v1` API. The reason is explained in the [official blog on deprecated ingress API versions](https://kubernetes.io/blog/2021/07/26/update-with-ingress-nginx/). -_(Reason #2)_ if you are already using the Ingress-NGINX controller and then upgrade to K8s version v1.22 , there are several scenarios where your existing Ingress objects will not work how you expect. Read this FAQ to check which scenario matches your use case. +### Reason #2 + +If you are already using the Ingress-NGINX controller and then upgrade to K8s version v1.22 , there are several scenarios where your existing Ingress objects will not work how you expect. Read this FAQ to check which scenario matches your use case. ## What is ingressClassName field ? @@ -85,7 +89,7 @@ _(Reason #2)_ if you are already using the Ingress-NGINX controller and then upg ```shell kubectl explain ingress.spec.ingressClassName ``` -``` +```console KIND: Ingress VERSION: networking.k8s.io/v1 @@ -112,7 +116,7 @@ The `.spec.ingressClassName` behavior has precedence over the deprecated `kubern - If you have only one instance of the Ingress-NGINX controller running in your cluster, and you still want to use IngressClass, you should add the annotation `ingressclass.kubernetes.io/is-default-class` in your IngressClass, so that any new Ingress objects will have this one as default IngressClass. -In this case, you need to make your controller aware of the objects. If you have any Ingress objects that don't yet have either the [`.spec.ingressClassName`](https://kubernetes.io/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec) field set in their manifest, or the ingress annotation (`kubernetes.io/ingress.class`), then you should start your Ingress-NGINX controller with the flag `--watch-ingress-without-class=true`. +In this case, you need to make your controller aware of the objects. If you have any Ingress objects that don't yet have either the [`.spec.ingressClassName`](https://kubernetes.io/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec) field set in their manifest, or the ingress annotation (`kubernetes.io/ingress.class`), then you should start your Ingress-NGINX controller with the flag [--watch-ingress-without-class=true](#what-is-the-flag-watch-ingress-without-class). You can configure your Helm chart installation's values file with `.controller.watchIngressWithoutClass: true`. @@ -130,7 +134,8 @@ metadata: spec: controller: k8s.io/ingress-nginx ``` -And add the value "spec.ingressClassName=nginx" in your Ingress objects + +And add the value `spec.ingressClassName=nginx` in your Ingress objects. ## I have multiple ingress objects in my cluster. What should I do ? @@ -138,7 +143,7 @@ And add the value "spec.ingressClassName=nginx" in your Ingress objects ### What is the flag '--watch-ingress-without-class' ? -- Its a flag that is passed,as an argument, to the `nginx-ingress-controller` executable. In the configuration, it looks like this ; +- Its a flag that is passed,as an argument, to the `nginx-ingress-controller` executable. In the configuration, it looks like this: ``` ... ... @@ -209,7 +214,7 @@ If you start Ingress-Nginx B with the command line argument `--watch-ingress-wit ``` helm repo update ``` -- Now, install an additional instance of the ingress-NGINX controller like this ; +- Now, install an additional instance of the ingress-NGINX controller like this: ``` helm install ingress-nginx-2 ingress-nginx/ingress-nginx \ --namespace ingress-nginx-2 \ diff --git a/docs/kubectl-plugin.md b/docs/kubectl-plugin.md index 7f4205746f..01be19f592 100644 --- a/docs/kubectl-plugin.md +++ b/docs/kubectl-plugin.md @@ -226,7 +226,9 @@ Use the `--service ` flag if your `ingress-nginx` `LoadBalancer` servic ### ingresses -`kubectl ingress-nginx ingresses`, alternately `kubectl ingress-nginx ing`, shows a more detailed view of the ingress definitions in a namespace. Compare: +`kubectl ingress-nginx ingresses`, alternately `kubectl ingress-nginx ing`, shows a more detailed view of the ingress definitions in a namespace. + +Compare: ```console $ kubectl get ingresses --all-namespaces @@ -235,7 +237,7 @@ default example-ingress1 testaddr.local,testaddr2.local localhost 80 default test-ingress-2 * localhost 80 5d ``` -vs +vs. ```console $ kubectl ingress-nginx ingresses --all-namespaces @@ -272,7 +274,7 @@ Checking deployments... https://github.com/kubernetes/ingress-nginx/issues/3808 ``` -to show the lints added **only** for a particular `ingress-nginx` release, use the `--from-version` and `--to-version` flags: +To show the lints added **only** for a particular `ingress-nginx` release, use the `--from-version` and `--to-version` flags: ```console $ kubectl ingress-nginx lint --all-namespaces --verbose --from-version 0.24.0 --to-version 0.24.0 diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md index 2bcc97dca5..2e8684a8bc 100644 --- a/docs/troubleshooting.md +++ b/docs/troubleshooting.md @@ -13,7 +13,7 @@ Do not move it without providing redirects. There are many ways to troubleshoot the ingress-controller. The following are basic troubleshooting methods to obtain more information. -Check the Ingress Resource Events +### Check the Ingress Resource Events ```console $ kubectl get ing -n @@ -41,7 +41,7 @@ Events: Normal UPDATE 58s ingress-nginx-controller Ingress default/cafe-ingress ``` -Check the Ingress Controller Logs +### Check the Ingress Controller Logs ```console $ kubectl get pods -n @@ -58,7 +58,7 @@ NGINX Ingress controller .... ``` -Check the Nginx Configuration +### Check the Nginx Configuration ```console $ kubectl get pods -n @@ -80,7 +80,7 @@ http { .... ``` -Check if used Services Exist +### Check if used Services Exist ```console $ kubectl get svc --all-namespaces @@ -130,14 +130,14 @@ Both authentications must work: **Service authentication** -The Ingress controller needs information from apiserver. Therefore, authentication is required, which can be achieved in two different ways: +The Ingress controller needs information from apiserver. Therefore, authentication is required, which can be achieved in a couple of ways: -1. _Service Account:_ 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. +* _Service Account:_ 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. -2. _Kubeconfig file:_ 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 `--kubeconfig` flag. The value of the flag is a path to a file specifying how to connect to the API server. Using the `--kubeconfig` does not requires the flag `--apiserver-host`. +* _Kubeconfig file:_ 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 `--kubeconfig` flag. The value of the flag is a path to a file specifying how to connect to the API server. Using the `--kubeconfig` does not requires the flag `--apiserver-host`. The format of the file is identical to `~/.kube/config` which is used by kubectl to connect to the API server. See 'kubeconfig' section for details. -3. _Using the flag `--apiserver-host`:_ Using this flag `--apiserver-host=http://localhost:8080` it is possible to specify an unsecured API server or reach a remote kubernetes cluster using [kubectl proxy](https://kubernetes.io/docs/user-guide/kubectl/kubectl_proxy/). +* _Using the flag `--apiserver-host`:_ Using this flag `--apiserver-host=http://localhost:8080` it is possible to specify an unsecured API server or reach a remote kubernetes cluster using [kubectl proxy](https://kubernetes.io/docs/user-guide/kubectl/kubectl_proxy/). Please do not use this approach in production. In the diagram below you can see the full authentication flow with all options, starting with the browser @@ -247,72 +247,72 @@ Note: The below is based on the nginx [documentation](https://docs.nginx.com/ngi 1. SSH into the worker -```console -$ ssh user@workerIP -``` + ```console + $ ssh user@workerIP + ``` 2. Obtain the Docker Container Running nginx -```console -$ docker ps | grep ingress-nginx-controller -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -d9e1d243156a k8s.gcr.io/ingress-nginx/controller "/usr/bin/dumb-init …" 19 minutes ago Up 19 minutes k8s_ingress-nginx-controller_ingress-nginx-controller-67956bf89d-mqxzt_kube-system_079f31ec-aa37-11e8-ad39-080027a227db_0 -``` + ```console + $ docker ps | grep ingress-nginx-controller + CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES + d9e1d243156a k8s.gcr.io/ingress-nginx/controller "/usr/bin/dumb-init …" 19 minutes ago Up 19 minutes k8s_ingress-nginx-controller_ingress-nginx-controller-67956bf89d-mqxzt_kube-system_079f31ec-aa37-11e8-ad39-080027a227db_0 + ``` 3. Exec into the container -```console -$ docker exec -it --user=0 --privileged d9e1d243156a bash -``` + ```console + $ docker exec -it --user=0 --privileged d9e1d243156a bash + ``` 4. Make sure nginx is running in `--with-debug` -```console -$ nginx -V 2>&1 | grep -- '--with-debug' -``` + ```console + $ nginx -V 2>&1 | grep -- '--with-debug' + ``` 5. Get list of processes running on container -```console -$ ps -ef -UID PID PPID C STIME TTY TIME CMD -root 1 0 0 20:23 ? 00:00:00 /usr/bin/dumb-init /nginx-ingres -root 5 1 0 20:23 ? 00:00:05 /ingress-nginx-controller --defa -root 21 5 0 20:23 ? 00:00:00 nginx: master process /usr/sbin/ -nobody 106 21 0 20:23 ? 00:00:00 nginx: worker process -nobody 107 21 0 20:23 ? 00:00:00 nginx: worker process -root 172 0 0 20:43 pts/0 00:00:00 bash -``` - -7. Attach gdb to the nginx master process - -```console -$ gdb -p 21 -.... -Attaching to process 21 -Reading symbols from /usr/sbin/nginx...done. -.... -(gdb) -``` - -8. Copy and paste the following: - -```console -set $cd = ngx_cycle->config_dump -set $nelts = $cd.nelts -set $elts = (ngx_conf_dump_t*)($cd.elts) -while ($nelts-- > 0) -set $name = $elts[$nelts]->name.data -printf "Dumping %s to nginx_conf.txt\n", $name -append memory nginx_conf.txt \ - $elts[$nelts]->buffer.start $elts[$nelts]->buffer.end -end -``` - -9. Quit GDB by pressing CTRL+D - -10. Open nginx_conf.txt - -```console -cat nginx_conf.txt -``` + ```console + $ ps -ef + UID PID PPID C STIME TTY TIME CMD + root 1 0 0 20:23 ? 00:00:00 /usr/bin/dumb-init /nginx-ingres + root 5 1 0 20:23 ? 00:00:05 /ingress-nginx-controller --defa + root 21 5 0 20:23 ? 00:00:00 nginx: master process /usr/sbin/ + nobody 106 21 0 20:23 ? 00:00:00 nginx: worker process + nobody 107 21 0 20:23 ? 00:00:00 nginx: worker process + root 172 0 0 20:43 pts/0 00:00:00 bash + ``` + +6. Attach gdb to the nginx master process + + ```console + $ gdb -p 21 + .... + Attaching to process 21 + Reading symbols from /usr/sbin/nginx...done. + .... + (gdb) + ``` + +7. Copy and paste the following: + + ```console + set $cd = ngx_cycle->config_dump + set $nelts = $cd.nelts + set $elts = (ngx_conf_dump_t*)($cd.elts) + while ($nelts-- > 0) + set $name = $elts[$nelts]->name.data + printf "Dumping %s to nginx_conf.txt\n", $name + append memory nginx_conf.txt \ + $elts[$nelts]->buffer.start $elts[$nelts]->buffer.end + end + ``` + +8. Quit GDB by pressing CTRL+D + +9. Open nginx_conf.txt + + ```console + cat nginx_conf.txt + ``` diff --git a/docs/user-guide/default-backend.md b/docs/user-guide/default-backend.md index d57b893235..f15561086b 100644 --- a/docs/user-guide/default-backend.md +++ b/docs/user-guide/default-backend.md @@ -1,6 +1,6 @@ # Default backend -The default backend is a service which handles all URL paths and hosts the nginx controller doesn't understand +The default backend is a service which handles all URL paths and hosts the Ingress-NGINX controller doesn't understand (i.e., all the requests that are not mapped with an Ingress). Basically a default backend exposes two URLs: diff --git a/docs/user-guide/monitoring.md b/docs/user-guide/monitoring.md index 05d6a3f872..7d86260f0f 100644 --- a/docs/user-guide/monitoring.md +++ b/docs/user-guide/monitoring.md @@ -22,11 +22,11 @@ This tutorial will show you how to install [Prometheus](https://prometheus.io/) --set-string controller.podAnnotations."prometheus\.io/scrape"="true" \ --set-string controller.podAnnotations."prometheus\.io/port"="10254" ``` - - You can validate that the controller is configured for metrics by looking at the values of the installed release, like this ; + - You can validate that the controller is configured for metrics by looking at the values of the installed release, like this: ``` helm get values ingress-controller --namespace ingress-nginx ``` - - You should be able to see the values shown below ; + - You should be able to see the values shown below: ``` .. controller: diff --git a/docs/user-guide/multiple-ingress.md b/docs/user-guide/multiple-ingress.md index f135740447..83eeb3f481 100644 --- a/docs/user-guide/multiple-ingress.md +++ b/docs/user-guide/multiple-ingress.md @@ -82,7 +82,7 @@ metadata: kubernetes.io/ingress.class: "gce" ``` -will target the GCE controller, forcing the nginx controller to ignore it, while an annotation like +will target the GCE controller, forcing the Ingress-NGINX controller to ignore it, while an annotation like: ```yaml metadata: @@ -91,7 +91,7 @@ metadata: kubernetes.io/ingress.class: "nginx" ``` -will target the nginx controller, forcing the GCE controller to ignore it. +will target the Ingress-NGINX controller, forcing the GCE controller to ignore it. You can change the value "nginx" to something else by setting the `--ingress-class` flag: diff --git a/docs/user-guide/nginx-configuration/configmap.md b/docs/user-guide/nginx-configuration/configmap.md index d35a19b1a9..b48cc1028e 100755 --- a/docs/user-guide/nginx-configuration/configmap.md +++ b/docs/user-guide/nginx-configuration/configmap.md @@ -221,7 +221,7 @@ Enables the return of the header Server from the backend instead of the generic ## allow-snippet-annotations -Enables Ingress to parse and add *-snippet annotations/directives created by the user. _**default:**_ `true`; +Enables Ingress to parse and add *-snippet annotations/directives created by the user. _**default:**_ `true` Warning: We recommend enabling this option only if you TRUST users with permission to create Ingress objects, as this may allow a user to add restricted configurations to the final nginx.conf file diff --git a/docs/user-guide/third-party-addons/opentracing.md b/docs/user-guide/third-party-addons/opentracing.md index 27c64e3006..468be24f7f 100644 --- a/docs/user-guide/third-party-addons/opentracing.md +++ b/docs/user-guide/third-party-addons/opentracing.md @@ -140,7 +140,7 @@ kubectl create -f https://raw.githubusercontent.com/rnburn/zipkin-date-server/ma kubectl create -f https://raw.githubusercontent.com/rnburn/zipkin-date-server/master/kubernetes/deployment.yaml ``` -Also we need to configure the NGINX controller ConfigMap with the required values: +Also we need to configure the Ingress-NGINX controller ConfigMap with the required values: ``` $ echo '