kubectl top nodes / kubectl describe node로 실측한 결과 기준. (2026-07-24)

클러스터 스펙과 실사용량

<table header-row="true"><tr><td>노드</td><td>CPU</td><td>메모리 capacity</td><td>메모리 실사용</td><td>requests/limits</td><td>taint</td></tr><tr><td>k3s-master</td><td>2 core</td><td>3027Mi</td><td>1622Mi(54%)</td><td>140Mi/170Mi</td><td>control-plane:NoSchedule</td></tr><tr><td>k3s-worker1</td><td>1 core</td><td>1487Mi</td><td>712Mi(49%)</td><td>544Mi/1408Mi(96%)</td><td>없음</td></tr><tr><td>k3s-worker2</td><td>1 core</td><td>1745Mi</td><td>1027Mi(60%)</td><td>256Mi/512Mi(30%)</td><td>없음</td></tr></table>

CPU는 세 노드 모두 실사용률이 10% 안팔이라 사실상 병목이 아니다. 메모리가 유일한 제약이다.

• master는 후보에서 제외. control-plane 전용 taint가 걸려있고, 지금 그 위에서 돐는 파드(coredns, traefik, metrics-server 등)는 전부 k3s 애드온이 자체적으로 넣은 toleration 덕분에 떠 있는 것 — 우리가 만든 Deployment는 toleration 없이는 애초에 스케쥴되지 않고, 굳이 toleration을 추가해서 컨트롤플레인에 올리는 것도 권장되지 않는 방식이라 처음부터 제외했다.
• worker1은 이미 빨둥하다. memory limit 합계가 allocatable의 96%. 여기에 새 워크로드를 더 얹는 건 피했다.
• worker2가 실질적인 유일한 후보. memory request는 겨우 15%만 차 상태고, 실사용 기준으로도 718Mi가 비어 있다. 이미 Kafka 브로커가 이 노드에 떠 있어서, 새 서비스의 Kafka consumer가 같은 노드에서 브로커와 통신하면 네트워크 홈도 하나 줌는 부수적 이점도 있다.

새 서비스가 실제로 얼마나 먹을까

로컬에서 docker compose up으로 직접 띄워서 확인한 실측치(임베딩/생성은 전부 Gemini API 호출이라 로컬에 LLM/임베딩 모델을 로드하지 않는다 — 이게 메모리 예산을 작게 잡을 수 있는 핵심 이유):

<table header-row="true"><tr><td>컴포넌트</td><td>예상 request</td><td>예상 limit</td><td>근거</td></tr><tr><td>Qdrant</td><td>128Mi</td><td>384Mi</td><td>공식 이미지 idle 시 100~150Mi대, 벡터 수천 개 규모면 400Mi 안쪽</td></tr><tr><td>FastAPI 앱</td><td>128Mi</td><td>384Mi</td><td>uvicorn+langgraph+langchain-text-splitters+qdrant-client+aiokafka, 로컬 모델 없음</td></tr><tr><td>합계</td><td>256Mi</td><td>768Mi</td><td></td></tr></table>

worker2 기준: request 256Mi 추가해도 (256+256)/1745 ≈ 29%, limit 768Mi 추가해도 (512+768)/1745 ≈ 73%. request 기준으로 스케쥴링 가능하고, limit 기준으로도 과포화되지 않는다.

결론

• 된다. worker2에 배치하는 걸 전제로.
• nodeSelector/podAffinity로 worker2를 명시하거나, 최소한 worker1을 피하는 podAntiAffinity를 걸도록 권장.
• 실제 배포 후 kubectl top pods로 며칠 관찰하면서 limit을 보정하는 게 안전.
• Qdrant는 상태를 갖는 컴포넌트라 PVC가 필요하다 — 클러스터에 이미 local-path-provisioner가 떠 있으니 StorageClass는 그대로 재사용 가능.