[Kubernetes] 로그 때문에 노드 디스크가 부족하면? 이미지가 노드 디스크를 전부 차지하면 어떡하지? - Disk Pressure 예방하기

 

 

 

예전부터 쿠버네티스를 관리하는 데 있어서 궁금한 점이 있었습니다.

 

"엄청 나게 많은 로그를 생성하는 애플리케이션들로 인해 노드의 디스크가 부족해지면 어떡하지?"

 

"계속 새로운 컨테이너 이미지를 다운 받아서 그로 인해 노드의 디스크가 부족해지면 어떡하지?"

 

노드의 디스크가 부족하게 되면 노드에서 DiskPressure 라는 메시지를 뱉게 될 것입니다.  그런데 궁금한 요점은 디스크가 부족할 때 "어떻게 해결하냐" 가 아니고 "어떻게 예방하냐" 입니다. 

 

그래서 이번 글에서는 예방하는 방법에 대해 알아보고자 합니다.

 

렛츠두더코드~

 

 

저는 개인적으로 쿠버네티스를 관리하면서 가장 중요시하게 생각하는 키워드가 있습니다.

바로 일시적(empheral) 과 동적(Dynamic) 입니다.

 

예를 들어, 쿠버네티스의 가장 기본 단위인 파드는 언제, 어디서든 정상적인 종료가 될 수 있어야 하는 상태를 유지하고 있어야 하며, 종료 되었을 때 다른 리소스에 영향이 없어야 합니다. 이후 다시 생성되더라도 이전 상태를 유지할 수 있게끔 구성을 해야 합니다. 

pod, pvc, sc, efs 의 관계

 

파드의 상태를 유지하는 가장 효과적인 방법은 Storage Class, PV 그리고 PVC 를 이용하는 것 입니다. 

더 나아가 NFS 와 같은 네트워크 파일 시스템을 도입하면 쉬우면서 효율적으로 클러스터 내 데이터를 관리할 수 있습니다.

 

어느 노드에 파드가 실행되든 지 Stateful 한 상태를 유지할 수 있게 되죠.

 

AWS EFS 를 이용해서 Storage Class, PV 관리하는 방법이 궁금하다면 여기!

 

그런데 문제는 우리가 흔히 kubectl logs 명령어를 써서 보는 컨테이너의 로그들은 컨테이너 내부에 저장되지 않습니다.

 

Nginx 로 살펴보면 리눅스 표준 출력인 stdout 으로 로그가 출력됩니다. 

nginx 컨테이너

 

access.log 와 error.log 가 각 stdout, stderr 와 소프트 링크 되어 있습니다.

 

따라서 이러한 표준 출력은 파드에 저장되지 않아, NFS 와 같은 파일 시스템을 활용할 수 없습니다.

 

여기서 잠깐!

파드의 Sidecar Pattern 을 이용해서 Sidecar 컨테이너에 따로 로그를 저장해 NFS 를 활용할 수 있겠지만, 매번 배포해야 하는 파드에 Sidecar 컨테이너를 추가해야 하는 번거로움이 있죠.

그치만 이 방법도 아주 좋은 방법이라고 생각합니다.

 

간단하게 한번 다뤄보도록 하죠.

 

사용할 yaml 은 아래와 같아요!

apiVersion: v1
kind: Pod
metadata:
  name: nginx-sidecar
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: log
          mountPath: /var/log/nginx
    - name: sidecar-access
      image: busybox
      args: [/bin/sh, -c, 'tail -n+1 -f /var/log/nginx/access.log']
      volumeMounts:
        - name: log
          mountPath: /var/log/nginx
    - name: sidecar-error
      image: busybox
      args: [/bin/sh, -c, 'tail -n+1 -f /var/log/nginx/error.log']
      volumeMounts:
        - name: log
          mountPath: /var/log/nginx
  volumes:
    - name: log
      emptyDir: {}
  nodeSelector:
    kubernetes.io/hostname: k8s-worker-3

 

도식화하면 아래와 같죠!

Nginx 컨테이너와 2개의 사이드카 컨테이너

 

 

Nginx 컨테이너에서 curl 명령어를 통해 localhost 로 접근하여 표준 출력을 얻게 되고,

 

Sidecar access 컨테이너로 접속해서 access.log 를 확인해보면 아래와 같은 로그가 입력된 것을 확인할 수 있습니다.

 

그럼 다음 Fluentd 나 Loki 를 이용해서 로그 데이터를 수집해나가면 됩니다.

 

하지만 위에서 언급한 바와 같이 사이드카를 추가해야 한다는 불편함이 있습니다. (저만 불편한 것일 수도..)

 

 

로그로 인한 디스크 부족

---

 

그럼 다시 본론으로 돌아오겠습니다.

 

stdout 으로만 로그가 출력된다고 해서 로그를 파일로 확인할 수 없는 것은 아닙니다. 파드가 실행되고 있는 노드에 접근하면 관련된 로그를 파일로 확인 할 수 있습니다.

 

/var/log/pods

 

보통 노드의 /var/log/pods 에 저장됩니다

 

따라서 파드 내에 로그가 저장되지 않더라도 노드에 저장이 되고, 로그가 지속적으로 쌓이게 된다면 충분히 노드에 디스크가 부족해지는 상황이 발생할 수 있습니다.

Nginx 가 실행되고 있는 노드에 직접 접근해서 확인 가능

 

default_nginx_ 뒤에 있는 난수는 Pod 의 Uid 입니다
crictl ps 와 crictl inspect <cotainer_id> | grep "uid" 로 알아 낼 수 있죠.

 

EKS 를 이용해서 노드들을 구성할 때, 모범 사례는 SSH 로 인한 접근을 막는 것입니다. 따라서 SSH 접근이 불가능한 경우 직접적으로 로그를 삭제하는 것이 불가능하죠. 계속 쌓여만 갈 것입니다. 

 

EC2 Userdata 를 이용해서 CronTab 과 스크립트를 이용해서 특정 기간 동안 액세스 되지 않은 로그를 삭제하는 방법도 있을 수 있겠지만, 이것도 썩 내키는 방법은 아닙니다. 

 

 

컨테이너 이미지로 인한 디스크 부족 

---

 

바로 위에선 축적된 로그로 인해 노드에 디스크 부족이 발생할 수 있는 상황을 봤다면, 이번에는 컨테이너 이미지로 인해 디스크 부족이 발생할 수 있는 상황을 살펴보겠습니다.

 

노드 접속해서 crictl 명령어를 통해 이미지들의 사이즈를 볼 수가 있습니다.

다운로드 된 이미지들

 

현재 사용하는 이미지라면 상관없지만, 분명 노드에서 삭제되어 불필요한 이미지가 있는 경우도 있을 겁니다.

 

예를 들어, Nginx 1.23 버전을 쓰고 있다가 똑같은 노드에서 1.24 버전으로 업그레이드 한다면 이전 이미지는 더 이상 쓸모가 없고 용량만 차지하고 있게 되죠.

 

따라서 이러한 불필요한 이미지들이 쌓이면 마찬가지로 노드는 금방 용량이 부족해 질 것입니다.

 

 

디스크 부족 미리 예방하기

---

 

우선 축적된 컨테이너 이미지로 인한 디스크 부족에 대해 예방하는 방법을 알아보겠습니다.

 

아마 EKS 든, 로컬 쿠버네티스 든 이미 이 예방 방법은 사용하고 계실 겁니다.

 

바로 가비지 컬렉터 입니다.

 

가비지 컬렉터는 Kubelet 에 내장되어 Kubelet 이 실행되고 있는 노드에서 이미 사용되고 있습니다. 쿠버네티스에서의 가비지라 하면 종료된 잡, 고아 오브젝트, 사용되지 않는 컨테이너와 컨테이너 이미지, 볼륨 등이 있습니다.

 

https://kubernetes.io/ko/docs/concepts/architecture/garbage-collection/

 

 

가비지 컬렉터가 노드 내에서 불필요한 이미지를 모두 삭제해주었던 것이죠.

 

그럼 진짜 불필요한 이미지가 삭제되는 지 한번 알아보죠!

 

aws-cli 를 이용하는 파드를 배포함에 따라 노드에는 aws-cli 컨테이너와  aws-cli 이미지가 설치되어 있는 것을 확인할 수 있습니다.

aws-cli 컨테이너

aws-cli 이미지

 

istio-proxy 는 이스티오에 의해 자동 주입 되어서 존재합니다.

 

그리고 아래와 같은 폴더에 이제 stdout 으로 출력되는 데이터들을 저장하고 있죠.

노드에 직접 저장되어 있는 표준 출력

 

컨테이너 이미지, 로그 모두 노드의 직접적인 디스크를 차지하는 걸 확인 할 수 있습니다.

 

이후, 이제 다시 aws-cli 파드를 삭제하겠습니다. 그럼 Kubelet 이 아래와 같은 로그를 출력하면서 관련 컨테이너와 로그가 저장되어 있는 볼륨 등을 삭제하는 것을 확인 할 수 있습니다.

kubelet 로그

 

journalctl | grep -i "kubelet" 을 통해 kubelet 의 로그를 관찰 할 수 있습니다.

 

공식 문서에 나와 있는 것처럼  사용되지 않는 컨테이너에 가비지 수집은 1분마다 수행되는 것을 확인 했습니다. 그리고 로그 또한 삭제되었죠.

사용되지 않는 컨테이너와 이미지 가비지 수집

 

그런데 문제는 5분이 지나도 사용되지 않는 이미지는 그대로 남아 있었습니다. 그래서 한번 kubelet 의 config 를 수정 해보도록 했습니다.

https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration

 

위 옵션들이 이미지와 관련된 옵션인 거 같아서 해당 부분을 수정해주었습니다.

/var/lib/kubelet/config.yaml

 

kubectl 의 config 위치는 /var/lib/kubelet/config.yaml 입니다.

 

 

imageMinimumGCAge 은 지정된 시간만큼은 가비지 컬렉터에 의해 삭제되지 않는 옵션입니다. 여기서 중요한 건 imageGCHighThresholdPercent 와 imageGCLowThresholdPercent 입니다.

 

imageGCHighThresholdPercent 은 기본값이 85인데 현재 노드의 남아있는 디스크 용량을 퍼센트로 계산해서 85 이상이라면 가비지 컬렉터가 항상 실행되게끔 하는 옵션이고, imageGCLowThresholdPercent 은 반대로 주어진 값보다 낮다면 실행되지 않는 옵션입니다.

 

가비지 컬렉터가 항상 실행될 수 있도록 imageGCHighThresholdPercent 은 1, imageGCLowThresholdPercent 은 0 을 부여했습니다.

 

변경된 옵션이 적용될 수 있도록 kubelet 을 재실행을 해주었습니다. 다행히 무사히 동작하네요.

systemctl status kubelet

kubelet 을 재시작하는 명령어는 systemctl restart kubelet 입니다.

 

이후 다시 crictl images 명령어로 확인해 본 결과, aws-cli 뿐만 아니라 이외에 사용하지 않는 모든 이미지가 삭제되었습니다. 마침 docker image prune 과 같은 효과였죠.

crictl images

 

이렇게 가비지 컬렉터로 인해 노드 내에 불필요한 컨테이너 이미지, 볼륨 리소스들을 정리하여 지속적으로 디스크를 확보할 수 있습니다.

 

그럼 다음으로 노드에 축적된 로그를 인한 디스크 부족을 예방해보겠습니다.

 

여기서 다시 한번 일시적(empheral) 과 동적(Dynamic) 이라는 키워드를 상기합니다.

 

이번에는 아쉽게도 가비지 컬렉터의 도움을 받을 수 없습니다. 현재로썬 로그를 지워주는 특별한 무언가도 존재하지 않습니다. (있다면 꼭 알려주세요!)

 

보통 Cloud 환경에서 쿠버네티스를 운영하고 계실 겁니다. EKS 같은 경우는 Karpenter 를 이용해서 노드들을 스케일 아웃하거나 스케일 업을 하고 계실 겁니다.

 

그리고 노드에 저장되는 데이터는 보통 로그 와 같은 데이터이지, 애플리케이션 실행에 중요하진 않습니다.

 

그렇다면  로그 데이터는 미리 Fluentd, Loki, AWS Cloudwatch 와 같은 로그 중앙 시스템에 몰아 넣고, 애플리케이션 실행에 중요한 데이터는 PVC 를 이용하면 됩니다. 이 말은 즉슨, 더 이상 노드에 가치 있는 데이터가 없다는 뜻입니다.

 

그냥 노드를 종료시키고 다시 실행시켜 버리면 됩니다. 이렇게 해도, 이미 이전 노드에 있던 로그 데이터들은 로그 중앙 시스템에 저장되어 있고, 애플리케이션에 필요한 중요한 데이터들은 PVC 를 통해 EFS 에 저장되어 있죠.

 

이 방법은 분명 일시적(empheral) 이면서 동적(Dynamic) 입니다.

 

그리고! Karpenter 는 분명 이러한 기능을 제공하죠!

 

아래는 Karpenter 리소스 중 하나인 NodePools 의 일부분 입니다.

https://karpenter.sh/docs/concepts/nodepools/

 

Karpenter v0.32 버전부터 Provisioner 가 NodePools 로 변경되었습니다.

 

Karpenter 가 궁금하다면 여기!

 

 

expireAfter 이 720h 로 정의되어 있는데, 그 말은 즉슨, 30 일 뒤에 해당 노드를 종료하고 새롭게 띄운다는 옵션입니다.

expireAfter 옵션

 

이렇게 함으로써 오래 지속된 노드에 대한 보안 취약점을 없앨 수 있고, 또한 file fragmentation 과 memory leaks 도 방지할 수 있습니다.

 

노드가 종료되기 직전까지 지속적으로 로그 중앙 시스템에 로그를 저장하고, 노드를 통째로 종료시키면서 아예 이전 로그 데이터를 날려버리는 거죠. 그리고 또 새롭게 생성된 노드에서 로그를 수집하면 됩니다.

 

그런데 여기서 하나 문제가 또 있습니다. Karpenter 를 이용하지 않는 로컬 쿠버네티스 환경은 어떡하냐는 것이죠. CronTab 과 스크립트를 짜야하는 것일까?..

 

다행히 여기도 해결책이 존재합니다. Kured(KUbernetes REboot Daemon) 라는 프로젝트가 바로 그 해결책이죠. 직접 사용해보진 않았지만, 이름에서 알 수 있듯이 특정 기간마다 데몬이 돌아가는 노드를 재부팅 해주고 그에 따라 불필요한 데이터가 삭제되는 것을 기대해 볼 수 있습니다.

 

24년 1월 08일 기준 SandBox 이긴 하지만 CNCF 프로젝트 중 일부이기 때문에 쿠버네티스와도 호환성이 뛰어날 것으로 예상됩니다.

 

https://github.com/kubereboot/kured

 

 

계속해서 쌓이는 로그 데이터나 컨테이너 이미지로 인해 쿠버네티스가 망가지면 어떡하지? 라는 걱정을 해왔는데, 이로써 모두 해소할 수 있었습니다.

 

쿠버네티스라는 녀석은 까면 깔 수록 참 재밌는 녀석인 것 같습니다. 짜식..

 

그럼 오늘은 여기까지~

 

 

ps. Karpenter 의 NodePools 로 Kubelet 의 Config 값도 설정할 수 있습니다! 

예제에 나와있는 옵션 말고도 쿠버네티스 공식 문서에 나와있는 옵션들도 추가해도 됩니다.

https://karpenter.sh/docs/concepts/nodepools/