day-log

배포 자동화는 다들 잘 해놨는데, 정작 "이 배포 잘 된 거 맞아?"를 판단하는 건 사람이 대시보드 보고 있다. 우리도 그랬다. 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..

지난주 화요일 새벽 2시 40분. 전화 진동이 침대 옆에서 부르르 떨었다. 결제 서비스 일부 Pod가 CrashLoopBackOff에 걸려서 P0 알람이 떴다는 PagerDuty. 졸린 눈으로 노트북을 열었는데, 보자마자 머리가 띵해졌다. 어제 낮에 내가 mutating webhook 설정 하나를 손댄 게 떠올라서.이 글은 그날 새벽 한 시간 동안 뭘 했는지에 대한 회고다. Vault Agent Injector를 쓰는 팀이면 한 번쯤은 밟을만한 지뢰라 기록을 남긴다.상황: agent-inject-secret 어노테이션이 사라졌다우리 팀은 1년 정도 Vault Agent Injector 1.4.x로 DB 자격증명을 주입해왔다. 패턴은 흔하다.metadata: annotations: vault.has..

요즘 운영하는 클러스터에서 메트릭 카디널리티가 슬슬 부담스러워졌다. http_request_duration_seconds 하나만 봐도 le 버킷이 12개씩 붙고, 거기에 method/status/route 라벨까지 곱해지면 한 서비스가 5만 series를 우습게 넘긴다. 그래서 작년부터 native histogram 으로 옮기는 작업을 조금씩 해왔는데, v3.8 부터 stable 표기가 붙으면서 본격적으로 손을 댔다.이번 글은 "어떻게 켜는지"가 아니라 "왜 이게 그렇게 효율적인지"에 대한 이야기다. 사실 내부 구조를 모르고 켜면 ingester 메모리만 튀어서 한참 헤매게 된다.classic histogram 의 비효율은 어디서 오는가classic histogram 은 도구라기보다 관행에 가깝다. le..

왜 옮겼나지난주 얘기다. 우리 팀 서비스 메시를 Istio sidecar mode에서 ambient mode로 옮기다가, 새벽 2시에 사내 메신저가 폭주했다. 일주일 정도 마이그레이션 준비를 한 줄 알았는데, 사실은 그때부터가 진짜 시작이었다.이번 KubeCon Europe 2026(암스테르담)에서 Ambient Multicluster Beta가 발표된 걸 보고 팀에서 좀 들떴다. 우리는 클러스터가 4개라 진작에 ambient를 보고 있었는데, 멀티클러스터까지 시야에 들어오니 "지금 single cluster부터 옮겨두면 나중에 편하겠다"는 분위기였다. 그래서 진행한 건데, 결론부터 말하면 마이그레이션 자체는 책 그대로 됐다. 문제는 책에 안 나온 부분이었다.직접적인 이유는 메모리였다. 노드당 envoy..

이번 주에 우리 팀 IAM trust policy 점검하다가 좀 놀란 게 있어서 짧게 적어둔다. 이거 모르는 분 꽤 많을 것 같다.익숙한 그 패턴GitHub Actions에서 AWS 붙일 때 OIDC federation 쓰는 건 이제 거의 표준이다. 그런데 trust policy 보다 보면 이런 게 자주 나온다.{ "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:*" } }}좋다, 우리 repo로 한정은 했다. 근데 *이 너무 넓다. PR에서 돌아가는 워크플로우든, 누가 임시로 만든 브랜치에서 돌리는 거든, 환경 보호 없는 워크플로우든 — 전부 이 role을 가..

비교를 시작한 배경작년 말에 Falco vs Tetragon 한 번 정리하면서 런타임 쪽은 어느 정도 정해뒀는데, 정작 더 매일같이 쓰는 "posture/이미지 취약점 스캔" 쪽이 계속 어수선했다. 우리 팀은 한동안 Trivy Operator 단일로 굴렸고, 작년 4분기쯤 Kubescape가 CNCF Incubating에서 한 단계 더 성숙해지면서 한번 다시 들여다볼 만하다는 얘기가 사내에 돌았다. 그래서 두 도구를 운영 환경에 6개월 정도 병행해서 돌려봤다. 결론부터 말하면 "둘 다 쓰긴 쓰는데 역할이 갈렸다"는 거다. 이 글은 그 갈리는 지점이 어디였는지에 대한 기록이다.전제는 이렇다. 클러스터는 EKS 1.31 두 개(prod/stg), 노드 합 60여 대, 워크로드 300개 안팎. 컴플라이언스는 ..

Karpenter NodeOverlay로 GPU spot 가격 흔들림 잡아보다 (alpha 도입 보류한 이야기)지난주에 GPU 학습 워크로드 비용 그래프를 보다가 멘탈이 좀 나갔다. 분명 spot으로 돌리고 있는데 월 비용이 예상의 1.6배. 클러스터에 들어가서 노드 목록을 찍어보니, Karpenter가 골라준 인스턴스 타입이 죄다 g5.12xlarge, g6e.12xlarge 같은 큰 놈들이었다. 우리가 돌리는 잡 사이즈 보면 g5.2xlarge 두세 대면 충분한데.원인을 찾는 데 한참 걸렸다. 결론부터 말하면 Karpenter의 spot 할당 전략 — price-capacity-optimized — 가 큰 인스턴스를 "더 싸다"고 판단한 결과였다. 단위 vCPU당 가격이 큰 인스턴스가 낮긴 한데, 우..

state 파일은 IaC를 운영하는 사람한테 늘 골치 아픈 물건이다. RDS 마스터 패스워드, IAM access key, 가끔은 슬랙 토큰까지, 다 평문으로 박혀있다. S3에 SSE 걸어두면 됐다고 생각했었는데, 작년에 인턴이 실수로 state 파일을 깃에 푸시한 일이 있고 나서 그 마음이 좀 달라졌다. S3 암호화는 결국 S3 안에서만 의미가 있다. 다운로드 받는 순간 끝이다.OpenTofu 1.7에서 state encryption이 GA로 풀린 게 2024년 5월이다. 우리 팀은 그때는 "재밌네" 정도로만 보고 넘겼는데, 1.10 즈음에서 진지하게 검토를 시작했고 결국 올해 초에 도입했다. 그러다 1.11.4의 보안 픽스 노트를 보고 한 번 더 들여다보게 됐다. 이번 글은 도입 과정에서 내가 결국 ..

EKS 클러스터에서 워크로드 권한 부여, 어떻게 바뀌고 있나EKS 클러스터에서 워크로드가 AWS API를 호출할 때 권한을 어떻게 주느냐는 꽤 오래된 주제다. 한참 동안은 IRSA(IAM Roles for Service Accounts)가 사실상의 표준이었는데, 2023년 말에 Pod Identity가 나오고 2024-2025년을 거치면서 AWS도 "신규 워크로드는 Pod Identity 권장"으로 톤이 바뀌었다. 우리 팀도 작년 말부터 클러스터 두 개를 점진적으로 옮겼는데, 그 과정에서 정리한 실무 노트다.IRSA를 완전히 버리는 건 아니다. Fargate는 여전히 IRSA만 지원하고, 어떤 도구들은 아직 Pod Identity 어노테이션 매핑이 어색하다. 그래도 "신규 SA는 Pod Identity,..