리소스의 메모리와 CPU 자원 관리

📍 Epilogue

---

• NCP의 NKS에서 프로젝트를 진행 중에 각자 팀원들에게 namespace를 할당해주었다.
• 어느 날 간단한 파드에 대한 스펙을 정해주고 생성을 시도하였더니 스케줄링 에러가 발생
• 원인을 확인해 보니 팀원 한 분께서 생성하신 파드에 어마 무시하게 자원을 할당해 놓으신 것..
• 결국 노드에 남아있는 자원이 없어서 파드 배포 스케줄링 에러가 발생한 것이었다.
• 그래서 여기서 의문점 ❗️
  • 사용자 개인이 할당 가능한 자원에 제한을 걸어둘 수 있을까? → 개인 별로 리소스 관리가 가능한 네임스페이스에?

 

▪︎ Plan

---

• namespace에 대하여 자원 관리를 수행해보자

💡 Limit Range : 네임스페이스 내에 파드나 컨테이너당 리소스 소비를 한정하는 제약 조건을 제공

 

 

▪︎ Namespace에 대한 CPU / Memory 요청량(request), 상한(limit) 구성

---

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    type: Container

 

• default
  • 상한(limit)에 대한 기본값 구성
• defaultRequest
  • 요청량(request)에 대한 기본값 구성

 

• LimitRange에 대한 위 매니페스트로 나의 네임스페이스에 생성한다.

 

• 적용된 값 확인 !
  • 빈 칸들은 조만간 곧 알아봅시다..!

 

• 그럼 실제 컨테이너 생성 시 위 LimitRange가 적용되는지 확인해보자
  • 아래 파드의 컨테이너는 어떠한 자원에 대한 요청량과 상한을 지정하지 않았다.

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action

 

• 생성 !

 

• 확인 !

 

• 어라.. 분명 나는 리소스 상한과 요청량을 지정해주지 않았는데 자동으로 지정되어 있는 것을 볼 수 있다.
• 값을 확인해보면 위에서 생성한 LimitRange에 의해 설정된 값이라는 것을 확인할 수 있다.

 

 

⭐️ 만약 컨테이너의 상한은 지정하고 요청량을 지정하지 않은 경우는?

---

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action
	resources:
		limits:
			cpu: 700m
			memory: 300Mi

 

• 일부러 cpu는 설정한 LimitRange 상한보다 높게 잡았고 memory는 상한과 요청량 사이로 구성했다.
• 생성 ! + 확인 !

 

 

• 여기서 몇 가지를 확인해 볼 수 있었다.
  1. 현재 설정한 LimitRange는 최댓값이나 최솟값이 아니며 단순히 기본값(Default) 설정이다.
  2. 리소스의 상한(limit)만 설정했을 시 요청 값(request)은 상한 값으로 자동 지정되는 것을 확인할 수 있다.
     • 이유를 생각해 보았더니 [ limits 값 = requests 값 ] ⇒ Guaranteed QoS 클래스 이므로..!
     • QoS 클래스에 대한 자세한 것은❗️ ⇒ Pod 안전하게 생성/배포 및 QoS 정책 설정

Pod 안전하게 생성/배포 및 QoS 정책 설정

 

 

⭐️ 그럼 진짜진짜 마지막으로 만약 컨테이너의 요청량은 지정하고 상한을 지정하지 않은 경우는?

---

• 단순한 호기심으로 매니페스트에 요청량을 LimitRange에서의 cpu 상한 Default 값보다 크게 잡고 생성을 해보았다.
• 역시나 cpu limit에 동등하거나 적어야 한다며 에러 !

	resources:
		requests:
			cpu: 700m
			memory: 300Mi

 

 

• 이번엔 제대로 요청량을 상한의 기본값보다 적게 설정하여 생성하고 확인해 보았다.
• 상한 값이 매니페스트에서 설정한 요청량을 따라가지 않고 LimitRange의 Default 값으로 자동 지정된 것으로 확인할 수 있었다.
  • 왜 이 경우엔 Guaranteed QoS 클래스를 따라가지 않는지에 대한 의문점이 생겼다.
  • 생각해보면 Limit란 관련 오브젝트에 큰 영향을 미칠 수 있는 중요한 이유(e.g. 총 자원량, 스펙의 제한..) 때문에 높은 우선순위를 가지고 있는 것이라고 생각한다.
  • 따라서 이를 고려하여 설정한 LimitRange의 상한 값을 우선시하여 값을 지정함이라고 생각하였다.

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action
	resources:
		requests:
			cpu: 300m
			memory: 256Mi

 

 

▪︎ Namespace에 대한 CPU / Memory 최소/최대 제약 조건 구성

---

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range-min-max
spec:
  limits:
  - max:
      cpu: 500m
      memory: 512Mi
    min:
      cpu: 200m
      memory: 256Mi
    type: Container

 

• max
  • cpu와 memory의 최대 제약 조건 값을 지정한다.
• min
  • cpu와 memory의 최소 제약 조건 값을 지정한다.

 

• 위 매니페스트로 LimitRange를 내 네임스페이스에 생성하였다.

 

• 생성된 LimitRange 정보를 확인해 보았다.
  • 오잉 신기한 것을 발견했다.
  • 분명 위 매니페스트에는 max와 min 필드만 작성하였는데 자동으로 상한과 요청량의 기본값(default / defaultRequest)이 구성되었다 !

 

 

• 이제 uhyeong 네임스페이스에 파드가 생성될 때마다 다음과 같은 절차를 수행한다.
  1. 만약 파드에 상한(limits)과 요청량(requests)이 명시되지 않았을 경우 컨트롤 플레인에서 해당 파드 컨테이너에 LimitRange에 명시되어 있는 상한과 요청량의 값(default / defaultRequests)을 지정한다.
  2. 생성되는 파드의 모든 컨테이너의 요청량이 LimitRange에 명시되어 있는 min 값을 따르는지 확인한다.
  3. 생성되는 파드의 모든 컨테이너의 상한 값이 LimitRange에 명시되어 있는 max 값을 따르는지 확인한다.

 

• 그럼 이제 직접 리소스 스펙을 구성한 후 파드를 생성해보자 !
  • 먼저 cpu의 상한 값은 max를 초과하게 설정한다.
  • memory의 요청 값은 min을 충족하지 않게 설정한다.
  • 당연히 안 되겠지만..

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action
    resources:
      limits:
        cpu: 700m
        memory: 512Mi
      requests:
        cpu: 200m
        memory: 128Mi

 

• 에러 메시지가 아주 친절하고 적나라하게 나와줬다!
  • 컨테이너당 사용할 수 있는 최소 메모리는 256Mi인데 너 지금 요청 128Mi 했어 😡..
  • 컨테이너당 사용할 수 있는 최대 cpu는 500m인데 너 지금 상한 700m이란다 😡..

 

• 이제 LimitRange의 구성대로 제대로 수정 후 생성 !

      limits:
        cpu: 500m
        memory: 512Mi
      requests:
        cpu: 300m
        memory: 300Mi

 

 

• 아주 잘 ~ 생성되었다!

🚨 LimitRange는 파드 생성 및 업데이트 시에만 적용된다.
     LimitRange 변경 시 이미 생성된 파드에 대해서는 영향이 미치지 않는다.

 

 

▪︎ Resource 쿼터

---

• 위에서 열심히 알아보았던 LimitRange는 네임스페이스에 생성되는 각각의 컨테이너의 리소스 기본값과 최대 최소에 대한 값을 지정해주는 것이 특징이었다.
• 그렇다면 각 네임스페이스마다 생성할 수 있는 리소스의 할당량 제한을 걸어 클러스터 리소스를 네임스페이스 단위로 분배해 줄 수 있을까?
• 또는 팀 단위나 사용자들끼리 클러스터를 공유할 시 특정 팀이나 사용자가 분배된 리소스보다 더 많은 리소스를 사용할 경우를 예방할 수 없을까?

💡 ResourceQuota : 네임스페이스 별 총 리소스 사용을 제한하는 제약 조건을 제공하는 오브젝트

 

 

• 요청이 지원되는 리소스 유형

리소스 이름	설명
limits.cpu	터미널이 아닌 상태의 모든 파드에서 cpu 제한의 합은 이 값을 초과할 수 없다.
limits.memory	터미널이 아닌 상태의 모든 파드에서 memory 제한의 합은 이 값을 초과할 수 없다.
requests.cpu (= cpu)	터미널이 아닌 상태의 모든 파드에서 cpu 요청의 합은 이 값을 초과할 수 없다.
requests.memory (= memory)	터미널이 아닌 상태의 모든 파드에서 memory 요청의 합은 이 값을 초과할 수 없다.

 

• 리소스 할당량에 대한 Resource Quota 생성 후 확인

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: 500m
    requests.memory: 1Gi
    limits.cpu: 1000m
    limits.memory: 2Gi

 

 

 

• 지원되는 오브젝트 수 쿼터 유형

리소스 이름	설명
configmaps	네임스페이스에 존재할 수 있는 총 컨피그맵 수
persistentvolumeclaims	네임스페이스에 존재할 수 있는 총 퍼시스턴트 볼륨 클레임 수
pod	네임스페이스에 존재할 수 있는 터미널이 아닌 상태의 파드의 총 수 .status.phase in (Failed, Succeeded)가 true인 경우 파드는 터미널 상태
replicationcontrollers	네임스페이스에 존재할 수 있는 총 레플리케이션 컨트롤러 수
resourcequotas	네임스페이스에 존재할 수 있는 총 리소스쿼터 수
services	네임스페이스에 존재할 수 있는 총 서비스 수
services.loadbalancers	네임스페이스에 존재할 수 있는 LoadBalancer 유형의 총 서비스 수
services.nodeports	네임스페이스에 존재할 수 있는 NodePort 유형의 총 서비스 수
secrets	네임스페이스에 존재할 수 있는 총 시크릿 수

 

• 위와 같이 오브젝트 수를 제한을 두는 경우는 리소스 자원 고갈 방지를 위함이다.
  • e.g.) 단일 네임스페이스에서 우선순위가 높지 않은 파드를 여러 개 생성하여 클러스터 파드 IP 자원이 고갈되는 경우 방지

 

• 리소스 개수에 대한 Resource Quota 생성 후 확인

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard:
    configmaps: "5"
    persistentvolumeclaims: "4"
    pods: "5"
    replicationcontrollers: "10"
    secrets: "5"
    services: "5"
    services.loadbalancers: "2"

 

 

• 쿼터 범위

범위	설명
Terminating	.spec.activeDeadlineSeconds >= 0 에 일치하는 파드
NotTerminating	.spec.activeDeadlineSeconds is nil 에 일치하는 파드
BestEffort	최상의 서비스 품질을 제공하는 파드
NotBestEffort	서비스 품질이 나쁜 파드
PriorityClass	지정된 Priority Class를 참조하여 일치하는 파드

 

• 각 쿼터에는 연결된 범위(scopes)가 존재할 수 있으며 지정한 범위와 일치하는 경우에만 리소스 사용량을 측정한다.
• 범위가 쿼터에 추가될 시 범위와 관련된 리소스 수가 제한된다.

 

 

• operator 필드 값
  • scopeSelector는 operator 필드에 아래 표의 값들을 지원한다.

필드 값	설명
In	values 필드에 설정한 값 중 레이블에 있는 값과 일치하는 것이 하나라도 있는지 확인
NotIn	In과 반대로 values에 있는 값 모두와 맞지 않는지 확인
Exists	key 필드에 설정한 값이 레이블에 있는지만 확인 (values 필드 필요 없음)
DoseNotExist	Exists와 반대로 노드의 레이블에 key 필드 값이 없는지만 확인 (values 필드 필요 없음)

 

 

• 이렇게 계속 뭐가 있다 있다.. 표만 보니 잘 와닿지가 않아 실습을 바로 진행해야..
• 🙌 K8s 공식문서의 예제를 따라 해 보았다! 🙌
  • 우선 순위 클래스별 리소스 쿼터 !

 

• ResourceQuota에 관한 매니페스트를 작성하였다.
  • 여기서 List라는 타입으로 여러 오브젝트를 한꺼번에 만들 수 있다는 새로운 경험 참 좋타.

apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-high
  spec:
    hard:
      cpu: 1000m
      memory: 1000Mi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["high"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-medium
  spec:
    hard:
      cpu: 500m
      memory: 500Mi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["medium"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-low
  spec:
    hard:
      cpu: 300m
      memory: 300Mi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["low"]

 

• 생성 및 확인 !

 

• 파드 priority class를 medium으로 주고 생성해보았다.
  • 파드의 priority class를 정의하는 방법 ⇒ Pod의 우선 순위

Pod의 우선 순위

 

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action
    resources:
      limits:
        cpu: 500m
        memory: 512Mi
      requests:
        cpu: 300m
        memory: 300Mi
	priorityClassName: medium

 

• 파드 생성 및 Quota 확인 !

 

• medium에 대한 우선 순위 쿼터가 적용된 pods-medium의 Used 통계가 변한 것을 확인할 수 있다 !

 

 

 

ref.

---

메모리, CPU 와 API 리소스 관리

리소스 쿼터