◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 5편
오토스케일링은 자동이지만 즉시가 아니다: HPA의 시간을 구간별로 실측한 기록
트래픽을 12배로 올렸을 때 새 파드가 첫 요청을 받기까지 걸린 31.5초와, 그중 HPA가 부하를 알아채는 데 쓴 22.5초. 배포 직후 5분 동안 오토스케일러가 반응하지 못하는 조건, 스케일 다운이 계단식으로 내려오는 이유, 메모리 기준 HPA가 Node 앱에 맞지 않는 이유, KEDA로 미리 확장하는 방법
06 POSTS
Kubernetes 1
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 4편파드는 어떻게 종료되는가: 배포 중 에러의 원인과 해결을 실측한 기록
코드를 한 줄도 바꾸지 않은 배포에서도 생기는 요청 실패. 롤링 배포 중 실패한 요청을 유형과 시각으로 태깅해 찾은 원인 네 가지, 해법을 하나씩 더해 실패를 0건으로 줄인 순서, Next.js의 종료 처리 코드와 CrashLoopBackOff의 실제 재시작 간격
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 3편트래픽은 어떻게 내 파드에 도착하는가: ClusterIP부터 port-forward까지
Service의 ClusterIP는 어느 기계에도 붙어 있지 않은 IP인데 curl 요청은 어떻게 파드에 도착할까. kind 클러스터에서 iptables 규칙과 conntrack, EndpointSlice, 클러스터 DNS의 ndots, Gateway, port-forward를 차례로 확인하며 요청 경로 따라가기
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 2편내 Next.js 앱은 어떻게 파드가 되는가: 컨테이너와 파드를 직접 열어본 기록
같은 Next.js 앱으로 만든 1.72GB와 208MB짜리 두 이미지. 사라진 1.5GB를 레이어에서 역추적하고, 컨테이너가 격리된 프로세스라는 것을 PID와 cgroup 파일로 직접 확인해보기
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 1편프론트엔드 개발자를 위한 쿠버네티스 개념 지도: 파드에서 오토스케일러까지
SSR을 운영하는 프론트엔드 개발자를 위해 클러스터 구성, 배포, 파드의 상태와 자원, 트래픽 경로, 오토스케일링 순서로 정리한 쿠버네티스 핵심 개념
◆ 프론트엔드 개발자가 알아야 할 쿠버네티스 · 6편Node.js 파드는 왜 그 크기인가: NODE_OPTIONS부터 파드 수까지 직접 재본 사이징
같은 워크로드에 GC 튜닝 플래그 한 줄을 붙였더니 살아 있는 데이터는 그대로인데 201MB에서 593MB로 늘어난 peak RSS. V8 New Space를 직접 측정해 그 이유를 따라가며 정리한, 프론트엔드 개발자를 위한 Node.js 파드 사이징의 세 가지 기준