In the last several years, Kubernetes has become the “go to” standard for managing and orchestrating containerized workloads. Thanks to it’s vendor agnostic nature, you can easily run Kubernetes almost anywhere, and in fact, all the major cloud vendors offer a managed Kubernetes service (AWS EKS, Google GKE, and Azure AKS).
With Kubernetes, one of the key advantages is the ease of managing multiple environments and workloads in a single cluster, by separating the cluster into logical areas using namespaces. This post will dive into how we can manage this by using Terraform to both manage the cluster provisioning as well as manage the namespaces.
Multiple Environments in One Cluster
When using Kubernetes for a team, you usually want to have an isolated environment for each developer, branch, or pull request. There are a few ways to achieve that using Kubernetes: one way is to create a full blown cluster for each division, but the way we’re focusing on is using Kubernetes namespaces feature.
While the namespaces feature is quite powerful it’s not without its complications, especially with a large team of developers: How many namespaces do I have on my cluster? Can I remove them? Does anyone use them? Can I schedule them to automatically shut down during night time and weekend? Can I have policies on who can run what and where? Fortunately, with a good management platform, a lot of this can be alleviated.
Why Manage Kubernetes using Terraform?
As a cloud-native technology that is deployed at wide scale, it’s quite common to manage the deployment of the infrastructure of Kubernetes clusters using Terraform. And where you have many clusters to manage (Dev, Staging, Production, etc.), Terraform allows you to maintain a consistent configuration for the cluster and underlying infrastructure while creating as many clusters as you like with the same configuration in a reliable and easy way.
Terraform’s multi-cloud approach lets you use any cloud provider you wish, including using the native managed services that I’ve mentioned above.
Similarly, when managing namespaces there’s a few ways, but using Terraform is probably the best overall. The main advantages of using Terraform are:
Use the same configuration language to provision the Kubernetes infrastructure and to deploy applications into it.Drift detection — terraform plan will always present you the difference between reality at a given time and the config you intend to apply.Full lifecycle management — Terraform doesn’t just initially create resources, but offers a single command for creation, update, and deletion of tracked resources without needing to inspect the API to identify those resources.Synchronous feedback — While asynchronous behaviour is often useful, sometimes it’s counter-productive as the job of identifying operation results (failures or details of created resource) is left to the user. e.g. you don’t have IP/hostname of load balancer until it has finished provisioning, hence you can’t create any DNS record pointing to it.graph of relationships — Terraform understands relationships between resources which may help in scheduling — e.g. if a Persistent Volume Claim claims space from a particular Persistent Volume, Terraform won’t even attempt to create the PVC if creation of the PV has failed.
#terraform #kubernetes #cloud-computing #aws-eks #env0 #k8s #orchestration #devops
