[katakoda] Running Stateful Services on Kubernetes

NFS (Network File system)

공유된 원격 호스트의 파일을 로컬에서 사용할 수 있도록 개발된 파일 시스템을 네트워크 파일 시스템

 

장점: 손쉽게 파일을 공유할 수 있다

단점: 보안에 취약하다

http://itnovice1.blogspot.com/2019/09/nfs.html

1. NFS 서버 배포하기

 

NFS는 노드가 네트워크를 통해 데이터를 읽고 쓸 수 있도록 하는 프로토콜입니다. 
이 프로토콜은 마스터 노드가 NFS 데몬을 실행하고 데이터를 저장하도록 함으로써 작동합니다. 
이 마스터 노드는 네트워크를 통해 특정 디렉토리를 사용할 수 있도록 합니다.

클라이언트는 드라이브 마운트를 통해 공유된 마스터에 액세스합니다. 
응용 프로그램의 관점에서 로컬 디스크에 쓰고 있습니다. 
덮개 아래에서 NFS 프로토콜은 이를 마스터에 씁니다.

이 시나리오에서 데모 및 학습 목적으로 NFS 서버의 역할은 사용자 정의된 컨테이너에서 처리됩니다.

컨테이너는 NFS를 통해 디렉터리를 사용할 수 있도록 하고 컨테이너 내부에 데이터를 저장합니다. 
프로덕션에서는 전용 NFS 서버를 구성하는 것이 좋습니다.

 

NFS 시작하기

NFS 서버는 data-0001 및 data-0002라는 두 개의 디렉토리를 노출합니다. 
다음 단계에서 이것은 데이터를 저장하는 데 사용됩니다.

docker run -d --net=host \
   --privileged --name nfs-server \
   katacoda/contained-nfs-server:centos7 \
   /exports/data-0001 /exports/data-0002

 

 

2. PersistentVolume (PV) 배포하기

 

Kubernetes가 사용 가능한 NFS 공유를 이해하려면 PersistentVolume 구성이 필요합니다. 
PersistentVolume은 AWS EBS 볼륨, GCE 스토리지, OpenStack Cinder, Glusterfs 및 NFS와 같은 데이터 저장을 위한 다양한 프로토콜을 지원합니다. 
구성은 일관된 경험을 허용하는 저장소와 API 간의 추상화를 제공합니다.

NFS의 경우 하나의 PersistentVolume은 하나의 NFS 디렉토리와 관련됩니다. 
컨테이너가 볼륨으로 완료되면 데이터는 향후 사용을 위해 보유하거나 볼륨을 재활용하여 모든 데이터가 삭제될 수 있습니다. 
정책은 persistentVolumeReclaimPolicy 옵션으로 정의됩니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: <friendly-name>
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    server: <server-name>
    path: <shared-path>

사양은 사용 가능한 공간 및 읽기/쓰기 액세스 권한이 있는지 여부를 포함하여 영구 볼륨에 대한 추가 메타데이터를 정의합니다.


두 개의 사용 가능한 NFS 공유를 가리키도록 두 개의 새 PersistentVolume 정의를 만듭니다.

 

 

PV 확인하기

 

 

3. PersistentVolume Claim(PVC) 배포하기

 

영구 볼륨을 사용할 수 있게 되면 애플리케이션에서 사용할 볼륨을 요청할 수 있습니다.
클레임은 응용 프로그램이 실수로 같은 볼륨에 쓰고 충돌 및 데이터 손상을 일으키는 것을 방지하도록 설계되었습니다.

클레임은 볼륨에 대한 요구 사항을 지정합니다. 
여기에는 읽기/쓰기 액세스 및 필요한 저장 공간이 포함됩니다. 

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: claim-mysql
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

두 개의 서로 다른 애플리케이션에 대해 두 개의 클레임을 만듭니다. 
MySQL Pod는 하나의 클레임을 사용하고 다른 하나는 HTTP 서버에서 사용합니다.

 

 

PVC 확인하기

 

 

4. 볼륨 사용하기

 

배포가 정의되면 이전 클레임에 자신을 할당할 수 있습니다. 
다음 스니펫은 mysql-persistent-storage 스토리지에 매핑되는 /var/lib/mysql/data 디렉토리에 대한 볼륨 마운트를 정의합니다. 
mysql-persistent-storage라는 저장소는 claim-mysql이라는 클레임에 매핑됩니다.

  spec:
      volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql/data
  volumes:
    - name: mysql-persistent-storage
      persistentVolumeClaim:
        claimName: claim-mysql

영구 볼륨 클레임이 있는 두 개의 새 Pod를 시작합니다. 
Pod가 로컬 디렉터리인 것처럼 애플리케이션이 읽기/쓰기를 허용하기 시작할 때 볼륨은 올바른 디렉터리에 매핑됩니다.

영구 볼륨 클레임이 영구 볼륨에 할당되지 않은 경우 포드는 사용 가능해질 때까지 보류 모드에 있습니다. 

다음 단계에서는 볼륨에 대한 데이터 읽기/쓰기를 수행합니다.

 

 

5. 데이터 읽고 쓰기

 

Pod는 이제 읽기/쓰기가 가능합니다. 
MySQL은 모든 데이터베이스 변경 사항을 NFS 서버에 저장하고 HTTP 서버는 NFS 드라이브에서 정적 서비스를 제공합니다. 
컨테이너를 업그레이드, 다시 시작하거나 다른 시스템으로 이동할 때 데이터에 계속 액세스할 수 있습니다.

HTTP 서버를 테스트하려면 'Hello World' index.html 홈페이지를 작성하세요. 
이 시나리오에서 우리는 볼륨 정의가 MySQL 크기 요구 사항을 충족하기에 충분한 공간을 구동하지 않았기 때문에 HTTP 디렉토리가 data-0001을 기반으로 한다는 것을 알고 있습니다.

docker exec -it nfs-server bash -c "echo 'Hello World' > /exports/data-0001/index.html"

Pod의 IP를 기반으로 Pod에 액세스할 때 예상 응답을 반환해야 합니다.

ip=$(kubectl get pod www -o yaml |grep podIP | awk '{split($0,a,":"); print a[2]}'); echo $ip

curl $ip

NFS 공유의 데이터가 변경되면 Pod는 새로 업데이트된 데이터를 읽습니다.

docker exec -it nfs-server bash -c "echo 'Hello NFS World' > /exports/data-0001/index.html"

 

 

6. 파드 재생성하기

 

원격 NFS 서버는 데이터를 저장하기 때문에 파드 또는 호스트가 다운되더라도 데이터는 계속 사용할 수 있습니다.

Pod를 삭제하면 영구 볼륨에 대한 클레임이 제거됩니다. 
새 Pod는 NFS 공유를 선택하고 재사용할 수 있습니다.

kubectl delete pod www

ip=$(kubectl get pod www2 -o yaml |grep podIP | awk '{split($0,a,":"); print a[2]}'); curl $ip

이제 애플리케이션은 데이터 저장을 위해 원격 NFS를 사용합니다. 
요구 사항에 따라 이 동일한 접근 방식은 GlusterFS, AWS EBS, GCE 스토리지 또는 OpenStack Cinder와 같은 다른 스토리지 엔진에서 작동합니다.