This app installs the Ingress NGINX Controller into your cluster.
Its job is to satisfy external requests to services running in the cluster. See the Kubernetes Ingress documentation for a higher level overview.
- Ingress NGINX Controller
- Prerequisites
- Installation
- Configuration
- Migration from
nginx-ingress-controller-app
- Development
- Kubernetes version >= v1.20.0
- Ingress API version >=
networking.k8s.io/v1
(extensions/v1beta1
&networking.k8s.io/v1beta1
are no longer supported)
Additionally, you'll have to make sure your Ingress
resources are using the .spec.ingressClassName
, matching the name of your IngressClass
resource (default: nginx
).
There are two ways to install this app into your cluster:
- Using our web interface.
- Directly creating the
App
resource.
This is an example of the values file you could upload using our web interface:
controller:
config:
error-log-level: info
If you have access to management cluster, you can create the App
& ConfigMap
resources directly. These sample values deploy the ingress-nginx
app to your cluster abc12
:
apiVersion: v1
kind: ConfigMap
metadata:
name: ingress-nginx-user-values
namespace: abc12
data:
values: |
controller:
config:
error-log-level: info
---
apiVersion: application.giantswarm.io/v1alpha1
kind: App
metadata:
name: ingress-nginx
namespace: abc12
spec:
catalog: giantswarm
name: ingress-nginx
version: 3.9.3
userConfig:
configMap:
name: ingress-nginx-user-values
namespace: abc12
namespace: kube-system
See our app configuration reference for more details.
All configuration options are documented in the values.yaml
.
In case it is not possible to update all Ingress
resources to specify the .spec.ingressClassName
, you can add the --watch-ingress-without-class
argument using the controller.extraArgs
. Please make sure there is no other Ingress Controller doing so deployed to your cluster.
If you are running multiple Ingress NGINX Controllers, each needs to have an unique IngressClass
resource. You can use the values structure below:
controller:
ingressClassResource:
name: nginx-internal
controllerValue: k8s.io/ingress-nginx-internal
Note: It is not possible to change the controller.ingressClassResource
values after installation, except you are also changing controller.ingressClassResource.name
. If you need to change these values, you will need to uninstall the app first.
This chart contains a template for an additional internal service to cover the use case of having separate external & internal services with a single Ingress NGINX Controller instance.
Valid configuration options are as follows:
External only (default)
This is the default behavior. No additional configuration required.
Internal only
This configures the default service to create an internal facing load balancer:
controller:
service:
public: false
External & internal
This enables the additional internal service and creates an internal facing load balancer.
controller:
service:
internal:
enabled: true
Since version v2.17.0, this chart has the use-proxy-procotol
enabled by default when installed in AWS.
To disable this behavior, it is still possible to set controller.config.use-proxy-protocol
to "false"
in the values.
Please see our migration guide if you want to update your nginx-ingress-controller-app
deployment to the new ingress-nginx
chart.
To install the chart locally:
$ git clone https://github.com/giantswarm/ingress-nginx-app.git
$ cd ingress-nginx-app
$ helm install helm/ingress-nginx
Provide a custom values.yaml
:
$ helm install helm/ingress-nginx --values values.yaml
This App includes E2E tests using the apptest-framework. You can trigger the configured tests on any open PR by adding the following as a comment:
/run app-test-suites
E2E tests include:
Suite | Test | Description | Providers |
---|---|---|---|
Basic | App install | Check if the App is installed correctly and marked as deployed |
CAPA |
Basic | Hello World | Deploy hello-world app and verify that it's reachable through the Ingress |
CAPA |
- Ensure CHANGELOG.md is up to date.
- Create a new branch with name
release#vx.x.x
. Automation will create a release PR. - Merging the release PR will push a new Git tag and trigger a new tarball to be pushed to the [giantswarm-catalog].