내 경험을 바탕으로 문서를 참고하고 최대한 많이 작성했지만 잘못된 정보가 있을 수 있습니다.
버그는 댓글로 알려주시면 확인 후 반영하겠습니다 🙂
EKS 노드를 관리하기 위해 최근에 CAS -> Karpenter로 마이그레이션했습니다. CAS와 Karpenter의 장단점을 정리한 포스팅입니다!
CAS/Karpenter 두 플러그인만 비교하여 비교
| 분할 | 카스 | 목수 | 메모 |
| 노드 생성 시간 | 느린. – 온수 풀 소개 약 4분 전 – 웜풀 도입 후 약 36초 |
빠른. – 약 1분 |
목수 – NotReady 상태에서도 Pod 할당이 가능하기 때문에 Pod 할당 시간이 빨라진다. |
| 비용 효율성 | 불충분하다 | 비용 효율적 | 카스 – 미리 정의된 노드 그룹을 사용하므로 Pod Resource.Request와 관련이 없습니다. 목수 |
| 장애 조치 | 불충분하다 | 가능한 | 카스 – 노드 그룹을 선택했기 때문에 Spot 노드 그룹을 지속적으로 선택하면 장애 조치 시간이 오래 걸립니다. 목수 |
| 노드 삭제 -데몬셋 전용 |
요청 시: 가능 위치: 아니오 |
요청 시: 가능 스팟: 대체 기능 사용 가능 |
CAS, 카펜터 – 스팟 노드 실행 시 데몬셋만 있어도 노드가 삭제되지 않습니다. 목수 |
| 스폿 스케일링 | 조정 불가 | 조절할 수 있는 | 목수 – Spot, On-Demand로 설정하면 기본적으로 Spot 100%가 먼저 사용됩니다. – 커미셔너를 통해 스팟:온디맨드 비율 조정이 가능합니다. |
위의 표를 보면 확실히 Karpenter가 더 나은 솔루션인 것 같지만 회사 상황에 따라 다를 수 있다고 생각합니다.
회사 상황과 팀 자원 상황에 따라 CAS나 Karpenter를 사용한다.
CAS를 사용할 때 노드 그룹과 스팟 노드가 어떻게 관리되는지에 대해 생각할 필요가 있을 것 같습니다.
끝!