From Laptop Hardware to a Local Kind Platform

Enterprise problem: Teams copy cloud manifests into production without seeing which processes consume CPU, memory, disk, and network, so capacity and failure assumptions remain hidden until customers are affected.

Whole-course context: The incoming platform charter defines three planes and a create-to-retire lifecycle; today supplies a local hosted-runtime boundary for the first implementation slices.

Today’s slice: Create a multi-node Kind cluster, where Kind means Kubernetes nodes running as Docker containers, and map each local layer to its later EKS equivalent.

End-of-day evidence: Cluster, node, namespace, pod, failure, reconciliation, and HTTP probe observations are joined to one immutable lab run.

Still unsolved: Kind nodes share one physical laptop and therefore do not prove infrastructure high availability, cloud identity, managed storage, or production isolation.

The customer outcome is a reviewable from laptop hardware to a local kind platform change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.

Docker Desktop virtual machine, Kind control plane and worker nodes, kubelet/containerd, CoreDNS and the HelixWorks services; SQLite volumes provide durable local state; cache: not involved. The laptop, VM, disk, network, and power are intentionally shared failure domains.

This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.

Run the local evidence loop

An unvalidated delete can target the wrong environment, so the lab creates its isolated kubeconfig through Terraform and uses the repository's validated failure script for mutation. Kind runs Kubernetes nodes as local container processes, so this proves orchestration behavior rather than independent-machine availability (Kind quick start). Read the exact cluster declaration in terraform/main.tf.

resource "kind_cluster" "helixworks" {
  name            = var.cluster_name
  wait_for_ready  = true
  kubeconfig_path = local.kubeconfig_path

  kind_config {
    kind        = "Cluster"
    api_version = "kind.x-k8s.io/v1alpha4"

    node {
      role = "control-plane"
    }

    dynamic "node" {
      for_each = range(var.worker_count)

      content {
        role = "worker"
      }
    }
  }
}

Use Kind to learn APIs, scheduling, and reconciliation cheaply. Do not use it to claim rack, availability-zone, IAM, load-balancer, or managed-control-plane resilience; those claims require later evidence from isolated AWS accounts and EKS clusters.