Docs를 참고하고 최대한 경험한 내용을 토대로 기재하였으나, 혹시나.. 잘못된 내용이 있을 수 있습니다.
잘못된 내용은 코멘트로 알려주시면 확인 후 반영하도록 하겠습니다 :)
최근 EKS 노드 관리를 위해 CAS -> Karpenter로 Migration 하였다. CAS, Karpenter의 장/단점을 정리하는 게시물이다!
CAS/Karpenter 2가지 플러그인만 비교한것으로 비교
구분 | CAS | Karpenter | 비고 |
노드 생성 시간 | 느리다. - Warmpool 도입 전 약 4분 - Warmpool 도입 후 약 36초 |
빠르다. - 약 1분 |
Karpenter - NotReady 상태에서도 Pod 할당이 가능하기 때문에 Pod 할당시간이 더 빠르다. |
비용 효율화 | 미흡함 | 비용 효율 | CAS - 미리 지정한 Nodegroup을 이용하기 때문에 Pod Resource.Request와 무관하다. Karpenter - 새로 생성할 Pod 용량에 맞는 가장 저렴한 노드를 생성한다. |
Fail-over | 미흡함 | 가능 | CAS - Nodegroup을 선택하기 때문에 Spot Nodegroup을 계속 선택할 경우 Fail-over 시간이 많이 걸린다. Karpenter - Spot이 안되면, 즉시 On-demand 노드를 생성한다. |
노드 삭제 - Only daemonset |
On-demand : 가능 Spot : 불가 |
On-demand : 가능 Spot : 대체 기능 존재 |
CAS, Karpenter - Spot 노드를 운영할때는 Daemonset만 있더라도 노드를 삭제하지 않는다. Karpenter - 정해진 시간 노드 통/폐합 기능을 통해 Only daemonset 노드 삭제할 수 있다. |
Spot 비율 조정 | 조정 불가 | 조정 가능 | Karpenter - 기본적으로 Spot, On-demand로 지정하면 Spot 100%로 우선 사용한다. - provisoner를 통해 Spot:On-demand 비율 조정이 가능하다. |
위 표만 보면 무조건적으로 Karpenter가 더 좋은 솔루션인것 같으나, 이것은 회사의 상황마다 다를 수 있다고 생각한다.
회사의 상황 그리고 팀 리소스 상황에 따라서 CAS 또는 Karpenter를 사용하면 될것 같다.
CAS를 사용할때는 Nodegroup, Spot 노드를 관리할 수 있는 방법에 대한 고민이 필요할것 같다.
끝!
'기술 이모저모 > [Ops] Devops' 카테고리의 다른 글
[Vault] Vault Helm 배포 및 활성화 방법 (2) | 2023.04.30 |
---|---|
[SLA] 서비스 안전성의 주요 지표 SLI, SAO + SLA (0) | 2023.04.02 |
[Karpenter] Karpenter를 활용하여 EKS 노드 비용 최적화[1/2] (0) | 2023.03.25 |
[Github] Container Image 취약점 점검 Trivy[1/2] (0) | 2022.11.26 |
[Ansible] Ansible을 이용한 서버 점검 스크립트 실행 자동화 구현 (0) | 2022.05.29 |