dev.Log

쿠버네티스는 왜 SWAP을 비활성해야하나? 본문

BACKEND.*/Server

쿠버네티스는 왜 SWAP을 비활성해야하나?

초코푸딩 2025. 4. 23. 11:15

"신뢰할 수 있는 메모리 상태와 리소스 스케줄링"을 보장하기 위해서

 

 

🔧 1. 리소스 스케줄링 정확도 보장

Kubernetes는 Pod 스케줄링 시 각 노드의 CPU/메모리 사용량을 기준으로 파드를 배치해.

  • 그런데 swap이 켜져 있으면 실제 메모리 부족인데도 스왑으로 인해 문제 없이 돌아가는 것처럼 보여.
  • → 결국 노드의 메모리 여유량을 과대평가해서 너무 많은 파드를 집어넣게 될 수 있어.
  • → 나중에 OOM(Out of Memory)으로 Pod가 죽거나, 전체 노드가 불안정해질 수 있음.

⚡ 2. 성능 예측이 어려워짐

  • 스왑은 디스크 기반이라 매우 느려.
  • 어떤 Pod가 swap 영역을 과도하게 쓰기 시작하면, → I/O 병목 + 전체 노드 성능 저하 발생 가능.
  • Kubernetes는 이런 예측 불가능한 성능 저하를 최대한 막고 싶어함.

🔒 3. 컨테이너 격리 보장

  • Kubernetes는 **컨테이너 자원 격리(CPU/메모리 제한)**을 cgroup으로 보장해.
  • 그런데 swap이 켜져 있으면 soft limit이 무의미해짐. → 컨테이너가 지정된 메모리 이상도 계속 버티게 되니까.

즉, "한 컨테이너가 지정된 메모리만 쓰게 만들고 싶은데, swap이 켜져 있으면 어기게 된다"는 거지.


✅ 그래서 어떻게 하냐면

Kubernetes는 kubelet 실행 시, swap이 켜져 있으면 아예 클러스터를 초기화하거나 조인하지 못하게 막아버려.

bash
복사편집
[WARNING Swap]: running with swap on is not supported.

해결법

bash
복사편집
sudo swapoff -a sudo sed -i '/swap/d' /etc/fstab # 부팅 시에도 swap 끄기

📌 예외: Kubernetes에서 swap을 쓰고 싶다면?

Kubernetes 1.22부터는 실험적으로 허용은 가능해졌지만, 기본은 여전히 비활성화야.

bash
복사편집
kubelet --fail-swap-on=false

요약

이유설명
스케줄링 정확도 메모리 여유 판단이 부정확해짐
성능 예측 불가 스왑으로 인해 성능 불안정
격리 실패 컨테이너 메모리 제한이 무의미해짐
기본 정책 swapoff -a 필수, fstab 수정 권장
Comments