- Facts
: 배운것 - 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임 - Findings
:
퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임
- PV(PersistentVolume) : 볼륨 자체를 의미. 클러스터 안에서 자원으로 다룬다. 파드하고는 별개로 관리되고 별도의 생명 주기가 있다.
- PVC(PersistentVolumeClaim) : 사용자가 PV에하는 요청. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청
- 프로비저닝 : PV를 만드는 단계
정적 방법 : PV를 미리 만들어 두고 사용
동적 방법 : 요청이 있을 때마다 PV를 만듦
- 바인딩 : 프로비저닝으로 만든 PV를 PVC와 연결하는 단계
- 사용 : 사용 중인 스토리지 오브젝트 보호
- 반환 : 사용이 끝난 PVC는 삭제되고 PVC를 사용하던 PV를 초기화하는 과정
Retain : PV를 그대로 보존
<수업 메모>
인증 및 권한 관리
- 쿠버네티스에서 명령어 등을 통해 작업 실행 시 kube-apiserver 를 통해 수행
- 이 때, api 요청 시 인증 필요
- ~/.kube/config 파일의 내용을 통해 사용자 인증 수행
- 인증 : 인증서 / 개인키 / 토큰 등으로 수행
- 일반 사용자와 서비스 사용자로 구분
- 일반 사용자 : 구글 계정 / LDAP / keystone 등을 통해 제공
- 서비스 사용자 : 쿠버네티스에서 관리 , 주로 파드의 동작 수행을 위해 필요
- 작업을 위해서는 알맞은 권한이 필요
- 역할 기반의 권한 설정 방식 사용 (RBAC)
- 역할은 일반롤 과 클러스터롤 로 나뉨 (범위에 따른 구분)
- 사용자에게 역할을 설정해줄 때에는 롤바인딩 / 클러스터롤바인딩 을 사용
쿠버네티스의 데이터 저장
- 기본적으로 파드의 데이터를 영구저장 하지 않음
- 데이터를 영구적으로 저장하거나 혹은 다른 컨테이너와의 공유를 위해 볼륨을 사용
- 각종 클라우드 서비스에서 제공하는 스토리지 및 상용 스토리지 제품 들을 지원
emptyDir
- 볼륨이지만 데이터를 영구저장하지 않음
- 파드의 라이프사이클과 동일
- 간편하게 설정 가능
- 디스크 / 메모리를 이용
- 파드의 컨테이너들이 서로 데이터 공유를 위해 사용
- 지금은 서비스종료된 git-repo 방식의 볼륨형태도 구성 가능 ( initContainer 사용 )
hostPath
- 사용 중인 호스트의 로컬 스토리지를 공유 (존재하는 디렉토리)
- 해당 디렉토리는 호스트에 꼭 존재
- 파드가 중지되더라도 데이터가 유지
- 보안에 좋지않음
- 파드가 재시작 시 다른 노드에서 동작하면 데이터 접근이 불가능
- 모든 노드에서 동일한 데이터를 제공해야 모든 파드가 동일한 데이터 사용
-> NFS 서비스를 이용하는 방식으로 구성 가능
1. NFS 서버 구성 ( 어디든 관계 X , 컨트롤플레인에서 )
1) nfs-kernel-server 패키지 설치
2) nfs-kernel-server 서비스 활성화
3) 공유할 디렉토리 및 파일 생성
4) /etc/exports 파일에 설정
5) exportfs 명령어 실행
6) 방화벽 설정 -> sudo iptalbes -A INPUT -p tcp --dport 2049 -j ACCEPT
sudo iptalbes -A INPUT -p udp --dport 2049 -j ACCEPT
2. NFS 클라이언트 구성 ( 모든 노드 )
1) nfs-common 패키지 설치
2) 디렉토리 생성 ( 모든 노드에서 동일한 이름으로 )
3) 마운트 설정
-> 실습 시 웹서비스 이미지 사용 (nginx) , 볼륨을 컨텐츠 디렉토리 (/usr/share/nginx/html/)
NFS 서버의 공유 디렉토리에 index.html 파일 생성 후 볼륨으로 제공
서비스 연결 후 서비스를 통해 외부에서 웹서비스 접근해보기.
NFS
- 네트워크를 이용한 볼륨 연결 방식
- NFS 서버를 구성하고 해당 서버에 대한 연결 설정 진행
- 사용하는 모든 파드가 동일한 데이터 사용
- 어떤 노드에서든 생성 가능
- NFS 서버 기능을 제공하는 파드 / 다른 시스템 이 필요
PersistentVolume (PV)
- 볼륨 종류 중 하나
- 스토리지에 대한 지식이 필요
- 파드 / 컨트롤러 정의 시 직접 지정
- 파드의 라이프사이클과 스토리지의 라이프 사이클이 동일
- 쿠버네티스 클러스터와 별개로 관리하는 스토리지 사용
PersistentVolumeClaim (PVC)
- PV를 파드에 연결할 때 사용하는 개체
- 스토리지의 크기 / 접근제어 등의 설정을 정의
- 요청 시 PV 의 사이즈보다 크게 요청하면 연결이 안됨
- 실제 스토리지 (PV) 의 스펙을 몰라도 사용할 수 있게 해주는 구성
라이프 사이클
1. Provisioning (배포)
PV를 원하는 크기에 맞게 만드는 단계
정적인 방식과 동적인 방식 가능
정적 : 미리 만들어두고 요청 시 알맞은 볼륨 선택 ( 장점 : 스토리지 절약 )
동적 : 요청 시 볼륨 자동 생성 ( 장점 : 편리 )
2. Binding (연결)
PV와 PVC , 그리고 파드 간의 연결을 하는 단계
PVC 요청 시 알맞은 PV가 없으면 실패(대기 상태)
PV 와 PVC 는 서로 1대1 관계
3. Using (사용)
파드와 PVC (PV) 가 연결된 상태
사용 중인 상태
임의로 삭제할 수 없도록 보호되고 있다.
모든 파드가 종료된 후에 삭제 가능
4. Reclaim (반환)
사용이 끝나고 (모든 파드가 종료) PVC 를 삭제하면서 PV 에 대한 처리 방식 결정
Retain - PV(데이터) 를 그대로 보존
수동으로 PV 를 삭제 (쿠버네티스 오브젝트만 제거, 스토리지의 데이터는 유지)
데이터가 필요 없을 경우 해당 스토리지에서 직접 제거
제거 후 확보된 공간 / 기존의 데이터를 이용해서 새로운 PV 를 생성
Delete - PV 를 삭제 (스토리지의 데이터까지 삭제)
Recycle - PV 및 데이터 삭제 후 PVC로 재사용 가능 (중단 예정)
- PV 와 PVC 연결 시 레이블 사용 가능
- PVC 를 제거하면 정책에 따라 PV 도 제거
- 기본적으로 PV 는 데이터를 영구저장
- PVC 에서 요청하는 사이즈 조정 가능
'GOORM' 카테고리의 다른 글
GOORM: Kubernetes-47 (0) | 2022.01.09 |
---|---|
GOORM: Kubernetes-46 (0) | 2022.01.07 |
GOORM: Kubernetes-44 (0) | 2022.01.07 |
GOORM: Kubernetes-43 (0) | 2022.01.05 |
GOORM: Kubernetes-42 (0) | 2022.01.05 |
댓글