This means that an underlying HTTP client calls http://<your cluster IP>:<some unique port>. You can try this out yourself: first, find out the NodePort assigned to your function, by using the nuctl get function command of the nuctl CLI or the kubectl get svc command of the Kubernetes CLI. Then, use curl to send an HTTP request to this port.

In addition to configuring a service, Nuclio creates a Kubernetes ingress for your function’s HTTP trigger, with the path specified as <function name>/latest. However, without an ingress controller running on your cluster, this will have no effect. An Ingress controller will listen for changed ingresses and reconfigure some type of reverse proxy to route requests based on rules specified in the ingress.

Setting up an ingress controller

In this guide, you’ll set up a Træfik controller, but any type of Kubernetes ingress controller should work. You can read Træfik’s excellent documentation, but for the purposes of this guide you can simply run the following commands to set up the controller:

Verify that the controller is up by running by running the kubectl --namespace=kube-system get pods command, and then run the kubectl describe service --namespace=kube-system traefik-ingress-service command to get the ingress NodePort. Following is a sample output for NodePort 30019:

And now, invoke the function by its path.
Replace <NodePort> with the NodePort of your ingress controller, and replace ${minikube ip) with your cluster IP if you are not using Minikube:

curl $(minikube ip):<NodePort>/helloworld/latest

For example, for NodePort 30019, run this command:

curl $(minikube ip):30019/helloworld/latest

Customizing function ingress

By default, functions initialize the HTTP trigger and register <function name>/latest. However, you might want to add paths for functions to organize them in namespaces/groups, or even choose through which domain your functions can be triggered. To do this, you can configure your HTTP trigger in the function’s configuration. For example:

...triggers:http:maxWorkers:4kind:"http"attributes:ingresses:i1:# this assumes that some.host.com points to <cluster ip>host:"some.host.com"paths:-"/first/path"-"/second/path"i2:paths:-"/wat"

If your helloworld function was configured in this way, and assuming that Træfik’s NodePort is 30019, the function would be accessible through any of the following URLs:

<cluster ip>:30019/helloworld/latest

some.host.com:30019/helloworld/latest

some.host.com:30019/first/path

some.host.com:30019/second/path

<cluster ip>:30019/wat

some.host.com:30019/wat

Note that since the i1 configuration explicitly specifies some.host.com as the host for the paths, the function will not be accessible through the cluster IP; i.e., <cluster ip>:30019/first/path will return a 404 error.

Deploying an ingress example

Let’s put this into practice and deploy the ingress example. This is the function.yaml file for the example:

Behind the scenes, nuctl populates a function CR, which is picked up by the Nuclio controller. The controller iterates through all the triggers and looks for the required ingresses. For each ingress, the controller creates a Kubernetes Ingress object, which triggers the Træfik ingress controller to reconfigure the reverse proxy. Following are sample controller logs: