[kubernetes] Resource Requirements and Limits

Resource Requirements and Limits

Kubernetes 클러스터에는 여러 노드가 있으며, 각 노드는 CPU, 메모리, 디스크 등 일정한 리소스를 보유하고 있습니다. Pod가 배치되면 해당 노드에서 이 리소스를 소비하게 됩니다. Pod가 어디에 배치될지는 Kubernetes 스케줄러가 결정하며, 스케줄러는 Pod가 요청한 리소스와 각 노드의 사용 가능한 리소스를 기준으로 판단합니다.

노드에 충분한 리소스가 없다면 Pod는 Pending 상태로 남아 있게 되며, 이벤트 로그를 통해 리소스 부족 이유(CPU 부족 등)를 확인할 수 있습니다.

Resource Requests

리소스 요청(Request)은 Pod 또는 컨테이너가 최소한으로 필요한 리소스 양을 정의합니다. 기본적으로 Kubernetes는 컨테이너마다 0.5 CPU와 256MiB 메모리를 요청한다고 가정합니다. (멀티 컨테이너 파드에서 Request와 Limit은 개별 컨테이너 단위로 정의됨.) 스케줄러가 파드를 노드에 배치하려고 할 때 이 숫자를 사용하여 사용 가능한 리소스가 충분한 노드를 식별합니다. deployment 의 YAML 파일에서 값을 수정할 수 있습니다.

resources:
  requests:
    memory: "1Gi"
    cpu: "1"

파드의 Definition 파일에서 이 경우에는 1GB의 메모리와 1개의 vCPU로 설정했습니다.

• 1 CPU는 AWS의 vCPU 1개, GCP 또는 Azure의 가상 코어 1개에 해당합니다.
  • 소수 단위(예: 0.1, 0.5)로 설정 가능하며, 100m과 같이 밀리 단위로도 표현할 수 있습니다.
  • 단위 하한선은 1m입니다.
• 메모리 단위로는 Mi, Gi 등이 사용됩니다.
  • 1Gi = 1024Mi, 1G = 1000MB
• Gi는 기비바이트, G는 기가바이트로 둘의 차이를 명확히 알아야 합니다.

Resource Limits

컨테이너는 기본적으로 노드에서 사용할 수 있는 리소스에 제한이 없습니다. 예를 들어, 노드에 하나의 vCPU가 할당된 파드가 있다고 가정하면, 해당 컨테이너는 노드의 기본 프로세스나 다른 컨테이너를 방해할 정도로 필요한 만큼의 리소스를 추가 사용할 수 있습니다. 하지만 Kubernetes에서는 이러한 리소스 사용량에 제한을 설정할 수 있습니다. 예를 들어, 컨테이너에 하나의 vCPU를 제한하면, 해당 컨테이너는 최대 하나의 vCPU만 사용할 수 있도록 제한됩니다. 메모리도 마찬가지로, 예를 들어 Kubernetes는 컨테이너에 대해 512MB의 메모리 제한을 설정할 수 있습니다.

이러한 리소스 제한은 Deployment 등의 정의 파일의 resources 섹션 아래 limits 섹션을 추가하여 설정할 수 있습니다. 이를 통해 CPU와 메모리에 대한 새로운 제한을 지정할 수 있습니다. Request는 최소 보장량이고, Limit은 최대 허용량입니다. Pod의 컨테이너가 지정된 Limit 이상으로 리소스를 사용할 수 없도록 강제합니다. 

 

 

Exceed Limits

• CPU: 컨테이너가 CPU limit을 초과하려고 하면, Kubernetes는 CPU 사용량을 제한한다. 하지만 CPU는 compressible 리소스라 throttling 은 되지만 애플리케이션 running은 이루어진다.
• 메모리: 컨테이너가 메모리 limit을 초과하면 OOM(Out of Memory) 에러로 인해 OOM Killer 가 파드 프로세스를 kill 한다. 이 경우 로그나 이벤트에서 OOMKilled 메시지를 확인할 수 있다.

Default Behavior

디폴트 값으로 쿠버네티스는 CPU 및 메모리 요청, Limit 세트가 없습니다. 그 말은 어떤 파드든 어떤 노드에서 요구되는 만큼의 자원을 소비하고 노드에서 실행 중인 다른 파드나 프로세스를 질식시킬 수 있습니다.

CPU Behavior

1. 클러스터 내에서 두 개의 파드가 CPU 리소스를 두고 경쟁하는 상황을 가정해보겠습니다. 만약 이 파드들에 대해 Request와 Limit이 설정되어 있지 않다면, 하나의 파드가 노드의 모든 CPU를 점유해버릴 수 있으며, 이로 인해 다른 파드가 필요한 리소스를 확보하지 못하는 상황이 발생할 수 있습니다. 이런 방식은 안정적인 리소스 관리 측면에서 바람직하지 않습니다.
2. Request가 명시되지 않은 경우, Kubernetes는 Request 값을 Limit 값과 동일하게 설정합니다. 예를 들어, Request와 Limit이 모두 3 vCPU로 지정된 경우, 각 파드는 최소 3개의 vCPU를 보장받게 됩니다.
3. 이번에는 Request를 1, Limit을 3으로 설정한 경우를 살펴보겠습니다. 언뜻 보기에는 효율적인 구성처럼 보일 수 있습니다. 하지만, 파드1이 어떤 이유로 3 이상의 CPU 사용이 필요하고, 반면 파드2는 많은 CPU를 사용하지 않는 상황이라면, 파드1에 Limit을 설정한 것이 오히려 불필요한 제약이 됩니다. 이처럼 리소스가 여유 있음에도 불구하고 파드의 사용을 제한하는 것은 자원의 낭비를 초래할 수 있습니다. 다시 말해, Limit이 설정되어 있으면 CPU 사용을 유연하게 조절하기 어렵게 됩니다.
4. 위의 예시에서 Request로 cpu가 1개 보장되고 limit이 없으면 특정 파드가 최대한 CPU를 활용할 수 있습니다. Request 가 있기 때문에 기본적인 CPU 할당은 보장받습니다. 하지만, 어떤 시점에서 파드2가 추가적인 CPU 사이클이나 요청이 요구되면 파드2는 파드1 로부터 CPU 사이클을 보장받을 수 있다. 가장 이상적인 환경입니다. 물론 상황에 따라 리소스 제한이 필요할 수도 있음.

Memory Behavior

1. 메모리의 경우에도 CPU와 유사한 원칙이 적용됩니다. Request와 Limit이 모두 설정되어 있지 않은 상태에서는 두 개의 파드가 메모리 리소스를 두고 경쟁하게 되며, 이때 하나의 파드가 노드의 전체 메모리를 소모할 수 있습니다. 이로 인해 다른 파드는 필요한 메모리를 확보하지 못하고, 질식될수도 있다. 
2. 두 번째 경우는 Limit만 설정된 상황입니다. 이 경우에도 Kubernetes는 Request 값을 자동으로 Limit 값과 동일하게 설정합니다. 따라서 각 파드는 Limit만큼의 메모리를 사용하도록 제한되며, 그만큼의 메모리를 보장받습니다.
3. 세 번째는 Request와 Limit을 모두 명시한 경우입니다. 이 경우 각 파드는 Request에 해당하는 메모리를 최소한으로 보장받으며, Limit을 초과해서는 메모리를 사용할 수 없습니다. 이 설정은 리소스 사용량을 예측 가능한 범위로 유지하는 데 유리하지만, 유연성이 떨어질 수 있습니다.
4. 마지막은 Request만 설정하고 Limit은 설정하지 않은 경우입니다. 이 설정은 CPU의 경우와 유사하게 보일 수 있으나, 메모리에는 결정적인 차이가 존재합니다. Request가 지정되어 있으므로 각 파드는 최소한의 메모리는 확보됩니다. 그러나 Limit이 없기 때문에 파드는 사용 가능한 메모리를 얼마든지 사용할 수 있습니다. 문제는, 파드1이 메모리를 많이 점유하고 있는 상황에서 파드2가 더 많은 메모리를 요구하게 되면, 이를 해결할 수 있는 유일한 방법은 파드1을 강제 종료(kill)하여 해당 메모리를 회수하는 것입니다. 이는 CPU와 달리, 메모리는 할당 후 자동으로 되돌려 받을 수 없기 때문입니다. 메모리 리소스는 물리적으로 반환되지 않기 때문에, 리소스를 회수하기 위한 유일한 방법은 파드를 종료시켜 그 메모리를 해제하는 것입니다.

Limit Range

쿠버네티스는 기본값으로 파드를 위해 구성된 리소스 요청이나 한계가 없습니다. 그렇다면 어떻게 모든 파드의 기본 설정을 만들 수 있을까? 이건 LimitRange 에서 가능합니다. LimitRange는 기본 값을 정의하는 데 도움을 줍니다. 파드 내 정의 파일에 요청이나 Limit 한도 없이 생성된 컨테이너에 대한 설정입니다. 이는 오브젝트이며 또한, namespace 레벨에서 작동합니다. max 는 파드 내 컨테이너에 설정할 수 있는 최대 한도를 나타내고 min 은 파드 내 컨테이너에 설정할 수 있는 최소 요청을 의미합니다.

• default
  • default 필드는 파드의 리소스 제한이나 요구사항이 명시되지 않은 경우 적용되는 기본값을 설정합니다.
  • 예를 들어, 만약 파드가 CPU 요청을 명시하지 않았을 때, default 값으로 설정된 CPU 요청이 자동으로 할당됩니다.
• defaultRequest
  • defaultRequest 필드는 파드가 요청한 리소스가 명시되지 않은 경우 적용되는 기본 요청값을 설정합니다.
  • 예를 들어, 파드가 CPU 요청을 명시하지 않았을 때, defaultRequest 값으로 설정된 CPU 요청이 자동으로 할당됩니다.
• max
  • max 필드는 파드가 요청할 수 있는 최대 리소스 제한을 설정합니다.
  • 이 값은 파드가 설정한 제한보다 클 수 없습니다.
• min
  • min 필드는 파드가 요청할 수 있는 최소 리소스 요구사항을 설정합니다.
  • 이 값은 파드가 설정한 요구사항보다 작을 수 없습니다.

Resource Quota

 

끝으로 쿠버네티스 클러스터에 배포된 앱이 사용할수 있는 전체 리소스를 제한할 방법이 있을까? 이는 네임스페이스 레벨에서 Quotas를 생성할 수 있습니다. ResourceQuota는 네임스페이스 레벨 객체로 요청과 한계에 대한 엄격한 제한을 설정하기 위해 생성될 수 있습니다. 위의 사진에서 리소스 할당량은 현재 네임스페이스에서 요청된 총 CPU를 4, 메모리를 4Gi로 제한합니다. 모든 파드가 CPU 사용량 최대치를 10으로 설정하고 메모리도 10Gi로 설정합니다. 즉, ResourceQuota는 네임스페이스 내에서 파드가 사용할 수 있는 리소스의 총량을 제한하는 설정입니다.