EKS에서 EBS로 Kubernetes 스토리지 제대로 쓰기

Volume 종류부터 PV/PVC, StorageClass, Retain/Delete, 용량 확장, StatefulSet/Helm 드리프트까지 한 번에 정리

Kubernetes를 처음 깊게 파기 시작하면 스토리지에서 한 번은 멈춥니다.
“Pod 재시작하면 데이터가 사라지나?”, “emptyDir은 기본이야?”, “PV/PVC는 왜 둘로 나뉘어?”, “EBS 하나를 여러 노드가 동시에 마운트해도 돼?”, “Retain인데 PVC 삭제하니 Terminating/Released는 뭐지?”, “용량 100Gi를 200Gi로 늘리면 무중단이야?” 같은 질문이 연쇄적으로 튀어나옵니다.

이 글은 **EKS + EBS(=블록 스토리지)**를 기준으로, 우리가 대화에서 다룬 질문들을 개념 → 동작 원리 → 운영 시나리오 순서로 정리한 글입니다. (중간중간은 AWS/EKS 이야기지만, 핵심은 Kubernetes 스토리지의 일반 원리입니다.)

1. Kubernetes에서 “디스크”는 어디에 있나: 컨테이너 파일시스템 vs Volume

먼저 가장 헷갈리는 지점부터 정리해야 합니다.

컨테이너의 writable layer(루트 파일시스템)

Pod 스펙에 volumes를 아무 것도 안 붙여도 컨테이너는 / 아래에 파일을 쓸 수 있습니다.
이 데이터는 “같은 Pod 안에서 컨테이너가 재시작” 되는 정도라면 보통 유지됩니다.

(컨테이너 크래시/재시작이 Pod 제거를 의미하진 않기 때문).
다만 이건 영속 스토리지라고 믿으면 안 됩니다.

왜냐하면 Kubernetes에서 “Pod 재시작”이라고 말할 때, 현업에서는 아래가 섞여 쓰이기 때문입니다.

컨테이너 재시작: 같은 Pod 오브젝트, 같은 노드에서 컨테이너만 다시 뜸
Pod 재생성/재스케줄: 기존 Pod는 없어지고 새로운 Pod가 생김(노드도 바뀔 수 있음)

두 번째(재생성/재스케줄) 상황이면 컨테이너의 writable layer는 새로 만들어진다고 보는 게 안전합니다. 그래서 Kubernetes는 애초에 데이터를 안전하게 다루려면 Volume이라는 명시적 메커니즘을 쓰라고 설명합니다. Kubernetes

2. “볼륨 마운트 방법” 전체 지도: Kubernetes Volume 타입 분류

Kubernetes의 Volume은 정말 종류가 많습니다. 공식 문서도 “목적별로 다양한 Volume 타입이 있다”고 먼저 못 박습니다. Kubernetes
실무에서 이해하기 쉬운 분류는 아래 2축입니다.

수명(lifecycle): ephemeral(임시) vs persistent(영속)
저장 위치: 노드 로컬 vs 네트워크/외부 스토리지

2.1 Ephemeral(임시) 계열: Pod와 생명주기를 같이함

대표적으로:

emptyDir: Pod가 노드에 스케줄될 때 생성되고 Pod가 노드에서 사라지면 삭제되는 임시 공간 Kubernetes
configMap, secret, downwardAPI: 설정/자격증명/메타데이터를 파일로 주입하는 용도 Kubernetes+1
projected: 여러 소스를 한 디렉터리에 “합쳐서” 마운트(예: secret+configMap+serviceAccountToken) Kubernetes
CSI ephemeral volume: 일부 CSI 드라이버가 제공하는 “Pod와 함께 생성/삭제되는” 임시 볼륨 Kubernetes
generic ephemeral volumes: PVC 형태를 빌려 쓰는 ephemeral 패턴(개념은 비슷: Pod와 함께 사라지는 스토리지)

2.2 Persistent(영속) 계열: Pod가 바뀌어도 데이터를 남기려는 목적

persistentVolumeClaim(PVC)로 마운트하는 방식(가장 표준) Kubernetes
NFS 같은 네트워크 파일시스템
클라우드 스토리지(EBS/EFS 같은)를 CSI 드라이버로 붙이는 구조

Kubernetes는 “Pod가 재시작되거나 교체되어도 데이터를 유지하려면 durable storage를 써야 한다”는 흐름으로 문서를 구성합니다. Kubernetes

3. emptyDir은 “기본(default)”인가?

결론부터 말하면:

emptyDir은 기본으로 자동 생성되는 것이 아니라, Pod spec에 명시할 때만 생깁니다.
다만 “볼륨을 안 쓰면” 컨테이너의 writable layer가 있으니, 체감상 “그냥 디스크가 있는 것처럼” 보일 수 있습니다.
emptyDir은 컨테이너 writable layer가 아니라 Pod 레벨 공유 임시 공간(여러 컨테이너가 같이 쓰기 쉬움)이라는 점이 핵심입니다. Kubernetes

4. emptyDir을 “쓰는 것”과 “안 쓰는 것”의 차이

여기서 질문이 자주 갈립니다.

4.1 emptyDir을 쓰면 얻는 것

Pod 내 컨테이너 간 공유 디렉터리가 명확해짐(예: sidecar가 생성한 파일을 app 컨테이너가 읽음)
수명주기 정의가 명확해짐: “Pod가 노드에서 사라지면 데이터 삭제”라는 규칙이 문서에 박혀 있음 Kubernetes
메모리 기반(tmpfs)로도 구성 가능(초고속 scratch)

4.2 emptyDir을 안 쓰면(=컨테이너 writable layer에 쓰면) 생기는 문제

데이터 수명이 명시적으로 보장되지 않음
컨테이너 이미지/레이어/재생성 방식(rollout, reschedule)에 따라 “어느 순간 갑자기 사라지는 것처럼” 보일 수 있음
컨테이너 간 공유도 애매해짐(각 컨테이너의 파일시스템은 기본적으로 분리)

정리하면:
emptyDir은 “영속 데이터”가 아니라 scratch 공간을 ‘명시적으로’ 만들기 위한 장치입니다. Kubernetes

5. PV/PVC/StorageClass: 왜 이렇게 복잡하게 나눴을까?

Kubernetes의 표준 영속 스토리지는 다음 3단으로 이해하면 깔끔합니다.

PV (PersistentVolume): 클러스터 입장에서 “실제 스토리지 한 조각”
PVC (PersistentVolumeClaim): 사용자가 “이만큼 스토리지 주세요”라고 요청하는 청구서
StorageClass: “어떤 방식/성능/정책으로 PV를 만들어줄지” 정의한 템플릿(동적 프로비저닝의 핵심)

Kubernetes 문서에서도 PV/PVC는 “1:1 바인딩”이라는 전제를 깔고 설명합니다(한 PV는 한 PVC에 바인딩). Kubernetes

6. StorageClass란 무엇인가? 정해진 종류가 있나?

StorageClass는 “정해진 몇 개 중에서 고르는 메뉴”라기보다,

클러스터 관리자가 정의하는 리소스
내부/외부 provisioner(드라이버)에 어떤 파라미터로 볼륨을 만들지 결정하는 정책

입니다. Kubernetes는 StorageClass에 대해 “각 StorageClass는 provisioner를 가진다”고 명확히 설명합니다. Kubernetes

또한 “기본(default) StorageClass” 개념이 있어, PVC에 storageClassName을 생략하면 default로 자동 채워질 수 있습니다(여러 default가 있으면 가장 최근 생성된 default가 적용될 수 있으니 보통 하나만 두라고 권장). Kubernetes

StorageClass 예시 1: EBS(gp3) 계열(예시)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete

allowVolumeExpansion: true면 PVC 수정으로 확장이 가능해집니다. Kubernetes+1
reclaimPolicy 기본값은 StorageClass가 지정하지 않으면 Delete가 됩니다. Kubernetes
WaitForFirstConsumer는 “어느 노드/AZ에 붙을지 Pod 스케줄링을 보고 결정”하게 해 topology 제약(EBS는 AZ 제약)을 피하는 데 중요합니다. Kubernetes

StorageClass 예시 2: EFS(RWX 공유 스토리지) 계열(공식 문서 예시 형태)

Kubernetes 문서의 AWS EFS StorageClass 예시는 efs.csi.aws.com provisioner를 사용합니다. Kubernetes

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-xxxxxxxx
  directoryPerms: "700"

7. “EBS 하나를 노드 A/B/C가 동시에 마운트 가능?” (가장 많이 하는 착각)

7.1 기본 답: 일반적인 EBS는 “한 번에 한 노드”가 표준

EBS는 블록 스토리지이고, Kubernetes에서 EBS CSI로 붙이는 일반 패턴은 사실상:

ReadWriteOnce(RWO): 한 번에 한 노드에 attach/mount

를 기본으로 봅니다. 즉 노드 A/B/C가 동시에 같은 EBS를 마운트하는 구조는 일반적으로는 안 된다고 생각하는 게 안전합니다.

7.2 예외: EBS Multi-Attach

AWS에는 EBS Multi-Attach 기능이 있고, 특정 볼륨 타입(io1/io2)에서 같은 AZ 내 여러 인스턴스에 붙일 수 있습니다. 하지만 이건 클러스터 파일시스템처럼 “동시 쓰기”를 안전하게 처리할 수 있는 계층이 필요하고, 일반 ext4 같은 단일 호스트 파일시스템을 그냥 여러 노드가 동시에 마운트하면 깨질 수 있습니다. Repost

그래서 Kubernetes 워크로드 관점에서 “여러 노드가 동시에 읽고/쓰는 공유 스토리지”가 필요하면 보통은:

EBS Multi-Attach를 억지로 쓰기보다
EFS 같은 RWX 파일시스템으로 가는 게 정석

입니다. (EFS StorageClass 예시는 위에서 봤듯이 공식 문서에도 나옵니다.) Kubernetes

8. PV 100Gi 만들고 PVC 10Gi 요청하면 10Gi만 쓰나, 100Gi까지 쓰나?

여기서 “Kubernetes가 용량을 강제로 잘라서 막아주냐?”를 기대하는데, 현실은 조금 다릅니다.

PVC의 requests.storage는 바인딩/스케줄링/프로비저닝 기준입니다.
PV는 “이만큼 용량이 있는 볼륨”을 나타냅니다.
바인딩은 “PV 용량 >= PVC 요청” 조건을 만족하는 PV를 잡습니다.
그래서 PV가 더 크면 “요청보다 큰 볼륨에 바인딩될 수 있다”는 점을 Kubernetes 문서도 언급합니다. Kubernetes

실제로 얼마나 쓸 수 있는지는 스토리지 백엔드/파일시스템이 결정합니다.

EBS처럼 PV를 동적으로 만들면 대개 “PVC 요청 = EBS 생성 크기”가 되어 PV도 같이 맞춰집니다.
반대로 수동 PV를 만들어 PV가 더 크면, 파일시스템이 그 크기만큼 열려 있는 한(=보통은) 더 쓸 수 있습니다.

즉 “무조건 10Gi로 제한된다”라고 단정하기는 어렵고, 대부분 케이스에서는 실제 디바이스/FS 크기까지 써집니다.
(엄격한 quota를 걸고 싶으면 별도 기능/구성이 필요합니다.)

9. PV 1개를 여러 PVC가 참조할 수 있나?

원칙적으로 안 됩니다.
PV는 특정 PVC와 1:1로 바인딩되고, PV spec에는 그 바인딩을 가리키는 claimRef가 들어갑니다. Kubernetes는 “각 PV는 하나의 PVC에만 바인딩된다”는 구조를 전제로 설명합니다. Kubernetes

공유가 필요하면 보통은:

“여러 PVC가 한 PV를 나눠쓴다”가 아니라
하나의 PVC를 여러 Pod가 마운트하는 구조로 갑니다(단, AccessMode/스토리지 특성에 따라 가능 범위가 갈림).

10. “Pod 100개가 같은 PVC를 쓰고 있는데 용량이 다 차면 무슨 일이 일어나?”

이건 꽤 현실적인 운영 이슈입니다.

볼륨이 꽉 차면 애플리케이션 관점에서는 보통 ENOSPC(No space left on device) 에러가 납니다.
로그/DB/임시파일 쓰기가 실패하면서 앱이 에러를 내거나, 일부는 크래시/재시작 루프에 들어갈 수 있습니다.
Kubernetes가 자동으로 “아 디스크 찼으니 확장해줄게”를 해주진 않습니다(확장은 운영자가 PVC를 키우거나, 별도 auto-scaler류를 붙여야 합니다).

그리고 더 중요한 함정:

“Pod 100개”가 한 노드에 붙어 있는지, 여러 노드에 흩어져 있는지
PVC의 AccessMode가 RWO인지 RWX인지

에 따라 “처음부터 성립 가능한 구조인지”가 달라집니다. EBS(RWO) 기반이면 대개 한 노드에만 attach되므로, 여러 노드에 흩어진 100개 Pod가 동시에 같은 PVC를 쓰는 구조 자체가 성립하지 않는 경우가 많습니다(공유가 필요하면 EFS 쪽으로 가는 이유). Repost+1

11. Retain/Delete: PVC 삭제했을 때 PV/EBS는 어떻게 되나?

StorageClass(또는 PV)에 설정하는 Reclaim Policy는 크게 두 가지가 핵심입니다.

Delete: PVC가 지워지면 PV와 “실제 스토리지”도 정리(삭제)되는 쪽
Retain: PVC가 지워져도 PV/데이터는 남겨서 “수동으로 회수(reclaim)”하게 하는 쪽

Kubernetes 문서도 StorageClass에서 reclaimPolicy를 Delete/Retain으로 둘 수 있고, 지정 안 하면 기본이 Delete라고 설명합니다. Kubernetes

11.1 Retain일 때 흔히 보는 상태: Released

PVC를 삭제하면 PV는 보통 Released 상태로 갑니다.
공식 문서는 “Retain이면 PVC가 삭제돼도 PV는 남고, 데이터도 남아서 수동으로 회수할 수 있다”는 흐름으로 설명합니다. Kubernetes

Released 상태가 “바로 재사용 가능”을 의미하진 않습니다.
왜냐하면 PV 안에 아직 이전 PVC를 가리키는 claimRef가 남아있고, 무엇보다 데이터가 남아있기 때문입니다.

12. Terminating에서 안 지워지는 이유: “스토리지 오브젝트 보호(finalizer)”

PVC/PV가 “삭제 요청했는데 Terminating에서 멈춤”은 대부분 finalizer 때문입니다.

Kubernetes는 “Storage Object in Use Protection”으로 PVC/PV에 finalizer를 붙여, Pod가 사용 중인 PVC를 실수로 삭제하는 사고를 막습니다. Kubernetes
PVC 보호는 kubernetes.io/pvc-protection 같은 finalizer로 동작하며, 관련 문서도 존재합니다. Kubernetes+1

12.1 “Pod가 PVC를 사용 안 한다”의 기준은?

실무적으로는 아주 단순하게 생각하면 됩니다.

어떤 Pod 오브젝트든 spec.volumes에서 그 PVC를 참조하고 있으면 “사용 중”으로 판정될 수 있고
그 Pod가 완전히 없어져야(삭제되어 API에서 사라져야) 보호가 풀리면서 PVC 삭제가 완료됩니다. Kubernetes+1

그래서 결론적으로, 당신이 정리한 문장이 거의 맞습니다.

“PVC를 사용하는 모든 Pod가 사라져야, PVC가 Terminating에서 실제 delete로 넘어간다”
(정확히는 “그 PVC를 참조하는 Pod가 더 이상 존재하지 않아야 한다”에 가깝습니다.) Kubernetes

13. Released 상태 PV는 “못 쓰는 거야?” 그리고 claimRef 제거 패치는 뭐야?

13.1 /spec/claimRef는 무엇인가?

PV 오브젝트 입장에서 “나는 어떤 PVC에 붙어있다”를 기록하는 필드가 claimRef입니다.
PV-PVC 1:1 바인딩 구조에서 핵심 포인터라고 보면 됩니다. Kubernetes

13.2 kubectl patch pv ... remove /spec/claimRef는 무슨 의미?

당신이 적은 명령은 JSON Patch로 PV의 spec.claimRef를 제거하는 겁니다.

kubectl patch pv pv-ebs-100g --type json \ -p='[{"op":"remove","path":"/spec/claimRef"}]'

이걸 왜 하냐면, Retain으로 남은 PV가 Released 상태일 때:

Kubernetes는 그 PV를 “아직 누군가(이전 PVC)랑 관계가 남은 PV”로 취급해서
자동으로 새로운 PVC에 재바인딩하지 않는 경우가 일반적입니다.

그래서 운영자가 “데이터 정리(필요 시 wipe/복구) + claimRef 제거” 같은 수동 조치를 통해 PV를 다시 Available로 돌려 재사용하는 절차를 밟습니다. (문서 흐름도 결국 수동 회수(reclaim)를 전제로 합니다.) Kubernetes+1

13.3 “수동 정리 안 하고 PV를 그냥 지워버리면?”

가능은 한데, 상황에 따라 위험합니다.

ReclaimPolicy가 Retain이면, PV 오브젝트를 지워도 백엔드 스토리지(EBS)가 자동 삭제되지 않아 ‘고아 볼륨’이 남을 수 있습니다. (비용/관리 리스크)
ReclaimPolicy가 Delete면, 원래는 PV 삭제 시 백엔드까지 정리되는 쪽이 자연스러운데, “삭제 순서/상황”에 따라 누수가 생겼던 역사도 있어서 Kubernetes가 개선을 해온 영역입니다. Kubernetes

현업적으로는:

Retain = PV 오브젝트를 쉽게 지우지 말고, 데이터/claimRef를 의도대로 정리해서 재사용
Delete = PVC 삭제로 수명주기를 끝내는 게 자연스러운 흐름
이렇게 운영 런북을 분리하는 편이 사고가 적습니다. Kubernetes+1

14. StatefulSet 컨트롤러는 뭘 하고, “템플릿을 보고 PVC를 자동 생성”은 무슨 말인가?

StatefulSet은 “상태가 있는 워크로드”를 위해 만들어진 컨트롤러이고, 중요한 특징이 두 개입니다.

Pod에 안정적인 이름/순서/정체성을 부여
Pod마다 안정적인 스토리지를 붙일 수 있게 설계됨

여기서 스토리지의 핵심이 volumeClaimTemplates입니다.

Kubernetes 문서는 StatefulSet 예시에서:

volumeClaimTemplates가 stable storage를 제공하고 Kubernetes
템플릿 엔트리마다, 각 Pod는 자기만의 PVC를 하나씩 받는다고 명시합니다. Kubernetes
또한 “Pod가 재스케줄되어도 그 PVC에 연결된 PV를 다시 마운트한다”는 식으로 동작을 설명합니다. Kubernetes
(그리고 중요한 문장) StatefulSet이나 Pod를 지워도 PVC/PV는 자동 삭제되지 않는다. 수동으로 해야 한다는 점도 문서에 적혀 있습니다. Kubernetes

즉 “차트에 pvc.yaml이 없다”는 말은 이런 뜻입니다.

Helm 차트가 직접 PVC 오브젝트를 배포한 게 아니라
StatefulSet의 volumeClaimTemplates에 “PVC 스펙 템플릿”만 적어두었고
StatefulSet 컨트롤러가 web-0, web-1… Pod를 만들면서
거기에 대응하는 PVC를 자동으로 생성했다

이게 “템플릿을 보고 자동 생성”의 의미입니다. Kubernetes

15. volumeClaimTemplates는 왜 쓰나? PVC를 그냥 만들면 안 되나?

둘 다 가능한데, 목적이 다릅니다.

15.1 PVC를 직접 만들면 좋은 케이스

특정 이름의 PVC를 여러 리소스가 공유해야 함
Helm/GitOps에서 PVC를 “명시적으로” 관리하고 싶음(드리프트 최소화)

15.2 volumeClaimTemplates가 빛나는 케이스(=StatefulSet의 핵심)

레플리카(Pod)마다 자기 전용 디스크가 필요함(예: DB, 큐, stateful 캐시)
스케일 아웃하면 자동으로 PVC가 늘어나야 함
Pod가 재스케줄되어도 “그 Pod의 디스크”가 따라다녀야 함

StatefulSet은 바로 이 패턴을 위해 volumeClaimTemplates를 공식적으로 설명합니다. Kubernetes

16. EBS 100Gi를 200Gi로 늘리면 무중단(Zero downtime)인가?

여기서도 “무중단”을 두 층으로 나눠야 합니다.

(A) 클라우드 레벨(EBS 디바이스 크기 증가)
(B) 노드/파일시스템 레벨(리눅스가 파일시스템을 확장 인지하고 실제 usable space가 늘어남)

16.1 EBS 자체는 “붙어있는 상태(in-use)”에서도 크기 변경이 가능

AWS의 EBS는 Elastic Volumes로 **attached/in-use 상태에서도 볼륨 수정(크기 증가)**이 가능합니다. AWS Documentation
즉 (A) 단계만 보면 꽤 무중단에 가깝게 진행됩니다.

16.2 Kubernetes에서 “정석 루트”는 PVC를 늘리는 것

Kubernetes는 StorageClass에 allowVolumeExpansion: true가 있으면 PVC의 용량 요청을 늘려서 볼륨을 확장할 수 있다고 설명합니다. Kubernetes+1
그리고 “줄이는(shrink) 건 안 된다”도 명확합니다. Kubernetes

16.3 파일시스템 확장은 종종 “Pod 재시작/재마운트”가 필요할 수 있다

스토리지/CSI 조합에 따라 다르지만, Kubernetes는 “온라인 파일시스템 확장” 흐름에서 FileSystemResizePending 같은 상태를 언급하고, 경우에 따라 Pod를 재시작해야 파일시스템 확장이 완료되는 시나리오가 있습니다. Kubernetes

즉 “EBS 크기 증가 자체는 무중단에 가깝지만”,
“애플리케이션 레벨에서 완전 무중단으로 usable space가 즉시 늘어난다”는 건 환경(파일시스템/드라이버/마운트 상태)에 따라 달라질 수 있다가 정직한 결론입니다.

17. allowVolumeExpansion: true면 “PVC만” 올려도 EBS/PV가 같이 늘어나나?

대부분의 EKS + EBS CSI 표준 구성에서는 이렇게 이해하면 됩니다.

StorageClass에 allowVolumeExpansion: true Kubernetes+1
PVC의 spec.resources.requests.storage를 200Gi로 수정
CSI 컨트롤러(external-resizer)가 백엔드(EBS)에 ModifyVolume 요청
PV의 capacity/상태가 업데이트되고
노드에서 파일시스템 확장이 완료되면 실제 사용 가능 용량이 증가

즉 “PVC만 조절해도 (대개) EBS와 PV가 따라온다”가 일반적인 운영 모델입니다. Kubernetes+1

18. 그런데 PV는 100Gi이고 PVC도 100Gi로 바인딩되어 있다. “PV 용량을 200Gi로 늘리려면?”

여기가 핵심 정리 포인트입니다.

18.1 실무 베스트 프랙티스: PV를 직접 건드리기보다 “PVC를 키운다”

Kubernetes가 공식적으로 설명하는 확장 경로도 “해당 PVC를 편집해서 더 큰 용량을 요청”입니다. Kubernetes+1

즉 보통은:

PV(100Gi) / PVC(100Gi) Bound
PVC를 200Gi로 patch/edit
컨트롤러가 실제 볼륨(EBS)을 늘리고
PV capacity도 결과적으로 200Gi로 맞춰지는 흐름

이 정석입니다.

18.2 “그럼 매니페스트와 실제가 불일치(드리프트) 나잖아?” — Helm/StatefulSet에서 진짜 자주 터지는 포인트

여기서 당신이 느낀 불편함이 정확합니다. 특히 StatefulSet + volumeClaimTemplates 조합에서 더 그렇습니다.

Kubernetes 문서가 말하듯 StatefulSet의 stable storage는 volumeClaimTemplates 기반이고, 그 결과 PVC는 컨트롤러가 생성합니다. Kubernetes
이때 Helm 차트가 “templates에 100Gi”를 박아둔 상태에서 운영 중 PVC만 200Gi로 키우면:

실제 PVC: 200Gi
차트 템플릿: 100Gi

가 되어 GitOps/Helm 관점에서 “desired vs live” 괴리가 생길 수 있습니다.

반대로 차트 values만 200Gi로 바꾸고 “기존 PVC까지 자동으로 커지겠지”를 기대하면, 이미 생성된 PVC는 자동 변경이 안 되는 케이스가 많아서(또는 업데이트 제약 때문에) 또 괴리가 생깁니다. 이게 현업에서 “StatefulSet volumeClaimTemplates는 생성 이후 관리가 까다롭다”라고 말하는 이유입니다. Kubernetes+1

19. “내 차트엔 pvc.yaml이 없고, StatefulSet이 자동 생성했다”를 운영 관점에서 어떻게 다뤄야 하나

여기서 실무적으로 선택지는 크게 두 개입니다.

선택지 A) PVC를 Helm이 직접 관리하도록 구조 변경

chart에 PersistentVolumeClaim 리소스를 명시적으로 두고
values로 size를 관리
helm upgrade가 곧 PVC patch로 이어지게 만드는 방식

장점: 드리프트가 줄어듦
단점: StatefulSet의 “Pod마다 PVC 자동 생성” 패턴과는 결이 다름(특히 레플리카별 전용 디스크가 필요하면 다시 설계 필요)

선택지 B) volumeClaimTemplates는 유지하되, “확장 런북”을 분리

values(템플릿)는 200Gi로 올려 “미래 기준”을 맞추고 Kubernetes
기존에 이미 만들어진 PVC들은 운영 작업으로 kubectl patch pvc ... 해서 확장 Kubernetes+1
필요 시 Pod 재시작으로 filesystem resize 마무리 Kubernetes

현업에서 가장 흔한 게 B입니다. “운영 작업”이 들어가긴 하지만, 사고가 적습니다.

20. 전체 흐름을 한 장으로 요약

20.1 EKS + EBS(동적 프로비저닝) 기본 플로우

StorageClass(ebs.csi.aws.com, allowVolumeExpansion=true)
            |
            v
PVC(100Gi)  --->  동적 프로비저닝 ---> PV(100Gi) + EBS(100Gi)
            |
            v
Pod mounts PVC

20.2 Retain + PVC 삭제 시 상태 변화

PVC 삭제 요청
  |
  | (pvc-protection finalizer: 사용 중이면 Terminating 유지)
  v
PVC 실제 삭제 완료
  |
  v
PV 상태: Released (Retain)   --- 데이터 남아있음 --- 수동 회수 필요

스토리지 오브젝트 보호(finalizer)로 “사용 중 삭제”를 막는다는 점이 핵심입니다. Kubernetes+1
Retain이면 Released가 된 PV는 바로 재사용 가능 상태가 아니라는 점도 중요합니다. Kubernetes+1

20.3 100Gi → 200Gi 확장(정석)

StorageClass: allowVolumeExpansion=true
   |
   v
PVC spec.resources.requests.storage = 200Gi 로 수정
   |
   v
CSI resizer가 EBS ModifyVolume 수행 (in-use 가능)
   |
   v
PV capacity 업데이트
   |
   v
노드에서 파일시스템 확장 완료(필요시 Pod 재시작)

Kubernetes가 “PVC를 수정해서 확장”이라고 명시합니다. Kubernetes+1
AWS는 EBS가 in-use 상태에서도 ModifyVolume 가능하다고 설명합니다. AWS Documentation
파일시스템 레벨은 때로 재시작/재마운트가 필요할 수 있습니다. Kubernetes

저작자표시 (새창열림)

'프로그래밍 > Kubernetes' 카테고리의 다른 글

Kubernetes Multi Scheduler: 기초부터 실전까지 - Part 1 (0)	2025.10.30
AmazonLinux2에 EC2에 쿠버네티스 설치하기. (0)	2023.07.02
쿠버네티스 공부 커리큘럼. (0)	2023.04.23