◆ SERIES · 5 POSTS

프론트엔드 개발자가 알아야 할 쿠버네티스

SSR을 운영하는 프론트엔드 개발자가 쿠버네티스를 블랙박스로 두지 않기 위해, kind 클러스터에서 직접 열어보고 실측한 기록

README

SSR을 운영하다 보면 배포, 트래픽, 메모리 같은 문제의 절반은 애플리케이션 바깥, 그러니까 쿠버네티스 쪽에서 벌어진다. 그런데 프론트엔드 개발자 입장에서 쿠버네티스는 대체로 남이 만들어 둔 매니페스트를 복사해 쓰는 블랙박스로 남기 쉽다. 이 시리즈는 그 블랙박스를 한 층씩 직접 열어본 기록이다.

각 편은 개념 설명에서 멈추지 않고 kind 클러스터와 실제 Next.js 앱으로 직접 재현하고 측정하는 것을 원칙으로 했다. 이미지 레이어에서 사라진 1.5GB를 역추적하고, ClusterIP라는 어디에도 없는 IP에 curl이 닿는 경로를 iptables 규칙으로 따라가고, 롤링 배포 중 새는 에러를 0으로 만들 때까지 처방을 한 층씩 얹는 식이다.

첫 편이 전체 개념 지도 역할을 하므로, 쿠버네티스가 처음이라면 순서대로 읽는 쪽을 권한다. 특정 문제를 겪고 있다면 해당 편만 읽어도 되도록 각 편을 독립적으로 구성했다.

05 ITEMS

전체 글

in order
01

프론트엔드 개발자를 위한 쿠버네티스 개념 지도: 파드에서 오토스케일러까지

#kubernetes#frontend#nodejs
SSR을 운영하는 프론트엔드 개발자가 마주치는 쿠버네티스 용어와 구조를 실무 흐름 순서로 정리했다. 클러스터의 전체 구조부터 배포, 파드의 상태와 자원, 트래픽 경로, 오토스케일링까지. 시리즈의 첫 편이자 이후 편들의 참조 지도다.
2026-08-0541분 · read
02

Next.js 앱은 어떻게 파드가 되는가: 컨테이너와 파드를 직접 열어본 기록

#kubernetes#docker#nextjs
같은 Next.js 앱인데 이미지 하나는 1.72GB, 하나는 208MB였다. 사라진 1.5GB를 레이어에서 역추적하고, 컨테이너가 격리된 프로세스라는 것을 PID와 cgroup 파일로 직접 확인한다. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 두 번째 편이다.
2026-08-0534분 · read
03

트래픽은 어떻게 내 파드에 도착하는가: ClusterIP부터 port-forward까지

#kubernetes#networking#nextjs
Service의 ClusterIP는 어느 기계에도 붙어 있지 않은 IP인데 curl은 어떻게 닿는가. iptables 규칙과 conntrack, EndpointSlice, 클러스터 DNS의 ndots, Gateway, port-forward까지, 요청이 파드에 도착하는 경로 전체를 kind 클러스터에서 직접 열어본 기록이다. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 세 번째 편이다.
2026-08-0648분 · read
04

파드는 어떻게 종료되는가: 배포 중 에러의 원인과 해결을 실측한 기록

#kubernetes#nextjs#nodejs
코드를 한 줄도 바꾸지 않은 배포에서도 에러는 샌다. 롤링 배포 중 새는 실패를 유형과 시각까지 태깅해 원인 네 가지를 부검하고, 처방을 한 층씩 얹어 0으로 만들기까지의 실측 기록이다. Next.js의 종료 코드 원문과 인질 드레인, CrashLoopBackOff의 실제 시간표까지. 프론트엔드 개발자를 위한 쿠버네티스 시리즈의 네 번째 편이다.
2026-08-0836분 · read
05

Node.js 파드는 왜 그 크기인가: NODE_OPTIONS부터 파드 수까지 직접 재본 사이징

#nodejs#kubernetes#v8
같은 워크로드에 GC 튜닝 플래그 한 줄을 붙였더니 peak RSS가 201MB에서 593MB로 뛰었다. 살아있는 데이터는 그대로였다. 왜 그게 당연한 결과인지 V8 New Space를 직접 측정해 역추적하고, 프론트엔드 개발자가 Node.js 파드를 사이징하는 세 축을 정리한다.
2026-08-0384분 · read