Expose Workload with a Public URL
Learn how to make Workloads available via a public URL in Humanitec.

Using Ingress to access a workload outside the cluster

Many workloads need to be accessible from outside the cluster. Often the workload should be reachable from the public internet. Examples include web-applications or workloads that provide a part of a public API.
Kubernetes has a concept known as Ingress. Ingress is a system for routing traffic from outside a cluster to a service inside the cluster. Ingress is at its simplest a set of rules for how to route traffic. The rules always include a DNS name or hostname and can optionally include parts of URLs to match.
For example, a cluster containing 3 workloads where one is a frontend for an online shop and the other two provide two provide the catalogue and payments parts of the API might have Ingress rules structured as follows:
1
frontent-workload:
2
Host: shop.example.com
3
Port: 4220
4
5
catalogue-workload:
6
Host: api.example.com
7
PathPrefix: /catalog/
8
Port 8080
9
10
payments-workload:
11
Host: api.example.com
12
PathPrefix: /payments/
13
Port 3001
Copied!
In this example, all traffic to shop.example.com is routed to port 4220 on the frontend-workload. Traffic to api.example.com is routed to either port 8080 on the catalogue-workloador port 3001 on the payments-workload depending on the prefix of the path in the URL.

DNS resources and Ingress

Humanitec takes care generating the Ingress manifests that will be deployed in the cluster. To to that it needs a DNS resource. DNS resources can either be specific to a Workload or shared across an Application. In the above example, shop.example.com should be specific to the Workload as it is only used by frontend-workload. api.example.com is used by 2 Workloads which means it makes sense for it to be a Shared Resource.
When you add a DNS Resource in Humanitec, you don't actually specify the DNS name you want. You simply declare a dependency on a DNS resource. Your DevOps or Operations team will have configured Humanitec to generate an appropriate DNS name for you.
If you need to reference a DNS name that will be provisioned for a resource, you can use Placeholders. For example, to reference the name of a DNS resource with ID shop-frontend-dns, you could using ${externals.shop-frontend-dns.host}.
See Working with Environment Variables for more information.

Path rules in Ingress

Kubernetes ingress allows the definition of rules to route traffic to the same DNS name to different services. Each rule will direct the specified traffic to the port specified on the workload. There are 4 types of path rules supported by Humanitec:
Path Rule Type
Description
Default
All traffic not captured by other rules will be routed using this rule.
Exact
Only traffic with a path exactly matching this rule will be routed.
Prefix
Any traffic with a path that starts with this pattern will be routed.
ImplementationSpecific
The Ingress Controller defines how this is interpreted.
In most cases Default or Prefix is used.

Adding Ingress to a Workload

Ingresses are added to Workloads. The rules in an Ingress refer to the current workload.
UI
    1.
    Enter the Workload Details screen for the Workload you want to add Ingress for.
    2.
    Ensure you are in Draft mode. If you are not, you can select it from the Deployment drop-down.
    3.
    Add a DNS resource if necessary from the External Resources drop down. (See Adding Shared Resources for DNS names that should be shared between workloads.)
    4.
    Either click the button or select the DNS Resource you want to define Ingress for from the list in the Ingress section.
    5.
    Select the type of rule you want to add.
    6.
    If applicable, define the path. (No path is required for Default rules.)
    7.
    Choose the port that a container in this workload is listening on.
    8.
    Add additional rules if necessary.
    9.
    Click Done to add the new rules to the Draft.
Last modified 2mo ago