day-log

PR 올릴 때마다 QA 환경 하나씩 띄우는 거, 다들 어떻게 하시나요. 우리 팀도 한참 동안은 PR 댓글에 /deploy preview 같은 슬래시 커맨드를 달고 Jenkins job을 트리거하는 방식을 썼는데, 결국에는 항상 누군가 환경을 안 지워서 노드가 터져 있곤 했다. 그래서 작년 말부터 ArgoCD ApplicationSet의 Pull Request generator로 전환했다. 지금까지 6개월 정도 돌려보니 만족도가 꽤 높아서, 셋업 가이드를 정리해둔다.이 글은 GitHub + ArgoCD 2.x 환경 기준이다. GitLab/Gitea도 거의 비슷하다.어떻게 동작하나핵심은 단순하다. ApplicationSet이 GitHub API를 폴링해서 열려 있는 PR 목록을 가져오고, 각 PR마다 App..

OpenTelemetry Collector를 운영하다 보면 refused_spans, enqueue_failed, OOMKilled 같은 시그널을 한 번쯤은 본다. 다들 "memory_limiter 처음에 두면 된다"고 말하지만, 정작 메모리가 한계에 닿았을 때 collector 내부에서 무슨 일이 일어나는지는 의외로 흐릿하게 알고 있는 경우가 많다. 나도 처음엔 그랬다. 어느 날 traces 파이프라인이 갑자기 데이터를 흘리기 시작해서 메트릭을 파보다가, 그때서야 batch와 queue, retry가 메모리 한계 앞에서 어떻게 상호작용하는지 본격적으로 파악하게 됐다.이 글은 그 흐름을 정리한 노트다. 2026년 2월 즈음 oneuptime이나 dash0 쪽에서 모범 사례 가이드가 다시 한번 정리됐는데,..

지지난 주에 우리 팀이 운영하는 결제 도메인 클러스터에서 Vault 토큰 관련 알람이 30분 가까이 폭주했다. P99 레이턴시도 같이 튀었고, 무엇보다 새벽 2시였다. 결론부터 말하면 Vault Agent injector가 만든 sidecar가 init 컨테이너가 이미 받아둔 토큰을 재사용한다고 믿고 있었는데, 실제로는 그렇지 않아서 매번 다시 인증을 시도하다가 Vault 서버 쪽 rate limit에 걸린 사건이었다.좀 더 풀어서 적어둔다. 같은 함정 밟는 분 있을지도 모르니까.어떻게 발견했는가알람은 단순했다. vault-agent 컨테이너에서 permission denied와 429 too many requests가 번갈아 찍히고 있었다. 처음에는 정책(vault policy) 문제인가 싶었다. 그런..

오늘 알게 된 건데, 의외로 모르는 분 꽤 있더라. kubectl 1.33부터 들어온 .kuberc 얘기.팀 단위로 kubeconfig를 공유해 본 사람은 다 한 번씩 짜증 났을 거다. 누군가 current-context를 prod로 바꿔놓고 그대로 푸시한 다음, 다른 사람이 dev에서 작업하다 prod 클러스터에 명령 날리는 그런 사고. 또 한 명은 alias k=kubectl을 셸에 박아두고, 다른 한 명은 kubectl get po -o wide를 매일 손가락으로 치고 있고. 개인 취향과 공용 자격증명이 같은 파일에 섞여 있는 게 문제다..kuberc(아직 alpha) 가 그 부분을 분리해 준다. ~/.kube/config에는 클러스터/사용자/컨텍스트만 두고, 내 개인 alias나 기본 플래그는 ~..

Access Key를 GitHub Secrets에 박아두는 거, 이제 진짜 그만할 때가 됐다. 우리 팀도 작년에 한 번 키가 외부로 새서 식겁한 적이 있는데, 그 사건 이후로 모든 리포지토리를 OIDC로 옮겼다. 사실 옮기는 작업 자체가 어렵진 않다. 어려운 건 신뢰 정책(trust policy)을 너무 느슨하게 잡거나, 반대로 너무 빡빡하게 잡아서 워크플로우가 자꾸 깨지는 거다.이번 글에선 GitHub Actions의 OIDC 토큰으로 AWS IAM Role을 assume하는 과정을 실전 기준으로 정리한다. 처음 세팅하는 사람도 따라할 수 있게 단계별로 적었다.왜 OIDC인가장기 credential(Access Key/Secret Key)을 Secrets에 저장하면 두 가지가 걸린다. 하나는 키가 유출..

Terraform 1.10에서 use_lockfile = true 옵션이 추가됐고, 1.11에 와서는 experimental 딱지가 떨어졌다. DynamoDB 테이블 없이 S3만으로 state lock을 거는 기능이다.처음 봤을 때 솔직히 좀 의심스러웠다. lock 메커니즘이라는 게 결국 "동시에 한 명만 쓰게" 만드는 건데, S3는 object storage고 트랜잭션 같은 게 없는데 어떻게? 그리고 DynamoDB는 강한 일관성(strong consistency)을 보장하는 KV store니까 lock 용도로 충분히 합리적이었다. 굳이 S3로 갈아탈 이유가 있나 싶었다.근데 마이그레이션을 준비하면서 내부를 까보니, 생각보다 깔끔하게 잘 만들어둔 구조였다. 단순히 "DynamoDB를 안 써도 된다"는 ..

들어가며3년 전쯤만 해도 "CNI는 그냥 Calico 깔자"가 답이었다. 안정적이고 자료 많고 문제 생기면 iptables 룰 뜯어보면 됐다. 그런데 최근 1년 사이에 분위기가 좀 바뀌었다. GKE Dataplane V2가 Cilium 기반이고, AKS도 "Azure CNI Powered by Cilium"을 권장 옵션으로 밀고 있다. EKS는 기본은 여전히 AWS VPC CNI지만 Cilium을 얹는 사례가 눈에 띄게 늘었다.우리 팀도 작년 하반기에 새 클러스터 두 개를 띄우면서 Cilium으로 갈아탔다. 기존 클러스터는 Calico를 계속 쓰고 있어서, 1년 정도 두 개를 같이 운영하면서 느낀 걸 정리해본다. 결론부터 말하면 "신규는 Cilium, 기존은 굳이 안 옮긴다"이긴 한데, 이게 모든 팀에 ..

오늘 알게 된 건데, 의외로 모르는 분 꽤 많더라. Pod의 graceful shutdown 늘리려고 PreStop hook에 sleep 박는 그 패턴 말이다. 우리도 한참 그렇게 썼는데, 사실 1.29부터는 그럴 필요가 없어졌다.기존 방식의 함정전형적인 zero-downtime 배포 트릭이다. Service에서 endpoint가 빠지는 동안에도 잠깐 트래픽이 계속 들어오니까, SIGTERM 받기 전에 몇 초 버텨주자는 거다.lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 10"]근데 이거 distroless 이미지 쓰는 순간 깨진다. sh도 없고 sleep도 없으니까. 우리 팀은 작년에 보안팀이 모든 이미지를 distroless..

지난주 화요일 새벽 3시 12분. 폰이 진동했다. PagerDuty다.알림 내용은 단순했다. "checkout-api 50x error rate spike". 처음에는 트래픽 이슈인가 싶었는데, 그래프를 열어보니 패턴이 이상했다. 트래픽은 평소 새벽 수준 그대로인데 5xx만 튀고 있었다. P99 레이턴시도 2초를 넘기고 있었다.결론부터 말하면 Karpenter consolidation 정책을 잘못 건드린 게 원인이었다. WhenEmptyOrUnderutilized를 그대로 두고 consolidateAfter를 30초로 줄였더니, 새벽 트래픽이 잠깐 빠질 때마다 노드가 통째로 갈리면서 stateful한 워크로드들이 같이 흔들렸다.우리가 뭘 바꿨길래며칠 전에 비용 최적화 한답시고 NodePool 설정을 손봤..