개요

emptyDir은 임시 볼륨 중 하나로, 노드의 자원을 사용하는 볼륨이 마운팅된다.
스펙에 메모리라고 명시하면 메모리 자원을 사용할 수 있게 되는데, 이 공간에 대해서 어떻게 구체적으로 제한을 걸 수 있을까?
어느 공간을 활용하는지, 그리고 어떤 제한에 걸리는지 각종 테스트를 진행해보려고 한다.

할당 자원 관리와 연관이 깊다.

환경

한 노드로 환경을 제한하여 나는 worker2 노드를 쓰기로 마음 먹었다.

할당 가능한 값만 단위 변환기를 통해 값을 내어봤다.

• 메모리
  • 2기가 가량
• 디스크
  • 30기가 가량

용량 테스트는 다음의 명령을 이용할 것이다.
처음 보는 명령어인데, 파일을 복사하고, 형식을 지정하거나 변환하는 작업을 할 수 있다.

이때 if에 입력할 파일을 지정하는데, /dev/zero는 무한히 null(0)을 찍어내는 파일이다.
of에는 출력할 파일을 지정하고, bs는 한번에 몇 바이트(블록)씩 쓸지 정한다.
count는 블록을 몇 번 쓸 지를 나타내는데, 이 경우에는 그냥 bs를 몇 번 반복할지를 정하는 거라 보면 되겠다.
그래서 위의 명령어는 1메가 * 10로, 10메가의 파일이 만들어지는 것이다!

디스크 테스트

apiVersion: v1
kind: Pod
metadata:
  name: empty-test
spec:
  nodeName: worker2
  containers:
    - name: test
      image: bash
      command: ['sh', '-c', 'echo "The app is running!" && tail -f /dev/null']
      volumeMounts:
        - name: empty
          mountPath: /test
  volumes:
    - name: empty
      emptyDir: 
        sizeLimit: 1Mi
        # medium: Memory

크게 하기는 싫어서 디스크 용량 단 1메비!
먼저 본격적으로 들어가기 전에 emptyDir의 데이터는 구체적으로 노드 어디에 저장될까?

파드 id는 f67~~이다.

이것만으로는 정보를 알기 어려워서 crictl을 조금 더 활용하는 중이다.
이름이 어떤 경로를 가지는지 몰라서 일단 경로를 출력해봤다.

첫번째 친구구만.

는 inspectp는 내부 컨테이너에 대한 정보를 잘 안 보여준다고 합니다..

그래서 그냥 컨테이너 id로 inspect 때렸다.
원래 파드가 실행될 때 생기는 각종 데이터는 /var/lib/kubelet에 저장된다고 했는데, 실제로도 그러하다!

이렇게 디렉토리가 제공된다.

emptyDir에 크기가 명시된 경우

사이즈 리밋을 넘기는 값을 파일을 만드니 대충 10초 정도 있다가 종료됐다.

파드는 실패했고, 그 이유는 축출, emptyDir이 크기를 넘었다고 메시지가 나온다.

컨테이너에만 크기가 명시된 경우

이번에는 컨테이너 리소스로 사이즈를 명시한다.
사실 이 결과도 역시 뻔할 것이다.

사실 내가 궁금한 건 구체적으로 이 상황이다.
여러 컨테이너가 볼륨 마운팅을 하고 있는 상황이라면?
이때 볼륨에 데이터를 채워넣는다면 무슨 일이 발생하는가?

crictl stats로 상황을 추적해본다.
내 예상과는 다르게, 마운팅된 공간에 대한 디스크 사용량은 제대로 측정되지 않고 있다.
내가 아무리 파일을 만들어도 여기에서의 값에는 변화가 없다.

아예 측정이 안 되고 있는 건가 해서 마운팅된 공간이 아닌 곳에서 파일을 만들어보니 제대로 측정되는 것이 보인다.
일단 전체 사용량을 넘기니 파드는 실패했다.

emptyDir 볼륨 사용량은 어떻게 추적되는가

음.. 이거 볼륨의 상태를 추적할 방법을 모르겠다.
의아해서 찾아봤는데 실제로도 지금 emptyDir의 사용량 상태를 추적하는 메트릭이 존재하지 않는다;;^[1]
그러나 이건 이를 노출하는 api가 만들어지지 않은 것일 뿐, 분명히 어떻게든 사용량은 추적되고 있다.
위에서 실험을 통해 사용량이 체크된다는 것을 알 수 있었다.
이를 활용해서 Prometheus로 데이터를 보내는 익스포터^[2]를 만든 사람도 있다.
이것에 대해 코드 단위로 조금 추적을 해보았다.

kubelet쪽 코드는 어후.. 고린이 입장에서 너무 어려워서 결국 ide의 힘을 빌려가면서 코드를 추적했다.
이게 거의 시작점이다.

궁극적으로 도달하는 부분은 리소스 애널라이저이다.
이 중간에는 summary를 만드는 것과, 이를 제공하주는 cri 프로바이더를 거쳐간다.
궁극적으로는 cri 프로바이더가 제공된 인터페이스에 맞게 리소스를 분석하는 기능들을 구현해주면 된다.

조금 헷갈렸는데, 정확하게 현재 상황에 축출을 시키는 코드는 이쪽이다.
파드의 임시 스토리지 제한 양을 정해둔 상태로, 각종 emptyDir을 포함한 각종 값의 총합이 제한을 넘어가면 축출을 시키는 것이다.
위에 실컷 봤는데, 결국 stats에 대한 analyze 코드를 만드는 것은 cri를 구현하는 측이므로 kubelet에서는 더 이상 확인할 방법이 없다.
내가 사용하는 것은 Containerd이니까 이 코드를 뜯으면 드디어 내가 원하는 정답에 이를 것이다.

메모리 테스트

디스크를 테스트하면서 코드를 뜯다보니 사실 비슷하게 동작할 것이라 짐작한다.
어차피 cpu와 메모리가 제한을 넘길 때 일어나는 상황이 다른 거지, 메모리가 제한을 넘길 때 일어난다는 상황이 디스크 사용량이 넘어갈 때도 똑같이 일어났다.
그래서 이쪽은 이 문서에서 추가적으로 테스트하지는 않겠다.
이 문서는 emptyDir을 테스트하는 것이 핵심 목적이다.

결론

나는 emptyDir에는 제한이 없는데 여러 컨테이너에 제한이 걸린 상황에서 해당 볼륨에 데이터가 쌓이면 이게 각 컨테이너의 디스크 사용량으로 잡힐까 궁금했다.
결론적으로, 컨테이너의 디스크 사용량과 emptyDir 사용량은 서로 측정 상 관계가 없다.
그러나 이들의 총합을 통해 파드가 전체 사용할 수 있는 제한 양을 지정하기에, 간접적으로는 영향이 있다고 할 수 있겠다.
가령 컨테이너가 디스크를 총 1기가를 쓸 수 있도록 제한을 걸었는데, 막상 컨테이너는 그만큼 사용하지 않았으나 임시 볼륨이 이를 넘겨서 파드가 실패하는 상황이 발생할 수 있다.

그렇다면 실제로 일어날 수 있을 만한 위험 상황은 무엇이 있을까?
대체로 디스크 사용량에 대한 제한을 걸진 않을 것이라고 생각한다.
(물론 거는 사람이라면 당연히 고려해야 한다.)
그러나 emptyDir을 메모리로 사용할 때는 다양한 문제가 발생할 여지가 있다.
메모리의 제한을 걸어두는 사용 케이스는 충분히 있을 수 있다.
이때 emptyDir을 메모리로 두게 되면 예상보다 더욱 빠르게 제한을 넘기게 될 수 있다.

이에 대한 예방책은 다음과 같다고 생각한다.

• 메모리로 기반 emptyDir 사용은 정말 적은 용량으로 활용되도록 국한한다.
• emptyDir에 사이즈 리밋을 건다.
  • 파드가 실패하더라도 실패하는 원인을 명확히 할 수 있다.
  • 파드 제한 총량에 반영이 될 것이기에 컨테이너의 메모리 자원에 대해서는 컨테이너의 사용량만 고려할 수 있다.

관련 문서

참고