1. kubectl get pod -o jsonpath='{.items[*].spec.containers[*].image}'

2.클린 리스타트 (Clean Restart)
STS만 삭제하면 기존 Pod가 물고 있던 환경이 남을 수 있습니다. 아래 순서로 진행해 보세요.

Scale을 0으로 조정: kubectl scale sts --replicas=0

모든 Pod 삭제 확인: Pod가 완전히 사라질 때까지 대기합니다.

Scale을 다시 원복: kubectl scale sts --replicas=<원래숫자>
이렇게 하면 모든 노드가 동일한 설정과 동일한 이미지 풀링 시점을 갖게 됩니다.]]

3. kubectl get objectstore -n -o yaml을 통해 지정된 이미지를 확인하고, 모든 노드가 완벽히 동일한 태그를 사용하는지 확인하세요.
4. 결론적으로: sts를 삭제해도 동일한 현상이 반복되는 것은 ObjectStore 컨트롤러(Operator)가 잘못된 설정이나 호환되지 않는 버전 정보를 계속 주입하고 있기 때문입니다. Operator의 로그와 ObjectStore 커스텀 리소스의 status 필드를 상세히 살펴보시는 것이 좋습니다.

DirectPVVolume 이 Bound,Deleting 상태로 오래 유지되는 경우는 실제 운영에서 꽤 자주 있습니다.
특히 DirectPV + MinIO AIStor 환경 업그레이드 중에 많이 발생합니다.

핵심은 데이터를 가진 디스크는 실제로 정상인데 Kubernetes/DirectPV 메타데이터 상태만 꼬인 경우가 대부분이라는 점입니다.
그래서 디스크를 절대 초기화하거나 삭제하지 않고 복구하는 절차가 중요합니다.

아래는 실제 운영에서 사용하는 안전 복구 Runbook입니다.

---

1️⃣ 먼저 절대 하면 안 되는 것

문제 volume을 보면 보통 이런 생각을 합니다.

kubectl delete pvc
kubectl delete pv
kubectl delete directpvvolume

⚠️ MinIO 환경에서는 절대 먼저 하면 안 됩니다.

이렇게 하면

disk metadata 제거
MinIO erasure set 깨짐
heal 필요

심하면 데이터 손실 위험이 있습니다.

---

2️⃣ 현재 상태 확인

먼저 상태를 정확히 확인합니다.

1. DirectPVVolume 상태

kubectl get directpvvolumes -o wide

확인

STATE = Bound,Deleting
NODE
DEVICE

---

2. PV / PVC 매핑

kubectl get pv | grep minio
kubectl get pvc -A | grep minio

확인

PVC -> PV -> DirectPVVolume

---

3. 어떤 Pod가 사용하는지

kubectl get pods -o wide

확인

objectstore-X

---

3️⃣ Pod 상태 확인

문제 pod 로그 확인합니다.

kubectl logs <objectstore-pod>

대표적으로 이런 메시지가 나옵니다.

drive not found
disk not mounted
waiting for quorum

이 경우 disk mount 문제일 가능성이 높습니다.

---

4️⃣ Node에서 실제 disk 상태 확인

문제 volume이 있는 node에 접속합니다.

확인

lsblk

그리고

mount | grep directpv

또는

df -h

중요한 것

disk가 실제로 존재하는지
mount 되어 있는지

대부분 상황

disk 정상
mount 정상

즉 DirectPV 상태만 꼬인 것입니다.

---

5️⃣ DirectPV node agent restart (가장 안전한 방법)

먼저 DirectPV daemonset을 restart 합니다.

kubectl rollout restart ds directpv-node -n directpv-system

이 작업은

node agent restart
volume reconcile 재실행
mount 상태 재확인

많은 경우 여기서 Deleting 상태가 정상으로 돌아옵니다.

확인

kubectl get directpvvolumes

---

6️⃣ 그래도 Deleting이면 (Finalizer 문제)

DirectPV CRD는 finalizer 때문에 삭제 상태에서 멈출 수 있습니다.

확인

kubectl get directpvvolume <volume> -o yaml

여기서

metadata.finalizers

확인합니다.

---

7️⃣ Finalizer 제거 (데이터 안전)

volume이 실제로 사용 중이면 CR metadata만 수정합니다.

kubectl patch directpvvolume <volume> \
-p '{"metadata":{"finalizers":[]}}' --type=merge

이 작업은

disk 삭제 ❌
metadata만 수정

그래서 데이터 손상 위험이 없습니다.

---

8️⃣ Pod 재시작

volume 상태가 정상으로 돌아오면 pod를 재시작합니다.

kubectl delete pod <objectstore-pod>

StatefulSet이 다시 생성합니다.

---

9️⃣ MinIO cluster 확인

pod 정상화 후 확인합니다.

mc admin info

확인

online drives
offline drives

---

🔟 heal 상태 확인

혹시 disk reconnect 때문에 heal이 필요할 수 있습니다.

mc admin heal -r

보통 heal 없이 바로 정상화됩니다.

---

실제 운영에서 가장 흔한 원인

운영 경험상 Bound,Deleting의 원인은 대부분 아래입니다.

1️⃣ DirectPV controller restart 중 reconcile
2️⃣ node agent restart
3️⃣ mount 상태 mismatch
4️⃣ device path 변경
5️⃣ upgrade 중 metadata sync 문제

즉 디스크 문제보다 controller metadata 문제입니다.

---

👍 실제 운영에서 가장 안전한 복구 순서 (요약)

1️⃣ 상태 확인

kubectl get directpvvolumes

2️⃣ node disk 확인

lsblk
mount

3️⃣ DirectPV node restart

kubectl rollout restart ds directpv-node

4️⃣ finalizer 제거

kubectl patch directpvvolume

5️⃣ MinIO pod restart

kubectl delete pod

6️⃣ cluster health 확인

mc admin info

---

💡 지금 질문자 상황(
6 pods 중 2 pods 503 + Bound,Deleting volume )은
DirectPV metadata stuck 케이스와 거의 동일한 패턴입니다.

---

원하시면 추가로 MinIO + DirectPV 환경에서 “503이 계속 유지될 때 원인을 1분 안에 찾는 디버깅 방법”도 알려드리겠습니다.
이건 운영 장애 대응에서 굉장히 강력한 방법입니다.

==

벤더가 말한 DirectPV → Operator → ObjectStore 순서는 원칙적으로 맞는 절차입니다.
다만 그 과정에서 말하는 “volume reconcile 문제”는 보통 DirectPV가 업그레이드되면서 기존 Volume CR을 재검증(reconcile)하는 과정에서 상태가 잠깐 바뀌거나 꼬이는 현상을 의미합니다. 이게 실제로 어떤 구조로 발생하는지 설명해보겠습니다.

---

1️⃣ DirectPV의 Volume 관리 구조

DirectPV는 일반 CSI와 조금 다르게 Kubernetes CRD로 디스크를 관리합니다.

구조는 대략 이렇게 됩니다.

Disk (node local device)
   ↓
DirectPVVolume (CRD)
   ↓
PV
   ↓
PVC
   ↓
Pod (MinIO)

즉 Kubernetes에서 실제 상태는:

DirectPVVolume -> PV -> PVC -> Pod

DirectPV controller가 이 상태를 계속 reconcile loop로 관리합니다.

---

2️⃣ DirectPV 업그레이드 시 내부에서 일어나는 일

DirectPV를 업그레이드하면 다음 컴포넌트가 재시작됩니다.

directpv-controller
directpv-node

이때 controller는 모든 volume을 다시 검사합니다.

reconcile volumes
reconcile disks
reconcile mounts

즉 내부적으로 이런 작업이 수행됩니다.

1 disk discovery
2 volume ownership 확인
3 mount 상태 확인
4 stale volume cleanup

이걸 volume reconcile이라고 합니다.

---

3️⃣ Reconcile 과정에서 상태가 바뀌는 이유

이때 controller가 다음 상황을 발견하면 상태를 바꿉니다.

예:

Case 1: volume metadata mismatch

PV 존재
하지만 DirectPVVolume metadata mismatch

→ 상태

Deleting
Released

---

Case 2: mount 상태 불일치

예

node reboot
mount 남아있음

→ DirectPV 판단

stale mount

→ 상태

Deleting

---

Case 3: node unreachable

node agent restart
controller가 node를 잠깐 못봄

→ 상태

Deleting

---

4️⃣ 왜 MinIO 환경에서 특히 문제인가

MinIO는 StatefulSet + Local disk 구조입니다.

예:

pod-0 → diskA
pod-1 → diskB
pod-2 → diskC

DirectPV reconcile 중에

diskB → Deleting

이렇게 되면

pod-1 mount 실패

결과

MinIO node join 실패
503

즉 DirectPV reconcile → disk 상태 변화 → MinIO node failure가 됩니다.

---

5️⃣ 그래서 벤더가 DirectPV 먼저 업그레이드하라고 하는 이유

그렇다면 왜 벤더는 DirectPV → Operator → ObjectStore 순서를 권장할까요?

이유는 CSI compatibility 때문입니다.

MinIO Operator와 MinIO AIStor는 특정 DirectPV 버전을 요구합니다.

예

AIStor version X
requires
DirectPV >= Y

그래서 순서는

1 DirectPV upgrade
2 Operator upgrade
3 ObjectStore upgrade

입니다.

---

6️⃣ 실제 운영에서 발생하는 문제 패턴

문제는 DirectPV upgrade 직후 reconcile이 동시에 실행되는 것입니다.

예:

DirectPV controller restart
↓
모든 volume reconcile
↓
일부 volume 상태 변경
↓
MinIO pod 재시작
↓
503

특히 다음 상황에서 자주 발생합니다.

disk mount 오래됨
node restart history
device path 변경

---

7️⃣ 안전하게 DirectPV 업그레이드하는 운영 팁

그래서 실제 운영에서는 보통 이렇게 합니다.

1️⃣ MinIO cluster health 확인

mc admin info

offline drive 없어야 합니다.

---

2️⃣ DirectPV volume 상태 확인

kubectl get directpvvolumes

다음 상태 있으면 업그레이드 중단

Deleting
Lost
Released

---

3️⃣ node mount 확인

문제 node에서

mount | grep directpv

---

4️⃣ DirectPV upgrade 후 확인

업그레이드 후 반드시 확인

kubectl get directpvvolumes

그리고

kubectl get pods -n directpv-system

---

8️⃣ 지금 질문자 상황과 연결해 보면

현재 상태

6 pods
2 pods 503
DirectPV volume = Bound,Deleting

이 패턴은 DirectPV reconcile 이후 volume 상태가 꼬인 전형적인 패턴입니다.

특히 다음 상황일 가능성이 높습니다.

DirectPV upgrade
↓
volume reconcile
↓
2 volume 상태 변경
↓
pod mount 실패
↓
MinIO peer join 실패
↓
503

그리고 pod log에 나온

remote cannot handle this api version

은 peer connection 실패 후 나오는 secondary error일 가능성이 큽니다.

---

✅ 만약 원하시면 제가 추가로

“DirectPV volume이 Bound,Deleting 상태일 때 데이터 손상 없이 복구하는 실제 운영 절차”

도 설명해 드리겠습니다.
이건 MinIO 운영에서 굉장히 중요한 troubleshooting 절차입니다.

===

MinIO + DirectPV 환경에서 MinIO AIStor 업그레이드할 때 실제 운영에서 많이 사용하는 안전 절차(runbook)를 정리해보겠습니다.
특히 Kubernetes + StatefulSet + Local Disk 구조라서 일반 애플리케이션 업그레이드보다 체크해야 할 것이 많습니다.

---

1️⃣ 업그레이드 전 사전 점검 (가장 중요)

업그레이드 실패의 80%는 이 단계에서 걸러집니다.

1. Cluster health 확인

MinIO가 완전히 정상이어야 합니다.

mc admin info <alias>

확인할 것

online drives = expected drives
offline drives = 0

그리고

mc admin heal -r

heal pending 없어야 합니다.

---

2. Erasure Set Quorum 확인

예:

EC 8:3

이면

minimum 8 drives

모든 node가 online인지 확인합니다.

---

3. DirectPV 상태 확인

모든 volume이 정상 상태인지 확인합니다.

kubectl get directpvvolumes

정상 상태

Bound

문제 상태

Deleting
Released
Lost
Terminating

하나라도 있으면 업그레이드 진행하지 않는 것이 좋습니다.

---

4. PVC/PV 상태

kubectl get pvc
kubectl get pv

확인

STATUS = Bound

---

5. DirectPV node 상태

kubectl get directpvnodes

모든 node

Ready

확인

---

6. Pod 분산 확인

StatefulSet pod가 rack/node에 분산되어 있는지 확인합니다.

kubectl get pods -o wide

---

2️⃣ 업그레이드 순서 (매우 중요)

MinIO ecosystem은 업그레이드 순서가 중요합니다.

권장 순서

1️⃣ Operator
2️⃣ DirectPV
3️⃣ ObjectStore (MinIO / AIStor)

잘못된 순서 예

MinIO 먼저 upgrade
→ operator incompatible

또는

DirectPV 먼저 upgrade
→ volume reconcile 문제

---

3️⃣ Operator 업그레이드

먼저 MinIO Operator를 업그레이드합니다.

확인

kubectl get pods -n minio-operator

정상 상태

Running

---

4️⃣ DirectPV 업그레이드

DirectPV CSI를 업그레이드합니다.

확인

kubectl get pods -n directpv-system

특히

directpv-node
directpv-controller

확인합니다.

그리고 반드시

kubectl get directpvvolumes

확인해서 상태 변화 없는지 체크합니다.

---

5️⃣ ObjectStore 업그레이드

이제 AIStor 업그레이드 진행합니다.

ObjectStore는 StatefulSet rolling update로 진행됩니다.

확인

kubectl rollout status sts <objectstore>

pod가 하나씩 업데이트됩니다.

pod-0
pod-1
pod-2

---

6️⃣ 업그레이드 중 모니터링

업그레이드 중 반드시 확인해야 할 것들입니다.

1. Pod 상태

kubectl get pods -w

확인

Running
Ready

---

2. MinIO cluster health

mc admin info

확인

online drives
offline drives

---

3. DirectPV volume

kubectl get directpvvolumes

확인

Deleting
Lost

없는지 체크

---

7️⃣ 업그레이드 후 검증

업그레이드 완료 후 반드시 확인합니다.

1. Cluster info

mc admin info

---

2. Bucket access

mc ls
mc cp

---

3. Erasure heal 상태

mc admin heal -r

---

4. Objectstore pod 상태

kubectl get pods

---

8️⃣ 운영에서 반드시 하는 추가 보호 절차

실제 운영에서는 아래도 많이 합니다.

1. Upgrade 전 snapshot

예

• etcd snapshot
• object metadata backup

---

2. Node drain 금지

업그레이드 중

node drain
cluster autoscaler

절대 하지 않는 것이 좋습니다.

---

3. PodDisruptionBudget 확인

MinIO cluster 보호

---

9️⃣ 업그레이드 실패 시 대응

업그레이드 중 문제가 생기면

1️⃣ rollout pause

kubectl rollout pause sts <objectstore>

2️⃣ 문제 pod 확인

kubectl logs

3️⃣ volume 상태 확인

kubectl get directpvvolumes

---

🔟 운영 경험상 가장 중요한 체크 3개

실제로 가장 중요합니다.

1️⃣ DirectPV volume 상태

Deleting
Lost

있으면 업그레이드 중단

---

2️⃣ MinIO cluster health

offline drives = 0

---

3️⃣ Rolling upgrade 확인

동시에 여러 pod restart 안됨

---

🔎 지금 질문자 상황에 대한 추가 조언

현재 상태

2 pods 503
DirectPV volume = Bound,Deleting

이 상태면 업그레이드 중 DirectPV reconcile이 걸린 가능성이 큽니다.

특히

directpv operator upgrade

직후에 자주 발생합니다.

---

👍 원하시면 제가 MinIO + DirectPV 환경에서 "volume Bound,Deleting 상태 100% 안전하게 복구하는 방법 (데이터 손상 없이)"도 정리해 드릴게요.

이건 실제로 운영에서 자주 쓰는 복구 절차입니다.

===

MinIO OSS → AIStor 업그레이드에서 실제로 가장 많이 터지는 장애 TOP 5 (DirectPV 포함)**도 정리해줘

==

6개 중 2개 pod에 문제야(계속 같은 pod만), volume은 모두 bound,deleting 상태야 (노드마다 한개씩 있음) remote cannot handle the api version 로그는 objectstore pod log에서 나왔어,

===

minio aistor pod 중 일부가 503에서 바뀌질 않네. sts 삭제 후에도 동일 pod가 그러는데.. 왜 그럴까? remote cannot handle this api version 이 관련이 있을까? 기존 open source minio에서 상용 aistor로 upgrade 를 하고 있어. directpv도 그렇고 operator도 그렇고. 이후 objectstore가 기동되면서 저런거 같아. 이런거와 관련이 있을까? 혹시 directpv 의 volume이 bound, deleting으로 되어 있다면 어떤 상태인거야?