[Kubernetes] MinIO Custom PV 연결

5 분 소요


문제

  • MLOps 시스템이 배포된 회사 현장 중 한 곳에서 K3s 클러스터 내 MLOps 워크플로우 실행이 중지되는 현상 발생

    보통 이런 경우, 경험적으로 CPU 사용량, 디스크 사용량을 먼저 확인해야 함

  • 루트 파티션 용량 부족 확인 minio-root-partition-storage

  • MLOps 시스템 내 오브젝트 스토리지로 MinIO 사용 중
    • helm을 이용해 배포
    • 추출한 프레임, 각 프레임 별 annotation json을 저장하는 용도로 사용
  • MinIO가 루트 파티션 내 디렉토리들을 PV로 사용함에 따라 루트 파티션 과부하 발생

    k3s-storage-pv

    참고: 왜 이 디렉토리를 PV로 사용했는가

    • 후술할 항목에서와 같이 values.yaml의 mode 항목 값을 distributed로 주고 배포했기 때문
    • MinIO가 statefulset으로 배포되어 있었는데, 배포에 사용한 helm chart 버전에서 values.yaml의 mode 항목 기본값이 distributed였음
  • 목표: SSD를 추가하고 해당 경로를 MinIO PV로 연결하여 루트 파티션 부담 해소


해결

다음과 같은 해결 전략을 이용해 위의 문제 상황을 해결하고자 함

  1. SSD 설치 및 /mnt/data 마운트
  2. PV 디렉토리 생성 및 권한 설정
  3. MinIO 재배포
    • PV/PVC 매니페스트 작성 후 적용
    • MinIO values.yaml 수정 후 재배포


디스크 증설 후 마운트

SSD 설치

ssd

설치할 녀석들

ssd-installation

SATA 포트를 통해 장착


SSD 인식 확인

서버에 SSD를 물리적으로 장착한 뒤, 리눅스에서 디스크 인식 여부 확인

sudo fdisk -l
Disk /dev/sda: 1.82 TiB, 2000398034016 bytes, 3907029168 sectors
Disk model: Samsung SSD 870
Units: sectors of 1 * 512 = 512 bytes
...
Disk /dev/sdb: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 870
Units: sectors of 1 * 512 = 512 bytes
  • 새로 장착한 SSD가 /dev/sda, /dev/sdb 등으로 표시되는지 확인
  • 만약 인식되지 않으면 케이블 연결, SATA 포트 등을 점검해야 함


파티션 생성 및 포맷

fdisk를 이용해 새 SSD에 파티션을 생성하고, ext4 파일 시스템으로 포맷해야 함

sudo fdisk /dev/sda
  • npEnterEnterw 순서로 파티션 생성 후 저장


sudo mkfs.ext4 /dev/sda
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 488278646 4k blocks and 122101760 inodes
Filesystem UUID: <uuid> # uuid 확인
Superblock backups stored on blocks:
				....
  • 출력 중에 block device ID가 UUID=<uuid> 줄을 통해 표시되므로, 나중에 fstab에 등록하기 위해 복사해 둠


마운트 경로 생성

SSD를 마운트할 디렉토리를 생성해야 함

sudo mkdir -p /mnt/data
sudo mkdir -p /mnt/sdb
sudo mkdir -p /mnt/sdc
  • /mnt/data를 주 마운트 경로로 사용할 예정


fstab 등록 (자동 마운트 설정)

/etc/fstab 파일을 수정하여 부팅 시 자동으로 마운트되도록 설정함

sudo blkid
/dev/sda: UUID="abcd-1234" TYPE="ext4"
/dev/sdb: UUID="efgh-5678" TYPE="ext4"

참고: blkid를 통한 UUID 확인

$ sudo blkid
...
/dev/sda: UUID="<uuid>" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdb: UUID="<uuid>" BLOCK_SIZE="4096" TYPE="ext4"
...
  • SSD는 블록 단위로 데이터를 읽고 쓰는 장치(block device)
  • 새 디스크 장착 후 포맷 시, block device ID가 생성됨
  • blkid: block device의 정보를 보여 주는 리눅스 명령어
  • blkid를 통해 각 디스크/파티션의 정보(장치 이름, 파일 시스템 타입, UUID 등) 확인 가능


sudo vi /etc/fstab
UUID=abcd-1234  /mnt/data  ext4  defaults  0  0
UUID=efgh-5678  /mnt/sdb   ext4  defaults  0  0
  • 위와 같이 fstab 설정 추가
  • fstab 설정 추가 후 파일 예시

    # /etc/fstab: static file system information.
    #
    # Use 'blkid' to print the universally unique identifier for a
    # device: this may be used with UUID= as a more robust way to name devices
    # that works even if disks are added and removed. See fstab(5).
    #
    # <file system> <mount point>		<type>	<options>				<dump>	<pass>
    # / was on /dev/sda3 during curtin installation
    UUID=<uuid> /mnt/data                      ext4     defaults        0 0 # 추가
    UUID=<uuid> /mnt/sdb											 ext4			defaults				0 0 # 추가
    ...
    


마운트 적용

fstab 변경 후 시스템에 적용

sudo mount -a
sudo systemctl daemon-reload
  • mount 시 systemd가 설정 파일을 읽도록 daemon-reload 명령어를 실행하라는 안내 확인 가능

    sudo mount -a
    mount: (hint) your fstab has been modified, but systemd still uses
    			 the old version; use 'systemctl daemon-reload' to reload.
    


df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda        1.8T   28K  1.7T   1% /mnt/data
/dev/sdb        1.8T   28K  1.7T   1% /mnt/sdb
  • 마운트 상태 확인


참고: systemctl daemon-reload

리눅스 시스템에서 systemd 프로세스로 하여금 설정 파일을 다시 읽도록 강제로 갱신

  • 대부분의 리눅스 시스템에서는 systemd라는 init 시스템 사용
  • 부팅 과정에서 /etc/fstab 파일을 읽고, 안에 정의된 파일 시스템을 mount unit으로 변환해 관리함
    • 예를 들어, UUID=abcd-1234 /mnt/data ext4 defaults 0 0와 같은 줄을 읽고, mnt-data.mount와 같은 내부 유닛으로 등록함
    • 즉, systemd가 fstab 파일을 읽고 “이 장치를 이렇게 마운트하라”고 기억하고 있는 것
  • fstab 수정 시, systemd는 메모리에 예전 내용을 가지고 있기 때문에, 갱신 내용이 반영되지 않음
  • 따라서 fstab 파일에 새 UUID를 추가하는 등의 수정이 발생했을 때, 해당 내용을 다시 읽도록 명령해야 함
    • fstab 고친 직후, mount 관련 경고가 뜰 때는 꼭 실행해 주어야 함


(주의) SSD 제거 시 부팅 문제

  • 나중에 SSD를 제거하면, /etc/fstab에 등록된 UUID가 존재하지 않아 부팅이 멈출 수 있음
  • 이 경우 fstab에서 해당 항목을 주석 처리하거나 삭제해야 함


PV 디렉토리 생성 및 권한 설정

MinIO PV로 사용할 디렉토리를 SSD 마운트 경로 아래에 생성

cd /mnt/data
sudo mkdir minio-pv
sudo chmod 777 minio-pv
  • 권한을 777로 설정하지 않으면 MinIO Pod가 디렉토리에 접근하지 못할 수 있음

    실제 권한 설정 없이 이하 과정을 진행할 경우, MinIO 배포 시 아래와 같은 에러 발생

    ERROR Unable to use the driver /export: driver access denied


MinIO 재배포

PV, PVC

apiVersion: v1
kind: PersistentVolume
metadata:
  name: minio-pv
  namespace: minio
spec:
  capacity:
    storage: 3Ti
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: minio-storage-class
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname # SSD 증설 후 PV 생성한 호스트
              operator: In
              values:
                - # 호스트명
  hostPath:
    path: "/mnt/data/minio-pv" # SSD 마운트 경로 내 PV 디렉토리
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: minio-pvc
  namespace: minio
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: minio-storage-class
  resources:
    requests:
      storage: 1Ti
  • 매니페스트 작성
    • PV node selector: SSD 설치한 노드로 선택해야 함


kubectl apply minio-pv-pvc.yaml
  • PV, PVC 배포


MinIO values.yaml 변경

# 생략
persistence:
  enabled: true
  existingClaim: "minio-pvc"
# 생략
mode: standalone 
# 생략

Helm을 이용해 MinIO를 배포할 경우 사용되는 values.yaml에서 persistence 항목 변경 후 재배포


재배포

helm uninstall minio -n minio
helm install minio -n minio ./minio.5.2.0.tgz --values minio-values.yaml


결론

해결 방안 요약

  • SSD 설치 → 파티션 포맷 → UUID 확인 → fstab 등록 → 마운트
  • PV 디렉토리 생성 → 권한 설정
  • PV/PVC 작성 → MinIO values.yaml 수정 → 재배포
  • systemd 특성(daemon-reload)과 fstab 주의사항 숙지 필요

결과

이후 MinIO 버킷 생성 시, /mnt/data 디렉토리 하위에 폴더가 생성되는 것을 확인할 수 있음

minio-new-bucket


추가 고려 사항

  • 루트 파티션 부담이 실제로 해소되는지 지속적으로 모니터링
  • 기존 데이터 이관
    • /mnt/data/minio/mnt/data/minio-pv
    • 이관 시, 권한 문제 발생 가능 → chown/chmod 필요
    • 이관 후, 기존에 수집한 데이터까지 활용한 운영 방한 검토 필요
  • 추후 MinIO PVC 확장 또는 다른 노드에 SSD 추가 시 PV/PVC 전략 재검토 및 고도화 필요


hit count

댓글남기기