Applications today rarely run in isolation. They need to be reachable by users, other services, or external systems, and they often need control over how traffic enters the deployment.
Charmed ingress solutions provide the traffic layer that makes this possible. They sit at the boundary of your deployment and manage how requests are routed to workloads.
They allow you to:
- Expose your applications outside their network boundary
- Control inbound traffic
- Add routing, security and caching layers
- Standardize access across machine and Kubernetes environments
If your charm workload needs to be reachable from the public internet, a virtual network, or other applications, you will likely need an ingress charm as part of your deployment.
There is no single ingress solution that fits every scenario. The right ingress solution depends on several factors, including:
- Substrate (machine vs Kubernetes)
- Traffic layer (Layer 4 or layer 7)
- Complexity of ingress requirements
- Security requirements
- TLS termination
Choosing the right ingress
Use the following considerations to identify which ingress setup best matches your needs.
Is your workload on a machine or Kubernetes substrate?
If it’s on a machine substrate, the recommended option is the HAProxy charm. For Kubernetes, we have the following charms available:
NOTE: Nginx ingress integrator and Gateway API integrator are workload-less charms and do not install an ingress. The ingress needs to be pre-installed.
Do you require caching?
The following charms provide content caching on both machine and Kubernetes substrates:
Built on top of NGINX, these charms are suited for workloads that serve static assets, documentation, or other repeatable content. Users will benefit from reduced backend traffic and improved response times.
Is your workload charmed? Will your ingress requirements remain static after deployment?
If your workload is not charmed, or if you expect ingress configuration to change over time, or if you need to configure additional ingress requirements that are not provided by the ingress interface, we recommend the ingress-configurator charm. This charm:
- Acts as a translation layer between applications requiring ingress and HAProxy
- Allows non-charmed workloads to integrate into the Juju ecosystem
- Enables dynamic ingress configuration without redeploying infrastructure
Is your traffic on Layer 4 or Layer 7?
The kind of traffic that enters your application will influence which ingress solution is appropriate.
- Layer 7 (HTTP/HTTPS) traffic is supported by all ingress charms listed above.
- Layer 4 (TCP) traffic is currently supported only by HAProxy and Traefik.
Choosing the right interface
Beyond the core questions above, you may also want to evaluate whether:
- Your ingress is managed per-application or per-unit
- Your requirements are simple or more advanced
The following interfaces are available to be implemented by the ingress requirer charms:
- Ingress - A simple controller-independent interface that provides HTTP/HTTPS routing to an application, including load balancing across all units.
- Ingress-per-unit - a simple controller-independent interface that provides an ingress URL per unit.
*-route(haproxy-route, gateway-route, traefik-route, nginx-route) - An advanced alternative to the ingress relation where workload specific configuration can be provided by the user.
Have questions?
Reach out to us on the Charm Development channel.