🧱 컨테이너 스토리지 연동 실무 가이드

📌 1. 개요: 왜 스토리지가 필요한가?

컨테이너는 기본적으로 휘발성(ephemeral) 환경이다.
→ 컨테이너를 재시작하면 데이터가 사라짐.

따라서 데이터 지속성(Persistence) 을 위한 스토리지 연동이 필수!

🐳 2. Docker Volume 연동 실무

✅ 개념 요약

  • Docker Volume은 호스트 OS와 컨테이너 사이의 디스크 공유 방식
  • 컨테이너가 사라져도 데이터는 볼륨에 남아있음
  • docker volume create 명령으로 생성 가능

✅ 실무 명령어 예시

 
# 1. 볼륨 생성 docker volume create myvolume # 2. 볼륨을 사용하는 컨테이너 실행 docker run -d -v myvolume:/app/data --name voltest nginx # 3. 볼륨 경로 확인 docker volume inspect myvolume

✅ 실전 활용 사례

  • MySQL, Redis, Elasticsearch 등의 데이터 디렉터리 보존
  • 로그 저장소, 애플리케이션 데이터 저장소

☸️ 3. Kubernetes PV/PVC 실무

✅ 기본 용어

용어설명
PV (PersistentVolume) 클러스터 내 실제 스토리지 리소스 (관리자가 생성)
PVC (PersistentVolumeClaim) 사용자가 요청하는 스토리지 요구 사항
StorageClass 동적 프로비저닝 시, 스토리지 종류를 정의 (ex. SSD, HDD, NFS 등)

✅ 실무 흐름

  1. StorageClass 정의 (옵션)
  2. PV 생성 (또는 동적 프로비저닝)
  3. PVC 생성
  4. Pod에서 PVC 마운트

✅ YAML 예시: PVC + Pod 연동

 
# 1. PVC 정의 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: standard
 
# 2. Pod에서 PVC 사용 apiVersion: v1 kind: Pod metadata: name: myapp spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: "/usr/share/nginx/html" name: storage volumes: - name: storage persistentVolumeClaim: claimName: my-pvc

✅ StorageClass 예시 (GCE, AWS, NFS 등)

 
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast provisioner: kubernetes.io/aws-ebs parameters: type: gp2

AWS EBS, Azure Disk, GCP PersistentDisk, NFS 등과 연동 가능.

🚨 실무 주의 포인트

  • accessModes 설정 오류로 마운트 충돌 발생 가능
  • 동적 스토리지 사용 시 StorageClass 지정 필수
  • ReadWriteMany는 NFS, CephFS, GlusterFS 등에서만 지원
  • PVC가 Pending 상태면 PV와 매칭이 안된 상태 → 이벤트 로그 확인 필요 (kubectl describe pvc)

🧪 실무 시나리오 예제

[시나리오 1]

Pod를 재시작했더니 DB 데이터가 초기화됨

원인: EmptyDir 볼륨 사용 중 → 휘발성
해결: PVC를 생성하고 Pod에 마운트해야 함

[시나리오 2]

PVC가 계속 Pending 상태

원인:

  • PV와 accessModes 불일치
  • storageClassName 불일치
  • 동적 프로비저닝용 CSI 미설정

조치:

  • kubectl describe pvc로 이벤트 확인
  • StorageClass 존재 여부 및 PV 상태 확인

 

 

📘 컨테이너 스토리지 연동 실무 문제집 (10문항)

✅ 난이도 분류

  • [하] 기초 개념
  • [중] 실무 구성
  • [상] 트러블슈팅/설계 판단

문제 1 [하]

Docker Volume의 주요 특징으로 가장 적절한 것은?
A) 컨테이너가 재시작되면 데이터가 사라진다
B) 호스트와 격리된 메모리 볼륨이다
C) 데이터의 영속성을 제공한다
D) 컨테이너 이미지에 포함된 디렉터리이다

정답: C
해설: Docker Volume은 휘발성인 컨테이너 환경에서 데이터를 영구적으로 보존하는 데 사용된다.

문제 2 [중]

다음 중 Kubernetes PVC(PersistentVolumeClaim)에 대한 설명으로 옳은 것은?
A) PVC는 항상 수동으로 PV를 연결해야 한다
B) PVC는 Pod의 Restart 시 삭제된다
C) PVC는 사용자 입장에서 스토리지를 요청하는 방식이다
D) PVC는 로그 저장용으로만 사용 가능하다

정답: C
해설: PVC는 사용자가 스토리지를 요구할 때 선언적으로 요청하는 객체로, PV와 바인딩된다.

문제 3 [중] (YAML 기반)

다음 YAML 중 PVC를 사용하는 Pod 구성으로 올바른 것은?

A)

 
volumeMounts: - mountPath: "/data" name: myvol volumes: - name: myvol emptyDir: {}

B)

 
volumeMounts: - mountPath: "/data" name: myvol volumes: - name: myvol persistentVolumeClaim: claimName: my-pvc

C)

 
volumeMounts: - mountPath: "/data" claimName: my-pvc volumes: - name: myvol hostPath: path: /mnt/data

D)

 
volumeMounts: - mountPath: "/data" pvc: my-pvc volumes: - name: myvol configMap: name: my-config

정답: B
해설: Pod에서 PVC를 사용할 때는 volumes.persistentVolumeClaim.claimName 형식으로 참조해야 한다.

문제 4 [중]

Kubernetes에서 StorageClass를 지정하지 않은 PVC는 어떻게 처리되는가?
A) 자동으로 삭제된다
B) 아무 스토리지도 매칭되지 않는다
C) 기본 StorageClass가 있다면 그것을 사용한다
D) 클러스터 전체가 에러 상태가 된다

정답: C
해설: default StorageClass가 존재할 경우 자동으로 바인딩된다.

문제 5 [상]

PVC가 Pending 상태로 계속 머무는 가장 일반적인 원인은?
A) Pod가 실행되지 않아서
B) 컨테이너 이미지가 없어서
C) PVC가 잘못된 형식으로 생성되어서
D) PV가 조건에 맞지 않아 바인딩되지 못해서

정답: D
해설: PVC의 용량, accessMode, StorageClass가 PV와 일치하지 않으면 바인딩이 되지 않고 Pending 상태가 지속된다.

문제 6 [상]

다음 중 ReadWriteMany(다중 Pod 쓰기 가능) accessMode를 지원하지 않는 볼륨 유형은?
A) NFS
B) CephFS
C) HostPath
D) Azure Disk

정답: D
해설: Azure Disk는 ReadWriteOnce만 지원한다. RWX를 원하면 Azure Files를 사용해야 한다.

문제 7 [중]

아래 YAML은 어떤 용도로 사용하는가?

 
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: redis-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi

A) Pod의 리소스 제한
B) ConfigMap 생성
C) 로그 수집 경로 설정
D) 스토리지 요청 선언

정답: D
해설: PVC를 정의한 예시로, 1Gi의 스토리지를 요청하고 있다.

문제 8 [하]

Kubernetes에서 Pod가 사용하는 디렉토리를 지속적으로 유지하려면 어떤 리소스를 반드시 생성해야 하는가?
A) ConfigMap
B) Secret
C) PersistentVolumeClaim
D) HorizontalPodAutoscaler

정답: C
해설: Pod가 재시작되어도 데이터를 유지하려면 PVC를 통해 외부 스토리지를 마운트해야 한다.

문제 9 [상]

스토리지 연동 시 다음과 같은 오류가 발생한다:

 
Warning FailedMount Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data]: timed out waiting for the condition

이 문제를 해결하기 위한 첫 번째 조치로 적절한 것은?
A) Pod 삭제
B) PVC 삭제
C) kubectl describe pvc 명령어로 이벤트 로그 확인
D) kubelet 재시작

정답: C
해설: PVC와 PV 간 매칭 실패 혹은 CSI 드라이버 문제일 수 있으므로, PVC 상태를 상세히 확인해야 한다.

문제 10 [중]

Docker Volume을 생성하고 컨테이너에서 사용할 때 올바른 방식은?

 
1) docker volume create myvol 2) docker run -d -v _____________ nginx

빈칸에 들어갈 알맞은 내용은?
A) myvol:/etc/nginx
B) ./data:/app
C) nginx:/data
D) data:myvol

정답: A
해설: 볼륨명:컨테이너 경로 형식으로 -v 옵션을 사용해야 하며, myvol:/etc/nginx가 올바르다.

📘 스토리지 장애 분석 단답형 문제집 (10문항)

문제 1.

Kubernetes Pod가 PVC를 마운트하지 못하고 FailedMount 오류가 발생했다. 가장 먼저 확인해야 할 명령어는?

정답: kubectl describe pvc [PVC명]

문제 2.

iSCSI 기반 스토리지가 정상인데도 Linux 클라이언트에서 마운트 실패가 발생한다. 연결 상태를 확인하는 명령어는?

정답: iscsiadm -m session

문제 3.

Docker 컨테이너에서 볼륨을 마운트했으나 디렉토리가 비어 있다. 가장 먼저 점검해야 할 것은?

정답: 컨테이너 내 경로 지정이 올바른지 확인

문제 4.

RAID 5 구성 중 하나의 디스크에 장애가 발생했다. 시스템은 동작 중이다. 이 상태에서 우선적으로 해야 할 작업은?

정답: 장애 디스크 교체 및 리빌드 시작

문제 5.

NFS 스토리지 연결이 불안정하고 간헐적으로 읽기 지연이 발생한다. 가장 먼저 점검해야 할 것은?

정답: 네트워크 상태 및 MTU 설정 확인

문제 6.

SAN 환경에서 LUN을 바인딩했는데 서버에서 디바이스가 인식되지 않는다. 무엇을 점검해야 하는가?

정답: HBA WWN 등록 여부 및 zoning 상태

문제 7.

스토리지 장애 이후, 일부 Kubernetes Pod가 재시작되지 않고 Terminating 상태로 남아있다. 우선 확인해야 할 리소스는?

정답: VolumeAttachment 상태

문제 8.

스토리지 시스템에서 High Latency 경고가 발생했다. 스토리지 입출력량이 과도한 상황이다. 어떤 리소스를 우선 확인해야 하는가?

정답: 특정 LUN 또는 볼륨의 IOPS

문제 9.

스토리지 연결이 끊어진 후 multipath가 failover 되지 않았다. 가장 가능성 높은 원인은?

정답: multipath 설정 오류 또는 path group 미구성

문제 10.

스토리지 장애가 발생했을 때 재시작 없이 데이터를 최대한 빨리 이전해야 한다. 가장 적절한 기술은?

정답: 스냅샷 복제 또는 LUN 클론

아래는 스토리지 마운트 충돌, 용량 부족, 권한 오류 등 실무에서 자주 발생하는 장애 시나리오 기반 단답형 문제 10제입니다. Kubernetes와 Docker, iSCSI, NFS, PV/PVC 등 다양한 컨테이너 및 서버 환경을 반영했습니다.

📌 장애 분석 시나리오 단답형 문제 (마운트 충돌·용량 부족·권한 오류 포함)

문제 1.

Kubernetes에서 PVC를 마운트하려 했지만, 이미 같은 경로를 다른 컨테이너가 사용 중이라 오류가 발생했다. 이때 발생하는 일반적인 오류 메시지는?

정답: MountVolume.SetUp failed for volume ... already mounted

문제 2.

Linux 서버에서 NFS 볼륨을 마운트했으나, 특정 사용자만 읽기 전용으로 인식된다. 가장 먼저 확인할 파일은?

정답: /etc/exports

문제 3.

Pod가 "VolumeMount" 실패로 CrashLoopBackOff 상태이다. kubectl describe pod 명령어에서 확인할 항목은?

정답: Events 섹션의 마운트 관련 오류 메시지

문제 4.

Docker 컨테이너 실행 시 permission denied 오류가 발생하며 호스트 디렉토리 마운트에 실패한다. 가장 가능성 높은 원인은?

정답: 호스트 디렉토리의 권한 문제 (chmod/chown 필요)

문제 5.

PV가 Bound 상태이나, Pod가 PVC를 제대로 마운트하지 못한다. 가장 먼저 확인해야 할 구성 요소는?

정답: volumeMounts 경로가 Pod 내에서 유효한지 확인

문제 6.

Kubernetes 클러스터에서 특정 노드에만 볼륨이 마운트되지 않는다. 가장 먼저 확인해야 할 것은?

정답: CSI 플러그인 또는 kubelet 로그

문제 7.

스토리지 마운트 이후 몇 시간 뒤 I/O 오류와 함께 Pod가 재시작되었다. 어떤 원인을 의심해야 하는가?

정답: 용량 부족 또는 underlying storage 장애

문제 8.

iSCSI 기반 PV가 간헐적으로 NodePublishVolume 오류를 보인다. 확인할 항목은?

정답: iSCSI target 접속 상태 (iscsiadm -m session)

문제 9.

스토리지 마운트는 성공했으나, df -h 출력 시 볼륨이 100% 사용 중으로 나타난다. 다음으로 확인할 명령어는?

정답: du -sh /* 또는 find / -type f -size +1G

문제 10.

ReadOnlyFilesystem 오류로 인해 Pod에서 파일 생성이 실패한다. 가능한 원인 중 하나는?

정답: 스토리지가 ReadOnly로 remount된 상태 (I/O 오류, 파일시스템 오류 등)

+ Recent posts

티스토리툴바