일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Codedeploy
- aws-dop
- Persistent Volume
- HTTPS Redirect
- ALB
- emptyDir Volume
- pod
- ingress
- SSL Offload
- ncp
- node exporter
- Codebuild
- Naver cloud platform
- kubernetes
- Prometheus
- volume
- RKE2
- Codepipeline
- emptyDir
- Persistent Volume Claim
- NFS Client Privisioner
- codecommit
- k8s
- grafana
- alertmanager
- DevOps
- AWS
- ingress controller
- slack
- cicd
- Today
- Total
Cloud SA's This and That
[NCP] Kubernetes - NAS 사용하기 (NFS Client Provisioner를 통한 Persistent Volume 동적 프로비저닝) 본문
[NCP] Kubernetes - NAS 사용하기 (NFS Client Provisioner를 통한 Persistent Volume 동적 프로비저닝)
뽀삐누냐 2023. 8. 23. 14:16파드에서 실행 중인 애플리케이션이 디스크에 데이터를 유지해야 하고 파드가 다른 노드로 재스케줄링된 경우에도 동일한 데이터를 사용해야 한다면 이전에 언급한 볼륨의 유형 중 emptyDir이나 hostPath 등은 사용할 수 없다.(참고 : https://jyyoon94.tistory.com/16)
그렇다면 해당 데이터들은 NAS 유형에 저장되어야 하는데 테스트 전 PersistentVolume과 PersistentVolumeClaim에 대해 간단히 알아보도록 한다.
PersistentVolume(PV) & PersistentVolumeClaim(PVC)
퍼시스턴트 볼륨은 파드 개발자가 실제 네트워크 스토리지 인프라에 관한 지식을 갖추고 있어야 한다.(NFS 기반의 볼륨을 생성하려면 개발자는 NFS 익스포트가 위치하는 실제 서버를 알아야 함)
인프라스트럭처의 세부사항을 처리하지 않고 애플리케이션이 쿠버네티스 클러스터에 스토리지를 요청할 수 있도록하는 것이 바로 퍼시스턴트 볼륨(PV)과 퍼시스턴트볼륨클레임(PVC)이다.
- 클러스터 관리자는 네트워크 스토리지 유형을 설정한다.(NFS 익스포트나 그와 유사한)
- 관리자는 쿠버네티스 API에 PV 디스크립터를 게시해 퍼시스턴트볼륨(PV)을 생성한다.
- 사용자는 퍼시스턴트볼륨클레임(PVC)을 생성한다.
- 쿠버네티스는 적정한 크기와 접근 모드의 PV를 찾고 PVC를 PV에 바인딩한다.
- 사용자는 PVC를 참조하는 볼륨을 가진 포드를 생성한다.
- 개발자가 파드에 세부사항을 기재한 볼륨을 추가하는 대신 관리자가 기반 스토리지를 설정하고 쿠버네티스 API 서버로 퍼시스턴트볼륨 리소스를 생성하여 쿠버네티스에 등록한다. 퍼시스턴트 볼륨이 생성되면 관리자는 크기과 지원 가능한 접근 모드를 지정한다.
- 클러스터 사용자는 먼저 최소 크기와 필요한 접근모드를 명시한 퍼시스턴트볼륨클레임 매니페스트를 쿠버네티스 API 서버에 게시하고 쿠버네티스는 적절한 퍼시스턴트볼륨을 찾아 클레임에 볼륨을 바인딩한다.
- 퍼시스턴트볼륨클레임은 파드 내부의 볼륨 중 하나로 사용될 수 있다. 퍼시스턴트볼륨클레임의 바인딩을 삭제해 릴리스될 때까지 다른 사용자는 동일한 퍼시스턴트볼륨을 사용할 수 없다.
참고 : 쿠버네티스 인 액션
============================================================================================
Kubernetes - NAS 서비스 사용하기 (NFS Client Provisioner를 통한 Persistent Volume 동적 프로비저닝)
(NFS Client Provisioner 설치 : https://guide.ncloud-docs.com/docs/k8s-k8suse-nfs)
쿠버네티스에서 PVC를 연결할 PV를 별도로 생성하는 대신 NFS Client Provisioner을 통해 PVC가 자동으로 생성된 PV에 바인딩 되도록 설정한다.(Persistent Volume 동적 프로비저닝)
Helm CLI를 통해 NCP의 NAS에 생성된 볼륨 연동이 가능하다.(프로비저너가 프로비저닝하는 실제 스토리지를 NCP NAS로 설정)
<사전 구성>
- Kubernetes Cluster(수동구성 - master & worker1,2)
- Container Registry(Container image)
- NAS
[NAS 생성] - https://guide.ncloud-docs.com/docs/nas-start-vpc
> 생성한 NAS의 마운트 정보를 확인한다. Provisioner 설치 시 사용해야 한다.
[Helm 설치] - https://helm.sh/docs/intro/install/ - 사용 중인 운영체제에 알맞는 방법으로 설치
> 공식 Helm chart repository를 CLI에 추가한다.
$ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
> NFS Client Provisioner 설치
$ helm install --kubeconfig=$KUBE_CONFIG nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
--set nfs.server=__NAS_IP__ \
--set nfs.path=__NAS_PATH__ \
--set storageClass.defaultClass=true
> StorageClass 리소스는 PV가 StorageClass에 요청할 때 어떤 Provisioner가 PV를 프로비저닝하는 데 사용돼야 할지를지정한다.
> PVC 생성시 StorageClass를 따로 지정하지 않는 경우 기본(default) StorageClass가 PV를 동적 프로비저닝하는 데 사용된다.
*만약 설치 중 해당 에러(cannot re-use a name that is still in use)가 뜬다면 helm list 삭제 후 다시 설치해보도록 한다.
[PVC]
> 해당 메니페스트로 생성된 PVC의 ACCESS MODES와 CAPACITY를 확인해보면 RWX와 500Gi를 확인할 수 있을 것이다.(크기 및 접근모드 지정 가능)
> 사용할 StorageClass도 지정할 수 있으며 해당 메니페스트에서는 따로 지정하지 않았기에 default로 지정된 nfs-client가 사용될 것이다.(존재하지 않는 StorageClass를 참조하면 PV 프로비저닝은 실패한다)
*만약 쿠버네티스의 모든 노드에 NFS의 마운트를 지원하기 위한 헬퍼프로그램이 없다면 해당 오류가 발생할 수 있다. (클러스터 내에서 PV를 사용하려면 볼륨 유형과 관련된 헬퍼프로그램이 필요하다)
모든 노드에 설치 - $ apt install nfs-common (Ubuntu 기준) / $ yum install nfs-utils (CentOs 기준)
<동적 프로비저닝된 PV와 생성된 PVC 검사>
> Volume : 클레임에 바인딩된 PV를 표시한다.
> ACCESS MODES : RWX(ReadWriteMany - 다수 노드가 읽기/쓰기용으로 볼륨을 마운트 가능) / RWO(ReadWriteOnly - 단일 노드만이 읽기/쓰기용으로 볼륨 마운트 가능) / ROX(ReadOnlyMany - 다수 노드가 읽기용으로 볼륨 마운트 가능)
> STORAGECLASS : nfs-client
> STATUS : Bound (바인딩 되지 않았을 경우 Available로 표시된다) / Release (클레임이 삭제되었지만 클러스터에서 아직 리소스를 반환하지 않은 경우) / Failed (볼륨이 자동 반환에 실패함)
> CLAIM : default/nas-pvc-test (바인딩 되어있는 PVC Namespace / PVC Name)
> RECLAIM POLICY : Delete (PVC가 삭제되면 PV가 삭제됨) / Retain (PVC가 삭제되면 PV의 기존 데이터는 유지하지만 Release 상태가 됨) / Recycle (볼륨의 콘텐츠를 삭제하고 볼륨이 다시 클레임될 수 있도록 사용 가능하게 함) - 리클레임 정책은 변경할 수 있다.
> PV는 특정 네임스페이스에 속하지 않으며 노드와 같은 클러스터 수준 리소스이다. (StorageClass 리소스도 네임스페이스에 속하지 않는다)
[Pod]
> PVC가 위에서 생성한 nas-pvc-test인 컨테이너를 가진 파드 2개 생성
> 컨테이너 이미지는 NCP의 Container Registry에서 가져오도록 함 (참고 : https://jyyoon94.tistory.com/2 )
> 생성된 파드 2개가 각자 다른 워커노드에서 생성된 것 확인(yjy-worker001, yjy-worker002)
> 파드 app1에 접속 후 /var/www/html/index.html 텍스트 생성
> 파드 app2에 접속 후 /var/www/html/index.html 텍스트 확인
> 정상적으로 두 파드가 NAS를 사용하고 있는 것 확인됨
> 추가로 PVC가 동일한 파드 하나를 더 생성
> 해당 파드 접속 후 동일한 데이터 확인 가능
'Naver-Cloud > Containers' 카테고리의 다른 글
[NCP] Kubernetes - ALB Ingress Controller를 통한 외부 클라이언트에 여러 서비스 노출하기(+ HTTPS Redirect Test) (0) | 2023.08.09 |
---|---|
[NCP] 쿠버네티스 클러스터 생성 & Container Registry 연동 (0) | 2023.07.20 |