꾸준히,성실하게

Karpenter + Spot 인스턴스 설계(끝)

운영으로 넘어갔을 시 Spot 100%를 사용할 수 있을까? Spot 인스턴스는 AWS의 남는 서버 자원을 저렴하게 빌리는 방식이다. 가격은 On-Demand 대비 60~70% 저렴하지만, AWS가 해당 자원이 필요해지면 2분 전 통보 후 회수한다.dev 환경에서는 잠깐 서비스가 내려가더라도 큰 문제가 없지만, 운영 환경에서는 상황이 다르다.가장 위험한 시나리오는 특정 AZ에서 동일 인스턴스 타입 Spot이 동시에 대량 회수되는 경우다.이때 Karpenter가 즉시 새 노드 프로비저닝을 시작하지만, 노드 부팅과 Pod 재배치까지 약 60초가 소요된다.Spot 100% 환경이라면 이 60초 동안 서비스 Pod가 하나도 없는 상태가 된다.더 나쁜 경우는 Spot 재고 자체가 없는 상황이다. Karpenter..

CSI, CRD, CRI, CNI

존재하는 이유: k8s가 특정 구현체에 종속되지 않도록 만든 표준 인터페이스 - CSI (Container Storage Interface): 스토리지를 파드에 붙이는 표준 인터페이스* EBS CSI Driver: CSI를 참고하여 구현한 AWS 전용 드라이버 -> EKS add on 에 추가 가능 PVC 생성 -> controller-manager-> CSI Controller Plugin 호출(EBS 생성)-> 파드 스케줄링-> kubelet -> CSI Node Plugin 호출-> 파드에서 볼륨 사용 PV / PVC / StorageClass 관계 1. 어떤 개발자가 요청을 하면, 2. 어떤 타입의 스토리지인지 정의되어잇는 StorgeClass를 참고해서 3. 동적으로 PV 한다. 개발자 ..

Kubernetes Architecture

Kubernetes 클러스터의 전체 구조를 알아보자.k8s의 클러스터는 control plane과 worker node로 나뉜다.control plane에는 cm, ccm, api-server, etcd, scheduler로 구성되어있고,worker node에는 kubelet, kube-proxy, CRI로 구성되어있다. api-server의 역할모든 요청의 출입문.클러스터의 진입점 역할을 하며 모든건 api-server를 통해서만 통신한다.요청을 수신 받으면 인증(IAM) -> 인가(RBAC)를 통해 etcd 순서로 처리된다.(~/.kube/config 파일 참고) etcd의 역할클러스터의 모든 상태를 저장하는 key-value 저장소.모든 오브젝트 정보를 저장하고 죽게되면 클러스터 상태를 조회할 수 ..

두개의 조합을 사용했을 때 문제없이 완벽할 수 있을까??장,단점이 궁금해서 발생할 수 있는 경우를 정리해본다. karpenter 의 문제보다는 Spot 인스턴스의 트레이트오프에서 발생하는 문제점이 있을 수 있다. 1. 콜드 스타트 문제콜드 스타트는 새로운 인스턴스나 컨테이너가 처음 시작될 때 발생하는 초기화 지연이 발생하는 것을 의미한다.Karpenter는 이러한 것을 보완해줄 수 있지만 완벽히 해결,없애지는 못한다. Spot 인터럽트 발생 시 pod가 트래픽을 받기까지 걸리는 시간 - 노드 프로비저닝 ~60초 (Karpenter가 빠르게 처리)- 이미지 pull ~5~60초 - Spring boot 기동 ~30~120초- 헬스체크 최대 00초 (설정에 따라)이렇게 까지보면 평균 2~3분은 걸릴 것 같다..

요약- DEV 환경이니 월1~2회 지연이 발생해도 개발/테스트에는 큰 지장이 없다(협의는 꼭 필요), 그 대신 매달 $200~ 이상의 비용 절감 가능- Karpenter의 빠른 프로비저닝과 자동 통합(consolidation), 그리고 Spot 인터럽트 대응을 활용하면 개발 환경 비용을 크게 줄이면서도 안정성을 유지가능하다. 현재 새롭게 DEV 인프라를 구성하고 있는 프로젝트는 총 5개의 도메인(member, order, point 등등)은 MSA로 이루어진 플랫폼이다.수십개의 서비스가 동시에 떠있는 DEV 환경에서 항상 켜져 있어야 하는 인프라 비용은 꽤 부담(낭비)가 된다. 이러한 문제를 해결하기 위해 Karpenter + Spot 인스턴스 조합을 선택했고, 어떻게 설계했는지 정리해본다.-- Spo..

요약NodeSelector: Pod 주체 -> 나는 해당 Label이 있는 node로 갈거야.Taint(필터/오염): Node 주체 -> 허락받지 않는 pod는 접근 불가.Toleration(허가증): pod 주체 -> 해당 pod는 Taint를 견딜 수 있는 접근 권한이 있다. *세 가지 종류는 각각 독립적으로 동작하지만, 셋을 조합해서 사용했을 때 의도한 대로 Pod를 격리하고 배치할 수 있다.-- 간단한게 생각하면 k8s에서는 pod를 적절한 노드에 배치하는 작업은 두 가지 메커니즘을 통해 이루어진다.1. pod의 node 선택2. node의 거부-- NodeSelector 는 pod가 주체이며 node를 선택한다.- pod 설정에 특정 노드 라벨 설정 - k8s의 스케줄러는 pod의 요구사항과 n..

요약: 새로 구성하는 EKS 환경에서는 Pod Identity를 기본적으로 사용하는 것이 좋다.설정이 단순하고 Terraform으로 중앙 관리가 가능하며 AWS의 권장 사항이다.*단 AWS SDK v1기반은 지원하지 않으니, 예외적으로 IRSA를 사용해야 한다. -- EKS에서 pod가 AWS 리소스(s3, MSK 등)에 접근하려면 IAM 권한이 필요하다.하지만 파드는 EC2처럼 인스턴스 프로파일을 직접 붙일 수 없다.해당 문제를 해결하기 위해서는 3가지 방법이 있다. 가상 선호/최신 방법인 Pod Identity부터 알아보자. Pod Identity (AWS 권장 최신 방식, 2023)AWS EKS Pod Identity Agent가 파드의 자격증명을 직접 담당한다, OIDC나 SA 어노테이션 없이 T..

global-prod-cluster의 global-settle-api 파드가 재생성 시 정상적으로 뜨지 못하고 HPA에 의해 강제 스케일 다운되는 현상이 반복적으로 발생.수동으로 파드를 삭제해야만 정상화되는 상황.원인 분석 결과, Spring Boot 기동 시간이 readinessProbe 실패 판정 시간(45초)을 초과하여 파드가 Unready 상태로 확정되고, HPA가 메트릭 수집 불가 상태에서 "All metrics below target"으로 판단해 기동 중인 파드를 강제 삭제하는 흐름이 확인.# NS 이벤트만 조회 # 마지막 발생 시간 기준으로 오래된 것부터 kubectl get events -n {Namespace} \ --sort-by='.lastTimestamp' \ ..

현재 새롭게 구축하는 프로젝트에서 특정 DB 의 변경 이벤트를 실시간으로 CDC(캡처)해서 타 서비스 (Neo4j, worker) 등에 전달하는 CDC 파이프라인이 필요하다.* CDC 도입 배경 : 기존의 배치 방식은 주기적인 쿼리 실행으로 DB 부하 및 실시간성이 떨어짐. CDC 는 DB 의 Binlog를 직접 읽어서 변경분만 캡처해 실시간성, 부하 최소화 등 장점이 뚜렷함 일반적으로 Debezium을 쓰려면 Kafka Connect 서버를 별도로 띄워야 한다.하지만 이미 EKS 클러스터에 서비스들이 올라가 있는 상황에서 Kafka Connect 전용 인프라를 추가로 관리하는 건 부담이 된다 판단. 해결책으로 AWS MSK Connect — Kafka Connect를 완전 관리형으로 제공하는 서비스를 ..

요약 : Karpenter는 k8s 환경에서 인프라 관리를 수동적인 노드 그룹 관리에서 워크로드 중심의 자동화로 전환하는 핵심 도구.MSA 환경에서 배포 속도와 비용 절감을 동시에 달성하고자 할때 필수적인 선택지. -- karpenter는 AWS로 구축된 오픈 소스의 고성능 k8s 클러스터 오토스케일러이다.원래 기존에는 EC2 Auto Scaling 과 Kuberntes Cluster Autoscaler를 사용했는데, Karpenter에 비해 상대적으로 복잡했다. 구분Cluster AutoscalerKarpenter추가 방식미리 정의된 ASG 규모 확장pod 스펙에 맞춰 EC2 인스턴스 즉시 생성의사 결정노드 그룹 내에서 부족한 자원 보충모든 EC2 인프라를 대상으로 최적 타입 선택확장 속도노드 그룹 업..