CKA - Storage

KodeKloud - CKA

Storage 정리

app pod의 log 확인

kubectl exec webapp -- cat /log/app.log

 

호스트의 /var/log/webapp 경로에 로그를 저장하도록 볼륨 구성

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: event-simulator
    image: kodekloud/event-simulator
    env:
    - name: LOG_HANDLERS
      value: file
    volumeMounts:
    - mountPath: /log
      name: log-volume

  volumes:
  - name: log-volume
    hostPath:
      # directory location on host
      path: /var/log/webapp
      # this field is optional
      type: Directory

 

Volume 참고사항 

https://kubernetes.io/docs/concepts/storage/volumes/

Volumes

Hostpath란?

• hostPath 볼륨은 호스트 노드의 파일시스템에 있는 파일이나 디렉터리를 파드에 마운트 한다.

hostPath 의 일부 용도

• 도커 내부에 접근할 필요가 있는 실행중인 컨테이너. /var/lib/docker 를 hostPath 로 이용함
• 컨테이너에서 cAdvisor의 실행. /sys 를 hostPath 로 이용함
• 파드는 주어진 hostPath 를 파드가 실행되기 이전에 있어야 하거나, 생성해야 하는지 그리고 존재해야 하는 대상을 지정할 수 있도록 허용함

Docs를 확인해 보면 hostpath에 대한 경고문이 다음과 같이 나와있다.

 

경고:
HostPath 볼륨에는 많은 보안 위험이 있으며, 가능하면 HostPath를 사용하지 않는 것이 좋다. HostPath 볼륨을 사용해야 하는 경우, 필요한 파일 또는 디렉터리로만 범위를 지정하고 ReadOnly로 마운트해야 한다.
AdmissionPolicy를 사용하여 특정 디렉터리로의 HostPath 액세스를 제한하는 경우,
readOnly 마운트를 사용하는 정책이 유효하려면 volumeMounts 가 반드시 지정되어야 한다.

 

Persistenct Voulme 생성

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-log
spec:
  persistentVolumeReclaimPolicy: Retain
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 100Mi
  hostPath:
    path: /pv/log

• persistentVolumeReclaimPolicy
  • 사용자가 볼륨을 다 사용하고나면 리소스를 반환할 수 있는 API를 사용하여 PVC 오브젝트를 삭제할 수 있다. 퍼시스턴트볼륨의 반환 정책은 볼륨에서 클레임을 해제한 후 볼륨에 수행할 작업을 클러스터에 알려준다. 현재 볼륨에 대한 반환 정책은 Retain, Recycle, 그리고 Delete가 있다.
  • Retain(보존)
  • Delete(삭제)
  • Recycle(재활용)

• volumeMode
  • 쿠버네티스는 퍼시스턴트볼륨의 두 가지 volumeModes인 Filesystem과 Block을 지원한다.
  • filesystem은 volumeMode 파라미터가 생략될 때 사용되는 기본 모드이다.
  • volumeMode: Filesystem이 있는 볼륨은 파드의 디렉터리에 마운트 된다. 볼륨이 장치에 의해 지원되고 그 장치가 비어 있으면 쿠버네티스는 장치를 처음 마운트하기 전에 장치에 파일시스템을 만든다.
• accessModes
  • 리소스 제공자가 지원하는 방식으로 호스트에 퍼시스턴트볼륨을 마운트할 수 있다.
  • ReadWriteOnce하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파드가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다.
  • ReadOnlyMany볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다.
  • ReadWriteMany볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다.
  • ReadWriteOncePod볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다.
• capacity
  • 일반적으로 PV는 특정 저장 용량을 가진다. 이것은 PV의 capacity 속성을 사용하여 설정된다.

PVC를 생성하여 애플리케이션에 대한 스토리지를 Claim

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: claim-log-1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Mi

주의사항

• AccessModes가 일치되어야 한다.
• Access Modes Mismatch 되면 PVC는 Pending 상태, PV는 Available 상태로 남아있음.

기존 Pod의 Hostpath 설정을 PVC 를 통해 연결하게 변경

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: event-simulator
    image: kodekloud/event-simulator
    env:
    - name: LOG_HANDLERS
      value: file
    volumeMounts:
    - mountPath: /log
      name: log-volume

  volumes:
  - name: log-volume
    persistentVolumeClaim:
      claimName: claim-log-1

다른 사항은 다 그대로 유지하고 volumes에 persistentVolumeClaim 속성을 추가한다.

 

The PVC is stuck in 'terminating' state 인 경우

• The PVC was still being used by the webapp pod when we issued the delete command. Until the pod is deleted, the PVC will remain in a terminating state.
• The PVC is being used by a POD

즉 현재 pod에서 연결된 PVC를 삭제하려고 하면 POD에서 사용중이기 때문에 지울수 없다는 것이다. Pod를 삭제하면 PVC도 삭제된다.

 

PVC가 삭제되면 Binding 되었던 PV도 Released 상태로 변화한다.

 

---

https://kubernetes.io/docs/concepts/storage/storage-classes/

Storage Classes

StorageClass 확인

kubectl get sc

스토리지 클래스에 사용되는 프로비저닝 도구도 확인 가능

 

What is the name of the Storage Class that does not support dynamic volume provisioning?

local-storage

로컬 스토리지 스토리지 클래스는 비 제공자를 사용하며 현재 동적 프로비저닝을 지원하지 않습니다.

 

What is the Volume Binding Mode used for this storage class (the one identified in the previous question)?

이 스토리지 클래스에 사용되는 볼륨 바인딩 모드는 무엇입니까?

kubectl describe sc local-storage

"volumeBindingMode":"WaitForFirstConsumer"

VolumeBindingMode 필드 확인

 

Let's fix that. Create a new PersistentVolumeClaim by the name of local-pvc that should bind to the volume local-pv.

기존 PV가 이미 존재할때 새로운 PVC를 만들어주자.

 

주의사항 - PV를 먼저 조회하여 아래 항목을 확인한다.

• accessModes가 일치해야 한다.
• 스토리지클래스 이름이 PV랑 동일해야 한다.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: local-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 500Mi

 

하지만 위에 설정대로 하면 pending 상태가 지속된다. 적절한 local-pv에 대해 request claim 했음에도 왜 pending인가?

waiting for first consumer to be created before binding

• local-storage라는 스토리지 클래스는 WaitForFirstConsumer로 설정된 VolumeBindingMode를 사용합니다. 
  이렇게 하면 PersistentVolumeClaim을 사용하는 Pod가 생성될 때까지 PersistentVolume의 바인딩 및 프로비저닝이 지연됩니다.

 

nginx:alpine 이미지로 nginx라는 새 포드를 만듭니다. Pod는 PVC local-pvc를 사용하고 /var/www/html 경로에 볼륨을 마운트해야 합니다.

kubectl run nginx --image=nginx:alpine --dry-run=client -o yaml > nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx:alpine
    name: nginx
    volumeMounts:
    - mountPath: "/var/www/html"
      name: local-persistent-storage
  volumes:
    - name: local-persistent-storage
      persistentVolumeClaim:
        claimName: local-pvc

최종적으로 local-pvc는 BOUND 상태가 되어야 한다.

 

Create a new Storage Class called delayed-volume-sc that makes use of the below specs:

스토리지 클래스를 만들어보자

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: delayed-volume-sc
provisioner:  kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

위 스펙은 no-provisioner 즉 Local 스토리지클래스라 스펙이 간단하다. 다른 환경 및 옵션은 Docs 참고
참고로 StorageClass는 yaml 파일로 만들어야함 Docs에서 복붙해오자