Karpenter Adoption Pilot

Saramin had been explicitly managing nodes with an Auto Scaling Group (ASG) in its existing AWS EKS environment, but recurring issues such as Not Ready, scaling delays, and manual node addition kept occurring due to responding to new services and resource spikes during deployment.

To solve this problem, they evaluated Karpenter, first defining test cases and then applying an operational strategy in stages. The key was to separate the roles of ASG nodes and Karpenter nodes so that Karpenter itself wouldn't run on top of the nodes it created.

To secure stability, they applied Taint & Toleration so that core Pods such as the Karpenter Controller and CoreDNS run only on ASG nodes, while general applications are directed to nodes created by Karpenter. Additionally, in multi-NodePool operation, they separated spot-instance and ondemand-instance, giving spot a weight 50 and on-demand a weight 1 to configure spot as the priority.

They also applied different disruption policies per NodePool. On-demand was set to WhenEmpty so pods wouldn't be evicted until they were completely gone, while spot allowed more aggressive cleanup with WhenUnderutilized and a short budget.

For pod distribution, they used TopologySpreadConstraints to ensure even placement across AZs, and application resources were aligned around request wherever possible so Karpenter could more accurately select instance types during bin packing. They also adjusted requests based on metrics, taking into account characteristics like Java's heavy resource usage during initial startup.

Node stability was reinforced with kubelet settings.

• kubeReserved: cpu 200m, memory 100Mi, ephemeral-storage 3Gi
• systemReserved: cpu 100m, memory 100Mi, ephemeral-storage 1Gi
• imageGCHighThresholdPercent 80 / imageGCLowThresholdPercent 60
• evictionHard: memory.available 500Mi, nodefs.available 10%, nodefs.inodesFree 5%

In the development environment, to save costs, they used a CronJob to bring down Karpenter nodes outside business hours. At 22:00 on weekdays, the memory limit of spot-instance is changed to 0 and the corresponding node is deleted, putting application Pods into a Pending state; then at 07:00 the next day, the limit is restored so they start up again.

To improve Spot allocation stability, relying only on instance-cpu / instance-memory criteria was insufficient, so they switched to directly specifying a desired instance-type list. In particular, they listed up over 15 types focused on cheap Spot instances, in order to reduce situations where unnecessarily expensive instances were allocated.

The log flow was also organized. After found provisionable pod, nodes are created in the order computed new nodeclaim → create nodeclaim → launched → registered → ready → initialized, and during deletion they are cleaned up in the order disrupting → tainted node → deleted node → deleted nodeclaim.

Finally, they also experimented with combining Descheduler, but HighNodeUtilization only works effectively together with the Kubernetes Scheduler's MostAllocated strategy, and since EKS's default is LeastAllocated, the expected Bin-Packing effect did not appear. In conclusion, they emphasize that while Karpenter is powerful, it should be applied in Production only after going through sufficient policy design and testing.