day-log

지난주에 팀 내부에서 조용히 진행해온 일 하나가 있다. EKS 클러스터 12개에 걸쳐 흩어져 있던 IRSA(IAM Roles for Service Accounts) 설정을 Pod Identity로 이관하는 작업이다. 큰 장애 없이 끝났지만, 중간에 몇 번은 새벽에 알람이 울려서 눈이 번쩍 떠졌다. 그 삽질 기록.시작한 이유는 단순했다. 클러스터를 하나 더 늘리는데, 또 OIDC provider를 만들고, trust policy에 system:serviceaccount:*:* 문자열을 하나하나 박고 있는 내가 좀 한심하게 느껴졌다. 마침 최근에 나온 자료들에서도 신규 워크로드는 Pod Identity 쪽으로 가는 게 대세라고 얘기하고 있었고. 참고로 IRSA가 deprecated 된 건 아니다. 그냥 새로..

GitHub Actions self-hosted runner를 Kubernetes 위에 굴리는 방법으로 요즘 표준은 사실상 Actions Runner Controller(ARC)다. 근데 올해 3월에 0.14.0이 GA로 풀리면서 꽤 큰 변화가 있었다. multilabel 지원이 들어왔고, 내부 클라이언트도 actions/scaleset 라이브러리로 교체됐다. 우리 팀도 이번 주에 0.11 → 0.14로 올리면서 몇 가지 정리한 게 있어서 가이드 형태로 남긴다.이 글은 "ARC 처음 세팅한다" 시나리오를 기준으로 쓴다. 이미 legacy(runner deployment) 모드로 굴리고 있는 팀이라면 뒷부분 마이그레이션 노트만 봐도 된다.왜 scale set 모드인가ARC는 두 가지 모드가 있다. 예전부터..

지난달 얘기다. 우리 팀 결제 API에 SLO를 새로 걸었고, burn rate 알림도 같이 설정했다. Google SRE 워크북에 나온 그 유명한 멀티 윈도우, 멀티 burn rate 알림 말이다. 문서 그대로 따라 붙였으니 잘 돌 줄 알았는데, 첫 주에만 새벽에 두 번 깨졌다. 둘 다 진짜 장애는 아니었다.처음 걸었던 설정우리 SLO는 30일 창(window) 기준 가용성 99.9%다. 워크북에서 권장하는 대로 두 개 알림을 걸었다.- alert: HighErrorBudgetBurnFast expr: | ( job:slo_errors_ratio:rate1h{job="payment-api"} > (14.4 * 0.001) and job:slo_errors_ratio:r..

라이선스 이슈로 시끄러웠던 게 벌써 2년 전이다. 그때는 "일단 지켜보자"로 넘어간 팀이 많았는데, 요즘 다시 이 얘기가 올라온다. 나도 최근에 팀 내부에서 마이그레이션 검토를 했고, 결과적으로는 OpenTofu 쪽으로 기울었다. 이유를 정리해본다.지금 어디까지 왔나Terraform은 1.15 라인이 stable, 1.16이 alpha다. OpenTofu는 1.12.2가 stable. 버전 넘버만 보면 Terraform이 앞서가는 것 같지만 실제 CLI 오픈소스 기능은 그 반대다.HashiCorp가 BSL로 넘어간 뒤 IBM에 인수됐고, 오픈소스 CLI에는 신규 기능이 거의 안 들어간다. 대신 HCP Terraform(관리형)과 AI 어시스트 쪽으로 투자가 몰려 있다. 반면 OpenTofu는 Linux ..

Prometheus를 운영하다 보면 어느 순간부터 “카디널리티(cardinality) 조심하세요”라는 말이 유령처럼 따라붙는다. 개발자가 라벨 하나 추가했을 뿐인데 다음 날 Prometheus 인스턴스가 OOMKilled로 재기동되고, prometheus_tsdb_head_series가 400만을 찍고 있는 걸 보게 된다. 사실 나도 예전에는 “라벨 값 종류 많아지면 메모리 좀 쓰겠지” 정도로만 생각했다. 근데 TSDB 내부를 좀 파고 들어가 보니 이건 “좀 쓰는” 수준이 아니라, 아예 저장 엔진의 구조 자체가 라벨 조합 하나하나에 비용을 부과하도록 설계돼 있다.이 글에서는 Prometheus의 로컬 TSDB가 시계열(series)을 어떻게 저장하고 인덱싱하는지, 그래서 왜 user_id, request..

트러블슈팅 하다가 오늘 알게 됐다. 정확히 말하면 "알고는 있었는데 안 쓰고 있었다"에 가깝다. kubectl events --for 얘기다.왜 이제서야 쓰나지금까지 특정 Pod의 이벤트만 보려면 이렇게 했다.kubectl get events --field-selector involvedObject.name=web-pod-abc,involvedObject.kind=Pod -n prod솔직히 매번 field-selector 문법이 헷갈렸다. involvedObject.name이었나 regarding.name이었나. Pod 이름을 오타 내면 결과가 조용히 비어있고, 그러면 또 오타를 의심하게 된다. 삽질 시간의 절반이 이 selector 맞추기였다.그런데 kubectl events는 v1.28에서 GA된 이..

지난주 화요일 오전 10시쯤, 데이터팀 슬랙에 핑이 왔다. "혹시 정산 배치 어제도 안 돈 것 같은데, 뭐 바뀐 거 있어요?" 처음엔 별 생각 없이 로그부터 봤다. 어제, 그저께, 그그저께. 세 번 다 스케줄 시각에 Job이 아예 생성되지 않은 상태였다. Pod가 실패한 게 아니라 Job 자체가 없었다. 이거 뭐지, 하는 마음으로 CronJob describe를 걸었다.문제 상황문제의 CronJob은 매일 새벽 3시에 도는 정산 집계 배치였다. schedule은 0 3 * * *, concurrencyPolicy는 Forbid. 원래 잘 돌던 놈이었는데, 일주일쯤 전에 내가 매니페스트를 손댔다. 이유는 이랬다.기존 설정은 startingDeadlineSeconds가 없었다. 배치가 오래 걸리는 날에 다음..

컨테이너 이미지 업데이트를 자동화하려고 이것저것 붙여본 지 꽤 됐다. GitHub 표준인 Dependabot을 쓰다가, 결국 Renovate로 옮겨온 팀들이 주변에도 늘고 있다. 두 도구는 언뜻 비슷해 보이지만 컨테이너 이미지 관점에서 뜯어보면 결이 꽤 다르다. 이번 글은 지금 우리 팀이 어떤 기준으로 골랐고, 왜 그런 결정을 했는지 정리한 것에 가깝다.우리가 원했던 것시작은 단순했다. 사내 서비스 20여 개, Helm chart 60여 개, GitHub Actions 워크플로 100개 이상에서 쓰이는 이미지 태그를 자동으로 최신화하고 싶었다. 규모가 커지면서 수작업 업데이트가 자꾸 밀렸고, 오래된 base image 하나가 CVE 리포트에 걸려서 리뷰가 늘어나는 일이 반복됐다.그리고 원한 건 세 가지였..

ArgoCD ApplicationSet Progressive Sync 실무 가이드멀티 클러스터로 ArgoCD를 굴리다 보면 한 번은 겪는 상황이 있다. 앱 매니페스트를 하나 바꿨는데 그게 20개 클러스터에 동시에 동기화되면서, 하필 그 변경이 문제였을 때 20개가 같이 뻗어버리는 케이스. 우리 팀도 지난 분기에 한 번 크게 데었고, 그 이후로 ApplicationSet Progressive Sync를 프로덕션에 도입했다.이 글은 도입하면서 정리한 내용이다. 문서만 보고 따라 하면 놓치기 쉬운 부분 위주로 적었다. Progressive Sync 자체는 2026년 현재 Beta로 승격됐는데, 여전히 experimental 플래그로 활성화해야 한다는 점을 먼저 짚어둔다.Progressive Sync가 뭘 하는..