The source code and default configuration of the Building Block is available in our For information on release notes and new features please follow the link: Release notes ingress-nginx


The Ingress Controller which is used by e.g. by Kubernetes for reverse proxy and load balancing capabilities.

Prerequisites on Ingress-Nginx

You need to provide a storage provider for this Building Block. Proceed with the following prerequisite description to use the Velero Building Block out of the box.

A recommended resource overview is listed in the table below.

CPU / vCPU Memory
1.26 532MiB

No further activities need to be carried out in advance.

Adding the Building Block

Add the directory syseleven-ingress-nginx to your control repository as well as the .gitlab-ci.yml to the directory with the following content:

  - project: syseleven/building-blocks/helmfiles/ingress-nginx
    file: JobDevelopment.yaml
    ref: 5.45.0
  - project: syseleven/building-blocks/helmfiles/ingress-nginx
    file: JobStaging.yaml
    ref: 5.45.0
  - project: syseleven/building-blocks/helmfiles/ingress-nginx
    file: JobProduction.yaml
    ref: 5.45.0

Remove environments you are not using by removing their include.

Required configuration

No configuration is required.

Example configuration

The following Ingress resource will create an ingress for the domain:
Due to the spec.tls section in the configuration, a certificate is generated for the domain.
The building block ingress-nginx creates a load balancer that binds an external IP address.
See kubectl get svc -n syseleven-ingess-nginx
A DNS A record pointing to the IP address of the load balancer is created for the ingress resource described here.

To make the following Ingress resource fully available, other Building Blocks besides the ingress-nginx must be installed:

  • external-dns
  • cert-manager
  • Use SysEleven DNSaaS to configure your DNS records


Create a namespace for the example:

kubectl create ns example-ingress

Create an http service:

kubectl apply -n example-ingress -f

This creates an application including a service httpbin in the namespace example-ingress.

Create the ingress resource

The service endpoint should be available outside the cluster with its own domain name using https.
The ingress must exist in the same namespace as the Service object.

kind: Ingress
  name: test-ingress
  namespace: example-ingress
    # Use ClusterIssuer: letsencrypt-production. letsencrypt-production
    # Use acme/solver: dns01defined in ClusterIssuer: letsencrypt-production. dns01
  ingressClassName: nginx

  - host: testdomain-cert.<customerdomain>.de
      - backend:
            name: httpbin
              number: 8000
        pathType: ImplementationSpecific
    - hosts:
        - testdomain-cert.<customerdomain>.de
      # Store the certificate as secret named testdomain-cert-secret in namespace: example-ingress
      secretName: testdomain-cert-secret

Check the generated certificate:
kubectl describe certificate -n example-ingress testdomain-cert-secret
kubectl get -n example-ingress secret testdomain-cert-secret -o jsonpath='{.data.tls\.crt}'| base64 -d -| openssl x509 -dates -subject -noout

Check the generated DNS configuration:
Providing the DNS record can take a few minutes. Please check regularly with the following command:
dig testdomain-cert.<customerdomain>.de

Check access to internal HTTPBIN service:
curl https://testdomain-cert.<customerdomain>.de/get


To remove the example again it is sufficient to delete the namespace.
kubectl delete ns example-ingress

Customize the default backend

The Building Block delivers a custom default backend. This default backend is used for all URLs the ingress-controller can not process (i.e., all the requests that are not mapped with an Ingress) or for requests that got a 502, 503 or 504 from the upstream backend server. This default backend delivers configurable static pages while still maintaining the original error code.

You can customize the default backend by overriding maintenancePages in values-ingress-nginx-extension.yaml. See the values.yaml for the default maintenance page.

Here is an example on how to configure different error pages for different error codes.

  404.html: |-
    <!DOCTYPE html>
  418.html: |-
  429.html: |-
  500.html: |-
  502.html: |-
  503.html: |-
  523.html: |-


Additional alertrules

  • None

Additional Grafana dashboards

  • Request Handling Performance
    • An overview of performance metrics of handled requests by the ingress-controller
  • NGINX Ingress controller
    • An overview of overall metrics collected by the ingress-controller (e.g., request volume, network pressure, ingress success rate, ingress throughput/requests, ssl certificates, ...)

Scale Setup

  • Choose between kind Deployment(default and recommended) or kind DaemonSet
  • Replicas - you can statically configure the amount of replicas you need (when using the Deployment kind)
  • Autoscale replicas - you can configure the horizontal pod autoscaler to autoscale the ingress-nginx Deployment. See values.yaml for possible options.
  • Requirements/Limits for CPU/Memory can be adjusted. We recommend not setting CPU limits so as not to throttle the Ingress controller and slow down the entire application.


Please find more infos on release notes and new features Release notes Ingres-Nginx