day-log

NetworkPolicy를 처음 도입할 때 가장 답답한 게 뭐냐고 물으면, 나는 망설임 없이 "왜 막혔는지 모르겠다"고 답한다. kubectl logs를 봐도 connection timeout만 보이고, 정작 어느 정책이 그 트래픽을 끊었는지는 알려주지 않는다. 예전엔 cilium monitor를 노드 단위로 띄워서 한참을 들여다봤는데, Hubble이 들어오고 나서는 이 과정이 꽤 깔끔해졌다.이 글은 Cilium 1.19.x 환경에서 Hubble을 가지고 네트워크 정책을 디버깅하는 워크플로우를 정리한 거다. 우리 팀에서 정책을 새로 추가할 때마다 반복적으로 쓰는 절차이고, 신규 입사자한테도 이 순서대로 보여준다.Hubble flow를 보기 전에 확인할 것먼저 Hubble이 활성화돼 있어야 한다. 의외로 ..

들어가며OOMKill은 K8s 운영하면서 가장 자주 마주치는 종류의 죽음 중 하나다. 그런데 막상 "왜 죽었냐"고 물으면 Last State: OOMKilled 로그 한 줄 외엔 잘 못 말하는 경우가 많다. 사실 나도 그랬다. 우리 팀 내부 논의에서 "메모리 limit 부족이지" 정도로 넘기던 게 한 90% 였고, 정작 그 직전 kernel과 kubelet이 어떤 신호를 주고 받았는지는 들여다본 적이 별로 없었다.이번 글에서는 cgroup v2 환경에서 Pod의 메모리가 limit 근처까지 차오를 때 노드 안에서 어떤 흐름이 도는지를 정리한다. K8s 1.28부터 cgroup v2 동작이 한 단계 정리됐고, 1.34에서 PSI 메트릭이 Beta로 올라오면서 이 영역의 운영 가시성이 꽤 좋아진 시점이다.m..

지난달에 SQS 기반 워커 파드를 KEDA로 옮겼다. HPA의 CPU 메트릭만으로는 큐가 쌓일 때 늦게 반응하는 게 계속 거슬려서, 큐 길이로 직접 스케일하는 게 자연스러워 보였다. KEDA는 2.19가 최근에 떨어졌고(2026-02), SQS scaler에 scaleOnDelayed 같은 옵션도 정리돼 있어서 큰 고민 없이 시작했는데, 정작 일주일 동안 새벽에 두 번 호출되고 나서야 정신을 차렸다. 그 과정 정리.시작은 정상이었다워크로드는 단순하다. 외부 이벤트 → SQS → 워커 파드(Go 단일 바이너리)가 메시지 하나씩 받아 처리. 평소엔 큐가 비어 있고, 1시간 단위로 큐가 수만 건씩 쌓이는 burst 패턴이다. 한 메시지 처리에 평균 2초, P99 8초.처음 달았던 ScaledObject는 거의..

오늘 알게 된 건 아니고, 최근에 팀원이 Karpenter 설정 PR을 올렸길래 리뷰하다가 "어 이게 v1.0부터 바뀌었는데 모르는 분들 꽤 많겠네" 싶어서 짧게 정리해둔다.WhenUnderutilized 라는 이름은 이제 없다Karpenter 1.0 GA 이후로 WhenUnderutilized는 WhenEmptyOrUnderutilized로 이름이 바뀌었다. 옛날 블로그 글이나 사내 위키 보고 그대로 복붙하면 NodePool apply가 깨진다. 지난주에 1.12.0이 나왔는데도 검색하면 아직 옛날 이름이 상위에 뜨더라.그리고 더 중요한 변화 — 1.0부터는 consolidateAfter를 WhenEmptyOrUnderutilized에서도 쓸 수 있다. 이전에는 WhenEmpty에서만 동작해서, "노드..

지난달에 결국 Karpenter로 갈아탔다. 팀에서 반년 넘게 "다음 분기에 해야지" 하며 미뤄왔던 숙제였는데, 예상대로 쉽지 않았다. 이 글은 자랑이 아니라 그냥 기록이다. 비슷한 고민 하는 분들에게 조금이라도 도움이 됐으면 해서 적는다.Karpenter가 v1.0 GA 찍은 지도 벌써 한참 됐고, 최근에는 OCI provider까지 GA 나오면서 더 이상 "AWS 전용 실험 프로젝트" 소리는 못 듣는 상황이다. 그래도 막상 프로덕션에 올려보면 문서에 안 나오는 함정이 꽤 있다.왜 옮겼나솔직히 Cluster Autoscaler(CAS)가 못 쓸 물건은 아니다. 노드 18대 규모에서 몇 년을 잘 돌았다. 문제는 배치 잡 비중이 커지면서부터였다.우리 팀은 데이터 파이프라인 일부가 Kubernetes Job..

운영 환경에서 Pod가 CrashLoopBackOff에 빠지거나, 네트워크 연결이 안 되거나, 파일시스템 상태를 확인해야 할 때가 있습니다. 문제는 대부분의 프로덕션 컨테이너 이미지에는 curl, dig, netstat 같은 디버깅 도구가 없다는 것입니다.distroless 이미지나 최소화된 Alpine 기반 이미지를 사용하면 보안과 이미지 크기 면에서 이점이 있지만, 장애 상황에서 원인을 파악하기가 까다로워집니다. kubectl debug는 이런 상황을 위해 만들어진 도구입니다.이 글에서는 kubectl debug의 세 가지 모드를 실전 예제와 함께 살펴보겠습니다.Ephemeral Container로 실행 중인 Pod 디버깅가장 많이 쓰이는 패턴입니다. 실행 중인 Pod에 임시 컨테이너(Ephemera..

들어가며Kubernetes 클러스터를 운영하다 보면 가장 자주 마주치는 에러 중 하나가 바로 CrashLoopBackOff입니다. Pod가 시작되자마자 죽고, 다시 시작되고, 또 죽는 무한 루프에 빠진 상태죠. 특히 새벽에 알림이 울릴 때 이 상태를 보면 심장이 철렁합니다.문제는 CrashLoopBackOff 자체가 원인이 아니라 증상이라는 점입니다. 실제 원인은 OOMKilled, 설정 오류, 의존성 실패 등 다양합니다. 오늘은 실무에서 이 상태를 체계적으로 진단하고 해결하는 방법을 정리합니다.CrashLoopBackOff란?Kubernetes는 컨테이너가 비정상 종료되면 restartPolicy에 따라 자동으로 재시작합니다. 그런데 컨테이너가 반복적으로 실패하면 kubelet은 재시작 간격을 점점 늘..