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
- Authenticate and select the clusterDelivery workflows establish AWS identity and update Kubernetes access for the intended environment.
- Apply foundational permissionsService accounts, RBAC and cloud identity integration are created before dependent controllers.
- Install platform controllersKarpenter, ingress and ExternalDNS are deployed with their environment-specific configuration.
- Deploy observabilityMonitoring and logging are established as shared cluster services.
- 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.