FLUID Ingress Controller

Description

This repository contains the FLUID controller forked from NGINX official ingress controller that uses ConfigMap to store the NGINX configuration.

This fork does not need to reload internal NGINX when any server or backend directive changes. Thanks to LUA libraries, the configuration changes are picked on the fly avoiding issues when cluster contains a huge numbers of servers or backends and they change frequently.

Learn more about using Ingress on k8s.io

What is an Ingress Controller?

Configuring a webserver or loadbalancer is harder than it should be. Most webserver configuration files are very similar. There are some applications that have weird little quirks that tend to throw a wrench in things, but for the most part you can apply the same logic to them and achieve a desired result.

The Ingress resource embodies this idea, and an Ingress controller is meant to handle all the quirks associated with a specific "class" of Ingress.

An Ingress Controller is a daemon, deployed as a Kubernetes Pod, that watches the apiserver's /ingresses endpoint for updates to the Ingress resource. Its job is to satisfy requests for Ingresses.

Different Ingress controllers comparison

The table below summarizes the key difference between nginxinc/kubernetes-ingress and kubernetes/ingress-nginx Ingress controllers. Note that the table has two columns for the nginxinc/kubernetes-ingress Ingress controller, as it can be used both with NGINX and NGINX Plus

| Aspect or Feature | NCCloud/fluid | kubernetes/ingress-nginx | nginxinc/kubernetes-ingress with NGINX | nginxinc/kubernetes-ingress with NGINX Plus | | --- | --- | --- | --- | --- | | Fundamental | | Authors | Namecheap community | Kubernetes community | NGINX Inc and community | NGINX Inc and community | | Server | OpenResty build based on Alpine image | Custom NGINX build that includes several third-party modules | NGINX official mainline build | NGINX Plus | | Commercial support | N/A | N/A | N/A | Included | | Load balancing configuration | | Merging Ingress rules with the same host | Supported | Supported | Under consideration | Under consideration | | HTTP load balancing extensions - Annotations | See the supported annotations | See the supported annotations | See the supported annotations | See the supported annotations| | HTTP load balancing extensions -- ConfigMap | See the supported ConfigMap keys | See the supported ConfigMap keys | See the supported ConfigMap keys | See the supported ConfigMap keys | | TCP/UDP | Supported via a ConfigMap | Supported via a ConfigMap | Not supported | Not supported | | Websocket | Supported | Supported | Supported via an annotation | Supported via an annotation | | TCP SSL Passthrough | Supported via a ConfigMap | Supported via a ConfigMap | Not supported | Not supported | | JWT validation | Not supported | Not supported | Not supported | Supported | | Session persistence | Supported via a third-party module | Supported via a third-party module | Not supported | Supported | | Configuration templates *1 | See the template | See the template | See the templates | See the templates | | Deployment | | Command-line arguments *2 | See the arguments | See the arguments | See the arguments | See the arguments | | TLS certificate and key for the default server | Required as a command-line argument/ auto-generated | TLS certificate and key for the default server | Required as a command-line argument/ auto-generated | Required as a command-line argument | Required as a command-line argument | | Helm chart | Supported | Supported | Coming soon | Coming soon | | Operational | | Reporting the IP address(es) of the Ingress controller into Ingress resources | Supported | Supported | Coming soon | Coming soon | | Extended Status | Supported via a third-party module | Supported via a third-party module | Not supported | Supported | | Prometheus Integration | Supported | Supported | Not supported | Supported | | Dynamic reconfiguration of endpoints (no configuration reloading) | Supported | Not supported | Not supported | Supported | | Dynamic reconfiguration of virtualhosts/servernames (no configuration reloading) | Supported | Not supported | Not supported | Not supported |

Conventions

Anytime we reference a tls secret, we mean (x509, pem encoded, RSA 2048, etc). You can generate such a certificate with: openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ${KEY_FILE} -out ${CERT_FILE} -subj "/CN=${HOST}/O=${HOST}" and create the secret via kubectl create secret tls ${CERT_NAME} --key ${KEY_FILE} --cert ${CERT_FILE}

Requirements

The default backend is a service which handles all url paths and hosts the nginx controller doesn't understand (i.e., all the requests that are not mapped with an Ingress). Basically a default backend exposes two URLs:

/healthz that returns 200
/ that returns 404

The sub-directory /images/404-server provides a service which satisfies the requirements for a default backend. The sub-directory /images/custom-error-pages provides an additional service for the purpose of customizing the error pages served via the default backend.

Annotation ingress.class

If you have multiple Ingress controllers in a single cluster, you can pick one by specifying the ingress.class annotation, eg creating an Ingress with an annotation like

metadata:
  name: foo
  annotations:
    kubernetes.io/ingress.class: "gce"

will target the GCE controller, forcing the nginx controller to ignore it, while an annotation like

metadata:
  name: foo
  annotations:
    kubernetes.io/ingress.class: "nginx"

will target the nginx controller, forcing the GCE controller to ignore it.

Note: Deploying multiple ingress controller and not specifying the annotation will result in both controllers fighting to

Fluid

Install / Use

README