[CKA] CKA 자격증 준비 자료 정리 7 (Storage)

본 포스팅은 CKA 자격증 준비를 위해 해당 강의를 보고 정리한 자료입니다.

일부 생략되었으니 꼭 강의를 수강하시고 내용 정리 용도로만 참고하시길 바랍니다. 

---

Docker Storage

Storage drivers

File system ⇒ /var/lib/docker/containers,image,volumes... 에 디폴트로 도커 데이터 저장 (호스트에 도는 images나 container 등)

Volume Mount

$ docker volume create data_volume

• /var/lib/docker/volumes/data_volume 에 볼륨이 생성됨

$ docker run -v data_volume:/var/lib/mysql mysql

• 생성한 volume을 도커 컨테이너 내에 mount
• mysql 컨테이너 내에 /var/lib/mysql 폴더로 mount 됨
• volume을 생성하지 않고 docker run -v 로 실행하면, 해당 이름의 volume이 자동 생성

Bind Mount

$ docker run -v /data/mysql:/var/lib/mysql mysql

• 호스트에 존재하는 폴더를 컨테이너 내부로 mount
• 현재 -v 옵션보다는, --mount 옵션을 권장함 (여러 옵션 지정 가능)

$ docker run --mount type=bind, source=/data/mysql, target=/var/lib/mysql mysql

 

도커의 이런 operation, layered 구조 유지, writable layer 생성 등은 Storage drivers의 역할이다.

• AUFS, ZFS, BTRFS, Device Mapper Overlay Overlay2

Volume Driver

• volumes을 다루는건 storage driver가 아닌, volume driver의 역할
• 기본적인 volume plugin은 local volume plugin
  • local volume plugin이 host에 volume을 생성하고 데이터를 저장하도록함
  • 그외 써드파티 volume driver을 사용할 수도 있음
    • Azure File Storage, Convoy, Digital Ocean Block ... 등등
    • driver는 docker run --volume-driver 옵션으로 지정 가능

---

Container Storage Interface

CRI (Container Runtime Interface): 쿠버네티스 같은 솔루션이 어떻게 도커 같은 container runtime 솔루션과 소통하는지 정의하는 기준

• container runtime 솔루션은 CRI 을 지킴으로써 쿠버네티스와의 직접적인 작업 없이 쿠버네티스와 함께 동작할 수 있음

CNI (Container Network Interface): 네트워크 interface로, CNI을 지킴으로써 쿠버네티스와 작동할 수 있는 네트워크 플러그인을 개발할 수 있음

CSI (Container Storage Interface): 여러 storage 솔루션을 위한 인터페이스

 

CSI의 경우를 예로 들면, storage driver가 CSI 에 따라 구현해야하는 것들이 있음.

• volume을 요구하는 pod 생성 요청이 생기면, 쿠버네티스가 create volume RPC를 호출하게 되므로, storage driver는 이 RPC를 구현해야하고, 요청을 처리하여 storage area에 새 volume을 생성한 후 결과를 반환하게 됨

---

Volumes

참고: https://kubernetes.io/ko/docs/concepts/storage/volumes/

apiVersion: v1
kind: Pod
metadata:
  name: random-number-generator
spec:
  containers:
  - image: alpine
    name: alpine
    command: ["/bin/sh", "-c"]
    args: ["shuf -i 0-100 -n 1 >> /opt/numver.out;"]
    volumeMounts:
    - mountPath: /opt
      name: data-volume
  volumes:
  - name: data-volume
    hostPath:
      path: /data
      type: Directory

• 원하는 path (host path)를 지정해 volume 생성
• 해당 volume을 volumeMounts 필드를 통해 mount → 어떤 volume을 컨테이너의 어떤 path에 마운트 할 것인가
• pod이 삭제되어도, host의 파일에 결과가 남아있음

✔ hostPath는 싱글 노드일때는 괜찮으나, 멀티 노드 클러스터 일 경우 권장되지 않음

• pod이 모든 노드의 /data 디렉토리(volume hostpath)를 사용하고 모두 똑같은 데이터를 저장하게 될 것
• 쿠버네티는 다양한 외부 storage solution을 지원하므로, 이를 사용하는 것을 권장

---

Persistent Volumes (PV)

참고: https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/

큰 환경에서, 많은 사용자가 많은 pod을 배포하게되면, 사용자가 각 pod의 storage를 매번 구성해야한다.

→ 이를 관리자가 큰 풀의 storage를 생성하고, 사용자들이 필요한만큼 조각으로 사용하는 방식이 Persistent Volumes

→ 즉, PV는 관리자가 클러스터 레벨의 storage volume을 구성하기 위한 오브젝트

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-vol1
spec:
  accessModes:
  - ReadWriteOnce # ReadOnlyMany, ReadWriteMany
    capacity:
      storage: 1Gi
    hostPath: # volume type
      path: /tmp/data

Persistent Volume Claim (PVC)

참고: https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/#볼륨으로-클레임하기

PV는 PVC를 통해 사용한다.

• 관리자가 PV를 만들면, 사용자는 storage를 사용하기 위해 PVC를 만듦
• PVC를 생성하면 쿠버네티스는 내용을 통해 Volume을 바인딩
• PVC는 하나의 PV에만 바인딩됨
  • PVC에 여러 PV 매칭이 가능한 경우, Labels와 Selector를 통해 특정 볼륨을 지정할 수 있음
  • PV에 매칭 후 공간이 남아도 남은 공간을 활용할 수 없음
• PVC가 바인딩할 PV이 없을 경우, pending 상태 → 새로운 PV이 생성되면 매칭 가능

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

PVC 확인

$ kubectl get persistentvolumeclaim

 

✔ PVC를 삭제할 경우 일어날 정책을 persistentVolumeReclaimPolicy 를 통해 지정할 수 있음

• Retain(default): 관리자가 manual하게 삭제할 때까지 PV가 남아있음
• Delete: 다른 claim이 재사용할 수 없도록하거나 자동으로 삭제될 수 있음
• Recycle: volume을 다른 claim이 사용할 수 있도록 volume내 data가 scrub(삭제?) 됨

 

pod에서 PVC로 volume 지정하기

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myfrontend
    image: nginx
    volumeMounts:
    - mountPath: "/var/www/html"
      name: mypd
  volumes:
  - name: mypd
    persistentVolumeClaim:
      claimName: myclaim

• PVC 생성 후 진행

---

Storage Class

참고: https://kubernetes.io/ko/docs/concepts/storage/storage-classes/

PVC 생성시 Google Cloud 같은 곳에 디스크를 만들어야고, 직접 PV 정의 file를 정의해야함 → provisioning volumes

• application이 요구할 때마다 volume이 자동으로 provision 될 수 있도록 하는 역할을 storage class가 도와줌
• → dynamic provisioning of volumes

Storage Class 오브젝트를 생성하면, PV와 연관된 storage가 자동으로 생성되기 때문에, PV를 정의할 필요가 없음

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: google-storage
provisioner: kubernetes.io/gce-pd
parameters: # parameter 는 provisioner에 따라 달라질 수 있음
  type: pd-standard
	replication-type: none

• 다양한 provisioner 와 다양한 parameter을 통해 다양한 class를 만들 수 있음

PVC에서 storageClassName 필드를 통해 생성한 storage class 사용

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessMode:
  - ReadWriteOnce
  storageClassName: google-storage
  resources:
    requests:
      storage: 500Mi

마지막으로 pod에서 PVC 매핑

apiVersion: v1
kind: Pod
metadata:
  name: random-number-generator
spec:
  containers:
  - image: alpine
    name: alpine
    command: ["/bin/sh", "-c"]
    args: ["shuf -i 0-100 -n 1 >> /opt/numver.out;"]
    volumeMounts:
    - mountPath: /opt
      name: data-volume
    volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: myclaim

---

[DevOps/Kubernetes] - [CKA] CKA 자격증 준비 자료 정리 8 (Networking)

[CKA] CKA 자격증 준비 자료 정리 8 (Networking)