- 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
- You might also find Digging around on the Kubernetes cluster of some use to help with the 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.
Before you can secure access to your service and run it over HTTPS, you’ll need to generate a certificate and certificate key. Working with certificates is horrible, and causes brain freeze in many people – including me. Luckily we have 3 things to help us.
- Letsencrypt allows you to get free certificates (normally you’d have to pay for them).
- Kube-lego is a set of Kubernetes components that can manage the whole business of renewing and applying those certificates and is available as a helm-chart. Kube-lego has been superseded by cert-manager, but it’s a lot simpler, so we’ll stick with that one.
- Kubernetes can store secrets and they can be accessed by other cluster resources.
You should already have helm installed from Bringing up an ingress controller, but if you don’t – that’ll do it.
curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash helm init
Next, install kube-lego, changing the email address to yours. Note I’m installing this in the kube-system namespace. kube-lego can work across namespaces – so it could be handy in other work in this cluster.
echo "start up kubelego" helm install stable/kube-lego --namespace kube-system --set config.LEGO_EMAILfirstname.lastname@example.org,config.LEGO_URL=https://acme-v01.api.letsencrypt.org/directory
If you hit a permissions problem with the deployment itself, you can try appending this to the helm install line. If you get problems with tiller permissions see Bringing up an ingress controller for how to deal with it.
You should see a deployment for kube-lego
As well as a service
What does kube-lego do
It searches for ingresses (not ingress controllers) that have a specific annotation (more about what that is later)
metadata: annotations: kubernetes.io/tls-acme: "true"
and creates and manages letsencrypt certificates for them, storing them as Kubernetes secrets. If you check the log of the kube-lego pod, you’ll see how it does that. An annoyance with letsencrypt is that their certs expire after 90 days. Kube-lego takes care of that too by automatically renewing them if they look like they’ll expire.
You may have noticed “annotations” in some of the .yaml configurations. These are markers that can be read by other Kubernetes resources. The next step is to create an ingress for our service that will contain an annotation like the one above to let kube-lego know that it needs to be processed for a certificate.
- The ingress controller checks for annotations in the configuration of ingresses to see if it should handle them
- Kube-lego checks ingresses for the tls-acme annotation to see if it needs to manage certificates
Nearly done – next step is the final piece of the puzzle. The ingress to connect the service to the ingress controller and to signal to kube-lego it needs to be managed.