{"id":12915,"date":"2019-10-27T16:32:17","date_gmt":"2019-10-27T15:32:17","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/provisioning-a-aks-cluster-and-kubeinvaders-with-terraform-aks\/"},"modified":"2023-07-13T16:38:55","modified_gmt":"2023-07-13T14:38:55","slug":"provisioning-a-aks-cluster-and-kubeinvaders-with-terraform-aks","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/provisioning-a-aks-cluster-and-kubeinvaders-with-terraform-aks\/","title":{"rendered":"Provisioning a AKS cluster and KubeInvaders with Terraform"},"content":{"rendered":"

Provisioning a K8s infrastructure may be performed in different ways. Terraform has a connector called the Kubernetes provider<\/a> but it doesn\u2019t allow building and deploying a Kubernetes cluster. The cluster must be up and running before using the provider. Fortunately, there are different cloud-specific provider depending which cloud provider you want to provision your cluster.<\/p>\n

\"\"<\/p>\n

In our CI pipeline for the MSSQL DMK maintenance, we provision SQL Server containers on Linux to perform then different tests. Our K8s infrastructure is managed by Azure through AKS and the main issue we have so far is that the cluster must exist before deploying containers. In other hand, the period of testing is unpredictable and depends mainly on the team availability. The first approach was to leave the AKS cluster up and running all the time to avoid breaking the CI pipeline, but the main drawback is obviously the cost. One solution is to use Terraform provider for AKS through our DevOps Azure pipeline.<\/p>\n

\"\"<\/p>\n

But in this blog let\u2019s start funny by provisioning the AKS infrastructure to host the KubeInvaders<\/a> project. KubeInvaders is a funny way to explain different components of K8s and I will use it during my next Workshop SQL Server on Kubernetes<\/a> at SQLSaturday Lisbon on November 29-30th<\/sup> 2019. In addition, deploying this project on AKS requires additional components including an Ingress controller, a cert manager and issuer to connect to KubeInvaders software from outside. In turn, those components are deployed through helm charts meaning we also must install helm and tiller (if you use helm version < 3).<\/p>\n

Before sharing my code, let\u2019s say there is already a plenty of blogs that explains how to build a Terraform plan to deploy an AKS cluster and helm components. Therefore, I prefer to share my notes and issues I experienced during my work.<\/p>\n

1) In my context, I already manage an another AKS cluster from my laptop and I spent some times to understand the Kubernetes provider always first tries to load a config file from a given (or default) location as stated to the Terraform documentation<\/a>. As a result, I experienced some weird behaviors when computing Terraform plan with detection of some components like service accounts that are supposed to not exist yet. In fact, the provider loaded my default config file ($HOME\/.kube\/config) was tied to another existing AKS cluster.<\/p>\n

2) I had to take care of module execution order to get a consistent result. Terraform module dependencies can be implicit or explicit (controlled by the depends_on clause).<\/p>\n

3) The \u201clocal-exec\u201d provisioner remains useful to do additional work that cannot be managed directly by a Terraform module. It was especially helpful to update some KubeInvaders files with the new fresh cluster connection info as well as the URL to reach KubeInvaders software.<\/p>\n

4) The tiller is installing only after deploying a first helm chart<\/p>\n

The components are deployed as follows:<\/p>\n