day-log

지난주에 우리 팀 OpenTelemetry Collector 파드들이 갑자기 OOMKill 잔치를 벌였다. 평소 워킹셋이 1.2GB 정도였는데, 어느 날 새벽부터 4GB까지 치솟더니 limit(6GB)을 넘기고 죽기 시작했다. 트래픽이 갑자기 늘어난 것도 아니고 설정을 건드린 것도 아니었다. 그라파나 패널 보면서 "아 이거 또 시작이네" 싶었다.결론부터 말하자면 batch processor의 send_batch_size를 잘못 키운 게 시작이었고, 거기에 exporter queue가 백프레셔를 못 받아주면서 메모리가 무한정 쌓였다. 글 안에 다 풀어쓰겠지만, 비슷한 증상 보시는 분들은 일단 memory_limiter부터 위에 끼워두시는 걸 권한다.증상 — 처음 3시간 동안 본 것오전 5시 23분에 첫 페..

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