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. This uses kube-leo which is being deprecated in favour of cert-manager. You can read how to use cert-manager instead here
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. SSLBefore 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.
Kube-legoYou should already have helm installed from Bringing up an ingress controller, but if you dont - this'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.
make-lego.sh echo "start up kubelego" helm install stable/kube-lego --namespace kube-system --set config.LEGO_EMAIL=bruce@mcpher.com,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. --set rbac.create=true You should see a deployment for kube-lego kubectl get deploy -n kube-system NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE event-exporter-v0.1.7 1 1 1 1 9d heapster-v1.4.3 1 1 1 1 9d kube-dns 2 2 2 2 9d kube-dns-autoscaler 1 1 1 1 9d kubernetes-dashboard 1 1 1 1 9d l7-default-backend 1 1 1 1 9d listless-nightingale-kube-lego 1 1 1 1 1d tiller-deploy 1 1 1 1 4d As well as a service kubectl get service -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default-http-backend NodePort 10.3.240.178 <none> 80:31830/TCP 9d heapster ClusterIP 10.3.246.133 <none> 80/TCP 9d kube-dns ClusterIP 10.3.240.10 <none> 53/UDP,53/TCP 9d kube-lego-nginx ClusterIP 10.3.242.70 <none> 8080/TCP 1d kubernetes-dashboard ClusterIP 10.3.249.40 <none> 443/TCP 9d tiller-deploy ClusterIP 10.3.247.43 <none> 44134/TCP 4d What does kube-lego doIt searches for ingresses (not ingress controllers) that have a specific annontation (more about what that is later)
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 automcatically renewing them if they look like they'll expire. AnnotationsYou may have notices "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.
Next stepNearly 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. See Getting an API running in Kubernetes for how.
|
Services > Desktop Liberation - the definitive resource for Google Apps Script and Microsoft Office automation > Google cloud platform > Getting an API running in Kubernetes >