Skip to content

태그: karpenter

총 3개의 글이 있습니다.

Karpenter best practices

Use Karpenter for workloads with changing capacity needs karpenter brings scailing management closer to Kubernetes native APIs than do Autoscaling Groups and Managed Node Groups. ASGs and MNGs are AWS-native

Karpenter의 스케줄링 우선순위 Karpenter는 pod를 스케줄링할 때 아래와 같은 순서로 조건을 체크하여 스케줄할 노드를 선택한다: 1. 기존 노드 활용 시도 (`addToExistingNode`) 이미 존재하는 노드에 추가 가능한지 확인 단, toleration하지 않은 taint가 붙어있으면 불가 (PreferNoSchedule 포함) 2. 생성 중인 노드 활용 (`addToInflightNode`) 현재 생성 중인 노드에 추가 가능한지 확인 3. 새 노드 생성 (`addToNewNodeClaim`) 새로운 노드를 추가해서 스케줄링 가능한지 확인 4. 제약 조건 완화 (Relax) Affinity, Topology 무시하고

spot 인스턴스에서 서버 가용성 개선하기

개요 대덕SW마이스터고 동아리에서 개발한 4개의 교내 서비스(약 250명의 교사와 학생이 사용 중)를 대상으로 서비스 인프라를 통합하는 프로젝트를 진행했다. 이 프로젝트에서 Karpenter를 코드를 커스텀하여, Spot 인스턴스 환경의 Replica 1인 Deployment의 가용성을 96% -99.95%로 개선한 과정을 설명하는 글이다. 문제 상황 해당 인프라에선 각 동아리가 새 프로젝트를 개발할 때마다 배포할 수 있어야 했기 때문에, 자주 변동하는 컨테이너, 컴퓨팅 리소스를 쉽게 관리하기 위해 Kubernetes(EKS)를 사용하였다. 초기에 가용성을 크게 고려하지 않고 각 Deployment의 Replica 수를 1로 유지했음에도, 수십개 컨테이너를 실행하기엔 서버비 예산에 압박이 있었다