반응형
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 |
Tags
- 커링
- 알고리즘
- 루씬 인 액션
- 고차원 함수
- 스프링 스케쥴러
- 해시
- 가장 큰 수
- 크론 표현식
- 정렬
- @Setter
- H-index
- 완주하지 못한 선수
- kubenetes
- 롬복 어노테이션
- Java
- 검색 기능 확장
- 코딩 테스트
- 전화번호 목록
- 쿠버네티스
- 영속 자료구조
- 기능개발
- @Getter
- @EnableScheduling
- @configuration
- @Data
- 프로그래머스
- 다리를 지나는 트럭
- 모던 자바 인 액션
- K번째수
- 스택/큐
Archives
- Today
- Total
Today I Learned
[쿠버네티스 인 액션] 6. 볼륨: 컨테이너에 디스크 스토리지 연결 (2) 본문
728x90
6.4 퍼시스턴트 스토리지 사용
- 애플리케이션이 디스크에 데이터를 유지해야 하고 다른 노드로 재스케줄링된 경우에도 동일한 데이터를 사용한다면,
어떤 클러스터 노드에서도 접근이 필요하기 때문에 NAS(Network-Attached Storage) 유형에 저장돼야 한다. - 영구 데이터를 허용하는 볼륨을 알아보기 위해 MongoDB를 실행하는 파드를 생성해보자
6.4.1 GCE 퍼시스턴트 디스크를 파드 볼륨으로 사용하기
GCE 퍼시스턴트 디스크 생성하기
- 먼저 GCE 퍼시스턴트 디스크를 쿠버네티스 클러스터가 있는 동일한 영역(zone)에 생성한다.
$gcloud compute disks create --size=10GB --zone=asia-northeast2-a mongodb
GCE 퍼시스턴트 디스크 볼륨으 사용하는 파드 생성하기
apiVersion: v1
kind: Pod
metadata:
name: mongodb
spec:
volumes:
- name: mongodb-data
gcePersistentDisk:
pdName: mongodb
fsType: ext4
containers:
- image: mongo
name: mongodb
volumeMounts:
- name: mongodb-data
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
- 파드는 생성한 GCE 퍼시스턴트 디스크를 기반으로 한 단일 볼륨과 단일 컨테이너로 이뤄진다.
- 볼륨을 컨테이너 내부의 MongoDB가 데이터를 저장하는 /data/db에 마운트한다.
MongoDB 데이터베이스에 도큐먼트를 추가해 퍼시스턴트 스토리지에 데이터 쓰기
$kubectl exec -it mongodb -- mongosh
- 간단한 JSON 데이터를 저장해 영구적으로 저장되는지와 파드가 다시 생성된 후에 데이터를 가져올 수 있는지 살펴보자
파드를 다시 생성하고 이전 파드가 저장한 데이터를 읽을 수 있는지 확인하기
- 새로운 파드가 이전 파드와 동일한 GCE 퍼시스턴트 디스크를 사용하고 MongoDB 컨테이너가 실행중이므로 파드가 다른 노드에 스케줄링됐다 할지라도 동일한 데이터를 볼 수 있어야 한다.
- 예상대로 파드를 삭제하고 재생성해도 데이터는 그대로 유지된다. 이런 식으로 GCE 퍼시스턴트 디스크를 파드 인스턴스 여러 개에서 데이터를 유지하는 데 사용할 수 있다.
6.4.2 기반 퍼시스턴트 스토리지로 다른 유형의 볼륨 사용하기
- 쿠버네티스 클러스터가 GCE가 아닌 아마존 AWS EC2에서 실행중이라면 파드에 퍼시스턴트 스토리지를 제공하기 위해 awsElasticBlockStore 볼륨을 사용할 수 있다.
- 마이크로소프트 Azure에서 클러스터를 실행 중이라면 azureFile이나 azureDisk 볼륨을 사용할 수 있다.
AWS Elastic Block Store 볼륨 사용하기
apiVersion: v1
kind: Pod
metadata:
name: mongodb-aws
spec:
volumes:
- name: mongodb-data
awsElasticBlockStore:
volumeID: my-volume
fsType: ext4
containers:
- image: mongo
name: mongodb
volumeMounts:
- name: mongodb-data
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
NFS 볼륨 사용하기
- 클러스터가 여러 대의 서버로 실행되는 경우 외장 스토리지를 볼륨에 마운트하기 위한 다양한 지원 옵션이 제공된다.
- 예를 들어 NFS 공유를 마운트하기 위해 다음과 같이 NFS 서버와 서버에서 익스포트 경로를 지정할 수 있다.
apiVersion: v1
kind: Pod
metadata:
name: mongodb-nfs
spec:
volumes:
- name: mongodb-data
nfs:
server: 1.2.3.4
path: /some/path
containers:
- image: mongo
name: mongodb
volumeMounts:
- name: mongodb-data
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
다른 스토리지 기술 사용하기
- 지원되는 다른 옵션으로 ISCSI 디스크 리소스를 마운트하기 위한 iscsi, GlusterFS 마운트를 위한 glusterfs 등이 있다.
- 하지만 이런 유형의 인프라스트럭처 관련 정보를 파드 정의에 포함한다는 것은 파드 정의가 특정 쿠버네티스 클러스터에 밀접하게 연결됨을 의미한다.
- 볼륨을 이런 방식으로 사용하는 것은 파드에 퍼시스턴트 스토리지를 연결하는 최적의 방법이 아니다.
6.5 기반 스토리지 기술과 파드 분리
- 이상적으로 쿠버네티스에 애플리케이션을 배포하는 개발자는 기저에 어떤 종류의 스토리지 기술이 사용되는지 알 필요가 없어야 하고, 동일한 방식으로 파드를 실해하기 위해 어떤 유형의 물리 서버가 사용되는지 알 필요가 없어야 한다.
6.5.1 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 소개
- 퍼시스턴트볼륨(PV)과 퍼시스턴트볼륨클레임(PVC)는 인프라스트럭처의 세부 사항을 처리하지 않고 애플리케이션이 쿠버네티스 클러스터에 스토리지를 요청할 수 있도록 하기 위해 도입된 리소스이다.
6.5.2 퍼시스턴트볼륨 생성
apiVersion: v1
kind: PersistentVolume
metadata:
name: mongodb-pv
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
- ReadOnlyMany
persistentVolumeReclaimPolicy: Retain
gcePersistentDisk:
pdName: mongodb
fsType: ext4
- 퍼시스턴트볼륨을 생성할 때 쿠버네티스에게 용량이 얼마가 되는지 단일 노드나 동시에 다수 노드에 읽기나 쓰기가 가능한지 여부를 알려야 한다.
- 또한 퍼시스턴트 볼륨이 해제되면 어떤 동작을 해야 할지 알려야 한다.
- 마지막으로 퍼시스턴트볼륨을 지원하는 실제 스토리지 유형, 위치, 그 밖의 속성 정보를 지정해야 한다.
- 아직 퍼시스턴트볼륨클레임을 생성하지 않았으므로 퍼시스턴트볼륨이 Available로 표시된다.
6.5.3 퍼시스턴트볼륨클레임 생성을 통한 퍼시스턴트볼륨 요청
퍼시스턴트볼륨클레임 생성하기
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mongodb-pvc
spec:
resources:
requests:
storage: 1Gi
accessModes:
- ReadWriteOnce
storageClassName: ""
- 퍼시스턴트볼륨클레임이 생성되자마자 쿠버네티스는 적절한 퍼시스턴트볼륨을 찾고 클레임에 바인딩한다.
- 퍼시스턴트볼륨의 용량과 접근 모드는 클레임의 요청을 수용할 수 있어야 한다.
퍼시스턴트볼륨클레임 조회하기
- 클레임이 퍼시스턴트볼륨 mongodb-pvc에 Bound 되었음을 나타낸다.
- 접근 모드로 사용되는 약어
- RWO(ReadWriteOne): 단일 노드만이 읽기/쓰기용으로 볼륨을 마운트할 수 있다.
- ROX(ReadOnlyMany): 다수 노드가 읽기용으로 볼륨을 마운트할 수 있다.
- RWX(ReadWriteMany): 다수 노드가 읽기/쓰기용으로 볼륨을 마운트할 수 있다.
퍼시스턴트볼륨 조회하기
- 퍼시스턴트볼륨이 Bound 상태가 되어 더 이상 Available로 표시되지 않으며 default/mongodb-pvc 클레임에 바인딩됨을 보여준다.
- 퍼시스턴트볼륨은 클러스터 수준의 리소스이므로 특정 네임스페이스에 생성할 수 없으며, 동일한 네임스페이스의 파드에서만 사용할 수 있다.
6.5.4 파드에서 퍼시스턴트볼륨클레임 사용하기
- 파드 내부에서 볼륨을 사용하기 위해 다음과 같이 퍼시스턴트볼륨클레임을 참조한다.
apiVersion: v1
kind: Pod
metadata:
name: mongodb
spec:
containers:
- image: mongo
name: mongodb
volumeMounts:
- name: mongodb-data
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
volumes:
- name: mongodb-data
persistentVolumeClaim:
claimName: mongodb-pvc
- 파드가 동일 퍼시스턴트 볼륨과 기반 GCE PD를 사용하는지 확인해보자.
- mongoDB 셸을 다시 실행해보면 이전에 저장한 데이터를 확인할 수 있어야 한다.
6.5.5 퍼시스턴트볼륨과 퍼시스턴트볼륨클레임 사용의 장점 이해하기
- 개발자는 실제 스토리지 기술을 알 필요가 없으며, 파드와 클레임 메니페스트는 인트라스터럭처와 관련된 어떤 것도 참조하지 않으므로 다른 쿠버네티스 클러스터에서도 사용할 수 있다.
6.5.6 퍼시스턴트볼륨 재사용
- 파드와 퍼시스턴트볼륨클레임을 삭제하고 재생성한 후 결과를 확인해보자
- 클레임의 상태가 Pending으로 표시된다. 즉시 퍼시스턴트볼륨에 바인딩되지 않은 이유는 무엇일까?
- 퍼시스턴트볼륨을 조회해보면 STATUS가 Released로 표시되어 있다.
- 이미 볼륨을 사용해서 데이터를 가지고있기 때문에 클러스터 관리자가 볼륨을 완전히 비우지 않으면 새로운 클레임에 바인딩할 수 없다.
- 볼륨을 비우지 않았다면 동일한 퍼시스턴트볼륨을 사용하는 새 파드는 이전 파드가 저장한 데이터를 읽을 수 있다.
퍼시스턴트볼륨을 수동으로 다시 클레임하기
- persistentVolumeClaimPolicy를 Retain으로 설정하면 클레임이 해제되어도 볼륨과 콘텐츠를 유지한다.
- 수동으로 재사용하려면 퍼시스턴트볼륨 리소르를 삭제하고 다시 생성해야 한다.
퍼시스턴트볼륨을 자동으로 다시 클레임하기
- Recycle 정책은 볼륨의 콘텐츠를 삭제하고 볼륨이 다시 클레임될 수 있도록 볼륨을 사용 가능하게 만든다.
- Delete 정책은 기반 스토리지를 삭제한다.
6.6 퍼시스턴트볼륨의 동적 프로비저닝
- 클러스터 관리자가 퍼시스턴트볼륨을 생성하는 대신 퍼시스턴트볼륨 프로비저너를 배포하고 사용자가 선택 가능한 퍼시스턴트볼륨의 타입을 하나 이상의 스토리지클래스 오브젝트로 정의할 수 있다.
- 사용자가 퍼시스턴트볼륨클래스에서 스토리지클래스를 참조하면 프로비저너가 퍼시스턴트 스토리지를 프로비저닝할 때 이를 처리한다.
6.6.1 스토리지클래스 리소스를 통한 사용 가능한 스토리지 유형 정의하기
- 스토리지클래스 리소스는 퍼시스턴트볼륨클레임이 스토리지클래스에 요청할 때 어떤 프로비저너가 퍼시스턴트볼륨을 프로비저닝하는 데 사용돼야 할지를 지정한다.
- 스토리지클래스에 정의된 파라미터들은 프로비저너에 전달되며, 파라미터는 각 프로비저너 플러그인마다 다르다.
6.6.2 퍼시스턴트볼륨클레임에서 스토리지 클래스 요청하기
- 크기와 접근 모드를 지정하는 것 외에도 퍼시스턴트볼륨클레임에 사용할 스토리지클래스를 지정해야 한다.
- 클레임을 생성하면 fast 스토리지클래스 리소스에 참조된 프로비저너가 퍼시스턴트볼륨을 생성한다.
동적 프로비저닝된 PV와 생성된 PVC 검사하기
- VOLUME 열은 클레임에 바인딩된 퍼시스턴트볼륨을 표시한다.
- 동적으로 프로비저닝된 퍼시스턴트볼륨을 볼 수 있으며, 리클레임 정책은 Delete로 PVC가 삭제되면 퍼시스턴트 볼륨이 삭제됨을 의미한다.
- PV 외에 실제 스토리지도 프로비저닝 되었으며, fast 스토리지클래스는 GCE 퍼시스턴트 디스크를 프로비저닝하는 kubernates.io/gee-pd 프로비저너를 사용하도록 설정됐다.
스토리지 클래스 사용하는 법 이해하기
- 클러스터 관리자는 성능이나 특성이 다른 여러 스토리지 클래스를 생성하고, 개발자는 각 클레임에 가장 적합한 스토리지를 결정한다.
- 스토리지클래스는 클레임 이름으로 참조되므로 다른 클러스터 간의 스토리지 클래스 이름을 동일하게 사용하면 PVC 정의들 다른 클러스터로 이식 가능하다.
728x90
'쿠버네티스' 카테고리의 다른 글
[쿠버네티스 인 액션] 7. 컨피그맵과 시크릿 : 애플리케이션 설정 (2) (0) | 2022.11.07 |
---|---|
[쿠버네티스 인 액션] 7. 컨피그맵과 시크릿 : 애플리케이션 설정 (1) (0) | 2022.11.07 |
[쿠버네티스 인 액션] 6. 볼륨: 컨테이너에 디스크 스토리지 연결 (1) (0) | 2022.10.07 |
[쿠버네티스 인 액션] 5. 서비스: 클라이언트가 파드를 검색하고 통신을 가능하게 함 (3) (0) | 2022.09.30 |
[쿠버네티스 인 액션] 5. 서비스: 클라이언트가 파드를 검색하고 통신을 가능하게 함 (2) (0) | 2022.09.26 |
Comments