Platform operations
EKS Platform Tools
I built the operational layer around EKS: capacity policy, traffic, observability, access boundaries and CI runners. Karpenter provisioning has explicit limits, and the cost evidence comes from tagged project usage.
My scopeCapacity policy · Platform services · Observability · Cost review
Independent engineering projectScope & provenance
Designed and built in my own environment to demonstrate EKS platform operations. All measurements come from this project; no former-employer infrastructure, budgets or operational data are used.
- System type
- EKS operational layer
- Measured period
- 22 days of tagged spend
- Purchase model
- 100% Spot capacity
- Guardrails
- 40 vCPU / 160 GiB cap
Engineering brief
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.
Tradeoffs & verification
- Express cost policy as configuration
- The development NodePool restricts instance families, prefers Spot with On-Demand fallback, and sets a 40 vCPU / 160 GiB limit. Consolidation and node expiry are explicit parts of the policy.
- Keep the measurement boundary clear
- The 22-day tagged spend report records 100% Spot usage for this project environment. It supports a concrete review of that period, rather than a projected saving for an unrelated production workload.
- Connect policy to runtime evidence
- The case study pairs NodePool configuration with the Prometheus and Grafana inventory and the cost report. This makes the intended capacity policy, installed platform services and measured usage independently reviewable.
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.
Implementation evidence
Project evidence: NodePool policy, monitoring inventory and the 22-day tagged spend report. Select the image to inspect it.