쿠버네티스 | Pod 자원관리

오늘은 쿠버네티스 리소스 자원관리에 대해서 정리를 해보려고 합니다.

이전에 쿠버네티스 아키텍처를 소개할 때, 쿠버네티스에서 Pod를 어떤 노드에 배포하게 될지는 스케줄러가 정하게 된다고 말씀을 드렸습니다.

스케줄러는 Pod를 배포할 수 있는 여유가 있는 노드로 배포하게 되는데, 이때 각 노드가 여유가 있는지를 판단하는 기준은 각 노드의 CPU, Memory의 사용량 등이 이용됩니다.

따라서 목표는 스케줄러가 어떤 기준으로 노드를 선별하게 되는지 알아보는 것이지만, 그전에 결국 노드의 자원은 노드에 띄워져 있는 쿠버네티스 리소스들의 자원의 합계치 임으로 리소스에 대한 자원을 먼저 알아보도록 하겠습니다.

 

리소스 단위

---

Pod의 리소스를 설정하게 되면 다음과 같습니다.

apiVersion: v1
kind: Pod
metadata:
  name: resource-limit-pod
  labels:
    name: resource-limit-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    resources:
      limits:
        memory: "256Mi"
        cpu: "1000m"

위의 코드처럼 Pod의 리소스를 지정한다는 것은 Pod안에서 동작하는 컨테이너에 리소스를 정의하는 것입니다.

• 컨테이너 리소스 관리

 

사용되는 리소스의 단위는 다음과 같습니다.

• cpu : 1000m(밀리 코어) == cpu : 1 Core
• memory : 256Mi == memory : 256Mb

 

Request와 Limit

---

Pod의 resources부분을 작성하다 보면 Request와 Limit가 존재하는 것을 알 수 있습니다.

그렇다면 이 둘의 차이는 어떤 점이 있는지 알아보도록 하겠습니다.

 

pod request & limit

 

위의 그림은 Memory를 Request:500Mb, Limit:750Mb를 지정한 Pod를 예시로 들었습니다.

그림에서 처럼 해당 Pod는 기본적으로 Memory를 500Mb 사용을 보장하되 더 많은 Memory를 필요로 할 경우에는 최대 750Mb까지 사용할 수 있는 것을 나타냅니다.

 

정리해 보면

Request는 적어도 이 만큼의 자원은 컨테이너에게 보장돼야 한다는 것을 나타냅니다. 

Limit는 유휴 자원이 있다면 최대 이 만큼의 자원까지 컨테이너가 사용할 수 있다는 것을 나타냅니다. 

 

Memory

---

지금과 같은 경우는 container가 1개인 경우를 나타냈지만 container가 여러 개일 경우 각 자원들을 효율적으로 쓸 수 있는 방법을 생각해볼 필요가 있습니다.

 

 쿠버네티스에서는 Request는 자원의 오버커밋을 가능하게 만들어 줍니다.

한정된 컴퓨팅 자원을 효율적으로 사용하기 위한 방법
(즉, 사용할 수 있는 자원보다 더 많은 양을 가상 머신이나 컨테이너에게 할당함 으로 써 전체 자원의 사용률을 높이는 방법)

 

간단한 예시를 들어보도록 하겠습니다.

 

 

위의 그림의 2개의 컨테이너는 각각 Limit를 500MB까지 지정해두었습니다.

실제 사용량을 보면 A컨테이너는 100MB 그리고 B컨테이너는 500MB로 최대치를 사용하고 있습니다.

 

하지만 위와 같은 경우 A컨테이너의 400MB만큼의 자원을 사용하고 있어 남는 자원이 됐지만, B컨테이너는 Limit를 500MB로 잡아두었기 때문에 남는 자원을 추가적으로 사용할 수 없게 됩니다.

 

이때 오버커밋을 통해 실제 물지 자원보다 더 많은 양의 자원을 할당하는 기능을 제공합니다

 

 

위의 그림은 Request를 통해 각 컨테이너는 500MB의 리소스 자원을 보장받고, 최대 750MB까지 사용할 수 있도록 적용하였습니다.

 

오버커밋을 적용하여 B컨테이너의 경우 500MB보다 더 많은 자원을 사용할 수 있게 되었고, 이전의 그림보다 자원을 효율적으로 사용할 수 있게 되었습니다.

 

하지만 위와 같이 지정을 하였을 경우 하나 문제점이 생길 수 있습니다. 

 

위의 그림처럼 컨테이너 A, B 둘 다 Request로 보장받은 범위 내에서 리소스를 사용한다면 문제는 없을 것입니다.

 

하지만 다음 그림과 같다면 어떨까요?

 

위의 그림처럼 Limit는 750MB로 지정했기 때문에 컨테이너 B가 컨테이너 A의 자원을 침범하게 될 경우 메모리 사용은 실패하게 됩니다.

 

이와 같은 경우에는 쿠버네티스는 가용 메모리를 확보하기 위해 우선순위가 낮은 Pod 또는 프로세스를 강제로 종료하도록 설계되어 있습니다. 강제로 종료된 Pod는 다른 노드로 옮겨가게 되는데 이를 퇴거(Eviction)라고 표현합니다.

 

CPU

---

CPU 또한 Memory와 같이 Request, Limit의 사용이 동일하나 한 가지 차이점이 존재합니다.

 

이전 Memory와 같이 컨테이너 B가 Limit인 750(0.5 core)을 사용 중일 때, 컨테이너 A에서 500m(0.5 core)의 CPU를 사용하려고 한다고 가정해봅시다.

이때 Memory와 차이점이 발생하는데 CPU의 경우에는 컨테이너 A가 500m(0.5 core)의 CPU를 사용하려고 시도할 때 

CPU 스로틀(throttle)이 발생하게 됩니다.

 

따라서 컨테이너 A는 CPU를 지정된 Request만큼 사용할 수 있게 됩니다.

 

쿠버네티스에서는 CPU를 압축 가능한(compressible) 리소스라고 부릅니다.
Request보다 더 많은 CPU를 사용해 CPU경합이 발생하더라도 컨테이너의 CPU 사용량을 스로틀(throttle)을 통해 억제할 수 있기 때문입니다.

이와 반대로 Memory나 Storage는 압축 불가능한(incompressible) 리소스라고 부릅니다.
컨테이너 간 Memory 사용의 경합이 발생하면 우선순위가 낮은 컨테이너의 프로세스가 먼저 종료되기 때문입니다.

 

이번 시간에는 리소스의 자원에 대해서 정리를 해보았습니다.

정리하면서 쿠버네티스는 가용메모리를 확보하기 위해 우선순위가 낮은 Pod 또는 프로세스를 강제로 종료하고, 강제로 종료된 Pod는 다른 노드로 옮겨가게 된다고 하였습니다.

다음 시간에는 쿠버네티스에서는 노드에 메모리 자원이 부족해지면 어떤 포드나 프로세스가 먼저 종료되는지에 관한 내용을 정리해보도록 하겠습니다.

 

참고자료

---

• https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/
• https://github.com/alicek106/start-docker-kubernetes
• https://bcho.tistory.com/1347?category=731548