6. K8s Volume

1. Volume의 특징

  - Pod가 생성되거나 삭제될때 Volume도 함께 생성/삭제

  - Volume의 Life cylce은Pod에서 관리

  - 동일 Pod의 컨테이너끼리 Volume 공유

 

  apiVersion: v1
  kind: Pod
  metadata:
    name: pv-recycler-
    namespace: default
  spec:
    restartPolicy: Never
    volumes:
    - name: vol
      hostPath:
        path: /tmp/path/
    containers:
    - name: pv-recycler
      image: "gcr.io/...
      command: ...
      volumeMounts:
      - name: vol
        mountPath: /scrub

 

2. Volume의 종류

 - Local Disk

  1) emptyDir 

    : 휘발성의 Local Disk로써 일시적인 데이터 저장

  apiVersion: v1
  kind: Pod
  metadata:
    name: redis
  spec:
    containers:
    - name: redis
      image: redis
      volumeMounts:
      - name: redis-storage
        mountPath: /data/redis
      volumes:
      - name: redis-storage
        emptyDir: {}

    : Physical Disk가 아닌 RAM Disk로 사용 가능 (속도가 빨라 AI 연산 환경 등에 사용)

  volumes:
  - name: html
    emptyDir:
      medium: Memory

 

  2) hostPath

    : Pod가 아닌 Node 내부의 Disk로써, 동일 Node의 Pod간 공유가 가능

    : Pod가 내려가더라도 삭제되지 않음

 

  3) gitRepo

    : 기본적으로 emptyDir인 Local Disk

    : Volume을 생성할 때 gitRepo의 clone을 가져와서 생성

    : web의 이미지나 JS file 등의 Static content이 별도의 빌드 배포 파이프 라인 없이도 쉽게 로딩

    : Node.js나 Python 등 스크립트 언어의 App 배포를 단순하게 가능 

gitRepo

  apiVersion: v1
  kind: Pod
  metadata:
    name: gitrepo-volume-pod
  spec:
    containers:
    - image: nginx:alpine
      name: web-server
      volumeMounts:
      - name: html
      mountPath: /usr/share/nginx/html
      readOnly: true
    ports:
    - containerPort: 80
      protocol: TCP
    volumes:
    - name: html
      gitRepo:
        repositroy: https://github.com/.../kube-website-example.git
        directory: .

 

 - Remote Disk

  1) PersistentVolume(PV)

    - Static Provisioning : 관리자가 직접 생성

 

Dynamic Provisioning : 사용자가 정의한 StorageClass에 따라 PVC가 PV 생성

Dynamic Provisioning

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
  spec:
    capacity:
      storage: 5Gi
    volumeMode: Filesystem
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    sotrageClassName: slow
    mountOptions:
      - hard
      - nfsvers=4.1
    nfs:
      path: /tmp
      server: 172.20.0.2

    * Reclaim Policy : Volume을 모두 사용 하였을 때에 대한 정책

• Retain - 전처리 Pod가 내려간 이후에도 Volume을 유지하여 후처리 Pod의 Mount가 필요한 경우 등
• Recycle - 'rm -rf /volume/*'과 같이 Disk를 Release했을 때, 다른 User가 사용하는 것을 방지
• Delete - AWS EBS, GCE PD, Azure Diskk, OpenStack Cinder 처럼 Volume 소진 시 삭제

    * VolumeMode 

• Filesystem (default)
• Block 

    * AccessModes : Read와 Write를 어떻게 할 것인가를 결정

• ReadWriteOnce (RWO) - 하나의 Pod만 Read/Write
• ReadOnlyMany (ROX) - 하나의 Pod만 Write, 여러 Pod에서 Read
• ReadWriteMany (RWX) - 여러 Pod에서 Read/Write (nfs)

    * PV Phase

• Available - Disk가 사용 가능한 상태
• Bound - VolumeClaim에 연결된 상태
• Released - Volume 사용이 끝난 상태
• Failed

  2) PersistentVolumeClaim (PVC)

     : 스토리지에 대한 사용자의 요청으로 StorageClass에 따라

### PVC 선언
  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: mongodb-pvc
  spec:
    resources:
      requests:
        storage: 1Gi
      accessModes:
      - ReadWriteOnce
      storageClassName: ""

 

### StroageClass 선언
  apiVersion: v1
  kind:PersistentVolumeClaim
  metadata:
    name: mongodb-pvc
  spec:
    storageClassName: fast   
  resources:
    requests:
      storage: 100Mi
  accessModes:
  - ReadWriteOnce

  apiVersion: sotrage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: fast   ### storageClassName
  provisioner: kubernetes.io/gce-pd
  parameters:
    type: pd-ssd
    zone: europe-west1-b

 

  ex) StorageClass

  kind: StorageClass
  apiVersion: sotrage.k8s.io/v1
  metadata:
    name: slow
  provisioner: kubernetes.io/aws-ebs
  parameters:
    type: io1
    zones: us-east-1d, us-east-1c
    iopsPerGB: "10"

  kind: StorageClass
  apiVersion: storage.k8s.io/v1
  metadata:
    name: slow
  provisioner: kubernetes.io/gce-pd
  parameters:
    type: pd-standard
    zones: us-cental1-a, us-central1-b

  ex) Pod에서 PVC 사용 예제

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: mongodb-svc
  spec:
    accessMoeds:
      - ReadWriteOnce
    volumeMode: Filesystem
    resources:
      requests:
        storage: 8Gi
    sotrageClassName: slow
    selector:
      matchLabels:
        release: "stable"
      matachExpressions:
        - {key: environment, operator: In, values: [dev]}

  apiVersion: v1
  kind: Pod
  metadata:
    name: mongodb
    environment: dev
    release: "stable"
  spec:
    containers:
    - iamge: mongo
      name: mongodb
      volumeMounts:
      - name: moongodb-data
        mountPath: /data/db
      ports:
      - containerPort: 27017
        protocol: TCP
      volumes:
      - name: mongodb-data
      persistentVolumeClaim:
        claimName: mongodb-svc

      * matachLabels는 {key, value} 쌍과 매칭되며, matchExpressions의 component와 같다.

      * matchExpressions에는 Key, Value, Operator의 3가지 필드가 있다.

      * Operator에는 In, Notin, Exsists, DoNotExist의 연산자가 있다.

      * matchLabels와 matchExpressions는 AND 조건으로 두 가지 요건이 만족되야 한다.

 

  - Life Cycle

    1) Provisioning (PV) - Static/Dynamic 두 가지 방법 중 Disk 생성

    2) Binding (PVC-PV) - PVC와 PV를 연결(Pod의 Filesystem에서는 보이지 않음)

    3) Using (Pod-PVC-PV) - Volume을 Pod에 마운트

    4) Reclaiming (PV)

 

3. StatuefulSet

 보통 Pod를 만들때는 ReplicaSet을 이용하여 Template의 형식으로 만들며 PV는 Pod와 함께 생성된다. 여기서 문제가 발생하는데, 아래와 같이 첫 번째 생성되는 Pod는 PV와 함께 생성되면서 PV와 연결되지만 그 이후 생성되는 Pod는 PV에 연결되지 못한다

 여러 Pod에서 PV를 사용하려면 Pod마다 PV와 PVC 각각 생성해 주어야 한다.

 이런 한계를 지원하기 위해서 등장한 것이 StatefulSet이다.

 

- StatefulSet의 특징

• K8s 1.9(GA) 버전부터 지원된다.
• Volume을 Template 형식으로 만들어준다.
• Pod가 비정상적으로 종료되더라도 Pod Name운 바뀌지 않으며, 항상 같은 숫자로 생성된다.

 cf) MySQL Pod를 Master 1(Pod 0) / Slave 2(Pod 1, 2)의 형태로 배포했을때,  Pod 0은 항상 Master가 되어야 한다. 그러나 RC나 RS에서 Pod가 생성될 때, 순서가 없이 네이밍이 되어 어떤 Pod가 어떤 번호인지 알수가 없다.

    * Pod Name은 ${Stateful set name}-${ordinary index}으로 지정

• Pod가 Scale In/Out이 될때 Pod/PVC/PV의 순서를 유지해준다.

 

  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: web
  spec:
    selector:
      matchLabels:
        app: nginx
    serviceName: "nginx"
    replicas: 3
    template:
      metadata:
        labels:
          app: nginx
      spec:
        terminationGracePeriodSeconds: 10
        containers:
        - name: nginx
          image: k8s.gcr.io/nginx-slim:0.8
          ports:
          - containerPort: 80
            name: web
          volumeMounts:
          - name: www
            mountPath: /usr/share/nginx/html
    volumeClaimTemplates:
    - metadata:
        name: www
      spec:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "my-storage-class"
        resources:
          requests:
            storage: 1Gi

    * .spec.podManagementPolicy  : Pod의 Start-up 절차에 대한 정책

• OrderedReady (default) : Pod를 순서대로 시작/종료

 cf) Master가 구동 된 후에 Slave가 구동되어야 하는 경우(DB) 등에 사용

 

• Parallel : Pod를 동시에 시작/종료

 cf) 실제 서비스 환경에서 DB는 K8s Clutser 외부에 있는 경우가 많으므로 K8s 사용 초기에는 StatefulSet을 사용할 일이 적으며, 설정에도 신중함이 필요하다.

 cf) Public Cloud의 경우 개발 환경에서 많이 사용한다. Cassandra나 MongoDB를 Helm과 같은 Installer를 통해 배포와 삭제를 쉽게 할때 용이하다.

3. Reference

Kubernetes Storage

Kubernetes Advanced Workshop

조대협의 블로그