Resource Request

Kubernetes Resource Request 완벽 가이드! Scheduler 배치 기준과 CPU·Memory 관리 구조 이해하기

작성자:

Kubernetes 운영에서 안정적인 Application 배포를 위해 가장 중요한 설정 중 하나가 Resource 관리입니다.

많은 초보 운영자가 Kubernetes를 사용할 때 Pod가 실행되지 않거나 성능 문제가 발생하는 이유는 CPU와 Memory 설정이 정확하지 않기 때문입니다.

예를 들어 Application이 사용하는 Resource보다 너무 낮게 설정하면 Container가 종료될 수 있고, 반대로 너무 높게 설정하면 Node Resource가 낭비됩니다.

Kubernetes는 이러한 문제를 해결하기 위해 Container Resource Request와 Limit 기능을 제공합니다.

Resource Request는 Kubernetes Scheduler가 Pod를 어느 Node에 배치할지 결정하는 기준이며, Resource Limit은 Container가 사용할 수 있는 최대 Resource를 제한하는 역할을 합니다.

구성 요소역할
Resource RequestScheduler 배치 기준
Resource Limit최대 사용량 제한
CPU처리 능력 관리
Memory메모리 사용 관리

Resource 구조를 이해하면 Pending Pod 문제를 해결하고 효율적인 Kubernetes Cluster 운영이 가능합니다.

Kubernetes Resource Request란?

Resource Request는 Container가 실행되기 위해 최소한으로 필요한 Resource 양을 의미합니다.

Kubernetes Scheduler는 실제 CPU와 Memory 사용량이 아니라 Request 값을 기준으로 Pod 배치를 결정합니다.

예:

Pod 설정:

CPU Request:

500m

Memory Request:

512Mi

의미:

이 Container는 최소한 CPU 0.5 Core와 Memory 512MB 공간이 필요하다는 뜻입니다.

Kubernetes Resource Limit이란?

Resource Limit은 Container가 사용할 수 있는 최대 Resource 한도를 의미합니다.

예:

CPU Limit:

2

Memory Limit:

2Gi

의미:

Container가 최대 CPU 2 Core, Memory 2GB까지만 사용할 수 있습니다.

Limit을 초과하면 Kubernetes는 다음과 같은 동작을 수행합니다.

CPU 초과:

→ 제한 적용

Memory 초과:

→ OOMKilled 발생 가능

따라서 Resource 설정은 신중해야 합니다.

Kubernetes Resource Request와 Limit 차이

구분RequestLimit
목적배치 기준사용 제한
관리 대상SchedulerContainer Runtime
초과 시다른 Node 선택제한 또는 종료
필수 여부선택 가능선택 가능

Request와 Limit은 서로 다른 역할을 수행합니다.

Kubernetes Scheduler와 Resource 관계

Pod가 생성되면 Scheduler는 실행 가능한 Node를 찾습니다.

과정:

Pod 생성

↓

Request 확인

↓

Node Resource 확인

↓

조건 비교

↓

Node 선택

↓

kubelet 실행

예:

Node A:

CPU 여유 4 Core

Pod Request:

CPU 2 Core

배치 가능

반대로 Node Resource가 부족하면 Pending 상태가 됩니다.

CPU Resource 단위 이해하기

Kubernetes CPU는 Core 단위를 사용합니다.

표현:

1 CPU

= 1000m

예:

500m

= 0.5 CPU

100m

= 0.1 CPU

실제 Server CPU 개념과 연결해서 이해하면 됩니다.

Memory Resource 단위 이해하기

Memory는 Byte 단위를 기반으로 표현합니다.

대표 단위:

표현의미
MiMebibyte
GiGibibyte

예:

512Mi

≈ 512MB

2Gi

≈ 2GB

운영 환경에서는 Memory 설정이 특히 중요합니다.

Resource Request 설정 예시

Deployment 예:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"

의미:

최소:

CPU 0.5 Core

Memory 512Mi

최대:

CPU 1 Core

Memory 1Gi

Application 특성에 맞게 설정해야 합니다.

Resource Request가 너무 낮으면 발생하는 문제

낮은 Request는 Resource 부족 문제를 발생시킬 수 있습니다.

예:

실제 사용량:

CPU 2 Core

설정:

CPU Request 200m

결과:

  • Scheduler 판단 오류
  • 성능 저하
  • Container 경쟁 증가

실제 사용량을 기반으로 조정해야 합니다.

Resource Request가 너무 높으면 발생하는 문제

반대로 과도한 설정도 문제가 됩니다.

예:

실제 사용량:

CPU 500m

설정:

CPU Request 4 Core

결과:

  • Node Resource 낭비
  • Pending Pod 증가
  • Cloud 비용 증가

적절한 균형이 필요합니다.

Kubernetes QoS Class 이해하기

Resource 설정에 따라 Kubernetes는 Pod를 QoS Class로 분류합니다.

Class특징
GuaranteedRequest와 Limit 동일
BurstableRequest와 Limit 다름
BestEffortResource 설정 없음

Node Resource 부족 상황에서 우선순위 판단에 사용됩니다.

Kubernetes Guaranteed QoS

가장 높은 안정성을 제공합니다.

조건:

CPU Request = CPU Limit

Memory Request = Memory Limit

예:

CPU:

2

Memory:

4Gi

운영 중요 Application에서 사용합니다.

Kubernetes Burstable QoS

가장 일반적으로 사용되는 방식입니다.

예:

Request:

CPU 500m

Memory 512Mi

Limit:

CPU 2

Memory 2Gi

일정 범위 안에서 유연하게 동작합니다.

Kubernetes BestEffort QoS

Resource 설정이 없는 Pod입니다.

특징:

  • 가장 낮은 우선순위
  • Resource 부족 시 먼저 종료 가능

테스트 환경에서는 사용할 수 있지만 Production에서는 주의가 필요합니다.

Resource 설정과 HPA 관계

HPA는 Resource Request 값을 기준으로 CPU 사용률을 계산합니다.

구조:

Resource Request 설정

↓

CPU 사용률 계산

↓

HPA 판단

↓

Pod 증가

따라서 HPA 사용 시 정확한 Request 설정이 필요합니다.

Resource 설정과 VPA 관계

VPA는 Resource Request 값을 자동으로 조정합니다.

구조:

사용량 분석

↓

적절한 Request 계산

↓

Resource 변경

VPA는 Resource 최적화 기능입니다.

Resource 부족 문제 해결 방법

운영 환경에서 Resource 부족이 발생하면:

방법 1

Resource 조정

↓

Request/Limit 수정

방법 2

Node 추가

↓

Cluster 확장

방법 3

Autoscaling 적용

↓

자동 관리

상황에 맞는 해결 방법을 선택합니다.

Kubernetes Resource Monitoring

Resource 관리를 위해 Monitoring이 필요합니다.

확인 명령어:

kubectl top pods
kubectl top nodes

확인:

  • CPU 사용량
  • Memory 사용량

운영 환경에서는 Prometheus와 Grafana를 함께 사용합니다.

Kubernetes Resource 운영 전략

Production 환경에서는 다음 방식을 추천합니다.

개발 환경:

낮은 Request

↓

테스트

↓

사용량 분석

↓

Production 최적값 적용

실제 Metric 기반 관리가 중요합니다.

자주 묻는 질문

Request와 Limit 중 무엇이 더 중요한가요?

둘 다 중요하지만 Scheduler 배치에는 Request가 직접적인 영향을 줍니다.

Limit 없이 Request만 설정해도 되나요?

가능하지만 Application 특성에 따라 설정하는 것이 좋습니다.

Resource 부족하면 자동으로 해결되나요?

아닙니다.

HPA, VPA, Cluster Autoscaler 같은 자동화 기능을 함께 구성해야 합니다.

마무리

Kubernetes Resource Request와 Limit은 안정적인 Container 운영을 위한 핵심 설정입니다.

구성 요소역할
RequestScheduler 배치 기준
Limit최대 Resource 제한
CPU처리 능력 관리
Memory메모리 관리

Resource 설정을 제대로 이해하면 Pending Pod 문제를 줄이고 Kubernetes Cluster 비용과 성능을 효율적으로 관리할 수 있습니다.

다음 글에서는 Kubernetes 내부 저장 구조를 다루는 Kubernetes Persistent Volume 완벽 가이드! PV와 PVC를 활용한 Container Storage 관리 방법 이해하기를 알아보겠습니다.

댓글 남기기