↓Skip to main content

Introducing Tf4k8s

Terraform Kubernetes

If you want to spin up an EKS cluster, you have 4 options:

  1. Create it via the AWS UI.
  2. Use an AWS-only tool like eksctl
  3. Use the AWS CLI or CloudFormation.
  4. Use Terraform.

I’m going to dismiss #1 almost immediately. AWS UI has a lot of knobs and dials and it is easy to miss an important piece of configuration. Besides, it can’t be automated. AWS-only solutions are just that. AWS only. If you intend to use only EKS, then eksctl ticks all boxes.

  • You create a YAML of the desired configuration.
  • This YAML can be version controlled.
  • eksctl can be run as a standalone executable.(Possibility to automate)

My wishlist #

Here’s a list of my expectations for a tool used to provision Kubernetes clusters. Let’s stick to managed Kubernetes only for now.

CLI based #

eksctl is a standalone binary. Our ideal tool would also be a standalone binary with very little or no dependencies.

Cloud agnostic #

works with Azure, GCP, Linode and DigitalOcean as well. I do recall seeing an aksctl somewhere in the internet.

Configuration as code #

Configuration stored as human manageable text. Wads of JSON is NOT human manageable.

Persist state of the system #

I want to be able to import a managed Kubernetes cluster into the tool’s fold in the near future. This requires that the tool stores the current state of my cluster somewhere secure.(Hint: terraform)

I Chose Terraform #

Terraform is CLI based, cloud agnostic. It stores configuration as code(well, almost, I’ll come back to this in a moment). It can persist the state of the system. There’s actually plenty of options to do this. For now, we will use an S3 bucket. A typical workflow would involve selecting the workspace in accordance with the environment, passing on the cloud credentials and provisioning Kubernetes according to a declarative configuration YAML. About the declarative configuration YAML part, we get a little adventurous. Terraform supports a declarative key value file, we wrap it and abstract the actual Terraform components [using an official library].

Why not use Terraform directly? #

That’s one of the design goals. Folks who’re comfortable with Terraform can directly consume the Terraform modules. But the number of people who don’t know Terraform is substantially greater than the number of people who know(grin). In short, I want a tool which is eksctl/aksctl/gcpctl all rolled into one.

Next steps #

As a proof-of-concept, I’ll be spinning up a GitHub repo with a Golang based CLI tool which parses YAML, converts it into Terraform inputs, and provisions an EKS cluster according to the input YAML. The end goal is to have the user furnish YAML to a tool, which will terraform the cluster(s) to the desired state and to make it work for all major cloud providers.

↑