Ingress Module uses CNCF recommended, Cloud Native projects, such as Ingress NGINX and HAProxy Ingress Controller as URL path-based routing reverse proxies and load balancers, and cert-manager to automate the issuing and renewal of TLS certificates from various issuing sources.
The module also includes additional tools like Forecastle, a web-based global directory of all the services offered by your cluster, and ExternalDNS to manage DNS records natively from Kubernetes.
The reference architecture used to deploy the Ingress Module is shown below:
flowchart LR
User([End users])
LB[Load Balancer]
subgraph cluster[Kubernetes Cluster]
direction LR
IC[Ingress Controller]
SVC[Service]
P1[Pod 1]
P2[Pod 2]
P3[Pod 3]
IC --> SVC
SVC --> P1
SVC --> P2
SVC --> P3
end
User --> LB
LB --> IC
The traffic from end users arrives first at a Load Balancer that distributes the traffic between the available Ingress Controllers (usually, one for each availability zone).
Once the traffic reaches the Ingress Controller, the Ingress proxies the traffic to the Kubernetes service based on the URL path of the request.
The service is a Kubernetes abstraction that makes the traffic arrive at the pods where the actual application is running, usually using iptables rules.
Ingress Module is part of SIGHUP Distribution (SD) and is deployed automatically by furyctl when you create or update a cluster. You don't need to download, vendor or install its packages manually.
You configure the module under spec.distribution.modules.ingress in your furyctl.yaml. You set the baseDomain and choose the ingress controller via nginx.type (or haproxy.type): single, dual, or none to disable it. The other fields are optional and fall back to sensible defaults.
