day-log

지난 화요일 새벽 3시쯤이었다. 알람이 울렸다. P99 latency가 400ms를 넘겼다는 알림. 자다 깨서 노트북을 열었을 때 제일 먼저 든 생각은 "또 뭐가 문제냐"였다.우리 EKS 클러스터는 노드 40대 정도 되고, 트래픽이 특별히 튀지도 않았다. Grafana에서 애플리케이션 CPU도 여유롭고, DB 지표도 정상. 근데 왜 느려졌지? 한참 파고 나서야 원인이 나왔다. DNS였다. CoreDNS 파드는 CPU 20%도 안 쓰고 있는데 DNS 응답이 느렸다. 좀 어이가 없었다.처음엔 CoreDNS 스케일업을 의심했다당연히 첫 반응은 "CoreDNS 파드 수 늘려야겠다"였다. 그런데 grafana를 보니 CoreDNS 자체는 문제가 없었다. coredns_dns_request_duration_seco..

배경: 기본 동작이 왜 종종 실무에 안 맞는가오늘 다룰 건 하나다. HorizontalPodAutoscaler(HPA) behavior 필드. 이거 모르는 사람 의외로 많아서 짧게 정리해둔다.우리 팀 클러스터에서는 오전 10시부터 트래픽이 슬금슬금 올라오는 서비스가 하나 있다. 점심 직후에 잠깐 훅 떨어졌다가 오후에 다시 올라온다. 그런데 HPA를 별다른 설정 없이 켜두면 12시 30분쯤 replica가 4→2로 급격히 떨어졌다가, 13시가 되면 또 CPU가 튀면서 부랴부랴 다시 올린다. 이게 하루에 두세 번씩 반복되니 pod 재기동이 잦아지고 P99가 흔들린다.원인은 기본 stabilization window. 지금 HPA v2 기본값은 scaleDown이 300초, scaleUp이 0초다. 5분짜리 ..

Kafka consumer를 K8s에서 돌리다 보면 결국 한 번은 마주치는 질문이 있다. "왜 lag이 쌓이는데 파드는 안 늘어나지?" HPA에 CPU 기준 스케일링을 걸어봐야 소용없다. consumer는 대부분 I/O bound라 lag이 폭증해도 CPU는 40%대에서 안정적일 수 있다.이 글은 KEDA(Kubernetes Event-Driven Autoscaler)를 실제 운영 환경에 붙일 때 알아야 할 것들을 정리한 가이드다. 공식 문서에 잘 나온 기본 설치법이 아니라, 실무에서 자주 밟는 함정 중심으로 썼다. KEDA 2.15 기준.HPA 대신 KEDA를 쓰는 이유기본 HPA는 CPU/메모리, 그리고 custom metrics API를 통한 임의 지표까지 지원한다. 그럼 왜 굳이 KEDA를 별도로..

오늘 사내 채널에서 후배가 "distroless 컨테이너 파드 안에서 tcpdump 뜨고 싶은데 어떻게 해요?" 라고 물어봐서 답해주다가, 생각보다 kubectl debug --profile 옵션을 모르는 사람이 많다는 걸 알았다. 나도 예전엔 급하면 그냥 securityContext.privileged: true 넣은 사이드카 파드 하나 붙여서 디버깅했는데, 지금은 그럴 필요가 없다.프로필이 뭘 해주냐면kubectl debug로 ephemeral container를 붙일 때 --profile 플래그 하나로 필요한 capability 조합을 미리 세팅해준다. 손으로 securityContext YAML을 쓰지 않아도 된다는 얘기다. 현재 지원되는 프로필은 다섯 개다.general — 일반적인 디버깅용 기..

cert-manager 무한 재발급 루프에 걸린 새벽 이야기새벽 3시. 폰이 울린다. 프로덕션 클러스터의 API 게이트웨이 인증서가 만료 2시간 전이라는 알림. 이상하다. cert-manager가 알아서 갱신했어야 정상인데. 눈을 비비면서 노트북을 열었다.처음엔 그냥 일시적인 문제인 줄 알았다kubectl get certificates -A 를 쳐봤다. Ready=False. kubectl describe로 이벤트를 보니 CertificateRequest가 계속 생성되고, 몇 초 뒤에 다시 실패하고, 또 다시 만들고... 초당 한 개꼴로 새 CR이 찍히고 있었다.$ kubectl get certificaterequests -n gateway | wc -l 38473847개. 헛웃음이 나왔다. 이 ..

정책 엔진 이야기다. 두 달 전쯤 팀 내부에서 Kyverno로 다 밀어붙이던 policy를 재정비하기로 했다. 계기는 별거 아니다. 신규 클러스터를 하나 더 세팅하는데 Kyverno controller 파드가 죽었다는 알람이 새벽에 두 번 울렸고, 새벽에 눈 뜬 내가 생각했다. "이거, 정말 다 Kyverno여야 되나."Kubernetes 1.30에서 ValidatingAdmissionPolicy(이하 VAP)가 GA된 게 2024년 4월이다. 지금은 2026년 중반이니 GA된 지 2년이 넘었고, EKS든 GKE든 안정 채널에서 이미 쓸 수 있는 상태다. CEL 기반이라 API 서버 안에서 바로 평가되고, 웹훅이 없다. 이 두 가지가 결국 우리 결정의 핵심이 됐다.Kyverno 하나로 밀어붙였을 때의 문..

처음엔 KEDA 버그를 의심했다지난 금요일 오후, 대시보드를 열었다가 눈을 의심했다. SQS 큐 depth는 0인데 워커 파드가 40대씩 떠 있었다. minReplicaCount 는 2로 잡아뒀는데 왜 안 내려가지?KEDA를 SQS와 붙여 쓰는 팀이라면 한 번쯤 겪는 함정인 것 같아 정리해둔다.우리 팀은 이미지 후처리 워커를 EKS에서 KEDA로 굴린다. SQS 큐 depth 기반으로 스케일 아웃/인 시키는 흔한 구조다. 큐가 비면 minReplicaCount인 2대까지 내려가야 하는데, 그날은 40대에서 요지부동이었다. kubectl describe scaledobject를 찍어보니 metricValue가 계속 큰 값으로 나왔다.근데 SQS 콘솔에서 큐 depth는 진짜 0이다. Approximate ..

크로스존 트래픽 비용 청구서를 보고 눈을 의심한 적이 있다. AZ 세 개에 노드가 흩어져 있는 EKS 클러스터에서, 결제 API가 유저 서비스를 호출하는데 세 번에 한 번은 다른 AZ로 넘어간다. NAT는 아니지만 AZ 간 트래픽은 GB당 $0.01. 요청 하나로는 티끌인데 P99 QPS로 곱해보면 월 결제서에 꽤 나온다.Kubernetes 1.34에서 Service의 spec.trafficDistribution에 PreferSameNode가 GA로 붙었다. 원래 있던 PreferClose(구 PreferSameZone)에 이어서 나온건데, 같은 노드에 엔드포인트가 있으면 무조건 거기로 보낸다. 없을 때만 외부로 나간다. 아주 간단한데 효과가 크다.어떻게 쓰나apiVersion: v1kind: Servi..

Karpenter를 도입하고 Spot으로 전환하면 비용은 30~70% 아낀다. 근데 이걸 유지하는 게 진짜 문제다. 우리 팀에서도 초반에 몇 번 겪었다. 어느 날 갑자기 특정 Availability Zone에서 c6i.4xlarge만 골라서 반복적으로 회수(termination) 되는데, 노드가 뜨자마자 5분도 안 돼서 다시 죽는 상황이 이어졌다.원인은 결국 하나였다. NodePool 정의가 너무 좁게 잡혀 있었다. Karpenter가 아무리 똑똑해도 선택할 수 있는 Spot capacity pool 자체가 몇 개 없으면 대체할 수단이 없다. 최근 AWS 문서에서도 Spot-to-Spot consolidation을 사용하려면 최소 15개 이상의 인스턴스 타입을 허용해야 한다고 명시하고 있는데, 이게 그냥..

오늘 알게 된 건 아니고, 얼마 전부터 팀 내부에서 오토스케일링 튜닝하다가 정리한 팁이다. 근데 이거 모르는 분들이 의외로 꽤 있어서 짧게 남긴다.HPA behavior 필드는 v2에서 나온 뒤로 GA 된 지가 좀 됐는데, 아직도 기본값 그대로 쓰는 팀이 많더라. 그 중에서도 stabilizationWindowSeconds가 특히 문제다.뭐가 문제였냐면트래픽이 규칙적으로 확 튀었다가 3-4분 안에 원상복구되는 서비스가 하나 있다. 이벤트 배너 서비스인데, CPU가 순간 60%까지 튀고 30초쯤 지나면 20% 아래로 떨어진다.HPA 기본 설정으로 놔뒀더니 이런 흐름이 반복됐다:트래픽 스파이크 → 5개 → 12개로 스케일 업30초 뒤 트래픽 원상복구5분 뒤 (기본 downscale stabilization ..