Merge pull request #3459 from jtravee/Ingress_rule_config

NGINX ingress controller no longer runs in hostNetwork
This commit is contained in:
Catherine Luse
2021-08-26 12:31:08 -07:00
committed by GitHub
3 changed files with 67 additions and 54 deletions
@@ -0,0 +1,60 @@
---
title: Ingress Configuration
description: Ingress configuration
weight: 9999
---
- [NGINX Ingress controller changes in Kubernetes v1.21](#nginx-ingress-controller-changes-in-Kubernetes-v1-21)
- [Automatically generate a xip.io hostname](#automatically-generate-a-xip-io-hostname)
- [Specify a hostname to use](#specify-a-hostname-to-use)
- [Use as the default backend](#use-as-the-default-backend)
- [Certificates](#certificates)
- [Labels and Annotations](#labels-and-annotations)
### NGINX Ingress controller changes in Kubernetes v1.21
For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork but uses hostPorts for port 80 and port 443. This was done so the admission webhook can be configured to be accessed using ClusterIP so it can only be reached inside the cluster.
### Automatically generate a xip.io hostname
If you choose this option, ingress routes requests to hostname to a DNS name that's automatically generated. Rancher uses [xip.io](http://xip.io/) to automatically generates the DNS name. This option is best used for testing, _not_ production environments.
>**Note:** To use this option, you must be able to resolve to `xip.io` addresses.
1. Add a **Target Backend**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**.
1. **Optional:** If you want specify a workload or service when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field. Typically, the first rule that you create does not include a path.
1. Select a workload or service from the **Target** drop-down list for each target you've added.
1. Enter the **Port** number that each target operates on.
### Specify a hostname to use
If you use this option, ingress routes requests for a hostname to the service or workload that you specify.
1. Enter the hostname that your ingress will handle request forwarding for. For example, `www.mysite.com`.
1. Add a **Target Backend**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**.
1. **Optional:** If you want specify a workload or service when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field. Typically, the first rule that you create does not include a path.
1. Select a workload or service from the **Target** drop-down list for each target you've added.
1. Enter the **Port** number that each target operates on.
### Use as the default backend
Use this option to set an ingress rule for handling requests that don't match any other ingress rules. For example, use this option to route requests that can't be found to a `404` page.
>**Note:** If you deployed Rancher using RKE, a default backend for 404s and 202s is already configured.
1. Add a **Target Backend**. Click either **Service** or **Workload** to add the target.
1. Select a service or workload from the **Target** drop-down list.
### Certificates
>**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/certificates/).
1. Click **Add Certificate**.
1. Select a **Certificate** from the drop-down list.
1. Enter the **Host** using encrypted communication.
1. To add additional hosts that use the certificate, click **Add Hosts**.
### Labels and Annotations
Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your ingress.
For a list of annotations available for use, see the [Nginx Ingress Controller Documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/).
@@ -18,55 +18,3 @@ Ingress can be added for workloads to provide load balancing, SSL termination an
**Result:** Your ingress is added to the project. The ingress begins enforcing your ingress rules.
# Ingress Rule Configuration
- [Automatically generate a xip.io hostname](#automatically-generate-a-xip-io-hostname)
- [Specify a hostname to use](#specify-a-hostname-to-use)
- [Use as the default backend](#use-as-the-default-backend)
- [Certificates](#certificates)
- [Labels and Annotations](#labels-and-annotations)
### Automatically generate a xip.io hostname
If you choose this option, ingress routes requests to hostname to a DNS name that's automatically generated. Rancher uses [xip.io](http://xip.io/) to automatically generates the DNS name. This option is best used for testing, _not_ production environments.
>**Note:** To use this option, you must be able to resolve to `xip.io` addresses.
1. Add a **Target Backend**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**.
1. **Optional:** If you want specify a workload or service when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field. Typically, the first rule that you create does not include a path.
1. Select a workload or service from the **Target** drop-down list for each target you've added.
1. Enter the **Port** number that each target operates on.
### Specify a hostname to use
If you use this option, ingress routes requests for a hostname to the service or workload that you specify.
1. Enter the hostname that your ingress will handle request forwarding for. For example, `www.mysite.com`.
1. Add a **Target Backend**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**.
1. **Optional:** If you want specify a workload or service when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field. Typically, the first rule that you create does not include a path.
1. Select a workload or service from the **Target** drop-down list for each target you've added.
1. Enter the **Port** number that each target operates on.
### Use as the default backend
Use this option to set an ingress rule for handling requests that don't match any other ingress rules. For example, use this option to route requests that can't be found to a `404` page.
>**Note:** If you deployed Rancher using RKE, a default backend for 404s and 202s is already configured.
1. Add a **Target Backend**. Click either **Service** or **Workload** to add the target.
1. Select a service or workload from the **Target** drop-down list.
### Certificates
>**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/certificates/).
1. Click **Add Certificate**.
1. Select a **Certificate** from the drop-down list.
1. Enter the **Host** using encrypted communication.
1. To add additional hosts that use the certificate, click **Add Hosts**.
### Labels and Annotations
Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your ingress.
For a list of annotations available for use, see the [Nginx Ingress Controller Documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/).
@@ -115,9 +115,14 @@ ingress:
### Configuring network options
_Available as of v1.1.11_
{{% tabs %}}
{{% tab "v1.30" %}}
For Kubernetes v1.21 and up, the NGINX ingress controller no longer runs in `hostNetwork: true` but uses hostPorts for port `80` and port `443`. This was done so the admission webhook can be configured to be accessed using ClusterIP so it can only be reached inside the cluster. If you want to change the mode and/or the ports, see the options below.
{{% /tab %}}
{{% tab "v1.1.11" %}}
By default, the nginx ingress controller is configured using `hostNetwork: true` on the default ports `80` and `443`. If you want to change the mode and/or the ports, see the options below.
{{% /tab %}}
{{% /tabs %}}
Configure the nginx ingress controller using `hostPort` and override the default ports: