dev.Log
쿠버네티스는 왜 SWAP을 비활성해야하나? 본문
"신뢰할 수 있는 메모리 상태와 리소스 스케줄링"을 보장하기 위해서
🔧 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 수정 권장 |
'BACKEND.* > Server' 카테고리의 다른 글
| 리눅스 시작 서비스(init, systemd) 정리 (1) | 2025.12.31 |
|---|---|
| 커널파라미터 - 네트워크 버퍼 설정 (1) | 2025.07.14 |
| 네트워크매니저 고장 (0) | 2025.02.15 |
| 두 가지 솔루션을 도커로 패키징하기 (0) | 2025.02.15 |
| epoll 보다 좋은 io_uring (0) | 2025.02.01 |
Comments