Back to projects

Platform operations

EKS Platform Tools

A structured operational layer for Amazon EKS covering node provisioning, ingress, DNS automation, observability, access control and CI runner workloads.

System type
EKS operational layer
Measured period
22 days of tagged spend
Purchase model
100% Spot capacity
Guardrails
40 vCPU / 160 GiB cap

Objective

An EKS control plane alone is not a usable application platform. Teams also need capacity, ingress, DNS, metrics, logs, access boundaries and a safe place to run delivery workloads.

This project organizes those responsibilities as independent platform components so each can be reviewed, deployed and changed without treating the cluster as one large manifest bundle.

Platform domains

  • CapacityKarpenter NodePool and EC2NodeClass resources provide workload-aware node provisioning.
  • Trafficingress-nginx exposes application traffic while ExternalDNS automates DNS record management.
  • ObservabilityPrometheus, Grafana and logging components form a shared operational foundation.
  • Delivery and accessGitLab Runner, Kubernetes service accounts and RBAC keep pipeline jobs scoped to their responsibilities.

Karpenter

Karpenter is treated as a platform capability rather than a standalone installation. Node classes define AWS-specific behavior; node pools express Kubernetes scheduling and capacity intent.

The development policy restricts capacity to t3 and t3a families, prefers Spot with On-Demand as a scheduling fallback, consolidates empty or underutilized nodes after 30 seconds and rotates nodes after seven days.

Private-cluster considerations

The structure accounts for private worker nodes, access to private container images and the AWS permissions required for provisioning. Capacity automation remains connected to the same IAM and networking boundaries as the rest of the platform.

Operational workflow

  1. Authenticate and select the clusterDelivery workflows establish AWS identity and update Kubernetes access for the intended environment.
  2. Apply foundational permissionsService accounts, RBAC and cloud identity integration are created before dependent controllers.
  3. Install platform controllersKarpenter, ingress and ExternalDNS are deployed with their environment-specific configuration.
  4. Deploy observabilityMonitoring and logging are established as shared cluster services.
  5. Enable CI workloadsRunner jobs use scoped service accounts and ephemeral Kubernetes pods.

Engineering evidence

  • Measured purchase mixA 22-day Cost Explorer report recorded 100% Spot usage and $0 of On-Demand compute.
  • Measured activityThe report covers more than 320 node instance-hours across short-lived development and scale-test capacity.
  • Measured spendTagged Karpenter resources totaled $18.03: $15.85 compute, $2.11 EC2 supporting resources and $0.07 VPC processing.
  • Configured controlst3/t3a restrictions, a 40 vCPU / 160 GiB cap, 30-second consolidation and seven-day expiry bound cost and lifecycle behavior.
Public presentation: Architecture and platform responsibilities are documented without exposing private repository names, version-control history or internal implementation details.

Technology

Amazon EKSKarpenterPrometheusGrafanaGitLab RunnerHelmingress-nginxExternalDNSRBACIRSAPrivate ECR
EKS Platform Tools architecture