- Already have a cluster up and running as described in Getting cockroachDB running with Kubernetes and are using the Google Cloud console shell with the kubectl CLI. The database is of course not necessary for this example, but the cluster and CLI preparation is.
- created an app to be deployed as described in Building your App ready for Kubernetes deployment
- deployed it as described in Creating a Kubernetes deployment
- created a service as described in Creating a microservice on Kubernetes
- created an ingress controller as described in Bringing up an ingress controller
- started the kube-lego process described in Getting an ssl certificate for Kubernetes ingress
- added an A record to the DNS record for the domain you’ll be assigning your app pointing at the ip address exposed by Bringing up an ingress controller
- You might also find Digging around on the Kubernetes cluster of some use to help with familiarity of concepts.
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
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: playback-ingress annotations: kubernetes.io/ingress.class: nginx kubernetes.io/tls-acme: 'true' spec: rules: - host: demo.awesome.com http: paths: - path: / backend: serviceName: playback-service servicePort: 80 - host: somewhere-else.awesome.com http: paths: - path: / backend: serviceName: someother-service servicePort: 4000 tls: - secretName: playback-tls-cert hosts: - demo.awesome.com - somewhere-else.awesome.com
and you can apply it
make-ingress.sh
kubectl apply -f make-ingress.yaml
gives this
kubectl get ingress NAME HOSTS ADDRESS PORTS AGE playback-ingress demo.awesome.com,somewhere-else.awesome.com 130.211.214.218 80, 443 1d
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).
annotations: kubernetes.io/ingress.class: nginx kubernetes.io/tls-acme: 'true'
-
ingress.class: nginx
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.
-
tls-acme: 'true'
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.
- host: demo.awesome.com http: paths: - path: / backend: serviceName: playback-service servicePort: 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.
tls: - secretName: playback-tls-cert hosts: - demo.awesome.com - somewhere-else.awesome.com

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