쿠버네티스 컨테이너 파일 시스템, 레이어 구조부터 볼륨까지 제대로 이해하기

🤖 AI Assisted Content
이 글은 AI(Claude, Anthropic)의 도움을 받아 작성되었습니다.
작성자가 내용을 검토하고 편집했으나, AI가 초안 작성 및 구성에 참여했음을 밝힙니다.

쿠버네티스 컨테이너 파일 시스템, 레이어 구조부터 볼륨까지 제대로 이해하기

쿠버네티스에서 파드를 운영하다 보면 "데이터가 왜 사라졌지?"라는 상황을 한 번쯤 겪게 됩니다. 컨테이너가 재시작됐을 뿐인데 기록했던 파일이 전부 유실되는 것이죠. 이 현상을 제대로 이해하려면 컨테이너 파일 시스템이 어떻게 구성되는지부터 알아야 합니다.

이 글에서는 컨테이너 파일 시스템의 레이어 구조, kubectl exec로 접근했을 때 실제로 보이는 것, Copy-on-Write 메커니즘, 그리고 볼륨을 통한 데이터 영속화까지 순서대로 정리합니다.

컨테이너 파일 시스템은 여러 레이어의 합이다

파드 속 컨테이너의 파일 시스템은 단일 디스크가 아닙니다. 여러 가지 출처를 합쳐 구성됩니다. 최소 구성 요소는 다음 세 가지입니다.

운영체제 레이어(Base Image) — alpine, ubuntu, debian 같은 베이스 이미지가 제공하는 OS 파일들입니다. /bin, /etc, /usr 등의 기본 디렉터리가 여기에 해당합니다. 이 레이어는 읽기 전용입니다.

애플리케이션 레이어 — Dockerfile에서 COPY, RUN 등으로 추가한 앱 바이너리, 라이브러리, 설정 파일이 담긴 레이어입니다. 역시 읽기 전용입니다.

기록 가능 레이어(Writable Layer) — 컨테이너가 실행될 때 이미지 레이어들 위에 추가되는 최상위 레이어입니다. 파일 생성, 수정, 삭제가 모두 이 레이어에서 일어납니다. 컨테이너가 삭제되면 이 레이어도 함께 사라집니다.

파드 속 각 컨테이너는 이 레이어 구성을 독립적으로 갖습니다. Container A와 Container B는 서로의 파일 시스템에 접근할 수 없습니다.

kubectl exec로 보이는 것은 "합쳐진" 파일 시스템이다

kubectl exec -it으로 컨테이너에 접근하면 하나의 통합된 파일 시스템이 보입니다. 여기서 흔히 오해하는 부분이 있습니다. "보이는 파일들은 기록 가능 레이어인가?"라는 질문인데, 답은 아닙니다.

kubectl exec -it my-pod -- ls /

이 결과에서 /bin/sh는 운영체제 레이어에서 온 것이고, /app/server.js는 애플리케이션 레이어에서 온 것이며, 컨테이너 실행 중 생성한 /tmp/log.txt는 기록 가능 레이어에 있는 것입니다. 하지만 사용자 눈에는 이 구분이 전혀 보이지 않습니다.

이것이 Union Filesystem(OverlayFS)의 역할입니다. 여러 레이어를 투명하게 겹쳐서 하나의 파일 시스템처럼 보여주는 것이 목적이기 때문입니다. 컨테이너 안의 애플리케이션에도, kubectl exec로 접근하는 사용자에게도 동일하게 적용됩니다.

그렇다면 어떤 파일이 어느 레이어에서 왔는지 확인할 수 있을까요? 컨테이너 안에서는 불가능합니다. 하지만 호스트 노드에서는 확인할 수 있습니다.

# 노드에서 컨테이너 런타임을 통해 레이어 구조 확인
docker inspect <container-id> --format '{{.GraphDriver.Data}}'

이 명령의 결과에서 LowerDir은 읽기 전용 이미지 레이어들, UpperDir은 기록 가능 레이어, MergedDir은 합쳐진 최종 뷰의 경로를 보여줍니다. kubectl exec로 보는 파일 시스템은 바로 이 MergedDir에 해당합니다.

Copy-on-Write — 읽기 전용 파일도 "수정 가능"한 이유

읽기 전용 레이어의 파일을 수정할 수 없느냐고 하면, 그렇지 않습니다. 수정은 가능하지만 원본을 바꾸는 것이 아니라 Copy-on-Write(CoW) 메커니즘이 동작합니다.

운영체제 레이어에 있는 /etc/nginx/nginx.conf를 수정한다고 하면 이런 일이 일어납니다.

1. OverlayFS가 읽기 전용 레이어(LowerDir)에서 해당 파일을 기록 가능 레이어(UpperDir)로 복사합니다.
2. 기록 가능 레이어에 생긴 사본을 수정합니다.
3. 이후 해당 파일을 읽을 때는 기록 가능 레이어의 사본이 원본을 가려서(overlay) 보여줍니다.

원본 이미지 레이어의 파일은 그대로 남아 있습니다. 기록 가능 레이어의 수정된 사본이 우선순위가 더 높아서 원본을 덮어 보이게 할 뿐입니다.

삭제도 마찬가지입니다. 읽기 전용 레이어의 파일을 삭제하면 실제로 원본이 지워지는 것이 아니라 기록 가능 레이어에 whiteout 파일이라는 특수 마커가 생성됩니다. OverlayFS가 이 마커를 보고 "삭제되었다"고 판단해서 사용자에게 보여주지 않는 것입니다.

이 구조 덕분에 하나의 이미지로 여러 컨테이너를 동시에 실행할 수 있습니다. 읽기 전용 이미지 레이어는 모든 컨테이너가 공유하고, 각 컨테이너는 자신만의 기록 가능 레이어에서만 변경 사항을 관리합니다. 같은 이미지로 10개의 파드를 띄워도 이미지 레이어는 디스크에 한 벌만 존재하므로 디스크 공간이 매우 효율적입니다.

💡 핵심 포인트 — 기록 가능 레이어의 사본은 컨테이너가 삭제되면 함께 사라집니다. kubectl exec로 직접 설정 파일을 수정해도 파드가 재시작되면 원본 이미지 상태로 돌아갑니다. 영구적인 변경이 필요하면 이미지를 다시 빌드하거나 ConfigMap, Volume 등을 사용해야 합니다.

파드 재시작 = 컨테이너 재시작 = 데이터 유실

여기서 기억해야 할 것은 두 가지입니다.

첫째, 기록 가능 레이어의 수명은 컨테이너의 수명을 따릅니다. 둘째, 파드의 재시작은 그 안에 들어 있는 컨테이너의 재시작입니다.

이 두 가지를 합치면 결론은 명확합니다. 파드에서 동작하던 애플리케이션이 열심히 데이터를 기록했더라도, 이 데이터가 파드 수준에서 별도 저장되지 않은 상태에서 파드가 컨테이너를 재시작하면 데이터는 유실됩니다.

당장은 정상 동작하는 것처럼 보이겠지만, 파드가 재시작하거나 새로운 파드로 대체될 때 문제가 드러납니다. 이것이 볼륨이 필요한 이유입니다.

볼륨으로 컨테이너 파일 시스템을 확장한다

컨테이너 파일 시스템은 이미지 레이어와 기록 가능 레이어만으로 끝나지 않습니다. ConfigMap, Secret, 볼륨 같은 다른 출처에서도 구성할 수 있습니다. 파드 수준에서 볼륨을 정의하고, 이 볼륨을 컨테이너 파일 시스템의 지정한 경로에 마운트하는 방식입니다.

ConfigMap / Secret — 읽기 전용 설정 마운트

쿠버네티스 API 서버에 저장된 설정 데이터를 컨테이너의 특정 경로에 읽기 전용으로 마운트합니다. 파드가 재시작되어도 API 서버에 데이터가 남아 있으므로 다시 마운트됩니다.

PersistentVolume — 파드와 독립적인 영구 스토리지

NFS, AWS EBS, Azure Disk 같은 외부 스토리지를 연결합니다. 파드와 독립적인 수명을 가지기 때문에 파드가 삭제되어도 데이터가 보존됩니다. 읽기/쓰기 모두 가능합니다.

EmptyDir — 파드 수명의 임시 볼륨

이름 그대로 빈 디렉터리로 시작하는 볼륨입니다. 컨테이너 이미지 레이어나 기록 가능 레이어에 속하지 않고, 파드 수준에서 별도로 정의됩니다.

기록 가능 레이어와의 차이가 중요합니다. 기록 가능 레이어는 컨테이너 수명에 종속되어 컨테이너가 재시작되면 데이터가 유실됩니다. 반면 EmptyDir은 파드 수명에 종속되므로, 파드 안에서 컨테이너가 재시작되는 것만으로는 데이터가 사라지지 않습니다. 하지만 파드 자체가 삭제되고 새 파드로 대체되면 EmptyDir도 빈 디렉터리로 초기화됩니다. 로컬 캐시나 같은 파드 내 컨테이너 간 임시 데이터 공유에 적합합니다.

데이터 수명 한눈에 비교

컨테이너에서 데이터를 기록할 때, 어디에 저장하느냐에 따라 수명이 완전히 달라집니다.

기록 가능 레이어  →  컨테이너 수명  →  컨테이너 재시작 시 유실
EmptyDir         →  파드 수명     →  파드 대체 시 유실 (컨테이너 재시작에는 유지)
PersistentVolume →  독립 수명     →  파드 대체에도 유지

⚠️ 주의 — 애플리케이션이 데이터를 기록할 필요가 있다면, 이 수명 차이를 이해하고 필요에 맞추어 파드를 정의해야 합니다. 기록 가능 레이어에만 쓰면 당장은 동작하지만, 파드 교체 시 모든 데이터가 날아갑니다.

마무리

컨테이너 파일 시스템은 겉으로는 하나의 디스크처럼 보이지만, 내부적으로는 읽기 전용 이미지 레이어 위에 기록 가능 레이어가 얹혀진 구조입니다. Copy-on-Write 덕분에 파일 수정이 가능하지만, 이 레이어의 수명은 컨테이너와 함께합니다. 데이터를 안전하게 보존하려면 애플리케이션의 성격에 맞는 볼륨(EmptyDir, PersistentVolume 등)을 선택하여 파드를 정의해야 합니다.

---

참고 문서

• Kubernetes - Volumes
• Kubernetes - Persistent Volumes
• Kubernetes - ConfigMaps
• Kubernetes - Secrets
• Docker - Storage drivers (OverlayFS)