EKS Platform Engineering — Deploying and Scaling Applications

Project Links

Tech Stack

KubernetesHelmAWS EKSHPAALBAWS Secrets ManagerDockerECR
DevOps / Platform

EKS Platform Engineering — Deploying and Scaling Applications

Deploying a Node.js API on EKS using Helm charts, HPA for pod autoscaling, ALB Ingress for traffic routing, and AWS Secrets Manager for zero-secret-in-Git configuration management.

The EKS cluster from Part 2 is the foundation. This project puts it to work — a Node.js API packaged with Helm, scaled with HPA, routed through an ALB, and configured without a single secret in Git.

EKS application deployment architecture

Key Architecture Decisions

Helm for packaging. One chart, two environments. values-dev.yaml runs one replica with minimal resources. values-prod.yaml runs three replicas with HPA enabled. No duplicate YAML, no configuration drift between environments.

HPA scales pods, Cluster Autoscaler scales nodes. The two work together — HPA adds pods when CPU exceeds 70%, Cluster Autoscaler adds nodes when there is nowhere to schedule those pods. Under load, the cluster expands automatically. When traffic drops, it contracts.

ALB Ingress with SSL termination. The AWS Load Balancer Controller from Part 2 watches for Ingress objects and creates a real ALB in AWS. SSL is terminated at the ALB — pods only see plain HTTP internally.

Secrets Manager over ConfigMaps. Database credentials, API keys, and connection strings never touch Git or a Kubernetes Secret. The Secrets Store CSI driver fetches them at pod start and mounts them as environment variables. If a secret rotates, pods pick up the new value on the next restart.

Full deployment walkthrough in the blog post. Source code on GitHub.

Read the full write-up

Detailed article covering the architecture, implementation, and lessons learned.

Read article →