Karpenter 도입 파일럿

사람인은 기존 AWS EKS 환경에서 Auto Scaling Group(ASG) 으로 노드를 명시적으로 관리해 왔지만, 신규 서비스 대응과 배포 시 리소스 급증 때문에 Not Ready, 확장 지연, 수동 증설 같은 문제가 반복됐다.

이 문제를 해결하기 위해 Karpenter를 검증했고, 테스트 케이스를 먼저 정의한 뒤 운영 전략을 단계적으로 적용했다. 핵심은 Karpenter가 만든 노드 위에 자기 자신이 올라타지 않도록 ASG 노드와 Karpenter 노드의 역할을 분리하는 것이었다.

안정성 확보를 위해 Taint & Toleration을 적용해 Karpenter Controller, CoreDNS 같은 핵심 Pod는 ASG 노드에서만 돌도록 했고, 일반 애플리케이션은 Karpenter가 만든 노드로 유도했다. 또한 다중 NodePool 운영에서는 spot-instance와 ondemand-instance를 분리하고, spot에 weight 50, on-demand에 weight 1을 둬서 spot을 우선 사용하도록 구성했다.

NodePool별 disruption 정책도 다르게 가져갔다. on-demand는 WhenEmpty로 설정해 파드가 완전히 없어질 때까지 축출하지 않도록 했고, spot은 WhenUnderutilized와 짧은 budget으로 더 적극적인 정리를 허용했다.

파드 분산을 위해 TopologySpreadConstraints를 사용해 AZ 단위로 균등 배치되도록 했고, 애플리케이션 리소스는 가능하면 request 중심으로 맞춰 Karpenter가 빈 패킹 시 인스턴스 타입을 더 정확히 고르도록 유도했다. Java처럼 초기 기동 시 자원을 많이 쓰는 특성도 고려해 메트릭을 기반으로 request를 조정했다.

노드 안정성은 kubelet 설정으로 보강했다.

• 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%

개발 환경에서는 비용 절감을 위해 업무시간 외에 Karpenter 노드를 내리도록 CronJob을 사용했다. 평일 22시에 spot-instance의 memory limit을 0으로 바꾸고 해당 노드를 삭제해 애플리케이션 Pod가 Pending 상태가 되게 한 뒤, 다음 날 07시에 limit을 복구해 다시 기동되도록 했다.

Spot 할당 안정성을 높이기 위해서는 instance-cpu / instance-memory 기준만으로는 부족해, 원하는 instance-type 목록을 직접 지정하는 방식으로 전환했다. 특히 저렴한 Spot 인스턴스 위주로 15개 이상 타입을 리스트업해, 불필요하게 비싼 인스턴스를 받는 상황을 줄이려 했다.

로그 흐름도 정리했다. found provisionable pod 이후에는 computed new nodeclaim → create nodeclaim → launched → registered → ready → initialized 순으로 노드가 만들어지고, 삭제 시에는 disrupting → tainted node → deleted node → deleted nodeclaim 순으로 정리된다.

마지막으로 Descheduler와의 조합도 실험했지만, HighNodeUtilization은 Kubernetes Scheduler의 MostAllocated 전략과 함께 써야 효과가 있는데 EKS 기본값은 LeastAllocated라서 기대한 Bin-Packing 효과가 나오지 않았다. 결론적으로 Karpenter는 강력하지만, Production에서는 다양한 정책과 테스트를 충분히 거친 뒤 적용해야 한다는 점을 강조한다.