꾸준히,성실하게

요약컨테이너만 돌리는 EKS 노드 → Bottlerocket 적합디버깅/커스터마이징 필요 → Amazon linux2 적합 -- Bottlerocket은 AWS가 만든 컨테이너 전용 linux OS. 일반 linux와 차이점-일반 Linux범용 OS (웹서버, DB, 컨테이너 등 모든 실행 가능)apt/yum으로 패키지 설치 가능SSH로 접속해서 직접 수정 가능 -Bottlerocket컨테이너 실행만을 위한 OS패키지 설치 불가 (읽기 전용 파일시스템)SSH 기본 비활성화SSM으로만 접근 가능 특징- 보안공격 표면 최소화 (불필요한 패키지 없음)읽기 전용 OS (변조 불가) - 자동 업데이트업데이트 실패 시 자동 롤백 - 빠른 부팅컨테이너만 실행하면 되니까 가벼움EKS 노드 스케일 아웃 시 유리 - Co..

요약완벽한 스펙을 처음부터 계산하는 것은 쉽지 않다.일단 작게 만들고, 모니터링 후 필요하면 올리는 전략을 사용한다. → dev, beta 에서 충분히 테스트 진행.보수적인 스펙 (t3.medium , m5.large 등) 으로 시작하고 CloudWatch, Grafana 등 알람 설정, 모니터링 후 기준 사용치 초과하면 조정. -- DevOps 엔지니어라면 EC2 인스턴스나 RDS를 만들 때 한 번쯤 이런 생각을 해본 적 있을 것이다."이 서비스, t3.medium으로 충분할까? 아니면 m5.large로 가야 하나?"명확한 기준 없이 감으로 정하거나, 무조건 크게 잡아두는 경우가 많다.실무에서 사용하는 판단 기준을 정리해본다. - 기존 리스소를 참고한다.가장 빠르고 현실적인 방법. 같은 환경에서 유사한..

docker, containerd, CRI-O 모두 k8s의 컨테이너를 실행하기 위한 엔진이다.과거에는 docker가 독보적인 위치였지만, 현재는 containerd와 CRI-O 중심으로 전환되었다. 쿠버네티스는 컨테이너를 관리하기 위해 CRI(Container Runtime Interface) 표준 규격을 사용한다.- Docker: CRI를 직접 지원하지 않아 Dockershim 이라는 중계 레이어가 있었는데 k8s v1.24 이후 완전히 제거되었다.- Containerd: 도커에서 이미지 관리와 실행 기능한 떼어낸 런타임. CNCF 프로젝트로 매우 안정적이다. ㄴ 도커와 호환이 높다. 클라우드(AWS 등) 벤더의 기본 런타임으로 채택.- CRI-O: OCI(Open Container Initiativ..

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

존재하는 이유: 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 클러스터의 전체 구조를 알아보자.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..