This is a part of the series of posts on Getting an API running in Kubernetes. For this to make sense you should have worked through a few of the earlier examples

I recommend that you save your commands in various scripts so you can repeat them or modify them later.

In this article – we’re doing this.

Ingress

This is the last step to getting your app out there. For my example, I’m using one of my exitsing domains, but lets pretend its called awesome.com.

The objective is to be able to do a /GET from the browser – as in
https://demo.awesome.com/?data=helloworld

or a /GET or a CORS /POST from a javaScript app with the message in the body.
https://demo.awesome.com/

The yaml file for the ingress looks like this – I’ve added another service that doesn’t exist so you can see how to do that if you need to eventually. In particulat, look at the red items – we’ll cover those in a moment.

make-ingress.yaml

and you can apply it

make-ingress.sh

gives this

Test

Over in the browser


from javaScript

Annotations

The .yaml file contains 2 annotations (annotations were covered in Getting an ssl certificate for Kubernetes ingress).

  • is a signal to the ingress controller, described in Bringing up an ingress controller, that it needs to handle this ingress and route messages to it.

  • is a signal to kube-lego that this ingress needs to have a certificate managed.

Rules

This rule says that when a request for the demo.awesome.com/ comes in, route it to the playback-service, which will be listening on port 80.

Tls

The tls section is used by kube-lego to decide which domains need ssl certificates, and the secretName is where to store them.

Next step

We’re done – thanks for sticking with me the whole way.

Why not join our forum, follow the blog or follow me on Twitter to ensure you get updates when they are available.