Kubernetes 기초 - Scheduling(2)

1. NodeSelector
2. Affinity and Anti-affinity
3. Pod Overhead          ←  오늘 볼 내용
4. 파드 스케줄링 준비성(Readiness)
5. 파드 토폴로지 분배 제약 조건
6. Taints and Tolerations
7. cordon and drain

---

3. Pod Overhead

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/pod-overhead/

파드 오버헤드

 

 

우리가 알다시피 파드가 동작할 때 컴퓨팅 리소스를 필요로 한다.

내부의 컨테이너가 무엇을 사용하냐에 따라 리소스의 사용량이 달라진다.

예를 들어 nginx 컨테이너는 어떻게 사용하는지에 따라 리소스 사용량이 달라지겠지만 우리가 테스트용으로 잠깐 nginx 컨테이너를 실행하는데 100Mi 메모리만 있으면 충분하다.

 

하지만 지금 살펴볼 파드 오버헤드는 그런 컨테이너들이 사용하는 리소스에 대한 이야기가 아니라 파드 자체를 구동하기 위해 노드가 사용하는 리소스를 말하는 것이다.

파드 오버헤드가 고려하는 리소스는 파드의 인프라에 필요한 것으로, 컨테이너가 실행되는 데 필요한 CPU나 메모리 등의 리소스를 제외한 것이다.

예를 들어, 파드의 네트워크 인터페이스, 파드를 실행하고 관리하는 데 필요한 커널 리소스, 파드의 메타데이터와 로그 저장 등에 필요한 리소스가 이에 해당할 수 있다.

이러한 리소스는 파드가 정상적으로 실행되고, 쿠버네티스 클러스터가 파드를 관리하고 모니터링하는 데 필요하다.

 

파드의 인프라 자체가 소비하는 리소스는 파드가 스케줄링하기 전 어떤 컨테이너 런타임을 사용하는가에 따라 달라진다.

컨테이너 런타임은 RuntimeClass를 통해서 결정할 수 있으며 RuntimeClass API리소스를 생성한 이후 파드 템플릿에 생생성한 runtimeClass를 기재하여 기본 컨테이너 런타임이 아닌 다른 컨테이너 런타임으로 컨테이너를 운영할 수 있게 한다.

그러기 위해서는 기존에 각 노드들에게 다른 컨테이너 런타임도 설치가 되어있어야 한다.

 

파드 오버헤드는 구체적으로 무엇으로 인해 리소스를 사용하는가 하면 다음과 같다.

• 네트워크 네임스페이스 및 IP 주소 공간 : 각 파드는 독립된 네트워크 네임스페이스를 가지고 있으며, 고유한 IP 주소 범위를 사용한다.
• IPC(Inter-Process Communication) 네임스페이스 : 파드 내의 컨테이너는 독립된 IPC 네임스페이스를 가지며, 프로세스 간 통신을 위한 격리를 제공한다.
• 호스트명 및 도메인 : 파드 내의 컨테이너는 동일한 도메인에 속하며, 고유한 호스트명이 할당된다.
• 파일 시스템 : 파드는 각 컨테이너 간에 공유되는 파일 시스템을 가지고 있다.
• 프로세스 관리 및 cgroup(Control Group) : 각 파드 내의 컨테이너는 프로세스 관리를 위해 별도의 cgroup을 가지고 있다.
• Kubelet 및 기타 에이전트 : Kubernetes 클러스터 내에서 파드의 라이프사이클 및 관리를 담당하는 Kubelet 및 다른 에이전트도 파드 오버헤드에 포함된다.

이와 같은 파드 외적으로 파드가 실행되기 위해 발생하는 시스템 리소스들을 파드 오버헤드라고 한다.

 

 

 

실습

실습으로 RuntimeClass를 생성하고 파드 템플릿에 기재하여 구성하는 실습을 해보자.

실습 내용은 쿠버네티스 공식문서를 기반으로 한다.

# kata-fc.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: kata-fc
overhead:
  podFixed:
    memory: "120Mi"
    cpu: "250m"

 

 

위 yaml코드에서 kata-fc(Kata Containers)는 경량 가상화 기술을 사용하여 컨테이너를 격리하는 데 사용되는 오픈 소스 프로젝트다.

이 기술은 가상 머신과 컨테이너를 결합하여 안전하고 격리된 환경을 제공하는 것을 목표로 하고 있다.
여러 컨테이너 런타임이 존재하는데, Kata Containers는 이 중 하나로써, 가상 머신 기반의 격리를 제공한다.

기존의 컨테이너는 호스트 운영 체제의 커널을 공유하여 가벼운 격리를 제공하는 반면, Kata Containers는 각 컨테이너에 대해 별도의 가상 머신을 사용하여 더 강력한 격리를 구현한다.

 

어쨌든 내용을 해석하자면 다음과 같다.

kata-fc라는 컨테이너 런타임을 생성하는데 파드를 구성할 때 사용할 오버헤드를 파드 당 120Mi의 메모리와 250m의 CPU로 고정하겠다는 의미다.

 

다음은 파드 템플릿을 작성해보자.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  runtimeClassName: kata-fc
  containers:
  - name: busybox-ctr
    image: busybox:1.28
    stdin: true
    tty: true
    resources:
      limits:
        cpu: 500m
        memory: 100Mi
  - name: nginx-ctr
    image: nginx
    resources:
      limits:
        cpu: 500m
        memory: 100Mi

 

위 yaml코드를 해석하자면 다음과 같다.

runtimeClassName을 기재하여 어떤 런타임 클래스를 사용할 것인지 지정할 수 있는데 파드를 생성하기 전 kata-fc라는 런타임 클래스를 생성하였기 때문에 해당 런타임 클래스를 사용하겠다는 의미다.

busybox 컨테이너에 stdin과 tty라는 필드에 true라는 값은 각각 표준입력과 터미널을 활성화하라는 의미다.

또한 해당 컨테이너가 사용할 수 있는 최대 리소스를 cpu 500m, memory 100Mi로 제한한다.

두번째 컨테이너는 nginx 컨테이너로 최대 리스소 사용량을 cpu 200m, memory 100Mi로 제한한다.

 

파드를 실행한 이후 다음 명령을 실행한다.

kubectl get pod test-pod -o jsonpath='{.spec.overhead}'

 

현재 오버헤드에 할당된 리소스를 나타낸다.

kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 overhead 와 해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다.

이 예제에서, 스케줄러는 리소스 요청과 파드의 오버헤드를 더하고, 1.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다.

일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 cgroup을 생성한다.

기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다.

 

다음 내용을 실행해서 컨테이너가 요청한 리소스를 확인해보자.

kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'

 

 

결과를 보면 1250 m의 CPU와 320 MiB의 메모리가 리소스로 요청되었다.

여기에는 파드 오버헤드가 포함되어 있다.

kubectl describe node | grep test-pod -B2

 

 

 

 

현재 나의 경우는 컨테이너 런타임으로 설정한 kata-fc가 제대로 구동하지 않는 문제때문에 파드가 정상적으로 실행중인 상태는 아니다(나만 그런건지는 모르겠다).

공식문서에 cgroup을 통해서도 오버헤드를 포함한 리소스 사용량에 대해서 확인할 수 있는 예제가 있다.

자세한 내용은 공식문서를 참고하고 이 내용은 개념적으로만 알고 있으면 좋을 듯하다.

 

 

---

kata-fc(kata containers)에 대한 내용

https://github.com/kata-containers/kata-containers/blob/main/tools/packaging/kata-deploy/README.md

 

kata containers 공식 문서

https://katacontainers.io/docs/

Technical Documentation - Tech Docs - Kata Containers