Udemy CKA course 8. Storage (저장): 도커 스토리지, 쿠버네티스 볼륨, Persistent Volume (PV), Persistent Volume Claim (PVC), Storage Class

Certified Kubernetes Administrator (CKA) with Practice Tests (강의 링크, 레퍼런스 노트)

• 평소 강의 할인도 많이 하고, 연습문제도 풀어볼 수 있으니 실제 강의 수강을 추천
• 아래는 강의 내용 번역 및 정리본 (문제 시 댓글로 알려주세요)

도커 스토리지

이미지 레이어와 컨테이너 레이어

• 도커를 시스템에 다운로드하면 기본적으로 /var/lib/docker에 데이터가 저장됨
  • 하위 파일 종류: aufs, containers, image, volumes, ...
• 도커는 계층적 구조(layered architecture)로 빌드
  • e.g. Docker 파일 내용이 아래와 같다고 가정
    • FROM Ubuntu
    • RUN apt-get update && apt-get -y install python
    • RUN pip install flask flask-mysql
    • COPY . /opt/source-code
    • ENTRYPOINT FLASK_APP=/opt/source-code/app.py flask run
  • docker build Dockerfile -t jihyelee/custom-app (이미지 빌드) 명령어 실행 시
    • 레이어 1. 기본 우분투 레이어
    • 레이어 2. apt 패키지 바뀐 내용
    • 레이어 3. pip 패키지 바뀐 내용
    • 레이어 4. 소스 코드
    • 레이어 5. 엔트리포인트 업데이트
    • 각 레이어는 이전 레이어와 다른 부분만 저장
    • 새로운 이미지를 빌드할 때 이전에 빌드한 레이어와 겹치는 부분들이 있으면 다른 부분만 빌드 (겹치는 부분들은 캐시 이용)
      • 시간 단축, 저장공간 효율적 사용
  • docker run jihyelee/custom-app (컨테이너 실행) 명령어 실행 시
    • 읽기 전용인 이미지 레이어들 (레이어 1-5) 위에 쓰기가 가능한 컨테이너 레이어를 추가
    • COPY-ON-WRITE 가능
      • 이미지 레이어에서 빌드한 파일의 경우, 컨테이너 레이어에 파일이 복사되어 수정될 수 있음 (이미지 내 파일은 언제나 동일)
      • 컨테이너 실행이 종료되면 복사된 파일들은 사라짐

볼륨

• 컨테이너에서 만든 변경사항을 저장하고 싶을 경우 persistent volume 사용
• docker volume create data_volume
  • /var/lib/docker/volumes 하위에 data_volume 폴더 생성
  • 해당 명령어 실행하지 않더라도 아래 실행 명령어 사용 시 새로운 폴더 생성됨 (없을 경우)
• docker run -v data_volume:/var/lib/mysql [이미지명]
  • 도커 호스트 내의 볼륨 폴더 경로:컨테이너 내 폴더 경로 순서로 작성
  • 컨테이너 레이어 내에서 /var/lib/mysql에 저장되는 내용은 도커 호스트의 data_volume에도 저장됨
  • 이처럼 볼륨 디렉토리에서 컨테이너로 마운팅하는 것을 볼륨 마운팅(volume mount)이라고 칭함
• docker run -v /data/mysql:/var/lib/mysql [이미지명]
  • /var/lib/docker/volumes이 아닌 도커 호스트 내 다른 경로 사용하고 싶을 때 사용
  • 이를 바인드 마운팅(bind mount)이라고 칭함
• docker run --mount type=bind,source=/data/mysql,target=/var/lib/mysql [이미지명] 처럼 사용할 수도 있음

스토리지 드라이버

• 계층적 구조를 가능케 하는 도커의 드라이버
• OS에 따라 사용하는 스토리지 드라이버가 다름
• e.g. AUFS, ZFS, BTRFS, Device Mapper, Overlay, Overlay2

볼륨 드라이버

• 볼륨은 스토리지 드라이버가 아니라 볼륨 드라이버 플러그인으로 관리됨
• e.g. Local, Azure File Storage, Convoy, DigitalOcean Block Storage, Flocker, gce-docker, GlusterFS, NetApp, RexRay, Portworx, VMware vSphere Storage, ...
• docker run -it --name mysql --volume-driver rexray/ebs --mount src=ebs-vol,target/var/lib/mysql mysql
  • --volume-driver 옵션으로 원하는 볼륨 드라이버 선택 가능 (AWS)

Container Storage Interface (CSI)

• 컨테이너 런타임 인터페이스(CRI)는 docker, crio-o, rkt 등 다양한 컨테이너 런타임 엔진을 쿠버네티스에서 사용할 수 있도록 도와줌
• 컨테이너 네트워킹 인터페이스(CNI)는 weaveworks, flannel, cilium 등 다양한 네트워킹 플러그인을 쿠버네티스에서 사용할 수 있도록 도와줌
• 마찬가지로, CSI는 다양한 스토리지 솔루션을 쿠버네티스에서 사용할 수 있도록 기준을 제공함
  • e.g. portworx, Amazon EBS, Dell EMC, GlusterFS, ...
  • CreateVolume, DeleteVolume, ControllerPublishVolume를 포함한 여러 RPC(Remote Procedure Calls) 정의를 만족해야 함

볼륨 (Volumes)

• 도커 컨테이너는 작업 단위로 생존이 결정됨
  • 작업이 시작될 때 생성되고, 작업이 끝나면 사라짐 (내부 데이터도 마찬가지)
• 컨테이너에 볼륨을 붙이면 컨테이너가 종료되어도 데이터가 볼륨에 저장됨
• 쿠버네티스의 파드도 도커의 컨테이너와 유사한 성격을 가짐
  • 파드에 볼륨을 붙여 데이터를 저장
• pod yaml 파일
  • (spec > ) containers:
    • volumeMounts:
      • -mountPath: /opt # 파드 내 데이터 저장 경로
      • name: data-volume
  • (spec > ) volumes:
    • -name: data-volume
    • hostPath:
      • path: /data # 노드 내 데이터 저장 경로
      • type: Directory # 멀티 노드일 경우 이런 식의 설정은 위험할 수 있음

볼륨 타입

• e.g. 아마존 웹서비스를 이용할 경우
• volumes:
  • -name: data-volume
  • awsElasticBlockStore:
    • volumeID: [volume-id]
    • fsType: ext4

Persistent Volumes (PV)

• 클러스터 전체에 걸쳐 관리자가 설정한 스토리지 볼륨
• 사용자가 해당 PV를 이용해 클러스터에 어플리케이션을 배포할 수 있음
  • 사용자는 Persistent Volume Claim(PVC)을 활용해 PV를 요청할 수 있음

yaml 파일

• apiVersion: v1
• kind: PersistentVolume
• metadata:
  • name: pv-vol1
• spec:
  • accessmodes: # 볼륨이 호스트에 어떻게 마운트되어야 하는지 결정
    • -ReadWriteOnce # e.g. ReadOnlyMany, ReadWriteMany
  • capacity:
    • storage: 1Gi
  • hostPath: # 운영 환경에서는 지양, 대신 awsElasticBlockStore나 gcePersistentDisk 사용
    • path: /tmp/data # 노드의 로컬 디렉토리 경로

Persistent Volume Claims (PVC)

• 사용자에 의해 PVC가 생성되면 쿠버네티스는 요청과 볼륨의 특성을 고려해 1:1 바인딩을 진행
  • 요청 종류: 충분한 용량, 접근 모드, 볼륨 모드, 스토리지 클래스 등
  • selector를 활용해 PV와 PVC를 바인딩할 수도 있음
    • e.g. labels: name: my-pv (PV)
    • e.g. selector: matchLabels: name: my-pv (PVC)
• PV가 바인딩된 PVC보다 더 큰 용량을 가지고 있어도 다른 PVC가 바인딩될 수는 없음 (1:1)
• 만약 볼륨이 존재하지 않는다면 새로운 PV가 생성될 때까지 PVC는 대기 상태

yaml 파일

• apiVersion: v1
• kind: PersistentVolumeClaim
• metadata:
  • name: myclaim
• spec:
  • accessModes:
    • -ReadWriteOnce
  • resources:
    • requests:
      • storage: 500Mi

PVC 삭제

• PVC가 삭제될 때 PV의 동작을 지정할 수 있음 (PV yaml 파일, spec 하위)
  • persistentVolumeReclaimPolicy: Retain
    • 기본값, 관리자에 의해 삭제될 때까지 PV 유지됨
    • 다른 PVC에 의해 재사용될 수 없음
  • persistentVolumeReclaimPolicy: Delete
    • PVC가 삭제될 때 PV도 함께 삭제됨
  • persistentVolumeReclaimPolicy: Recycle
    • 다른 PVC에 의해 사용될 수 있음
    • 볼륨에 있던 이전 데이터는 삭제됨

Pod에서 PVC 사용하기

• PV와 연결된 PVC를 Pod에서 볼륨으로 사용할 수 있음
• (spec > ) volumes:
  • -name: [볼륨명]
  • persistentVolumeClaim:
    • claimName: [PVC명]
• ReplicaSets, Deployments에서도 pod template 부분에 동일하게 사용할 수 있음
• 만약 아직 사용되고 있는 Pod의 PVC를 삭제한다면, 해당 PVC는 Terminating 상태
  • pod가 삭제된 이후에 pvc도 삭제됨

스토리지 클래스 (Storage Class)

Static Provisioning

• PV를 생성하기 이전에 구글 클라우드에서 미리 저장공간을 만들어놔야 함
  • e.g. gcloud beta compute disks create --size 1GB --region us-east1 pd-disk
• PV yaml 파일의 spec 하위에 hostPath 대신 다음과 같이 작성할 수 있음
  • gcePersistentDisk:
    • pdName: pd-disk
    • fsType: ext4

Dynamic Provisioning

• 정적 방식처럼 수동으로 저장 공간을 프로비져닝할 필요 없이 자동으로 프로비져닝하는 방식
• 스토리지 클래스를 활용함으로써 가능
  • PV와 관련 저장공간이 자동으로 생성되기 때문에 PV yaml 파일 필요 없음
  • PVC yaml 파일 spec 하위에 storageClassName: [스토리지 클래스명] 추가

스토리지 클래스 Yaml 파일

• apiVersion: storage.k8s.io/v1
• kind: StorageClass
• metadata:
  • name: google-storage
• provisioner: kubernetes.io/gce-pd # e.g. AWSElasticBlockStore, AzureFile, ...
• parameters: # 프로비져너마다 다른 특정 파라미터를 넘겨줄 수 있음
  • type: pd-standard # e.g. pd-ssd
  • replication-type: none # e.g. regional-pd

참고

기타 명령어

• kubectl exec webapp -- cat [로그명].log
  • webapp 파드 내에서 저장된 로그를 보는 명령어
• pod 수정하는 법 (yaml 파일)
  • 1. yaml 파일 생성
    • 1-1. 기존 pod 이용: kubectl get pod [pod명] -o yaml > [파일명].yaml
    • 1-2. 기존 pod 이용: kubectl edit pod [pod명] 후 tmp 파일 활용
    • 1-3. 새 pod 이용: kubectl run [pod명] --dry-run=client -o yaml > [파일명].yaml
  • 2. kubectl replace -f [파일명].yaml --force
    • delete와 create를 한 번에 해줌