lander.log

K8s Node Allocatable

4 min read

K8s Node Allocatable

정의 (Definition)

Node Allocatable 은 노드의 전체 리소스(Capacity) 중에서 시스템 안정성을 위해 예약된 부분을 제외하고,파드(Pod)가 실제로 사용할 수 있다고 간주되는 가용량 이며, 노드의 “물리적 총량”과 동일하지 않습니다.

문제가 되는 배경 (Problem Context)

kubectl describe node에서 Capacity가 충분해 보이는데도 파드가 스케줄링되지 않거나, 노드가 압박 상태에 빠지는 경우가 있습니다. 원인은 “파드가 쓸 수 있는 양”이 Capacity가 아니라 Allocatable 이라는 점, 그리고 Allocatable이 여러 예약/버퍼로 차감된다는 점을 놓치기 때문입니다.

핵심 메커니즘 (How it Works)

Allocatable은 다음과 같이 계산할 수 있습니다.

Node Allocatable = Node Capacity - kube-reserved - system-reserved - eviction threshold
  • Node Capacity: 노드의 총 물리/가상 리소스
  • kube-reserved: kubelet/container runtime 등 K8s 시스템 프로세스를 위한 예약 (관련: K8s kube-reserved)
  • system-reserved: sshd/journald 등 OS 프로세스를 위한 예약 (관련: K8s system-reserved)
  • eviction threshold: 노드가 압박 상태로 붕괴하지 않도록 남겨두는 버퍼 (관련: K8s 파드 축출(Eviction) 정책)

불변 조건과 보장 범위 (Invariants & Guarantees)

  • 보장: 스케줄러는 노드 적합성 판단에서 Capacity가 아니라 Allocatable을 기준으로 request 총량을 비교합니다.
  • 비보장: Allocatable이 충분해도 어피니티/테인트/쿼터/이미지 풀 등 다른 제약으로 스케줄링이 실패할 수 있습니다.

비유 (Analogy)

Capacity가 “연봉(세전)”이라면, Allocatable은 세금/공제(예약·버퍼)를 제외한 “실수령액(세후)”에 가깝습니다.

실무적 함의 (Operational Implications)

  • 노드 사이징/밀도 최적화는 Capacity 기준이 아니라 Allocatable 기준으로 해야 합니다.
  • 예약(Reserved)과 eviction 임계값은 워크로드 밀도와 안정성의 트레이드오프이므로, 노드 역할(시스템 에이전트/로깅/보안 등)과 함께 조정해야 합니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • Capacity가 크다고 “파드를 더 올릴 수 있다”는 결론을 내리면 안 됩니다.
  • kube-reserved/system-reserved를 과도하게 줄이면 밀도는 좋아지지만, 노드 운영 안정성이 먼저 무너질 수 있습니다.

References

Recent Posts