day-log

큐가 갑자기 쌓일 때 HPA(CPU 기반)는 거의 도움이 안 된다. 워커 파드의 CPU는 정작 한가한데 메시지는 계속 쌓이는 상황, 한 번쯤 겪어봤을 것이다. 이런 경우엔 큐 길이 자체를 메트릭으로 써야 한다. KEDA가 그걸 표준화해준다.이 글은 RabbitMQ 컨슈머를 KEDA로 스케일링할 때 실제로 챙겨야 하는 설정들을 정리한 가이드다. KEDA 2.17 기준이고, 운영하면서 한 번씩 발 걸렸던 항목 위주로 적었다.왜 HPA만으로는 부족한가전형적인 큐 워커는 메시지 하나 처리에 I/O 대기가 많다. 외부 API 콜, DB 조회, S3 업로드 같은 것들. 이런 워커는 CPU가 30%만 찍혀도 큐는 만 건씩 쌓일 수 있다. CPU 50%를 임계로 HPA를 걸어두면 영원히 안 늘어난다.큐 길이를 직접 보..

작년 이맘때쯤 progressive delivery를 본격적으로 도입하기로 결정했다. 그 때만 해도 우리 팀은 "둘 다 비슷한 거 아니야?"라는 분위기였고, 사실 데모만 보면 정말 비슷해 보였다. 캐너리, 블루그린, 메트릭 기반 자동 promotion. 똑같은 단어들이 양쪽 문서에 다 나온다.그래서 우리는 좀 무책임한 결정을 했다. 둘 다 써보기로 했다. 일부 서비스는 Flagger, 일부는 Argo Rollouts. 1년이 지난 지금, 한쪽으로 통일하기로 했고, 그 과정에서 알게 된 차이들을 정리해 본다.시작 환경우리 환경을 먼저 짧게 적는다. 비교는 결국 환경 의존적이라서.EKS 1.32 클러스터 두 대 (스테이지/프로덕션)서비스 메시는 Istio (ambient 아니고 sidecar)GitOps는 ..

ArgoCD ApplicationSet으로 12개 클러스터 한 번에 날린 이야기지난 금요일 저녁이었다. 정확히는 금요일 저녁 8시 47분. 슬랙이 한 번에 12번 울렸다. PagerDuty도 같이 울렸다. 12개 리전 prod 클러스터의 핵심 워크로드가 동시에 CrashLoopBackOff에 빠진 거였다.원인은 단순했다. ArgoCD ApplicationSet의 matrix generator에 새 컨테이너 이미지 tag를 commit했고, 그게 모든 클러스터에 동시에 sync된 거다. 캐너리도 없고, 단계적 롤아웃도 없었다. 그냥 한 방에 전부.이 글은 그날 밤 11시 40분까지 이어진 복구 과정과, 그 후에 progressive sync를 도입하면서 배운 것들에 대한 회고다.우리가 어쩌다 12개를 한 ..

Distroless 이미지는 좋다. CVE 스캔 결과가 깨끗하고, attack surface가 작고, 이미지 크기도 작다. 그런데 사고가 났을 때가 문제다. sh도 없고 curl도 없고 ls도 없다. 컨테이너 안에 들어가서 뭔가 보고 싶어도 들어갈 수단 자체가 없는 셈이다.kubectl debug 한 줄이면 끝나는 일이긴 하다. -it --image=nicolaka/netshoot --target=app. 이렇게 치면 netshoot 컨테이너가 붙고, ps도 보이고, tcpdump도 된다. 신기하다. 분명히 distroless 컨테이너 안에는 셸이 없는데 어떻게 그 컨테이너의 프로세스를 들여다보고 있는 걸까. 이게 사실 처음 봤을 때 좀 헷갈렸다. 그래서 한번 파봤다.표면적으로는 pod.spec.ephe..

작년 이맘때쯤 우리 팀은 Prometheus 단일 인스턴스로 버티는 게 한계에 다다랐다. 노드 800대, 활성 시리즈 3천만개를 넘기면서 메모리는 80GB를 넘어가고, 재시작 시 WAL 리플레이에 20분이 걸렸다. 장기 저장도 필요했다. 그래서 VictoriaMetrics 클러스터와 Grafana Mimir 두 개를 PoC로 띄워서 6개월씩 돌려봤고, 결국 메인을 VictoriaMetrics로 갔다. 이 글은 그 1년치 의사결정 기록이다.근데 미리 말해두면, 이건 "VM이 무조건 좋다"는 글이 아니다. 우리 팀 상황에 VM이 맞았던 거지, 다른 팀은 Mimir가 더 나을 수 있다. 그 경계가 어디인지 정리해보려고 한다.리소스 사용량 차이가 진짜였다벤치마크 자료들이 "VM이 메모리 5배 효율"이라고 떠드는..

내부 보안팀에서 "프로덕션 클러스터에 서명 안 된 이미지 못 들어오게 하자"는 얘기가 나온 지 한참 됐다. 우리 팀은 GitHub Actions로 빌드한 이미지를 ECR에 푸시하고 있었고, Cosign keyless 서명 자체는 이미 파이프라인에 붙여둔 상태였다. 문제는 검증. 클러스터 어드미션에서 막는 부분이 없었다.Kyverno ImageValidatingPolicy(IVP)로 정리한 결과를 적어둔다. 1.13에서 들어온 새 정책 타입인데, 기존 ClusterPolicy의 verifyImages 룰보다 모듈화가 잘 돼 있어서 운영하기 편하다.전제: Cosign keyless 서명이 무엇을 보장하나Keyless는 키 파일을 보관하지 않는다. 대신 Sigstore Fulcio가 OIDC ID(예: Git..

지난 화요일 새벽이었다. 4시 12분에 휴대폰이 부르르 울렸다. PagerDuty.vault-prod cluster: all nodes sealed침대에서 일어나면서 머릿속이 멍했다. 보통 vault가 sealed 상태로 돌아가는 일은 없다. unseal key는 사람이 들고 있지도 않다 — auto-unseal로 AWS KMS에 위임해놨으니까. 그런데 sealed라니. 노트북을 열면서 솔직히 멘탈이 좀 나갔다.첫 30분: 뭐가 죽었는지조차 몰랐다처음엔 vault 자체 이슈인 줄 알았다. 컨테이너가 OOM이라도 났나 싶어서 노드부터 확인했다. CPU도 메모리도 멀쩡했다. Pod도 다 running이었고. 그런데 vault status를 때려보면 매번 같은 응답이 돌아왔다.Sealed: trueTotal ..

한 줄 요약cert-manager 1.17부터 ACME challenge authorization timeout이 1분 → 2분으로 늘었다. 그동안 가끔씩 사라지던 그 timeout, 1.17 올리면 꽤 줄어든다.어떤 상황에서 만났나우리 팀 클러스터 중 하나가 EKS이고, NLB 뒤에 ingress-nginx, 그 뒤에 cert-manager로 Let's Encrypt 인증서를 발급받는 흔한 구성이다. 그런데 한 달에 한두 번 정도 갱신 시점에 이런 로그가 떴다.Failed to wait for order resource to become ready: order is in "errored" state:Failed to wait for authorization: context deadline exceede..

올해 KubeCon EU에서 가장 많이 들었던 단어 중 하나가 ambient mode였다. 사이드카 없이 mesh를 한다는 컨셉은 매력적이지만, "사이드카가 사라진 자리에서 트래픽은 도대체 어떤 경로를 타는가?"가 제대로 그려지지 않으면 운영이 어렵다. 우리 팀도 4월부터 스테이징 클러스터에 ambient mode를 깔고 한 달 넘게 트래픽 흐름을 들여다봤는데, 사실 내부적으로는 생각보다 단순하지 않다.이 글은 그 한 달 동안 tcpdump와 ztunnel 로그를 번갈아 보면서 정리한 내용이다. 1.24 기준이고, 일부는 1.25-rc 노트도 섞여 있다.ztunnel이 뜨는 순간 노드에서 일어나는 일ambient를 활성화하면 DaemonSet으로 ztunnel이 노드마다 한 개씩 깔린다. 그런데 ztun..