제한된 하드웨어(MacBook Air VMware VM 3대, Master 2GB / Worker 1GB×2 + Swap 2GB)에서 K3s 클러스터를 운영하며 격은 리소스 배치 문제와 설계 판단 근거 기록.

1. 문제 상황

VM 리소스가 클라우드 대비 매우 제한적인 환경(Master 2GB, Worker 각 1GB + Swap 2GB)에서 아래 워크로드를 어떻게 배치할지 결정해야 했다: defense-api-gateway, target-tracking-service, Kafka, Redis, PostgreSQL + pgvector.

2. 초기 배치안

<table header-row="true"><tr><td>노드</td><td>역할</td><td>배치 컴포넌트</td><td>메모리 합계</td></tr><tr><td>server1 (Master, 2GB)</td><td>Control Plane 전용</td><td>K3s server/etcd/apiserver/scheduler (~900MB)</td><td>—</td></tr><tr><td>server2 (Worker, 1GB+Swap 2GB)</td><td>앱 워크로드</td><td>gateway×1(192Mi), target-tracking×1(256Mi), Redis(~80Mi)</td><td>~528Mi (여유)</td></tr><tr><td>server3 (Worker, 1GB+Swap 2GB)</td><td>앱 워크로드</td><td>gateway×1(192Mi), target-tracking×1(256Mi), Kafka(~400Mi)</td><td>~848Mi (빠듯)</td></tr></table>

3. 핵심 판단 1 — Master는 Control Plane 전용으로 격리

etcd(클러스터의 모든 상태를 저장하는 저장소)가 마스터 노드에서 돌는데, 여기서 앱 파드까지 스케쥴링되다가 OOM이 발생하면 이 때 자체가 죽어서 클러스터 전체가 마비될 수 있다. 이 리스크를 원천 차단하기 위해 앱 파드의 마스터 스케쥴링을 막기로 결정.

kubectl taint nodes server1 node-role.kubernetes.io/master=:NoSchedule

4. 핵심 판단 2 — Kafka는 Swap이 있는 워커에 격리, 단 리스크 존재

메모리를 가장 많이 쓰는 Kafka(~400Mi)를 Swap 여유가 있는 server3에 배치.

발견한 리스크 — Swap 위에서 Kafka + JVM 성능 저하 가능성

• Kafka는 디스크 I/O와 OS 페이지 캐시에 민감한 시스템. Swap 발동 시 컴슈머 랬 증가나 예측 불가능한 지연으로 직결
• Spring Boot(JVM) 기반 서비스도 Swap과 상성이 나말. GC pause 시간이 비정상적으로 늘어날 수 있음
• 초기안의 192Mi~256Mi는 Spring Boot 기준 빨응한 수치 — -Xmx나 -XX:MaxRAMPercentage로 명시 제한 안 하면 OOMKilled 가능성 높음

5. 미확정 이슈 — PostgreSQL + pgvector 배치 계획 누락

Stateful한 컴포넌트라 노드, PV 요구사항, 메모리 할당량을 먼저 결정해야 함 — 별도로 배치 계획 확정 후 진행하기로 함.

6. 배운 점

• Control plane과 애플리케이션 워크로드는 물리적으로 격리해야 한다. 저사양 온프레미스 환경에서는 이 원칙을 안 지키면 클러스터 전체 장애로 직결된다.
• Swap은 만능 해결책이 아니다. 메모리 부족을 swap으로 메우는 접근은 stateless 가벼운 워크로드엔 괜찮지만 Kafka나 JVM 기반 컴포넌트엔 성능 저하 리스크를 동반한다.
• 리소스 요청값(requests/limits)은 애플리케이션 특성을 감안해 설정해야 한다.