How has the recent turmoil within the OpenAI offices changed your plans to use GPT in a business process or product in 2024?
Increased uncertainty means we are more likely to evaluate alternative AI chatbots and LLMs.
No change in plans, though we will keep an eye on the situation.
With Sam Altman back in charge, we are more likely to go all-in with GPT and LLMs.
What recent turmoil?
Cloud Native Ecosystem / Kubernetes

A Better Way to Provision Kubernetes Using Terraform

Despite Kubernetes' own declarative API, and the obvious benefits of maintaining a cluster's infrastructure and services from the same infrastructure as code repository, Terraform is far from the first choice to provision Kubernetes resources. Kubestack, the open-source Terraform framework I maintain, aims to provide the best developer experience for teams working with Terraform and Kubernetes.
Jul 14th, 2021 10:54am by
Featued image for: A Better Way to Provision Kubernetes Using Terraform
Feature image via Pixabay.

Philipp Strube
Philipp has been cloud native ever since he dropped out of university in 2008 to found the cloudControl PaaS and help developers build better software faster. Since then, Philipp has worked on IaaS at Exoscale, Enterprise Kubernetes at CoreOS and most recently helped organizations with their cloud native transformations as a consultant at Container Solutions. Philipp is the maintainer of the Kubestack open source framework. Kubestack is a Terraform GitOps framework for teams that want to automate infrastructure, not reinvent automation.

Terraform, an open source project managed by HashiCorp, is immensely powerful when it comes to defining and maintaining infrastructure as code. In combination with a declarative API, like a cloud provider API, it can determine, preview, and apply changes to the codified infrastructure.

Consequently, it is common for teams to use Terraform to define the infrastructure of their Kubernetes clusters. And as a platform to build platforms, Kubernetes commonly requires a number of additional services before workloads can be deployed. Think of ingress controllers or logging and monitoring agents and so on. But despite Kubernetes’ own declarative API, and the obvious benefits of maintaining a cluster’s infrastructure and services from the same infrastructure as code repository, Terraform is far from the first choice to provision Kubernetes resources.

With Kubestack, the open source Terraform framework I maintain, I’m on a mission to provide the best developer experience for teams working with Terraform and Kubernetes. And unified provisioning of all platform components, from cluster infrastructure to cluster services, is something I consider crucial in my relentless pursuit of said developer experience.

Because of that, the two common approaches to provision Kubernetes resources using Terraform never really appealed to me.

On the one hand, there’s the Kubernetes provider. And while it integrates Kubernetes resources into Terraform, maintaining the Kubernetes resources in HCL is a lot of effort. Especially for Kubernetes YAML you consume from upstream. On the other hand, there are the Helm provider and the Kubectl provider. These two use native YAML instead of HCL, but do not integrate the Kubernetes resources into the Terraform state and, as a consequence, lifecycle.

I believe my Kustomization provider based modules are a better alternative because of three distinct benefits:

  1. Like Kustomize, the upstream YAML is left untouched, meaning upstream updates require minimal maintenance effort.
  2. By defining the Kustomize overlay in HCL, all Kubernetes resources are fully customizable using values from Terraform.
  3. Each Kubernetes resource is tracked individually in Terraform state, so diffs and plans show the changes to the actual Kubernetes resources.

To make these benefits less abstract, let’s compare my Nginx ingress module with one using the Helm provider to provision Nginx ingress.

The Terraform configuration for both examples is available in this repository. Let’s take a look at the Helm module first.

The Helm-based Module

Usage of the module is straightforward. First, configure the Kubernetes and Helm providers.

Then define a kubernetes_namespace and call the release/helm module.

If you now run a terraform plan for this configuration, you see the resources to be created.

Terraform will perform the following actions:

And this is the key issue with how Helm is integrated into the Terraform workflow. The plan does not tell you what Kubernetes resources will be created for the Nginx ingress controller. And neither are the Kubernetes resources tracked in Terraform state, as shown by the apply output.

Similarly, if planning a change, there’s again no way to tell what the changes to the Kubernetes resources will be.

So if you increase the replicaCount value of the Helm chart, the terraform plan will merely show the change to the helm_release resource.

What will the changes to the Kubernetes resources be? And more importantly, is it a simple in-place update, or does it require a destroy-and-recreate? Looking at the plan, you have no way of knowing.

Terraform will perform the following actions:

The Kustomize-based Module

Now, let’s take a look at the same steps for the Kustomize-based module. Usage is similar. First, require the kbst/kustomization provider and configure it.

Then call the nginx/kustomization module.

Unlike for the Helm-based module though, when you run Terraform plan now you will see each Kubernetes resource and its actual configuration individually. To keep this blog post palatable, I show the details for the namespace only.

Terraform will perform the following actions:

Applying, again, has all the individual Kubernetes resources. And because the modules use explicit depends_on to handle namespaces and CRDs first and webhooks last, resources are reliably applied in the correct order.

Naturally, it also means that if you increase the replica count like this…

…the Terraform plan shows which Kubernetes resources will change and what the diff is.

Terraform will perform the following actions:

Maybe more importantly even, the Kustomization provider will also correctly show if a resource can be changed using an in-place update. Or if a destroy-and-recreate is required because there is a change to an immutable field, for example.

This is the result of two things:

  1. That, as you’ve just seen, every Kubernetes resource is handled individually in Terraform state, and
  2. that the Kustomization provider uses Kubernetes’ server-side dry-runs to determine the diff of each resource.

Based on the result of that dry-run, the provider instructs Terraform to create an in-place or a destroy-and-recreate plan.

So, as an example of such a change, imagine you need to change spec.selector.matchLabels. Since matchLabels is an immutable field, you will see a plan that states that the Deployment resource must be replaced. And you will see 1 to add and 1 to destroy in the plan’s summary.

Terraform will perform the following actions:

Try It Yourself

If you want to try the modules yourself, you can either use one of the modules from the catalog that bundle upstream YAML, like the Prometheus operator, Cert-Manager, Sealed secrets, or Tekton, for example.

But there is also a module that can be used to provision any Kubernetes YAML in the exact same way as the catalog modules.

Get Involved

Currently, the number of services available from the catalog is still limited.

If you want to get involved, you can find the source repository on GitHub.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.