day-log

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

Karpenter 얘기는 이제 새롭지 않다. AWS re:Invent 때마다 나오고, 트위터에서도 마이그레이션 후기가 쏟아진다. 얼마 전 Salesforce가 1,000개 넘는 EKS 클러스터를 Karpenter로 옮겼다는 소식도 있었고. 그런데 우리 팀은 좀 늦게 결정한 편이다. 작년에 Cluster Autoscaler(이하 CA)에서 Karpenter로 넘겼고, 반년 정도 운영해봤다. 결론부터 말하면 이득은 있었다. 다만 처음 예상했던 이유들과는 조금 달랐다.왜 넘어갔나원래 이유는 명확했다. 노드 스케일링이 느리다. CA는 ASG 기반이라 unschedulable 파드가 생기면 → CA가 감지 → ASG desired capacity 조정 → EC2 프로비저닝 → kubelet join. 이 사이클이..

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를 별도로..

resources.limits.memory: 512Mi 한 줄. 이게 사실 얼마나 복잡한 일을 시키는 건지, 최근에 팀 내부에서 OOM 관련 장애를 하나 겪고 나서야 제대로 파봤다. 대충 "커널이 알아서 죽여준다" 수준으로만 알고 있었는데, cgroup v2로 넘어오면서 동작이 꽤 달라졌다는 걸 그제서야 알았다.이 글은 그때 정리한 노트에 가깝다. Kubernetes에서 메모리 limit이 실제로 커널까지 내려가서 어떤 파일에 어떤 값이 쓰이고, OOM이 터질 때 어떤 순서로 뭐가 일어나는지 — 이게 왜 최근 몇 년 사이 근본적으로 바뀌었는지 순서대로 짚어본다.메모리 limit이 커널로 내려가는 경로파드 매니페스트에 limits.memory: 512Mi를 적었다고 하자. 이 값은 kubelet → CRI..

지난 목요일 새벽 두 시. 슬랙에 "prod 배포 30분째 안 끝나요"라는 메시지가 올라왔다. 나는 이미 자고 있었고, 폰 진동에 눈이 번쩍 떠졌다. 노트북을 열어보니 ArgoCD 대시보드가 애매한 상태였다. Application은 Syncing 인데 진행률은 그대로. 사실상 멈춰 있었다.이 글은 그날 새벽에 뭘 삽질했고, 왜 그런 일이 벌어졌는지에 대한 회고다. 결론부터 말하면 sync wave 하나가 조용히 우리 파이프라인을 인질로 잡고 있었다. 최근 ArgoCD 공식 문서와 오퍼레이션 노트를 다시 정리하다 보니 이 삽질담을 남기는 게 낫겠다 싶었다.상황: 어디가 막혔는지도 모르겠다우리 팀은 프로덕션 배포를 GitOps로 굴린다. Argo CD가 이십 몇 개 애플리케이션을 관리하고 있고, 그중 하나가..

오늘 사내 채널에서 후배가 "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 ..

Deployment를 Rollout으로 마이그레이션배포할 때마다 심박수가 올라가는 사람 있으면 손. 나만 그런 거 아닐 거다. 특히 트래픽이 몰리는 시간대에 롤아웃 눌러야 할 때는 정말 부담이다. Deployment의 기본 RollingUpdate 전략이 나쁜 건 아닌데, 문제는 "일단 다 밀리고 나면 되돌리기가 귀찮다"는 점이다. HPA에 물려 있는 상황에서 새 버전이 죽으면 롤백 중에도 오토스케일이 계속 돌아서 상황이 더 꼬인다.그래서 우리 팀은 몇 달 전부터 Argo Rollouts를 도입해서 카나리 배포로 옮기고 있다. 이 글은 도입 과정에서 배운 것과, "이건 처음에 알았으면 좋았을 텐데" 싶은 것들을 정리한 실무 가이드다.이달 말에 열리는 ArgoCon Japan 2026 세션 리스트를 훑어보..