Connecting Octopus to MicroK8s
We have a production Kubernetes cluster running on Azure and it works great with minimal operations effort. We then decided that we needed another cluster for Dev but without the expense of another entire cluster for what would be relatively small usage.
Enter MicroK8s, a small cluster, easy to install and run that by default will have a single node. Rather than using VMs as such, it will install as a package in Ubuntu and give you a relatively small and easy cluster. Great.
However, getting it connected up to Octopus Deploy wasn't quite so straight-forward and that was partly due to the initial workload to get the networking going. Router rules, firewalls etc. but I finally got the Octopus server to be able to establish a connection to the MicroK8s cluster, which was nice.
The next problem was that when connecting, you can get Octopus to verify the TLS connection, even if it uses a self-signed certificate, by uploading the expected cert from the K8s cluster to Octopus and referencing it there. When I tried to connect and test, however, I received the following error:
This was confusing however since the MicroK8s docs are pretty slim and it was unclear whether this was related to Kubernetes itself (kubeadm etc) or whether it was a MicroK8s issue.
Well it turns out that a recently fixed issue allows us to modify the certificate issuance to include the correct IP addresses. All you have to do is edit /var/snap/microk8s/current/certs/csr.conf.template to include the additional IPs/names and then reboot and the certificate is re-issued. Octopus then connected and the world was good!
EDIT 10th December 2019
It appears that the current version of Octopus uses a version of the api for deployments which is deprecated and NOT supported on the latest version of microk8s. There is an issue to fix it but it appears to be marked for March's release of Octopus deploy so for now, I had to grab the script from the deployment log and paste it directly into the cluster and used kubectl to apply it. Not great because the automation bit doesn't work. I'm going to see if I can find a more manual way of specifying the deployment in Octopus to work around it.
Enter MicroK8s, a small cluster, easy to install and run that by default will have a single node. Rather than using VMs as such, it will install as a package in Ubuntu and give you a relatively small and easy cluster. Great.
However, getting it connected up to Octopus Deploy wasn't quite so straight-forward and that was partly due to the initial workload to get the networking going. Router rules, firewalls etc. but I finally got the Octopus server to be able to establish a connection to the MicroK8s cluster, which was nice.
The next problem was that when connecting, you can get Octopus to verify the TLS connection, even if it uses a self-signed certificate, by uploading the expected cert from the K8s cluster to Octopus and referencing it there. When I tried to connect and test, however, I received the following error:
Unable to connect to the server: x509: certificate is valid for 127.0.0.1, 10.152.183.1, 192.168.1.123, not This was confusing however since the MicroK8s docs are pretty slim and it was unclear whether this was related to Kubernetes itself (kubeadm etc) or whether it was a MicroK8s issue.
Well it turns out that a recently fixed issue allows us to modify the certificate issuance to include the correct IP addresses. All you have to do is edit /var/snap/microk8s/current/certs/csr.conf.template to include the additional IPs/names and then reboot and the certificate is re-issued. Octopus then connected and the world was good!
EDIT 10th December 2019
It appears that the current version of Octopus uses a version of the api for deployments which is deprecated and NOT supported on the latest version of microk8s. There is an issue to fix it but it appears to be marked for March's release of Octopus deploy so for now, I had to grab the script from the deployment log and paste it directly into the cluster and used kubectl to apply it. Not great because the automation bit doesn't work. I'm going to see if I can find a more manual way of specifying the deployment in Octopus to work around it.