- 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.
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
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.
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
kubectl apply -f make-ingress.yaml
kubectl get ingress NAME HOSTS ADDRESS PORTS AGE playback-ingress demo.awesome.com,somewhere-else.awesome.com 184.108.40.206 80, 443 1d
Over in the browser
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'
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.
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
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
We’re done – thanks for sticking with me the whole way.