day-log

cgroup v2 전환 후 OOMKill 동작이 바뀐 이유올해 초 우리 팀 클러스터를 EKS 1.28에서 1.30으로 올리면서 cgroup v2 노드 비율이 100%가 됐다. 그 직후부터 묘하게 신경 쓰이는 현상이 생겼다. 예전 같으면 사이드카 하나만 OOM으로 죽고 메인 컨테이너는 살아 있던 케이스가, 이제는 컨테이너 안의 모든 프로세스가 한꺼번에 같이 죽고 있었다. 처음에는 "그래, 이게 더 깔끔하긴 한데" 정도로 넘겼는데, 일부 멀티 프로세스 워크로드가 갑자기 불안정해지는 걸 보고 한참을 파봤다. 결론부터 말하면 이건 버그가 아니라 의도된 변경이고, 알고 쓰면 오히려 운영이 단순해진다. 다만 모르고 쓰면 황당한 장애를 만난다.이 글은 그 동작이 왜, 어디서, 어떻게 바뀌었는지를 cgroup, kub..

Pod resize, kubelet은 사실 어떻게 하는가 — 1.35 GA 내부 동작작년 12월 1.35에서 in-place pod resize가 드디어 GA로 올라왔다. 1.27 알파(2023년 봄), 1.33 베타(2025년 봄)를 거쳐 약 2년 반 만이다. 베타 시점부터 우리 팀 일부 워크로드에 켜놨고, GA 이후엔 좀 더 적극적으로 쓰고 있다. 그런데 운영하다 보면 "왜 이건 resize가 한 번에 안 되지?", "왜 어떤 컨테이너는 restart 되고 어떤 건 안 되지?" 같은 질문이 자꾸 나온다.사실 내부적으로는 kubelet이 꽤 복잡한 상태 머신을 돌리고 있다. KEP-1287과 1.33/1.35 GA 변경분을 같이 읽어보면 그림이 좀 잡힌다. 이 글에서는 kubelet → CRI → 컨테..

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