Introduction

Why framework

A key principle of cloud native platform engineering is to adopt proven software development methodologies. Frameworks are ubiquitous in software development because they:

  • Provide tested, reusable implementations of common components
  • Foster a unified approach across a jointly owned code base
  • Speed up time to value and
  • Reduce long term maintenance effort

But before containers and Kubernetes, frameworks for infrastructure rarely made sense. With operating systems both being part of the infrastructure layer, and being a weak abstraction, application dependencies frequently leaked into the infrastructure layer. This led to most infrastructure being built application specific.

Containers and Kubernetes provide a stronger abstraction between the two layers. Making it more easily viable to build common platforms where reusable framework components are of great value.

Kubestack is a Terraform framework for Kubernetes platform engineering teams to define the entire cloud native stack in one Terraform code base and continuously evolve the platform safely through GitOps. It brings the benefits of frameworks to teams building self-service Kubernetes based platforms for application developers.

Terraform modules and Terraform providers

As a framework, Kubestack integrates natively into the Terraform ecosystem. It maintains various modules as well as a provider to fully integrate platform infrastructure and services into a single Terraform code base.

The framework differentiates between three types of Terraform modules:

  1. Cluster modules use the respective cloud's Terraform provider to provision managed Kubernetes clusters from Amazon (EKS), Azure (AKS) and Google (GKE).
  2. Node-pool modules attach managed node pools to cluster's privisioned using cluster modules.
  3. Platform service modules use the Kubestack maintained Kustomization provider to deploy Kubernetes services required by application workloads on top of those Kubernetes clusters.

Inheritance model and GitOps flow

All modules implement Kubestack's inheritance model to make differences between environments explicit and avoid configuration drift.

By including cloud infrastructure and Kubernetes resources in Terraform's plan/apply lifecycle, the Kubestack framework enables you to build fully integrated automation for your complete platform.

Following the GitOps workflow, teams can peer-review proposed code changes alongside the Terraform plan and validate them by applying against real infrastructure before they get promoted to any environment running application workloads.

Design principles

The core design principles of the Kubestack GitOps framework are:

  • All changes start with a commit in a Git repository and follow a GitOps process.
  • Teams jointly maintain all configuration using inheritance to avoid configuration drift.
  • Automation validates changes against the internal ops environment before they are promoted to any external environment like apps or apps-prod.

Kubestack scope

Kubestack Scope

Kubestack differentiates between committed, desired and current state.

  • Committed state: Is the state committed to the Git repository.
  • Desired state: Is the state last applied to the active control plane.
  • Current state: Is the state the resources are currently in.

Kubestack syncs committed and desired state. Reconciliation of desired and current state is the responsibility of the cloud provider or the Kubernetes control plane.

To understand the scope, consider what Kubestack does do and does not do:

Kubestack does:

  • bootstrap an infrastructure automation repository
  • provide tested, reusable Terraform modules
  • provide a GitOps workflow for teams

Kubestack does not:

  • replace a CI/CD system
  • replace managed Kubernetes services
  • replace Kubernetes controllers or operators