day-log

EKS를 몇 년째 운영하다 보면 한 번쯤은 이런 순간이 온다. 누군가 kubectl delete ns prod-something을 잘못 쳤거나, GitOps 동기화가 꼬여서 ConfigMap이 통째로 날아갔거나. 우리 팀에서는 작년에 한 번 비슷한 사고가 났다. ArgoCD가 잘못된 브랜치를 source로 잡아서 네임스페이스 하나를 prune 해버린 거다. 다행히 ETCD 덤프가 있었지만, 복구하는 데 반나절을 썼다.그 사건 이후로 Velero를 정식으로 도입했다. 이번 글은 EKS 환경에서 Velero를 0에서부터 세팅하고 운영하는 실전 가이드다. 공식 문서에 나오는 기본 설치 말고, 실제 운영 들어갔을 때 부딪히는 부분 위주로 적었다.왜 Velero인가EKS 백업 옵션은 몇 가지가 있다. AWS Ba..

Karpenter를 1년 넘게 운영하다 보니 "왜 이 인스턴스 타입을 골랐을까" 하는 순간이 종종 생긴다. m5.2xlarge면 충분해 보이는데 c6i.4xlarge를 띄운다거나, 분명히 비슷한 spec인데 어떤 Pod는 한 노드에 몰리고 어떤 Pod는 새 노드를 띄운다. 처음엔 그냥 "알아서 잘 해주겠지" 하고 넘어갔는데, 최근 Karpenter 1.11에서 Application Recovery Controller(ARC) zonal shift 통합이 들어오면서 zone 단위 회복 시나리오를 검토할 일이 생겼다. 이 김에 스케줄러 내부를 한 번 제대로 들여다봤다.사실 Karpenter의 스케줄링 로직은 pkg/controllers/provisioning/scheduling/scheduler.go 한 파..

KEDA SQS scaler에서 새벽에 만난 함정지난주 토요일 새벽 3시쯤이었다. 핸드폰 진동 한 번에 눈이 떠졌다. SQS DLQ 누적 알림. 큐 메시지가 12,000개 쌓여 있었고, 컨슈머 파드는 정확히 한 개. 분명 KEDA로 ScaledObject 걸어놨고, 두 달 동안 잘 돌던 워크로드인데 왜 안 늘어났을까. 멘탈이 좀 흔들렸다.그래서 뭐가 문제였나상황부터 정리하자. 우리 팀이 운영하는 컨슈머는 이미지 후처리(리사이즈 + 메타데이터 추출)를 하는 파이썬 워커다. SQS에서 메시지 꺼내서 S3 거쳐 DynamoDB 업데이트하는 평범한 패턴. KEDA 2.16으로 SQS scaler 붙여놨고 설정은 이랬다.apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetada..

워커노드 OS 얘기를 팀에서 다시 꺼낸 게 두 달쯤 됐다. 그동안은 EKS 기본인 AL2023을 별 생각 없이 썼는데, 멀티클라우드로 한 발 걸치는 작업이 시작되면서 "노드 OS를 통일하면 좋겠다"는 얘기가 나왔다. 후보는 두 개. Bottlerocket, 그리고 Talos. 이번 글은 정답을 내는 글은 아니고, 우리 팀이 한 달 정도 굴려보면서 정리한 비교 노트다.지난 가을 InfoQ에 Talos가 다시 한 번 크게 다뤄지면서 사내 분위기도 살짝 기울었는데, 막상 PoC를 돌려보니 그렇게 단순하진 않았다.두 OS의 출발점이 다르다Bottlerocket은 AWS에서 만든 "컨테이너 워크로드 전용 OS"다. EKS, ECS 둘 다 지원하고, 바이너리는 250개 정도. control container와 ad..

처음에 의심한 것들지난주 새벽 2시 반에 알람이 울렸다. P99 레이턴시 알람이었는데, 한두 번이면 그냥 무시하고 자고 다음 날 보겠지만 같은 알람이 5분 간격으로 계속 울렸다. 누워서 폰만 보다가 결국 노트북을 열었다.원인은 Karpenter였다. v1.0으로 올리고 한 달 정도 됐는데, 이 시점에 처음으로 큰 사고가 터졌다. 자려고 누웠다가 새벽 5시까지 깨어 있었던 그 밤 이야기를 정리해두려고 한다.알람이 P99 latency였으니까 당연히 애플리케이션을 먼저 봤다. 그런데 백엔드 트레이스를 까보니 응답 자체는 빠른데, 가끔 한 노드의 모든 파드가 동시에 사라지는 패턴이 보였다. terminated 이벤트가 5분에 한 번씩 떴다.처음엔 spot interruption인 줄 알았다. 우리 서비스 노드..

작년에 신규 EKS 클러스터를 띄우면서 한 가지 결정을 미뤘다. 워크로드 IAM을 IRSA로 갈지 Pod Identity로 갈지. 그때는 "어차피 둘 다 지원되니까 나중에 보자"고 미뤘는데, 올해 들어 클러스터가 4개로 늘어나면서 더는 미룰 수 없는 상태가 됐다.지난 두 달 동안 stage 환경 전체를 Pod Identity로 옮겨보고, prod의 일부 워크로드도 마이그레이션을 시작했다. 결론부터 말하면 우리 팀은 신규 워크로드는 전부 Pod Identity로, 기존 IRSA는 천천히 전환 중이다. 왜 그런 결정을 했는지, 어떤 케이스에서는 IRSA가 더 나았는지 정리해본다.비교의 배경: 우리는 어떤 환경이었나먼저 우리 팀 환경을 짧게 적어둔다. 비교 결과는 환경에 따라 다르게 읽힐 수 있어서다.EKS ..

GitHub-hosted runner 비용이 슬슬 부담스러워서 self-hosted로 갈아탈 때, 요즘은 거의 ARC(Actions Runner Controller) + Karpenter 조합이 정석처럼 굳어가는 분위기다. 우리 팀도 작년 말부터 이 구성으로 전환했고, 그 과정에서 정리해둔 내용을 가이드로 풀어본다.작년 6월에 ARC 0.12가 나오면서 ephemeral runner 설치가 큐잉되고 실패 시 5번까지 재시도하는 식으로 바뀌었다. 노드 스케일 다운 도중에 러너 파드가 휘말려 죽는 케이스에서 체감이 꽤 좋아졌다. 이 글은 0.12 이상 기준이다.왜 Karpenter랑 묶나처음엔 Cluster Autoscaler로도 충분하지 않을까 했었다. 결론부터 말하면, CI 워크로드 특성상 Karpent..

오늘 알게 된 건 아니고, 최근에 팀원이 Karpenter 설정 PR을 올렸길래 리뷰하다가 "어 이게 v1.0부터 바뀌었는데 모르는 분들 꽤 많겠네" 싶어서 짧게 정리해둔다.WhenUnderutilized 라는 이름은 이제 없다Karpenter 1.0 GA 이후로 WhenUnderutilized는 WhenEmptyOrUnderutilized로 이름이 바뀌었다. 옛날 블로그 글이나 사내 위키 보고 그대로 복붙하면 NodePool apply가 깨진다. 지난주에 1.12.0이 나왔는데도 검색하면 아직 옛날 이름이 상위에 뜨더라.그리고 더 중요한 변화 — 1.0부터는 consolidateAfter를 WhenEmptyOrUnderutilized에서도 쓸 수 있다. 이전에는 WhenEmpty에서만 동작해서, "노드..

작년 KubeCon Salt Lake City 끝나고 팀에서 한참 얘기가 나왔던 게 EKS Pod Identity였다. 우리 팀은 그동안 IRSA(IAM Roles for Service Accounts)를 잘 쓰고 있었는데, 클러스터를 4개 운영하다 보니 OIDC provider를 클러스터마다 다 등록하고, 신뢰 정책에 sub 조건을 박아놓는 방식이 점점 귀찮아졌다. 멀티 클러스터 환경에서 같은 워크로드에 같은 권한을 주려면 클러스터마다 trust policy를 다르게 써야 했고, 새 클러스터를 띄울 때마다 이걸 반복했다.그래서 최근 2주에 걸쳐 dev → staging 클러스터를 차례로 Pod Identity로 옮겼다. prod는 다음 주 작업 예정이다. 이 글은 그 작업을 정리한 가이드다. 이미 운영..