EKS, Helm, autoscaling and safe rollouts

EKS setup sequence

1. Review EKS cluster/node pricing and supported Kubernetes versions in your Region.
2. Create a lab cluster with appropriate endpoint access, IAM administration and VPC/subnet design using a reviewed IaC tool or console flow.
3. Add a managed node group or another supported compute option and verify nodes are Ready.
4. Configure kubectl access using aws eks update-kubeconfig --name YOUR_CLUSTER --region ap-south-1 with an authorized role.
5. Install only required compatible add-ons and configure workload identity using supported EKS Pod Identity or IRSA patterns.
6. Deploy the academy sample into its own namespace and verify service health.

Helm

Helm packages Kubernetes resources as charts. Values customize a release; templates render YAML. Inspect rendered resources before install, especially RBAC, privileged containers and externally exposed Services.

helm template academy ./chart -f values-lab.yaml
helm upgrade --install academy ./chart -n academy --create-namespace -f values-lab.yaml
helm history academy -n academy

These commands require a real chart you have reviewed; they are not a reference to an included chart unless you create one in the exercise. Keep environment-specific values separate from reusable templates.

Autoscaling

HPA scales workload replicas from metrics. CPU-utilization targets depend on CPU requests and an available metrics API such as Metrics Server. Node capacity scaling is a separate function provided by tools such as Cluster Autoscaler or Karpenter under suitable configuration.

kubectl -n academy autoscale deployment academy-web --min=2 --max=5 --cpu-percent=60
kubectl -n academy get hpa

A pending Pod cannot be fixed merely by increasing desired Pod count when no node can host it. Load-test only a controlled lab with explicit limits.

Rollouts and disruption

Readiness governs traffic eligibility; liveness can restart a stuck process; startup probes protect slow initialization. Configure them based on failure modes. PodDisruptionBudgets constrain voluntary disruptions and do not guarantee protection from all failures. Plan node/cluster upgrades and version compatibility before changing production.

Cleanup and assignment

Delete lab LoadBalancer Services/Ingress resources and verify cloud load balancers are removed before deleting the cluster/VPC. Explain control-plane responsibility versus worker/app responsibility. Record a rollback rehearsal, including what happens to database schema changes.

Official references

EKS guide HPA Helm docs

Interview and revision check

Why can HPA create more desired Pods without improving throughput?

Nodes may lack capacity or the bottleneck may be a database/dependency. Workload and node scaling are separate concerns.