볼륨클레임템플릿 생성후에도 공유 파일시스템은 여전하여 문의드립니다.

강사님, 애초 드린 질문의 의미가 제 3자 입장에서 애매하게 해석되었었나봅니다.

제 질문의 의도를 하나 문장으로 축약하자면 다음과 같습니다.

"statefulset 파드 <=> pvc <=> pv 가 모두 1대1 관계임에 따라 파드별 독립된 pv 볼륨을 할당받았음, 다만 이러한 1대1 관계가 의미를 갖으려면 각 statefulset 파드가 독립된 볼륨영역 (다른 파드에게는 보이지 않는..) 을 가져야할 것 같은데, 실습 테스트 환경은 SC 프로비저너가 가진 볼륨 자체가 마스터노드의 단일 NFS 볼륨이라서 그런것인지 파드<=>pv 는 1대1이 맞지만, 그 이후 pv 가 가지는 물리적 디렉터리 영역은 공유볼륨에 지나지 않음"

제 질문의 의도를 표현해보기 위해 아래와 같은 확인절차를 수행하였습니다 (1~5단계로 숫자 표기하여 절차 분리표기)

1) Statefulset 내 선언된 VolumeClaimTemplates 가 SC 를 호출하여 PV 대 PVC 가 1대1 생성된것 확인

[root@m-k8s dynamic-vol]# k get pv,pvc

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE

persistentvolume/pvc-1fb0d529-ed2e-48d3-94b3-522334b3345b 20Gi RWO Delete Bound default/each-sts-backup-sts-0 managed-nfs-storage 12m

persistentvolume/pvc-28110ec7-a4e5-4743-8362-26989aefa75b 20Gi RWO Delete Bound default/each-sts-backup-sts-2 managed-nfs-storage 12m

persistentvolume/pvc-828760bc-4324-4d35-a841-f4726a16baa4 20Gi RWO Delete Bound default/each-sts-backup-sts-1 managed-nfs-storage 12m

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

persistentvolumeclaim/each-sts-backup-sts-0 Bound pvc-1fb0d529-ed2e-48d3-94b3-522334b3345b 20Gi RWO managed-nfs-storage 12m

persistentvolumeclaim/each-sts-backup-sts-1 Bound pvc-828760bc-4324-4d35-a841-f4726a16baa4 20Gi RWO managed-nfs-storage 12m

persistentvolumeclaim/each-sts-backup-sts-2 Bound pvc-28110ec7-a4e5-4743-8362-26989aefa75b 20Gi RWO managed-nfs-storage 12m

2) 각 statefulset 파드가 가지는 PVC 클레임 확인 => 파드 대 PVC = 1대1 관계 확인

[root@m-k8s dynamic-vol]# k get po sts-0 -o yaml | grep claimName

claimName: each-sts-backup-sts-0

[root@m-k8s dynamic-vol]# k get po sts-1 -o yaml | grep claimName

claimName: each-sts-backup-sts-1

[root@m-k8s dynamic-vol]# k get po sts-2 -o yaml | grep claimName

claimName: each-sts-backup-sts-2

3) 각 파드에 할당된 PV 의 소스 경로 체크 (당연히 마스터노드의 동일경로 바라보는게 맞지만, 확인차원으로 체크해봄)

애초 SC 프로비저너가 프로비저닝하는 경로가 마스터노드의 /nfs_shared/dynamic-vol 경로가 NFS Export 에 의해 공유된 경로이므로 모두 동일경로.. 당연한 결과

[root@m-k8s dynamic-vol]# k get pv pvc-1fb0d529-ed2e-48d3-94b3-522334b3345b -o yaml | grep path

path: /nfs_shared/dynamic-vol/default

[root@m-k8s dynamic-vol]# k get pv pvc-28110ec7-a4e5-4743-8362-26989aefa75b -o yaml | grep path

path: /nfs_shared/dynamic-vol/default

[root@m-k8s dynamic-vol]# k get pv pvc-828760bc-4324-4d35-a841-f4726a16baa4 -o yaml | grep path

path: /nfs_shared/dynamic-vol/default

4) 마스터노드의 NFS Exported 된 경로에서 임의 파일 생성

[root@m-k8s default]# pwd

/nfs_shared/dynamic-vol/default

[root@m-k8s default]#

[root@m-k8s default]# touch 1 2 3 4 5

[root@m-k8s default]# ls -l

total 0

-rw-r--r--. 1 root root 0 Apr 26 15:12 1

-rw-r--r--. 1 root root 0 Apr 26 15:12 2

-rw-r--r--. 1 root root 0 Apr 26 15:12 3

-rw-r--r--. 1 root root 0 Apr 26 15:12 4

-rw-r--r--. 1 root root 0 Apr 26 15:12 5

5) 각 StatefulSet 에서 SC 통해 마운트된 경로 체크시 모두 다 바라볼 수 있음

=> Statefulset 파드 <=> PVC <=> PV 를 모두 1대일로 매칭시킨 것까지는 이해가 됨 (Statefulset 파드가 각 PV를 전용 볼륨처럼 1:1 할당받았음)

다만 실제 원본 소스는 테스트 차원에서 마스터노드의 특정 단일경로를 NFS Exported 된 것을 가져다 SC 프로비저너가 마운트하는 공유볼륨...

의문이 드는 부분은 모두 같은 볼륨을 바라보게 된다고 하면, 각 파드별 독립된 PV 볼륨을 1:1 로 할당받았던 의미가 희석되는게 아닌가 하는 생각

만약 /nfs_shared/dynamic-vol/default 아래 sts-0, sts-1, sts-2 파드명 하위디렉터리가 새로 만들어지고 이를 각 파드가 마운트하였다면 각 파드는 모두 서로 다른 디렉터리를 부여받았기 때문에 최종적으로 바라보는 경로도 1:1이 되는 것이므로 Statefulset 파드가 각 PV를 전용 볼륨처럼 1:1 할당받았던 의미가 있었지 않았을까 하는데서 출발한 의문이었음

[root@m-k8s default]# k exec sts-0 -it -- /bin/bash -c 'ls -l /backup_data'

total 0

-rw-r--r--. 1 root root 0 Apr 26 06:12 1

-rw-r--r--. 1 root root 0 Apr 26 06:12 2

-rw-r--r--. 1 root root 0 Apr 26 06:12 3

-rw-r--r--. 1 root root 0 Apr 26 06:12 4

-rw-r--r--. 1 root root 0 Apr 26 06:12 5

[root@m-k8s default]#

[root@m-k8s default]# k exec sts-1 -it -- /bin/bash -c 'ls -l /backup_data'

total 0

-rw-r--r--. 1 root root 0 Apr 26 06:12 1

-rw-r--r--. 1 root root 0 Apr 26 06:12 2

-rw-r--r--. 1 root root 0 Apr 26 06:12 3

-rw-r--r--. 1 root root 0 Apr 26 06:12 4

-rw-r--r--. 1 root root 0 Apr 26 06:12 5

[root@m-k8s default]# k exec sts-2 -it -- /bin/bash -c 'ls -l /backup_data'

total 0

-rw-r--r--. 1 root root 0 Apr 26 06:12 1

-rw-r--r--. 1 root root 0 Apr 26 06:12 2

-rw-r--r--. 1 root root 0 Apr 26 06:12 3

-rw-r--r--. 1 root root 0 Apr 26 06:12 4

-rw-r--r--. 1 root root 0 Apr 26 06:12 5

안녕하세요
statefulset까지 들으셨다면, 관리자와 사용자로 구분된다는 것은 이해하셨을 것으로 생각됩니다.

이 때 관리자는 거의 모든 것에 대해서 이해하고 있어야 하니, 온프레미스의 경우 내부적으로 구현되어지는 것들을 알고 있어야 합니다. (그래야 조치도 가능하니까요)
하지만 사용자는 그것을 알지 않아도 되긴합니다.
그것은 계정과 일반적인 linux permission 그리고 쿠버네티스 내라면 RBAC(추후에 나옴)으로 관리됩니다.

여전히 독립적인 PV가 왜 안 보여야 하는건지는 모르겠사오나....
아마 관리자와 사용자에 관점 및 현재 랩에는 구현되어 있지 않으나, 계정에 대한 부분에 대해서 아직 미처 생각하지 못하여서 그런거 같긴 한데...해당 부분으로 의문점이 풀리셨을지 모르겠습니다.

아직 해결되지 않은 부분이 있다면 댓글 달아주시기 바랍니다.

의문이 드는 부분은 모두 같은 볼륨을 바라보게 된다고 하면, 각 파드별 독립된 PV 볼륨을 1:1 로 할당받았던 의미가 희석되는게 아닌가 하는 생각

>> 이 부분은 무슨 의미인지 제가 이해가 되지 않아 답변 드리기가 어려운데...
>> 위에 예제로 드린 것처럼 같은 NAS를 바라보면 안되는걸까요? 이건 디자인 컨셉에 대한 건데 어떤 것을 원하시는지 모르겠습니다.

부득이하게 제가 정확하게 답변을 못 드리는거 같은데...
원하시는건 구현할 수 있을 것 같습니다만...이건 디자인 컨셉에 관련해서 어떻게 구현할 것인가인거 같다는 생각이 듭니다.
아시는 것처럼 현재는 각 기능을 이해하고자 하는 교육이라 최적의 아키택처를 교육하지 않습니다. 참고 부탁드립니다.

의문이 드는 부분은 모두 같은 볼륨을 바라보게 된다고 하면, 각 파드별 독립된 PV 볼륨을 1:1 로 할당받았던 의미가 희석되는게 아닌가 하는 생각

>> 이 부분은 무슨 의미인지 제가 이해가 되지 않아 답변 드리기가 어려운데...
>> 위에 예제로 드린 것처럼 같은 NAS를 바라보면 안되는걸까요? 이건 디자인 컨셉에 대한 건데 어떤 것을 원하시는지 모르겠습니다.

--> 어떤것을 원하는게 아니고, pv는 1:1로 할당받았는데 최종적으로 바라보는 타겟은 동일 경로... 그렇다면 앞서 파드에 pv를 1:1로 하는 의미가 무엇이었는가? 에 대한 의문입니다. 배우는자의 관점에서 보다 보니 왜 pv를 파드 전용볼륨이라고 하는걸까... 실제로는 전용은 아닌데... 라는데서 출발하는 의문입니다. 뭘 원하고 그런게 아니니 디자인 컨셉이 원래 그렇다면 그냥 답변안주셔도 됩니다.. 제가 뭘 원하는식으로 얘기하시는데, 원하는 답변이 도출되는것을 제가 의도적으로 원하진 않았습니다. QnA 게시판이 이런 목적이니깐요...

--> 어떤것을 원하는게 아니고, pv는 1:1로 할당받았는데 최종적으로 바라보는 타겟은 동일 경로... 그렇다면 앞서 파드에 pv를 1:1로 하는 의미가 무엇이었는가? 에 대한 의문입니다. 배우는자의 관점에서 보다 보니 왜 pv를 파드 전용볼륨이라고 하는걸까... 실제로는 전용은 아닌데... 라는데서 출발하는 의문입니다. 뭘 원하고 그런게 아니니 디자인 컨셉이 원래 그렇다면 그냥 답변안주셔도 됩니다.. 제가 뭘 원하는식으로 얘기하시는데, 원하는 답변이 도출되는것을 제가 의도적으로 원하진 않았습니다. QnA 게시판이 이런 목적이니깐요...

>>>
QnA 게시판의 목적에 대해서는 저도 정의하기가 어려워서 그 부분을 제외하고
현재 환경에서 최종적으로 바라보는 타켓이 동일 경로라는건
1) 일단 저희는 알고 있지만, 일반적으로 사용할때는 모릅니다.
2) 다만 지금은 아는 상태에서 어떤 의미가 있냐고 물어보신다면...
괜찮으시다면 어떤 의미가 ...정말 어떤 것을 생각하고 문의하시는지 몰라서요.
2-1) 한 곳인데 이거 장애나면 문제냐? 라고 물어보신다면 > 네 문제죠.라고 답변을 드릴 수 있을 것 같고요.
2-2) 한 곳이라 다 볼 수 있는데 괜찮은거야? 라고 보안의 관점으로 물어보신다면, 위에 답변 드린 것처럼 또는 #1번처럼 보통 어디에 있는지 어떻게 되는지 볼 수 있는 계정을 제공하지 않을 것 같습니다.

위의 답변으로 부족한 부분이 있으면 댓글 부탁드립니다.
참고로 현재 storageclass를 구현한 것은 (줄여서) nfs-provioner 이오나 실무적으로 쓰는 경우도 있고 좀 더 다른 요건들을 충족하기 위해서 (SLA, Performance 기타등등) 다른 CSI를 붙여서 도 사용합니다.

++ 부가적으로 왜 pv를 파드 전용볼륨이라고 하는걸까... 실제로는 전용은 아닌데... 라는데서 출발하는 의문입니다 에 대해서 좀 더 기입해 드리면...
마운트 하는 것처럼 pv <-> pvc 가 bound 되게 되면 다른 곳에서 접근해서 쓰지 못하니 전용으로 본다고 말씀드릴 수 있을 것 같습니다.

QnA 게시판의 목적에 대해

제가 이해하고 있는 부분으로 기입 드리오니, 참고 부탁드립니다.
현재 제공되고 있는 내용과 실습 진행에 문제가 발생한다면 또는 틀리거나 잘못된 내용을 전달하는 부분이 있다면, 해당 부분에 대해서 공유해 주시거나 이상한 부분에 대해서 문의하는 목적으로 이해하고 있습니다.
이를 통해서 조치하여 다수의 사용자들이 불편을 겪지 않는 목적으로요.

이는 온라인 강의의 특성상 굉장히 많은 다수를 1인 지식공유자가 담당해야 하기 때문이기도 합니다.
(만약 제한적인 인원으로 진행하는 오프라인 강의였다면 달랐다는 의미입니다.)
이에 현재까지 주셨던 질문을 보면, 아마 학습자님께서는 당연히 많은 고민과 궁금함을 통해서 주셨을 것이라고 생각되지만 안타깝게도 온라인 강의 특성상 개개인의 특성에 맞는 답과 진행을 하기에는 위의 기술한 많은 다수에 대해서 1인이 서비스를 제공해야 하기 때문에 어렵습니다.

사실 위와 같이 적긴 했지만, 1-2번 정도야 궁금하신 부분을 해결하는 과정에서 다른 분들이 함께 배워가는 부분도 있을 수 있으니 진행하고 있사오나, 지금 또는 전의 질문과 같은 타입에 대해서 지속 가능할지 모르겠습니다. 해당 부분에 대해서 만족스럽지 않다면, 인프런에 해당 부분을 문의하시고, 제가 가능한 선에서 최대한 처리토록 하겠습니다.

여러가지로 제가 부족해서 발생하는 문제인거 같아서 송구스럽다는 말씀을 함께 드립니다.

말씀하신데로 "pv <-> pvc 가 bound 되게 되면 다른 곳에서 접근해서 쓰지 못하니 전용으로 본다" 의 의미에서 전용이라는 단어가 사용된것으로 이해하려고 합니다..

a) 애초 각 statefulset 에 의해 생성된 파드는 독립된 고유의 네이밍으르 가지고
b) statefulset 파드에 VolumeClaimTemplates 를 활용시 파드 전용 볼륨처럼 활용된다

라는 두가지 특성을 전제로 그럼 볼륨 자체도 각 파드가 서로 다른 영역을 바라보겠지?
(nfs 아래 sts-0, sts-1, sts-2 라는 파드명과 같은 네임의 하위경로가 생성되어 각 파드에 배분할당) 라고 생각했지만, 테스트 결과는 결국 똑같은 경로이길래... 전용이라는 단어가 사용된 바운더리를 이해하고 싶었습니다.
암튼 결과적으로 실제 그 "전용"의 의미는 pv와 pvc 간의 1:1 전용(앞단)일뿐이라는게 결론이네요.. 그 뒷단의 3개 pv가 nfs 단일 경로를 바라보는것까지가 전용이라는 정의의 바운더리가 아닌것이고요

모쪼록 강의 잘 듣고있습니다. 시스템 엔지니어 관점에서 접근하다보니 온프레미스, 레가시 베어메탈과 비교하면서 보다보니 여러 궁금증을 매번 가지고 접근중입니다 ... 다소 질문방향이 애매하게 전달되었다면 양해말씀 구합니다.

QnA 게시판의 목적에 대해

QnA 게시판이 말씀하신데로 강의 중의 실습이슈/오류지적 부문으로만 함축된다라는 그런 정의가 있기를 수강생 입장에서도 원하는 바입니다.

다만 애초 그런 공식 공지문구가 따로 없다보니 강사 입장과 반대로 수강생은 나의 기술적인 궁금증도 답변가능한 영역으로서 내 구매내역에 포함된 것으로 보편적으로 인식합니다. 대부분 수강생들이 온라인 이전에 오프라인 IT 강의를 많이 접해왔고 오프라인에선 강사님들이 여러 질의응답을 대체로 받아주시며 내용이 오로지 강의자체의 오류지적으로만 국한되지는 않기 때문입니다. 그간 여러 벤더교육을 많은 강사님들께 받아봤지만 수업외 다른 기술적 질의는 받지 않습니다라는 언급을 한 것을 저와 제 지인포함 사실 아직까지 본적이 없네요.

오프라인처럼 온라인도 n:1 수업인건 동일한데, 저 포함 온라인 수강생들이 모르는 온라인 강의만의 또다른 숨겨진 무언가의 제약이 있다는것으로 이해됩니다. 이미 다른 수강생들도 일부 기술 질의응답을 한것들이 있고, 얼마전 드렸던 질문에도 답변을 꾸준히 주시길래 랜선교육 Y/N 관계없이 당연히 가능한 부분으로 인식했는데 오프라인에서는 겪지 못한 온라인강의의 또다른 숨겨진 QnA 제약이 있다는것을 다른 수강생들도 잘 모르고 있는것으로 보여집니다.

애초 질의답변 게시판의 수용영역/범주/특성을 모두가 알 수 있도록, 미래 수강생들도 오해의 소지가 없게끔 명확히 전달된다면 참 좋겠네요...

암튼 결과적으로 실제 그 "전용"의 의미는 pv와 pvc 간의 1:1 전용(앞단)일뿐이라는게 결론이네요.. 그 뒷단의 3개 pv가 nfs 단일 경로를 바라보는것까지가 전용이라는 정의의 바운더리가 아닌것이고요

>>> 네 전통적인 온프레미스의 관점의 LUN을 할당하는 Storage 개념과 비교되서 그러셨을 수도 있을 것 같습니다. 현재 statefulset의 VolumeClaimTemplates의 가장 큰 존재 가치는 Stateful(상태유지, 저장 보존)한 것에 있습니다. 이에 따라 기존에 하셨던 것과 다르게 statefulset 오브젝트는 지워도 pv,pvc가 삭제되지 않습니다. (기본으로는)
이는 위와 같이 Stateful하게 pv,pvc를 바라보기 때문입니다. 그러한 이유로 각각의 statefulset이 고유한(또는 해 보이는) 경로를 가지고 각각의 관리 주체를 따로 가지고 되는 것입니다.
추후에 필요가 있다면 관리 객체를 따로 가지고 가는 수준으로 만들어 질 수도 있으나..제가 볼때는 이렇게 하게 되면 굳이 관리 포인트를 더 가져가게 되는 수준이기 때문에 그럴 필요는 없을 것 같습니다.
아마도 Provioner 또는 CSI에 따라 원하시는 형태의 동작이 가능한 경우도 있을 것 같기도 합니다. (보안 요건등으로)

다시 살펴보니 관점에 따라 충분히 의문점이 나올 수도 있는 부분인데...
제가 부족해서 미처 살펴보지 못한거 같습니다.
여러가지로 좋은 관점을 공유해 주셔서 감사드립니다.

1. QnA 게시판 관련은 제가 지금 바로 답변하기 어려우니 인프런과 상의 후에 답변 다시 응답드리겠습니다.

2. 다른 provisioner(EKS,GKE)의 기본 동작은 내일 테스트 후에 공유드리겠습니다.

#2
해당 부분은 현재 사용하는 NFS-Provisioner에 일부 설정 또는 확인이 필요하지만 limitation일수도 있을 것 같습니다.
우선적으로 확인되는 내용은 생성되는 pv마다 고유의 디렉터리를 가져야 하는데 /nfs_shared/dynamic-vol/<namespace>/<pv #1,2,3>해당 부분이 되지 않아서 발생하는 이슈로 보시면 될 것 같습니다.
이 외에 CSP에서 제공하는 스토리지클래스 중에 즉시(Immediate)에 해당 하는 것으로 실습해 보시면 해당 문제가 발생하지 않는 것을 확인하실 수 있습니다.

GKE

[EKS]

#1
구구절절 적었는데, 어떤 것을 적어도 언잖음이 풀리거나 이해를 구하는게 쉽지 않을 것 같아서 언급해 주신 것처럼 할 수 있는 방법이 어떤게 있을까 고민을 해 봤는데....
시작 페이지와 질문에 모두
질문 답변을 제공하지만, 강의 비용에는 Q&A는 포함되어 있지 않습니다.

라는 문구를 넣도록 하겠습니다. 오해를 불러일으킨 점과 좋은 의견을 주신점에 대해서 감사드립니다.
위의 변화로 인해서 수강에 어려움이 있으시다면 인프런에 케이스를 열어주시면 최선을 다해서 요청하신 부분이 반영되도록 하겠습니다.

SIGs 단체 제공 nfs 프로비저너 리밋일 수도 있다고 하시니 이제 확실한 이해가 됩니다. 이걸 모르면 원래 PV는 모두 같은 공간(온프렘의 LUN) 을 공용하는거야.. 라고 착각할 소지가 충분히 있다는것도 알게 되었구요!

애초 드린 의문점이 PV, PVC, 파드 관계를 질문드린것이었으니 인강내용의 범주였습니다.. 충분히, 조금만 생각하면 어? 뭔가 이상한데? 라는걸 그 누구든 체크할 수 있는 부분이었구요..

QnA가 비용에 포함되느냐 아니냐는 사실 핵심도 아니고 그것보다는 강의 질을 보고 수강여부를 결정합니다. 결론적으로 강의비용 QnA 포함여부 관계없이 질문답변을 받아주시는것은 맞나보네요. 지금까지 다른 수강생의 QnA 글들도 그래왔고 제가 질문드렸던것과 같이 강의 관련된 내용에 한해서요..깔끔하네요!

정리를 해야 할 것 같아서 다음의 내용을 추가로 드립니다.

nfs-provioner의 경우 세부적인 디렉터리를 만들기 위해서는 annotation을 설정해야 하는데
이 경우에도 sts-backup을 자체를 volumeClaimTemplates 내에서 공유합니다.

그런데 이렇게 디렉터리를 추가로 만드는 경우라고 할지라도 현재 상태 내에서 리커시브하게 만들어내기 때문에
sts-backup이라는 디렉터리에 추가로 만들지 않고 해당 디렉터리 내에서 공유하게 됩니다.

이것에 대해서 아직까지 특별히 issue를 열었던 사람이 없는 것을 봐서 nfs-provisioner는 이와 같은 동작은 현재 상태에는 디자인적인 구성이라고 보는게 좋을 것 같습니다. (그리고 개인적으로 statefulset 내에서는 공유되어서 사용되어도 문제가 없어 보입니다.)

이와 같은 내용으로 정리가 되셨으면 좋겠습니다.
덕분에 많은걸 배웠습니다.
감사합니다.