AEWS Study 3 주차 (스토리지)

이어서 3주차 스토리지를 정리해본다.

마찬가지로 구축 내용은 스킵하고 그 외 자세한 내용을 정리한다

 

아래 그림은 스터디 멤버 중 한분이 storage에 잘 정리해주신 그림이다.

 

kubernetes에서 사용하는 storage는 크게 3가지로 나뉘어진다

각각의 스트로지의 특징은 다음과 같다

 

emptydir : 파드 내부에 스토리지가 생성되며 파드가 중지 및 삭제 시 해당 스토리지도 삭제된다.

apiVersion: v1
kind: Pod
metadata: 
  name: busybox
spec: 
  terminationGracePeriodSeconds: 3
  containers: 
  - name: busybox
    image: busybox
    command: 
    - "/bin/sh"
    - "-c"
    - "while true; do date >> /home/pod-out.txt; cd /home; sync; sync; sleep 10; done"

위 10초마다 시간을 /home/pod-out.txt에 저장하는 파드를 생성 하고 삭제해보면 아래와 같이 기존 데이터가 삭제되고 새로운 데이터가 입력된것을 확인할 수 있다. 

 

hostpath : 각 노드의 path를 사용하므로서 파드를 삭제해도 데이터는 남아있다 하지만 노드에 종속적이여서 노드를 맞춰주거나 노드가 삭제되면 사용할 수 없다.

 

기존 eks에서는 pv, pvc만 사용하여 hostpath를 생성해본적이 없어 몰랐는데 해당 스토리지도 스토리지 클래스를 생성해서 hostpath를 생성해야한다.

 

아래 경로에서 yaml을 가져와 apply하면 설치 가능하다

https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

 

후 아래와 같이 hostpath 기반의 스토리지와 해당 스토리지를 마우트하는 pod를 생성

apiVersion: v1
kind: PersistentVolumeClaim
metadata: 
  name: localpath-claim
spec: 
  accessModes: 
    - ReadWriteOnce
  resources: 
    requests: 
      storage: 1Gi
  storageClassName: "local-path"
  
  ---
  apiVersion: v1
kind: Pod
metadata: 
  name: app
spec: 
  terminationGracePeriodSeconds: 3
  containers: 
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts: 
    - name: persistent-storage
      mountPath: /data
  volumes: 
  - name: persistent-storage
    persistentVolumeClaim: 
      claimName: localpath-claim

 

생성된 pv를 확인해보면 Node Affinity가 설정되어 특정 노드에만 연결되는것을 확인할 수 있으며 

 

생성되어진 파드에 저장된 데이터들은 아래와 같다

이제 파드를 제거하고 다시 생서해보면 데이터가 삭제되지 않고 보존되어있는것을 확인 할 수 있다.

 

pv, pvc : 데이터 보존이 필요한 Stateful한 스토리지로서 사용,hostpath와는 다르게 아무 노드에서 사용가능하며

Reclaim Policy를 가져 퍼시스턴트 볼륨의 사용이 끝났을 때 해당 볼륨은 어떻게 초기화할 것인지 별도로 설정가능하다 크게 Retain, Delete, Recycle(이제 사라짐) 방식이 있다 (실습은 생략)

 

ebs : 동일 AZ에 있는 EC2 인스턴스에 배포된 파드에 연결해야는것이 특징으로 파드를 배포할때 따로 스케줄링 해줘야한다. 또한 ebs 특성 상 accessModes는 ReadWriteOnce로 설정해야 한다.

 

 

해당 pvc와 생성된 pv가 마운트하는 파드 생성

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  storageClassName: gp3
  
  ---
  apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  terminationGracePeriodSeconds: 3
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo \$(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-claim

 

생성이 완료되면 아래와 같이 NodeAffinity를 통해 특정 노드로 스케줄링 되어진것을 확인 가능하다.

 

efs : ebs와는 다르게 여러az에 걸쳐 사용가능하여 운영 편리성(따로 스케줄링 안해도 됨) 및 가용성, 내구성을 제공한다.

실습은 예전 내용이 있기 때문에 정리만 하고 넘어간다

https://jiheon95.tistory.com/94

 

다음으로는 snapshot이다 이 부분은 pkos에서 진행 했지만 따로 정리를 하지 않았기 때문에 정리한다.

스냅샷을 사용하려면 Snapshot Controller, Snapshot CRDs, Snapshotclass를 생성해줘야한다.

 

# Install Snapshot CRDs
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f snapshot.storage.k8s.io_volumesnapshots.yaml,snapshot.storage.k8s.io_volumesnapshotclasses.yaml,snapshot.storage.k8s.io_volumesnapshotcontents.yaml

# Install Common Snapshot Controller
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
curl -s -O https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
kubectl apply -f rbac-snapshot-controller.yaml,setup-snapshot-controller.yaml


# Install Snapshotclass
curl -s -O https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/snapshot/manifests/classes/snapshotclass.yaml
kubectl apply -f snapshotclass.yaml

 

 

ebs-volume-snapshot을 생성해서 배포하면 해당 pv에 대하여 스냅샷이 생성된것을 확인 가능하다.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata: 
  name: ebs-volume-snapshot
spec: 
  volumeSnapshotClassName: csi-aws-vsc
  source: 
    persistentVolumeClaimName: ebs-claim

 

복원하는 방법은 다음과 같다

해당 생성한 snapshot의 data sourc가 있는 pvc를 생성하고 파드에 마운트 하면 데이터가 스냅샷 복원 후 같은것을 확인할 수 있다

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-snapshot-restored-claim
spec:
  storageClassName: gp3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  dataSource:
    name: ebs-volume-snapshot
    kind: VolumeSnapshot
    
 ---
 apiVersion: v1
kind: Pod
metadata: 
  name: app
spec: 
  containers: 
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts: 
    - name: persistent-storage
      mountPath: /data
  volumes: 
  - name: persistent-storage
    persistentVolumeClaim: 
      claimName: ebs-snapshot-restored-claim   
    apiGroup: snapshot.storage.k8s.io

 

스냅샷 복원 전

 

스냅샷 복원 후

 

스터디 중 제일 신기했던게 instance store를 사용한다는 것이였다

평소에도 해당 리소스는 사용하지 않았는데 고연차 실무자들께서 자주 사용하는건 물론 만족도를 나타낸것이였다

instance store도 테스트를 했었지만 volume 모니터링 및 성능 측정 확인해주는 kubestr이 잘 안돼 성능 테스트는 다음에 다시 테스트 해봐야겠다 

또한 velro는 예전에 사용한 경험이 있는데 이것 또한 다시 정리를 해봐야겠다