Ingress-NGINX

Overview

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

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.

Recommended Setup

A recommended resource overview is listed in the table below.

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:

include:
  - 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:
testdomain-cert.<customerdomain>.de.
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.

Prepare

Create a namespace for the example:

kubectl create ns example-ingress

Create an http service:

kubectl apply -n example-ingress -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml

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.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: example-ingress
  annotations:
    # Use ClusterIssuer: letsencrypt-production.
    cert-manager.io/cluster-issuer: letsencrypt-production
  labels:
    # Use acme/solver: dns01defined in ClusterIssuer: letsencrypt-production.
    cert-manager.io/solver: dns01
spec:
  ingressClassName: nginx
  rules:

  - host: testdomain-cert.<customerdomain>.de
    http:
      paths:
      - backend:
          service:
            name: httpbin
            port:
              number: 8000
        pathType: ImplementationSpecific
  tls:
    - 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
or
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 @ns01.cloud.syseleven.net testdomain-cert.<customerdomain>.de

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

Cleanup

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.

maintenancePages:
  404.html: |-
    <!DOCTYPE html>
    <html>
      <head>
        <title>Error</title>
      </head>
      <body>
        ...
      </body>
    </html>
  418.html: |-
    ...
  429.html: |-
    ...
  500.html: |-
    ...
  502.html: |-
    ...
  503.html: |-
    ...
  523.html: |-
    ...

Monitoring

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.

Release-Notes

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