day-log

우리가 깐 구성지난주 화요일 새벽에 알림이 울렸다. 정확히는 알림이 안 울려서 문제였다. 이미지 변환 워커가 SQS 큐의 메시지를 잘 먹고 있는 줄 알았는데, 다음 날 아침에 보니 "어제 업로드한 썸네일이 안 나와요"라는 CS 티켓이 17건 쌓여 있었다. SQS DLQ에 들어간 것도 아니고 그냥 큐 어디에도 없었다. 처리는 안 됐는데 사라졌다는 게 가장 큰 문제였다.원인은 KEDA였다. 정확히는 KEDA가 잘못한 건 아닌데, scaleToZero를 너무 공격적으로 설정한 우리 팀이 잘못했다. 이 글은 그 이야기다.배경부터 정리하면, 우리 팀은 이미지 변환 파이프라인을 KEDA + SQS로 운영하고 있다. 사용자가 이미지를 업로드하면 S3 트리거가 SQS로 메시지를 보내고, 워커 파드가 그걸 받아서 리사이..

CNI 교체는 사실 자주 할 일이 아니다. 한 번 들어가면 클러스터 수명 내내 같이 가는 컴포넌트라 잘못 고르면 두고두고 후회한다. 우리 팀은 작년 4분기에 Calico로 운영하던 프로덕션 클러스터 3개를 Cilium으로 옮겼고, 그 후 약 8개월을 양쪽 다 운영해봤다. 아직 일부 레거시 클러스터는 Calico를 그대로 두고 있어서 비교가 가능한 상황이다.이번 KubeCon EU에서도 Cilium 세션이 절반은 되더라. CNCF 2025 연간 서베이에서 Cilium이 Calico랑 Flannel을 제치고 프로덕션 CNI 1위를 먹었다는 발표가 있었는데, 우리 팀이 옮길 때만 해도 그 정도까진 아니었다. 1년 사이에 분위기가 꽤 바뀐 셈이다.왜 옮겼는가솔직히 처음부터 옮길 생각은 없었다. Calico는 안..

Kyverno ClusterPolicy를 ValidatingPolicy(CEL)로 옮기는 법Kyverno가 3월 KubeCon EU 암스테르담에서 CNCF graduated 프로젝트로 승격됐다. 같은 흐름에서 1.17부터 CEL 기반의 새 정책 타입(ValidatingPolicy, MutatingPolicy 등)이 GA로 바뀌었고, 기존 ClusterPolicy API는 2026년 10월 제거 예정이라는 공지가 같이 나왔다. 우리 팀은 그동안 ClusterPolicy로 30개 가까운 정책을 운영하고 있었는데, 일정상 7월까지는 옮겨야 한다. 이번 글은 그 마이그레이션 작업을 하면서 정리한 가이드다.대상 독자는 Kyverno를 이미 한 번이라도 운영해 본 사람이다. CEL 자체가 처음이라면 마지막 섹션의 ..

cgroup v2 전환 후 OOMKill 동작이 바뀐 이유올해 초 우리 팀 클러스터를 EKS 1.28에서 1.30으로 올리면서 cgroup v2 노드 비율이 100%가 됐다. 그 직후부터 묘하게 신경 쓰이는 현상이 생겼다. 예전 같으면 사이드카 하나만 OOM으로 죽고 메인 컨테이너는 살아 있던 케이스가, 이제는 컨테이너 안의 모든 프로세스가 한꺼번에 같이 죽고 있었다. 처음에는 "그래, 이게 더 깔끔하긴 한데" 정도로 넘겼는데, 일부 멀티 프로세스 워크로드가 갑자기 불안정해지는 걸 보고 한참을 파봤다. 결론부터 말하면 이건 버그가 아니라 의도된 변경이고, 알고 쓰면 오히려 운영이 단순해진다. 다만 모르고 쓰면 황당한 장애를 만난다.이 글은 그 동작이 왜, 어디서, 어떻게 바뀌었는지를 cgroup, kub..

새벽 3시 7분에 진동이 왔다새벽 3시 7분. 폰이 진동했다. etcd_mvcc_db_total_size_in_bytes 가 6GiB를 넘었다는 알람이었다. 우리 클러스터는 컨트롤플레인이 EKS가 아니라 자체 운영이고, etcd quota를 8GiB로 잡아놨다. 8GiB를 넘기는 순간 클러스터가 read-only로 떨어진다. 일어났다.평소에는 etcd db size가 1.2~1.5GiB 사이를 왔다 갔다 한다. 그게 6GiB라는 건 어딘가가 단단히 잘못됐다는 뜻이다. 처음엔 그냥 defrag 한번 돌리면 되겠지 했는데, 이게 그렇게 단순한 얘기가 아니었다.일단 무슨 일이 일어났는지부터 봤다ssh로 컨트롤플레인 노드 3대에 붙어서 etcdctl로 상태를 봤다.ETCDCTL_API=3 etcdctl \ -..

GitOps 도구 고민은 의외로 끝나지 않는다. 작년 이맘때 우리 팀은 ArgoCD를 쓰고 있었는데, 어쩌다보니 한 분기를 Flux로 갈아엎고 돌렸다가 결국 다시 ArgoCD로 돌아왔다. 비교 글은 인터넷에 차고 넘치지만, 둘 다 운영 환경에서 한 사이클씩 굴려본 입장에서 쓸 만한 글은 의외로 적었다. 그래서 정리해본다.전제부터 깔자. 우리 팀은 EKS 클러스터 7개(prod 3, staging 2, dev 2), 약 220개 마이크로서비스, 배포는 하루 평균 60건쯤이다. 큰 조직은 아니지만 작지도 않다. 이 규모에서 우리가 겪은 차이를 적는다.왜 갈아탔다가 다시 돌아왔나원래 ArgoCD 2.10대를 1년 정도 잘 쓰고 있었다. 그런데 ApplicationSet generator 설정이 점점 비대해지고..

마이그레이션 전에 점검할 것ingress-nginx가 결국 작년 3월에 EOL됐다. 깃허브 저장소는 archived 처리됐고, 보안 패치도 더 이상 안 나온다. 그동안 미루고 미뤘는데 이제는 정말 도망갈 데가 없다. 우리 팀도 6월 들어서야 본격적으로 Gateway API 마이그레이션을 시작했고, 이 글은 그 과정에서 정리한 가이드다.처음에는 막막했다. Ingress 리소스가 200개가 넘는데 이걸 일일이 손으로 옮긴다고? 다행히 SIG-Network에서 올해 3월에 ingress2gateway 1.0을 정식 릴리스했다. 이걸 쓰면 대부분의 Ingress 리소스가 자동으로 변환된다. 물론 자동 변환이 모든 걸 해결해주지는 않는다는 게 함정이지만.본격적으로 시작하기 전에 두 가지를 먼저 확인했다.첫 번째는..

작년 이맘때쯤 우리 팀에 Chaos Engineering 도입 미션이 떨어졌다. SRE 본부에서 "장애 대응 훈련을 코드로 돌릴 수 있게 만들자"라는 좀 추상적인 OKR이 내려왔고, 첫 분기는 Chaos Mesh, 두 번째 분기부터는 Litmus로 갈아탔다가, 결국 둘을 섞어서 쓰고 있다. 1년이 지나서 다시 정리해보니 둘 중 뭘 골라야 하느냐는 질문이 잘못된 질문이었다는 결론이 났다. 어느 팀이 어느 부분을 책임지냐에 따라 답이 달라진다.Litmus는 작년 가을 3.0으로 메이저 버전이 올라가면서 UI가 Harness UIcore 기반으로 싹 바뀌었고, Chaos Workflow가 Chaos Experiments로, Chaos Experiments가 Chaos Faults로 용어가 재정의됐다. 올해 1..

배포 자동화는 다들 잘 해놨는데, 정작 "이 배포 잘 된 거 맞아?"를 판단하는 건 사람이 대시보드 보고 있다. 우리도 그랬다. ArgoCD가 알아서 sync까지는 해주는데, P99가 튀거나 에러율이 올라가면 누군가는 새벽에 깨서 롤백을 해야 했다.올해 초 Argo Rollouts을 본격적으로 도입했고, AnalysisTemplate으로 Prometheus 메트릭을 보고 자동 롤백까지 시키는 데까지 왔다. 이 글은 그동안 정리해둔 셋업 노트다. 처음 도입하는 팀이 보면 30분 안에 동작하는 canary는 만들 수 있게 썼다.왜 Rollout인가 (Deployment로는 안 되나)솔직히 Deployment + RollingUpdate로도 canary 비슷한 흉내는 낼 수 있다. 그런데 두 가지가 안 된다...

1.36 Pod-level in-place resize, 사이드카 많은 Pod일수록 의미가 크다지난달 Kubernetes 1.36이 나오면서 In-Place Pod Resize에 한 가지 작은 게이트가 추가됐다. InPlacePodLevelResourcesVerticalScaling. 1.35에서 컨테이너 단위 in-place resize가 GA 된 직후라 잘 안 보이지만, 사이드카가 덕지덕지 붙은 Pod를 운영하는 입장에선 이게 더 반갑다. 오늘은 그 얘기를 짧게.뭐가 달라졌나기존 in-place resize는 컨테이너 하나하나의 resources.requests/limits를 따로 바꿔야 했다. Pod에 컨테이너가 3개면 patch도 3번. 그것도 모자라서, 사이드카가 자기 limit에 먼저 걸려 t..