Planning your Ingress setup

Expose multiple apps in your Red Hat® OpenShift® on IBM Cloud® cluster by creating Ingress resources that are managed by the Ingress controller.

For information about how to expose apps in Satellite, see Exposing apps in Satellite clusters.

Planning networking for single or multiple projects

One Ingress resource is required per project where you have apps that you want to expose.

All apps are in one project

If the apps in your cluster are all in the same project, you must create one Ingress resource to define the routing rules for the apps that you want to expose.

For example, if you have app1 and app2 exposed by services in a development project, you can create an Ingress resource in the project. The resource specifies domain.net as the host and registers the paths that each app listens on with domain.net.

Note that if you want to use different domains for the apps within the same project, you can create one resource per domain.

Apps are in multiple projects

If the apps in your cluster are in different projects, you must create one Ingress resource for each project to define the app's routing rules.

You can either define the same domain in multiple resources, or use a wildcard domain to specify different subdomains within the Ingress resource for each project.

When a wildcard domain is registered, multiple subdomains can all resolve to the same host. The IBM-provided Ingress subdomain wildcard, *.<cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud, is registered by default for your cluster.

The IBM-provided TLS certificate is a wildcard certificate and can be used for the wildcard subdomain. If you want to use a wildcard custom domain, you must register the custom domain as a wildcard domain such as *.custom_domain.net, and to use TLS, you must get a wildcard certificate.

For example, consider the following scenario in which you might want to use a wildcard subdomain:

You have two versions of the same app, app1 and app3, for testing purposes.
You deploy the apps in two different projects within the same cluster: app1 into the development project, and app3 into the staging project.

To use different subdomains to manage traffic to these apps, you create the following services and resources:

A Kubernetes service in the development project to expose app1.
An Ingress resource in the development project that specifies the host as dev.domain.net.
A Kubernetes service in the staging project to expose app3.
An Ingress resource in the staging project that specifies the host as stage.domain.net.

Within a project, use subdomains in one or multiple resources — Subdomains in one or multiple resources within a project

Now, both URLs resolve to the same domain. However, because the resource in the staging project is registered with the stage subdomain, the Ingress controller correctly proxies requests from the stage.domain.net/app3 URL to only app3.

Multiple domains within a project

Within an individual project, you can use one domain to access all the apps in the project. If you want to use different domains for the apps within an individual project, use a wildcard domain. When a wildcard domain is registered, multiple subdomains all resolve to the same host. Then, you can use one resource to specify multiple subdomain hosts within that resource. Alternatively, you can create multiple Ingress resources in the project and specify a different subdomain in each Ingress resource.

The IBM-provided Ingress subdomain wildcard, *.<cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud, is registered by default for your cluster. The IBM-provided TLS certificate is a wildcard certificate and can be used for the wildcard subdomain. If you want to use a wildcard custom domain, you must register the custom domain as a wildcard domain such as *.custom_domain.net, and to use TLS, you must get a wildcard certificate.