GenDev®
AWS · Cloud & DevOps

Private Kubernetes Foundation

AWS Private Kubernetes Foundation stands up a private Kubernetes cluster on AWS and bootstraps it into a full service-mesh stack, entirely as code. Terraform provisions the network and machines; Ansible installs a kubeadm cluster and layers on ingress, TLS, GitOps, observability, and two meshes, every step idempotent and safe to re-run.

Private Kubernetes Foundation: screen 1 of 1
Role
Cloud & DevOps engineering
Platform
AWS · ap-south-1
Cluster
3-node kubeadm · Ubuntu 24.04
Tooling
Terraform · Ansible · Helm
01

The brief

The goal was a real Kubernetes platform, the kind a team would actually run services on, but private and reproducible from a clean AWS account rather than a managed click-through. Control plane and workers, networking, TLS, GitOps, observability, and a service mesh, all standing up from code.

The harder requirement was idempotency. Every layer had to be safe to re-run, so the platform could be rebuilt or repaired without hand-holding and without drifting from what the code says.

02

The network and machines

Terraform builds the foundation as composable modules: a VPC with public and private subnets, an internet gateway, and a NAT gateway with an elastic IP. The control plane sits in the public subnet; the two workers sit in the private subnet with no public IP, reaching the internet only outbound through NAT.

Access is tight by construction. Security groups scope the API server and SSH to a single admin IP, control plane and workers talk over private addresses by security-group reference, and state lives in S3 with DynamoDB locking, so the infrastructure has one source of truth.

  • Modular VPC / EC2 / IAM / security groups
  • Private workers, NAT-only egress
  • API server + SSH pinned to one admin IP
  • S3 + DynamoDB locked remote state
03

The cluster

Ansible turns those machines into a cluster. A sequence of ordered, idempotent plays prepares each node (swap off, kernel modules, sysctl), installs containerd and pinned Kubernetes packages, runs kubeadm on the control plane, and joins the workers, reaching them through a proxy jump because they have no public address.

On top of the bare cluster it lays the essentials: Calico for pod networking, the Metrics Server for autoscaling signals, and Helm wired to the chart repositories the platform layer needs.

  • kubeadm cluster, 14 ordered plays
  • containerd + version-pinned kube packages
  • ProxyJump into the private workers
  • Calico CNI + Metrics Server
04

Ingress, TLS, GitOps, observability

The platform layer makes the cluster usable. NGINX Ingress terminates TLS at the edge on fixed node ports, cert-manager issues self-signed certificates against nip.io hostnames so every UI gets working HTTPS, and ArgoCD brings GitOps continuous delivery, putting the cluster's desired state in Git.

Observability comes from the kube-prometheus-stack: Prometheus scraping the cluster and Grafana dashboards on top, installed and configured the same idempotent way as everything else.

  • NGINX Ingress, edge TLS on NodePorts
  • cert-manager self-signed, nip.io HTTPS
  • ArgoCD GitOps continuous delivery
  • Prometheus + Grafana observability
05

Two service meshes and a demo

Finally, the platform installs two meshes side by side: Istio, as base CRDs and istiod that namespaces opt into, and Consul, providing service discovery and a Connect sidecar mesh. A small demo application, a frontend and backend wired together through Consul Connect, proves the mesh actually carries traffic.

Because every component is idempotent, the whole stack, from an empty AWS account to a meshed demo app, can be torn down and rebuilt from code on demand.

  • Istio base CRDs + istiod, opt-in per namespace
  • Consul service discovery + Connect mesh
  • Demo frontend/backend over Consul Connect
  • Whole stack rebuildable from code

Deep dive

From an empty account to a meshed cluster

The platform's real feature is that it builds itself. One Terraform apply and one Ansible run take a clean AWS account to a private, observable, mesh-enabled Kubernetes cluster, and either step can be re-run safely.

  1. 1

    Provision the network

    Terraform creates the VPC, public and private subnets, internet and NAT gateways, security groups, and IAM roles, with state locked in S3 and DynamoDB.

  2. 2

    Lay down the machines

    A control-plane instance comes up in the public subnet and two workers in the private subnet, reachable only over private IPs and an admin-pinned SSH path.

  3. 3

    Form the cluster

    Ansible preps every node, installs containerd and pinned Kubernetes, runs kubeadm on the control plane, and joins the workers through a proxy jump.

  4. 4

    Install the platform

    Calico, Metrics Server, NGINX Ingress, cert-manager, ArgoCD, and the Prometheus stack go on in dependency order, each play safe to re-run.

  5. 5

    Wire the mesh

    Istio and Consul are installed and a demo app is connected through Consul Connect, proving the mesh end to end.

What carried the build

Private by construction

Workers have no public IP and reach the internet only through NAT; the API server and SSH are pinned to a single admin address.

Everything idempotent

Terraform and fourteen ordered Ansible plays are safe to re-run, so the platform can be rebuilt or repaired without drift.

GitOps and observability built in

ArgoCD makes Git the source of truth while Prometheus and Grafana watch the cluster and the apps on it.

Two meshes, proven

Istio and Consul ship together, with a demo app routed over Consul Connect to show the mesh carrying real traffic.

Built with

Infrastructure

  • Terraform
  • AWS VPC / EC2
  • IAM
  • S3 + DynamoDB

Cluster

  • kubeadm
  • Ubuntu 24.04
  • containerd
  • Calico

Platform

  • NGINX Ingress
  • cert-manager
  • ArgoCD
  • Prometheus / Grafana

Mesh & config

  • Istio
  • Consul
  • Ansible
  • Helm

Want something built like this?