Why Kubestack

When cloud native is about applying software development methodologies to operations why are there no GitOps frameworks?

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.

Kubestack is a GitOps framework based on Terraform and Kustomize and brings these benefits to infrastructure automation.

Terraform modules and Kustomize manifests

Kubestack provides tested and reusable Terraform modules and Kustomize manifests. Modules provision managed Kubernetes clusters from Amazon (EKS), Azure (AKS) and Google (GKE). Kustomize manifests deploy services required for application workloads.

Both, infrastructure configuration and cluster manifests are integrated into Terraform's plan/apply lifecycle, follow Kubestack's inheritance model and support the GitOps flow.

Inheritance model and GitOps flow

Kubestack lets teams propose, review, and apply changes in a reliable and automated way following its GitOps flow. Convention over configuration makes the repository layout intuitive. The inheritance model improves automation reliability by making differences between environments explicit.

Purpose built and open-source

Kubestack lays the foundation of a team's infrastructure automation. This frees teams to focus on the business critical parts of their infrastructure.

Using an open-source framework compared to building bespoke infrastructure automation reduces the future maintenance effort.

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 ops environment before it applies them to the apps environment.

Kubestack scope

Kubestack Framework Overview

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 cloud provider or the Kubernetes control plane.
  • Current state: Is the state the cloud or Kubernetes resources are currently in.

Kubestack maintains 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 a infrastructure automation repository
  • provide tested, reusable Terraform modules
  • provide tested, reusable Kustomize bases and overlays
  • provide a GitOps workflow for teams

Kubestack does not:

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