섹션 7. - Volume의 개념만 잘 이해하면 쉬운 PV, PVC 기능들

35강 - 인트로 (Intro)

 

쿠버네티스는 어플리케이션과 DevOps 그리고 인프라 전체 영역에 걸쳐 있고 컨테이너를 이용해서 이 모든 영역을 다룰 수 있게 만들어진 오케스트레이션이다. 

쿠버네티스가 다루는 내용은 결국 기존부터 해왔던 어플리케이션을 개발하고 CI/CD 환경을 거쳐 배포를 한 다음에 인프라에서 운영하는 것이다. 그렇기 때문에 이미 개발에서 인프라 영역까지를 경험해 본 사람이라면 쿠버네티스를 시작하기가 수월하다. 기존 기술을 쿠버네티스에서 어떻게 다루는지만 알면 되기 때문이다. 반면에 전체 과정을 처음 접해보는 사람이 쿠버네티스를 공부하면 난이도는 2배 이상 힘들어진다. 그래도 요즘 CI/CD나 인프라 환경을 처음할 때 쿠버네티스를 베이스로 하는 경우가 많기 때문에 이런 사람들이 많다. 결국 쿠버네티스가 어렵다는 말은 쿠버네티스의 순수 사용법 대한 어려움이 아니라 인프라 개념에 대한 어려움이 큰 지분을 차지한다. 

 

 

내가 학습한 내용이 실무에서 사용되기까지 노력 대비 가성비가 매우 낮음. ① 볼륨의 경우 실무에서 무조건 적용되는 케이스가 몇 가지로 정해져있다. 그렇기 때문에 ② 필요한 인프라 개념만 공부를 하고 ③ 구축 방법에 따라 ④ 쿠버네티스에서 제공하는 기능한 사용하면 끝난다.

 

 

Pod가 삭제되면 Container 안에 파일도 지워지기 때문에 데이터를 영구적으로 보관할 목적으로 PVC와 PV를 만들면 PV는 워커노드(Node (MasterNode))를 볼륨으로 사용하라는 속성이 있다. PVC가 Pod와 볼륨을 연결하고 있기 때문에 결국 /root/k8s-local-volume/1231에 파일(data.txt)이 만들어진다. 이렇게 워커노드를 저장소로 사용하는 방식은 테스트 용도로만 사용을 해야 된다(워커노드에 리소스가 부족해져서 노드가 죽으면 다 죽기 때문에). 실제 테스트 용도로도 워커노드에 임시로 데이터를 저장하려면 Pod의 hostpath라는 속성을 사용해도 데이터가 워커노드에 저장된다는 결과는 같기 때문에 굳이 PVC와 PV를 만들지 않아도 되어서 간편하기 때문에 많이 사용한다. 쿠버네티스에서 PVC와 PV를 공부할 때 이해하기 어려운 이유 중 첫 번째는 PV를 쓰는 것 자체가 마냥 불편하게만 느껴지게 된다는 것이다. 두 번째로, PVC에 resource, accessModes라는 필수 값이 있다. Pod에서 사용할 수 있는 볼륨의 양과 모드를 제한하기 위한 기능인데, PV-local(path: /root/k8s-local-volume/1231)로 속성을 줬을 경우 capacity-storge: 2G 를 줫더라도 Pod-Container 안에서는 2G 이상 워커노드에서 가용한 용량까지 파일이 저장된다. 그리고 accessModes 역시 PV에는 ReadWriteMany라고 있지만 PVC에는 ReadWriteOnce, ReadOnlyMany도 있는데 이 속성을 변경한다고 해서 정말 한 곳에서만 연결이 되도록 하거나 아니면 여러 곳에서 연결이 되더라도 읽기 모드로만 동작하도록 하지 못한다. 이렇게 PVC, PV를 위한 설정들이 있지만 모두 설정대로 동작하지 않는데 그 이유는 이 설정들이 모두 인터페이스이기 때문이다. 그냥 쿠버네티스에서 제공해주는 규격일 뿐 모두 볼륨들과 연결된 기능들은 아닌 것이다. 예를 들어 PV는 NFS 속성도 있어서 NFS 서버를 통해 볼륨과 연결이 될 수는 있지만 NFS에는 디스크를 제한하는 기능 자체가 없다. 그래서 아무리 PV-capacity에 용량을 2G로 준다고 하더라도 이 기능을 동작시킬 수가 없는 것이다. 하지만 이 속성들은 쿠버네티스 리소스를 만들 때 기본값들이기 때문에 꼭 넣어줘야한다. 그래서 이때는 단순 정보성의 역할로 사용이 되는 것이다. 그런데 NFS에는 accessModes와 같이 여러 곳에서 읽고 쓰거나 한 곳에서 읽고 쓰도록 제한하는 기능, 그리고 읽기 전용 모드로만 사용하는 기능이 있긴 하다. 하지만 그렇다고 이 상황에서 이 accessModes가 동작하지는 않는다. 그 이유는 쿠버네티스에서 PV의 속성을 통해서 NFS의 볼륨과 연결을 하는 부분만 구현을 한 거지 NFS에 볼륨을 만들고 또 사용에 대한 권한까지 주는 기능을 만든 건 아니다. 이런 내용처럼 처음에는 알기 어렵기 때문에 왜 이 속성들이 동작을 안하는 건지 혹시 내가 뭘 잘못하는 건 아닌지라는 생각을 들게 만든다.

세 번째로 실제 볼륨을 만들고 연결을 하려면 스토리지 클래스라는 리소스를 사용해야 한다. 그러면 여러 스토리지 솔루션들을 컨트롤 할 수가 있는데 만드는 방식은 PVC에서 storageClassName (nfs) 를 지정을 하면 PV가 자동으로 만들어지면서 PVC에 연결이 된다. 리소스 생성 순서의 차이를 보면 지금까지 PV를 먼저 만들고 PVC를 생성해서 연결을 해줫다면 솔루션 볼륨을 사용할 때는 ① 스토리지 클래스를 만들고 ② PVC에 지정을 하면 ③ PV가 자동 생성되면서 ④ PVC와 연결이 되는 순서가 된다. 연결구조가 복잡한 것 같지만 그래도 스토리지 클래스는 딱 하나만 만들어 놓으면 된다. 결국 사용자는 PVC만 생성을 하고 스토리지 클래스 이름만 지정을 해주면 돼서 사용법은 간편하다. 이 스토리지 클래스 자체에는 속성들이 좀 많다(provisioner, reclaimPolicy, volumeBindingMode, mountOptions, parameters...). 그리고 솔루션별로 이 스토리지 클래스에 대한 사용 방법들이 다 다르다. 실무에서 사용되는 볼륨을 사용할 때는 사용법이 복잡해지기도 하지만 다양한 볼륨 솔루션들이 있기 때문에 어떤 걸 해봐야 할지 처음 공부하는 입장에서는 너무 막연하게 느껴진다. 

네 번째로 이 볼륨 솔루션들은 언제 어떻게 사용해야 되는지에 대한 실무적인 유즈 케이스를 모른다는 것이다. 파드의 볼륨을 정하고 PV와 PVC를 통해서 연결하는게 끝이 아니라 시작이다. 이 볼륨들이 어디서 어떤 케이스로 사용이 되는지 알아야 한다. 

 

---

37강 - 쿠버네티스에서 Volume 구축 및 유즈케이스

 

Block Storage

사용 구분 : 하드디스크에서 많이 쓴다. 

사용 방법 : 물리적으로 장착한 후에 내 디스크처럼 쓴다. 흔히 내 PC에 메인보드에 하드디스크를 꼽아 쓴다.

특징 : 데이터를 공유할 수는 없지만 처리속도가 빠르다.

저장 구조 : 고정 크기의 블록 형태

 

File Storage

사용 구분 : 네트워크 공유 파일 시스템을 구축하기 위해서 사용을 한다. 회사에서 이런 시스템들이 대부분 구축돼 있어서 프로젝트를 할 때 팀원들끼리 파일을 공유한다. 

사용 방법 : 여러 PC에서 네트워크로 한 디스크 공간을 연결한다. 연결된 이후에는 블록 스토리지와 마찬가지로 내 PC에 있는 폴더처럼 사용을 할 수 있게 된다.

특징 : 공간에 있는 파일들을 사용할 땐 항상 네트워크를 타고 접근을 해야 되기 때문에 처리 속도에 네트워크 통신 시간이 추가되어 블록 스토리지보다 처리속도가 느리다. 

저장 구조 : 계층적 구조

 

Object Storage

사용 구분 : 사용 목적은 스토리지 서비스를 위한 용도이다.

사용 방법 : 서비스에 로그인을 해서 api로 호출한다. 여러 사용자들이 각각의 클라우드 서비스에 api를 날려서 데이터를 업로드하고 필요할 때 다운로드를 받는다.

특징 : 디스크 확장이 용이하다. 대규모 스토리지를 구축을 하는데 많이 쓴다. 블록 스토리지나 파일 스토리지는 스토리지와 연결이 되어 있는 상태이기 때문에 디스크 공간을 확장하려면 메인보드에서 장착을 해제하거나 pc에서 연결을 끊은 다음에 저장 공간이 큰 스토리지로 교체를 해서 다시 연결을 해줘야 한다. 이때 기존 디스크에 있던 파일도 복사를 해줘야 하는 번거로움이 있다. 반면에 오브젝트 스토리지는 스토리지 기술 자체가 데이터를 여러 디스크에 분산을 해서 관리를 하고 사용자와 디스크가 항상 연결되어 있는 상태가 아니라 필요할 때만 api를 호출을 해서 쓰기 때문에 디스크가 아무리 늘어나도 사용자 입장에서는 영향이 전혀 없다. 

저장 구조 : 객체 단위로 저장

 

파일 시스템의 FTP와 오브젝트 스토리지가 혼동이 올 수도 있다. 기존에 인터넷에서 각종 설치 파일들이나 패키지들을 다운로드 받을 때 대부분 FTP를 이용해서 받았고 이때 서비스에 로그인을 해야 되는 경우도 있어서 오브젝트 스토리지랑 특징이 같다. 그러나 FTP 자체는 통신 기술의 이름이다. 오브젝트 스토리지에서 User 들이 클라우드 스토리지에 api 호출하는 것도 HTTP라는 통신 기술이다. FTP는 파일 스토리지에 있는 파일들을 원격에서 업로드하고 다운로드 받을 수 있게 하려고 만들어진 프토로콜이다. 각각의 특징을 가지고 있는 스토리지들이 있는 것이고 이 스토리지들을 원격에서 사용하기 위한 각각의 통신 프로토콜이 있다. FTP를 사용하면 파일 스토리지와 오브젝트 스토리지에 대한 차이가 없어지는데 파일 스토리지는 기본적으로 연결을 해서 써야 되고 FTP로 스토리지에 대한 활용이 넓어진 개념이다. 블록 스토리지도 내 PC에 네트워크를 연결하면 원격에서 사용이 가능해지는 것처럼. 오브젝트 스토리지도 api 호출이 아닌 직접 연결의 형태로도 쓸 수가 있지만 흔히 사용하는 형태에 대해서 이야기 하는 것이다. 

 

 

 

1. 테스트 용도로 워커 노드를 사용할 수 있다.

2. 기존 로컬 시스템에 구축된 volume 사용(제약적 사용)

> 솔루션들이 쿠버네티스용으로 만들어진게 아닌 경우가 많아서 솔루션 자체에는 여러 기능들이 있을 수도 있지만 쿠버네티스와 연결을 할 때는 제약적인 기능만 사용이 될 수 있다. 

3. 클라우드 서비스에 있는 volume 사용 (대체로 StoragClass 지원, 다양한 기능 사용)

4. 컨테이너 volume 솔루션 구축

> 이때 워커 노드는 볼륨 전용 노드가 되는 거라서 노드에 디스크를 많이 할당해 줘야 되고 NodeSelector로 볼륨 노드와 어플리케이션 노드를 구분해서 쓴다. 당연히 스토리지 클래스도 제공함. 

> 오브젝트 스토리지의 경우(minio) 파일이나 블록 스토리지와는 달리 연결을 해서 쓰는 개념이 아니기 때문에 PV를 사용하지는 않고 pod에서 직접 오브젝트 스토리지로 api를 호출한다. 

 

Block Storage

데이터베이스를 위한 스토리지로 사용한다. 데이터베이스에서 가장 중요한게 성능이기 때문이다. 베이터베이스가 PostgreSQL이라고 했을 때 이 데이터베이스는 StatefulSet으로 쿠버네티스에 배포가 된다. 이중화를 위해 pod가 두 개 만들어졌다고 해보자. StatefulSet은 쿠버네티스에서 데이터베이스 배포를 위한 목적으로 만들어진 컨트롤러이다. 결국 블록 스토리지 솔루션과의 연결은 각 pod에 각각의 볼륨이 연결이 돼서 데이터를 독립적으로 저장할 수 있게 구성이 된다. 그리고 백엔드 서버에서 headless 서비스를 통해서 한쪽 pod로만 연결을해서 데이터를 읽고 쓴다. 데이터베이스들은 자체적으로 이중화를 위해서 다른 쪽 db로 데이터를 복제시키는 기능이 있다. 대부분의 데이터베이스 솔루션들은 이렇게 동작하기 때문에 그에 맞게 쿠버네티스에서 데이터베이스를 위해 headless 서비스와 statefulset, block stroage를 한 세트로 사용을 한다. 

 

File Storage

일반 어플리케이션에서 주로 사용을 한다. 어플리케이션은 deployment로 쿠버네티스에 배포를 한다. 이때 어플리케이션에는 데이터베이스처럼 자체적으로 데이터를 이중화시켜주는 기능은 없기 때문에 모든 파드를 한 볼륨에 연결을 해서 데이터를 공유한다. 프론트엔드 서버에서 클러스터ip 타입의 서비스를 이용해서 모든 파드들의 api를 보내준다. 

 

Object Storage

deployment로 배포된 어플리케이션에서 오브젝트 스토리지를 사용하고 클러스터ip 타입의 서비스가 사용이 된다. 여기서 오브젝트 스토리지 솔루션에는 api를 받을 수 있는 서버 기능과 볼륨이 있어서 pod에서 api를 보내서 파일을 다운로드 받을 수도 있고 업로드를 할 수도 있는데 이게 일반적인 오브젝트 스토리지에 대한 사용 케이스이다. 그리고 파일 스토리지와 같이 두 서버 간의 데이터 공유의 목적으로도 사용할 수가 있다. 하지만 파일을 공유하기엔 연결 상태에 있는 파일 스토리지에 비해 성능이 좋지 않고 매번 api를 보내야 되니까 사용법에 있어서도 좀 더 불편한 면이 있기 때문에 어플리케이션에서 자주 쓰는 파일을 공유하는 데는 좋지 않다. 하지만 유투브나 깃허브, 도커 허브 등과 같이 대용량 저장 공간이 필요한 시스템을 만들 때는 저장공간이 계속 늘어날 수 있어야 한다는 점이 중요하기 때문에 오브젝트 스토리지를 많이 사용한다. 

 

 

 

---

38강 - 실습하기

 

[Sprint3]  Volume의 개념만 잘 이해하면 쉬운 PV, PVC 기능들

1. File Storage - NFS Server 구축(CI/CD Server) 및 Deployment 배포

 

1-1. CI/CD Server - NFS Server 설치

yum -y install nfs-utils rpcbind
systemctl start rpcbind
systemctl start nfs-server
systemctl start rpc-statd
systemctl enable rpcbind
systemctl enable nfs-server

# 상태 확인
systemctl status nfs-server

 

 

 

1-2. Volume(공유 폴더) 생성 및 설정

// 폴더 생성
mkdir /file-storage

// exports 파일 설정
vi /etc/exports
--- vi 편집기 ---
/file-storage *(rw,sync,no_root_squash)
----------------

// 설정 반영
exportfs -r
// 재시작
systemctl restart nfs-server

 

▶ 특정 IP 대역에서만 접근 할 수 있도록 제한

/file-storage 192.168.56.0/24(rw,sync,no_root_squash)

▶ 특정 IP에서만 접근 할 수 있도록 제한

/file-storage 192.168.56.30(rw,sync,no_root_squash)

▶ 읽기 전용으로만 연결

/file-storage *(ro,sync,no_root_squash)

▶ sync / async : 데이터 쓰기에 대한 작업 모드 (sync 안정적-느림), (async 불안전-빠름)

▶ no_root_squash : 클라이언트의 root 사용자가 서버에서도 root 권한을 유지

(기본값 root_squash : root 사용자가 서버에 접근하면 NFS 서버는 그 사용자를 "anonymous" 사용자로 매핑하여 root 권한을 제한

​

1-3. Master Server에서 Yaml 파일 배포

kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint3/main/3231/deploy/k8s/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint3/main/3231/deploy/k8s/secret.yaml
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint3/main/3231/deploy/k8s/configmap.yaml
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint3/main/3231/deploy/k8s/file/deployment.yaml
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint3/main/3231/deploy/k8s/file/pv.yaml
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint3/main/3231/deploy/k8s/file/pvc.yaml

 

 

 

 

1-4. Resource 확인

▶ PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-volume-3231
  labels:
    part-of: k8s-anotherclass
    component: backend-server
    name: api-tester
    instance: application-3231
spec:
  capacity:
    storage: 1G
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.56.20
    path: /file-storage
// Master에 nfs client가 설치되 있는 지 확인
 yum list installed | grep nfs-utils

 

▶ PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-volume-3231
  namespace: anotherclass-323
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1G
  storageClassName: ""
  selector:
    matchLabels:
      part-of: k8s-anotherclass
      component: backend-server
      name: api-tester
      instance: application-3231

 

- storageClassName: "" // StorageClass 사용 안함 설정

- storageClassName: // Default StorageClass 적용

- storageClassName: "longhorn" // StorageClass 지정

 

▶ Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-3231
...
      containers:
        - name: api-tester-3231
          image: 1pro/api-tester:3.0.0
          volumeMounts:
            - name: shared-volume
              mountPath: /mnt/shared
              subPath: application-3231
      volumes:
        - name : shared-volume
          persistentVolumeClaim:
            claimName: shared-volume-3231

 

- subPath : 연결된 Volume에 폴더를 추가 생성 후 그 디렉토리와 연결

Container path : /mnt/shared,

NFS Path : /file-storage/application-3231 (생성)

* Volume 구성은 유지한 채, 기존 디렉토리의 데이터는 보존하고, 새 디렉토리에 데이터를 쓰고 싶을 때

(subPath만 추가/변경하면서 새 디렉토리 경로를 변경)

* Pod에 컨테이너가 두개(Main, Logging 역할)일 경우 각각 저장 공간을 분리하고 싶을 때

 

      containers:
        - name: main
          volumeMounts:
            - name: shared-volume
              mountPath: /mnt/shared
              subPath: main-data
        - name: logging
          volumeMounts:
            - name: shared-volume
              mountPath: /mnt/shared
              subPath: log-data
      volumes:
        - name : shared-volume
          persistentVolumeClaim:
            claimName: shared-volume-3231

 

1-5. 파일 공유 확인

▶ Pod 내부 /mnt/shared 위치에서 파일 생성

// Pod 내부로 들어가기
k exec -n anotherclass-323 application-3231-<tab> -it -- /bin/bash

// 파일 생성
cd /mnt/shared/
touch file.txt

// NFS Server 확인
cd /file-storage/application-3231

 

pod 1에 들어가서 공유파일에 흔적 남기기

nfs 서버에서도 확인된다.

pod 2에서도 확인이 된다.

 

 

 

 

2. Block Storage - Longhorn 설치(Master Node) 및 StatefulSet 배포

 

 

2-1. Master에 Longhorn 설치

# iscsi 설치 및 상태 확인
yum --setopt=tsflags=noscripts install iscsi-initiator-utils
echo "InitiatorName=$(/sbin/iscsi-iname)" > /etc/iscsi/initiatorname.iscsi
systemctl enable iscsid
systemctl start iscsid

# longhorn 배포
kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/longhorn-1.4.2/longhorn.yaml

# replicas 수 조정
kubectl scale deploy -n longhorn-system csi-attacher --replicas=1
kubectl scale deploy -n longhorn-system csi-provisioner --replicas=1
kubectl scale deploy -n longhorn-system csi-resizer --replicas=1
kubectl scale deploy -n longhorn-system csi-snapshotter --replicas=1

# 설치 확인
kubectl get pod -n longhorn-system

 

 

▶ 설치 전체 조건

https://longhorn.io/docs/archives/1.4.2/deploy/install/#installation-requirements

Longhorn | Quick Installation

 

 

▶ longhorn 설치

https://longhorn.io/docs/archives/1.4.2/deploy/install/install-with-kubectl/

Longhorn | Install with Kubectl

 

2-2. Longhorn UI 접속

http://192.168.56.30:30005/

 

 

 

 

2-3. Master Server에서 StatefulSet 배포

kubectl apply -f https://raw.githubusercontent.com/k8s-1pro/kubernetes-anotherclass-sprint3/main/3231/deploy/k8s/block/statefulset.yaml

 

 

2-4. Resource 확인

▶ StorageClass

kubectl get storageclass -o yaml

 

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
  annotations:
    // 디폴트 StorageClass로 선언   
    storageclass.kubernetes.io/is-default-class: "true"   // - storageClassName: 
allowVolumeExpansion: true       // 이 StorageClass로 만들어진 Volume은 확장이 가능
provisioner: driver.longhorn.io  // Longhorn 드라이버 지정
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:                      
  dataLocality: disabled
  fromBackup: ""
  fsType: ext4
  numberOfReplicas: "1"
  staleReplicaTimeout: "30"

 

 

reclaimPolicy

- Delete (default) : PVC가 삭제될 때 PV도 자동으로 삭제

- Retain : PVC가 삭제되더라도 PV는 삭제되지 않음. (실수방지용도, 임시보관용도)

- Recycle : PV의 내용을 초기화 시켜서 Volume을 재사용함 (deprecated)

volumeBindingMode:

- Immediate : PVC가 생성되면 즉시 PV가 만들어져서 연결이 됨

- WaitForFirstConsumer : PVC를 생성해도 바로 PV가 만들어지지 않고, Pod가 만들어지는 시점에 PV가 같이 만들어져서 연결이 됨 (Pod가 위치한 워커노드에 Volume이 만들어 지는 솔루션에 사용됨)

parameters :

 

https://longhorn.io/docs/archives/1.4.2/references/storage-class-parameters/

Longhorn | Storage Class Parameters

 

 

▶ StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: anotherclass-323
  name: database-3231
...
      containers:
        - name: database-3231
          image: 1pro/api-tester:3.0.0
          volumeMounts:
            - name: longhorn-volume
              mountPath: /data/db
  volumeClaimTemplates:
    - metadata:
        name: longhorn-volume
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 10M
        storageClassName: "longhorn"

 

StatefulSet 특징

- volumeClaimTemplates를 통해 Pod별로 PVC/PV 생성

- StatefulSet를 삭제 했을 땐, PVC와 PV는 삭제되지 않음 (필요시 PVC를 직접 삭제)

- StatefulSet 재생성시 기존 PVC와 연결

​

▶ Longhorn의 경우 storage로 지정된 만큼만 Volume을 생성

[13MB 파일 다운로드 시]
// Pod 영역 저장 성공
curl -L -o 13M.file https://github.com/k8s-1pro/kubernetes-anotherclass-sprint3/raw/main/3231/deploy/k8s/block/13M

// Volume 영역 - 용량 부족으로 실패
cd /data/db
curl -L -o 13M.file https://github.com/k8s-1pro/kubernetes-anotherclass-sprint3/raw/main/3231/deploy/k8s/block/13M

 

2-5. Longhorn 삭제 (pvc, pv 모두 정리 후)

kubectl delete -f https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/longhorn-1.4.2/longhorn.yaml

 

 

 

 

 

3. Object Storage - Minio 설치(CI/CD Server) 및 Deployment 배포

 

 

3-1. CI/CD Server에 Minio 설치

# minio 다운 (windows) - minio 서버가 좀 느려요.
wget https://dl.min.io/server/minio/release/linux-amd64/minio
# minio 다운 (mac)
wget https://dl.min.io/server/minio/release/linux-arm64/minio

# 설치
chmod +x minio
mv minio /usr/bin/minio

# 서버 실행 
mkdir /root/minio
minio server /root/minio --console-address :9001 &   // API Server Port : 9000
(CI/CD 서버 재기동시 다시 실행 시켜줘야 합니다.)

 

https://min.io/docs/minio/linux/index.html

MinIO Object Storage for Linux — MinIO Object Storage for Linux

 

 

3-2. Minio 접속

WebUI: http://192.168.56.20:9001
   RootUser: minioadmin
   RootPass: minioadmin

API: http://192.168.56.20:9000
   RootUser: minioadmin
   RootPass: minioadmin

 

 

3-3. 접속 및 파일 업로드/다운로드

// 로그인 
mc alias set myminio ${minio_endpoint} ${minio_access_key} ${minio_secret_key}

// 서버 상태 확인
mc admin info myminio

// 버킷 생성
mc mb myminio/test

// 업로드 
touch upload.txt
mc cp ./upload.txt myminio/test/upload.txt

// 업로드 파일 확인
mc ls myminio/test

// 다운로드 
mc cp myminio/test/upload.txt ~/download.txt

// 파일 삭제
mc rm myminio/test/upload.txt
mc ls myminio/test