[Scheduling] Resource Requirements and Limits

앞서 공부했듯이, 스케쥴러가 노드의 리소스 현황을 확인하고 파드를 배정해줍니다.

만약 어떤 노드에 더 이상 자원이 없을 때는 해당 노드에 파드를 배정하지 않습니다.

 

모든 노드에 자원이 없을 때는 리소스가 running 상태로 들어가지 못하고 pending 상태에 머물러 있다.

이 때 파드의 Events를 확인하(describe 명령어)면 Insufficient cpu 혹은 memory 등으로 상태를 확인할 수 있다.

 

Resource Requests

apiVersion: v1
kind: Pod
metadata:
	name: simple-webapp-color
	labels:
		name: seimple-webapp-color
spec:
	containers:
		- name: simple-webapp-color
			image: simple-webapp-color
			ports:
				- containerPort: 8080
			resources:
				requests:
					memory: "1Gi"
					cpu: 1
				limits:
					memory: "4Gi"
					cpu: 2

• spec.containers.resources.requests 에 컨테이너에서 사용할 자원(cpu, memory)을 기술합니다.
• spec.containers.resources.limits 에 이 컨테이너에서 사용할 수 있는 자원의 한계를 정합니다.

컨테이너 단위로 정할 수 있습니다.

 

만약 컨테이너가 정해진 limit보다 더 자원을 사용하려고 할 때,

주의할 점은, cpu는 정해진 리밋을 넘지 않도록 자체적으로 조절되지만,

memory는 조절이 불가능하여 초과해서 사용하게 되면 강제적으로 해당 pod가 terminated 됩니다.

 

해당 pod의 log를 확인하면 OOM(Out of Memory) 내용이 존재할 것입니다.

Default Behavior

기본적으로 kubernetes에는 cpu나 메모리 request 혹은 limit 이 없습니다.

따라서 어떠한 pod라도 원하는 만큼 자원 이용이 가능하므로 한계를 정하는 것이 중요합니다.

(정하지 않으면,, 끝도 없이 사용하게 됨)

 

CPU

1. No request, No limits
   • 이상적이지 않음. 하나의 pod가 모든 CPU 리소스 사용이 가능해져서 다른 pod의 배정이 불가능해짐
2. No request, Limits
   • 쿠버네티스는 limit 과 requset를 동일하게 설정함
3. Request, Limits
   • request와 limit 이 모두 정해진 pod는 각각의 request 만큼 cpu 개수가 보장되고 limit 까지 사용할 수 있다.
   • 하지만 만약 파드1에서 limit 보다 더 cpu를 사용하게 되고 파드2는 예상보다 덜 사용하게 된다고 가정했을 때 자원의 효율성을 높이기 위해 파드1의 limit을 높이고 싶은 상황이 발생할 수 있다.
4. Requests, no Limits ⭐
   • request 한 만큼의 자원이 보장되지만 limit은 설정하지 않았을 때, 어떤 pod든 전체 자원이 여유롭다면 원하는 만큼 더 리소스를 사용할 수 있다.
   • 이 경우에는 모든 pod가 request를 정하는 게 좋다.
   • limit이 없기 때문에 하나의 pod에서 독식 시 다른 pod가 pending 상태에 머무를 수 있기에 최소 보장 request를 정해주는 것이다.

 

Memory

 

cpu와 기본적으로 동일하게 동작하지만 다른 점은 memory는 cpu와 다르게 throttle 할 수 없기 때문에,

만약 memory가 부족해지면 존재하는 pod를 삭제해서 여유를 만들어야 합니다.

 

Limit Range 리소스

limitrange 리소스는 컨테이너의 cpu 리소스에 대한 제한을 설정합니다.

limitrange를 사용하면 파드의 컨테이너들이 정의된 cpu 제한 범위 내에서 리소스를 사용하게 됩니다.

apiVersion: v1
kind: LimitRange
metadata:
	name: cpu-resource-constraint
spec:
	limits:
		- default: # default limit
				cpu: 500m
			defaultRequest:
				cpu: 500m
			max:
				cpu: "1"
			min: 
				cpu: 100m
			type: Container	

apiVersion: v1
kind: LimitRange
metadata:
	name: memory-resource-constraint
spec:
	limits:
		- default: # default limit
				memory: 1Gi
			defaultRequest:
				memory: 1Gi
			max:
				memory: 1Gi
			min: 
				memory: 500Mi
			type: Container	# 제한 범위가 컨테이너에 대한 것

주의) 이미 running 중인 pod 에는 해당되지 않고 새로 deploy 되는 리소스에만 적용됩니다.

type은 container, pod, pvc, request, limit 가 될 수 있습니다.

 

Resource Quotas

 

클러스터 내에서 네임스페이스 단위로 사용 가능한 리소스의 한계를 설정하는 정책으로, 각 네임스페이스에 대해 리소스 사용량을 제한하고 제어할 수 있는 메커니즘입니다.

apiVersion: v1
kind: ResourceQuota
metadata:
	name: my-resource-quota
spec:
	hard:
		requests.cpu: 4
		requests.memory: 4Gi
		limits.cpu: 10
		limits.memory: 10Gi

 

 

Containers.mem-stress.State.Reason에서 OOMKilled 확인 가능합니다.

The status OOMKilled indicates that it is failing because the pod ran out of memory. Identify the memory limit set on the POD.

 

이 pod 의 limit 을 늘리고 싶지만 running 중인 pod의 environment 설정은 바꿀 수 없습니다.

이런 경우에는 yaml 파일을 추출한 후에 pod를 삭제하고 변경한 yaml 파일로 재배포합니다.

 

혹은 replace 명령어를 써도 됩니다.

kubectl replace --force -f [파일위치]

 

 

참고

Certified Kubernetes Adiminstrtor(CKA) with Practice Tests by Mumshad Mannambeth, KodeKloud Training