스토리지


OpenShift Container Platform 4.19

OpenShift Container Platform에서 스토리지 구성 및 사용

Red Hat OpenShift Documentation Team

초록

이 문서에서는 다양한 스토리지 백엔드에서 영구 볼륨을 구성하고 Pod의 동적 할당을 관리하는 방법을 설명합니다.

1장. OpenShift Container Platform 스토리지 개요

OpenShift Container Platform에서는 온프레미스 및 클라우드 공급자를 위해 여러 유형의 스토리지를 지원합니다. OpenShift Container Platform 클러스터에서 영구 및 비영구 데이터에 대한 컨테이너 스토리지를 관리할 수 있습니다.

1.1. OpenShift Container Platform 스토리지의 일반 용어집

이 용어집은 스토리지 콘텐츠에 사용되는 일반적인 용어를 정의합니다.

액세스 모드

볼륨 액세스 모드는 볼륨 기능을 설명합니다. 액세스 모드를 사용하여 PVC(영구 볼륨 클레임) 및 PV(영구 볼륨)와 일치시킬 수 있습니다. 다음은 액세스 모드의 예입니다.

  • 한 번 읽기/쓰기(RWO)
  • 읽기 전용(ROX)
  • 읽기/쓰기다중(RWX)
  • ReadWriteOncePod (RWOP)
Cinder
모든 볼륨의 관리, 보안 및 스케줄링을 관리하는 Red Hat OpenStack Platform(RHOSP)용 블록 스토리지 서비스입니다.
구성 맵
구성 맵에서는 구성 데이터를 Pod에 삽입하는 방법을 제공합니다. 구성 맵에 저장된 데이터를 ConfigMap 유형의 볼륨에서 참조할 수 있습니다. Pod에서 실행되는 애플리케이션에서는 이 데이터를 사용할 수 있습니다.
CSI(Container Storage Interface)
다양한 컨테이너 오케스트레이션(CO) 시스템에서 컨테이너 스토리지를 관리하기 위한 API 사양입니다.
동적 프로비저닝
이 프레임워크를 사용하면 필요에 따라 스토리지 볼륨을 생성할 수 있으므로 클러스터 관리자가 영구 스토리지를 미리 프로비저닝할 필요가 없습니다.
임시 저장소
포드와 컨테이너는 작동을 위해 일시적 또는 임시적인 로컬 저장소가 필요할 수 있습니다. 이러한 임시 스토리지의 수명은 개별 Pod의 수명 이상으로 연장되지 않으며 이 임시 스토리지는 여러 Pod 사이에서 공유할 수 없습니다.
파이버 채널
데이터 센터, 컴퓨터 서버, 스위치 및 스토리지 간에 데이터를 전송하는 데 사용되는 네트워킹 기술입니다.
FlexVolume
FlexVolume은 exec 기반 모델을 사용하여 스토리지 드라이버와 인터페이스하는 트리 외부 플러그인 인터페이스입니다. 각 노드의 사전 정의된 볼륨 플러그인 경로에 FlexVolume 드라이버 바이너리를 설치해야 하며, 어떤 경우에는 제어 평면 노드에도 설치해야 합니다.
fsGroup
fsGroup은 Pod의 파일 시스템 그룹 ID를 정의합니다.
iSCSI
iSCSI(Internet Small Computer Systems Interface)는 데이터 저장 시설을 연결하기 위한 인터넷 프로토콜 기반 저장 네트워킹 표준입니다. iSCSI 볼륨을 사용하면 기존 iSCSI(SCSI over IP) 볼륨을 Pod에 마운트할 수 있습니다.
hostPath
OpenShift Container Platform 클러스터의 hostPath 볼륨은 호스트 노드 파일 시스템의 파일 또는 디렉터리를 Pod에 마운트합니다.
KMS key
키 관리 서비스(KMS)는 다양한 서비스에서 필요한 수준의 데이터 암호화를 달성하는 데 도움이 됩니다. KMS 키를 사용하여 데이터를 암호화, 암호 해독 및 다시 암호화할 수 있습니다.
로컬 볼륨
로컬 볼륨은 디스크, 파티션 또는 디렉토리와 같은 마운트된 로컬 저장 장치를 나타냅니다.
중첩된 마운트 포인트

중첩된 마운트 지점은 이전 볼륨에서 생성된 마운트 지점을 사용하려는 마운트 지점입니다.

중첩된 마운트 지점이 있는 포드 정의 예

kind: Pod
apiVersion: v1
metadata:
  name: webapp
  labels:
    name: webapp
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
      - mountPath: /mnt/web
        name: web
      - mountPath: /mnt/web/redis 
1

        name: redis
  volumes:
    - name: redis
      persistentVolumeClaim:
       claimName: "redis"
    - name: web
      persistentVolumeClaim:
        claimName: "web"
Copy to Clipboard Toggle word wrap

1
중첩된 마운트 지점

중첩된 마운트 지점을 사용 하지 마세요 . OpenShift Container Platform은 마운트 지점이 생성되는 순서를 보장하지 않습니다. 이런 식으로 사용하면 경쟁 조건과 정의되지 않은 동작이 발생하기 쉽습니다.

NFS
원격 호스트가 네트워크를 통해 파일 시스템을 마운트하고 마치 로컬에 마운트된 것처럼 해당 파일 시스템과 상호 작용할 수 있도록 해주는 네트워크 파일 시스템(NFS)입니다. 이를 통해 시스템 관리자는 네트워크의 중앙 집중식 서버에 리소스를 통합할 수 있습니다.
OpenShift Data Foundation
파일, 블록 및 개체 스토리지를 사내 또는 하이브리드 클라우드에서 지원하는 OpenShift Container Platform을 위한 독립적인 영구 스토리지 제공업체
영구 스토리지
Pod 및 컨테이너는 작업을 위해 영구 스토리지가 필요할 수 있습니다. OpenShift Container Platform에서는 Kubernetes PV(영구 볼륨) 프레임워크를 사용하여 클러스터 관리자가 클러스터의 영구 스토리지를 프로비저닝할 수 있습니다. 개발자는 기본 스토리지 인프라에 대한 구체적인 지식이 없어도 PVC를 사용하여 PV 리소스를 요청할 수 있습니다.
영구 볼륨(PV)
OpenShift Container Platform에서는 Kubernetes PV(영구 볼륨) 프레임워크를 사용하여 클러스터 관리자가 클러스터의 영구 스토리지를 프로비저닝할 수 있습니다. 개발자는 기본 스토리지 인프라에 대한 구체적인 지식이 없어도 PVC를 사용하여 PV 리소스를 요청할 수 있습니다.
영구 볼륨 클레임(PVC)
PVC를 사용하여 PersistentVolume을 포드에 마운트할 수 있습니다. 클라우드 환경의 세부 사항을 모르는 상태에서 스토리지에 액세스할 수 있습니다.
Pod
OpenShift Container Platform 클러스터에서 실행되는 볼륨 및 IP 주소와 같은 공유 리소스가 있는 하나 이상의 컨테이너입니다. Pod는 정의, 배포 및 관리되는 최소 컴퓨팅 단위입니다.
정책 회수
볼륨이 해제된 후 클러스터에서 볼륨을 어떻게 처리할지 알려주는 정책입니다. 볼륨 회수 정책은 Retain, Recycle 또는 Delete일 수 있습니다.
역할 기반 액세스 제어(RBAC)
역할 기반 액세스 제어(RBAC)는 조직 내 개별 사용자의 역할에 따라 컴퓨터 또는 네트워크 리소스에 대한 액세스를 규제하는 방법입니다.
상태 비저장 애플리케이션
상태 비저장 애플리케이션은 한 세션에서 생성된 클라이언트 데이터를 해당 클라이언트와의 다음 세션에서 사용하기 위해 저장하지 않는 애플리케이션 프로그램입니다.
상태 저장 애플리케이션
상태 저장 애플리케이션은 영구 디스크 저장소에 데이터를 저장하는 애플리케이션 프로그램입니다. 서버, 클라이언트 및 애플리케이션은 영구 디스크 저장소를 사용할 수 있습니다. OpenShift Container Platform의 Statefulset 객체를 사용하면 Pod 세트의 배포와 확장을 관리할 수 있으며 이러한 Pod의 순서와 고유성을 보장할 수 있습니다.
정적 프로비저닝
클러스터 관리자는 여러 PV를 생성합니다. PV에는 저장에 대한 세부 정보가 포함되어 있습니다. PV는 Kubernetes API에 존재하며 사용할 수 있습니다.
스토리지
OpenShift Container Platform은 온프레미스 및 클라우드 공급자를 위해 다양한 유형의 스토리지를 지원합니다. OpenShift Container Platform 클러스터에서 영구 및 비영구 데이터에 대한 컨테이너 스토리지를 관리할 수 있습니다.
스토리지 클래스
스토리지 클래스는 관리자가 제공하는 스토리지 클래스를 설명할 수 있는 방법을 제공합니다. 다양한 클래스는 서비스 품질 수준, 백업 정책, 클러스터 관리자가 결정한 임의 정책에 매핑될 수 있습니다.
VMware vSphere의 가상 머신 디스크(VMDK) 볼륨
가상 머신 디스크(VMDK)는 가상 머신에서 사용되는 가상 하드 디스크 드라이브의 컨테이너를 설명하는 파일 형식입니다.

1.2. 저장 유형

OpenShift Container Platform 스토리지는 크게 임시 스토리지와 영구 스토리지의 두 가지 범주로 분류됩니다.

1.2.1. 임시 저장소

포드와 컨테이너는 본질적으로 일시적이거나 일시적이며 상태 비저장 애플리케이션용으로 설계되었습니다. 임시 저장소를 사용하면 관리자와 개발자가 일부 작업에 대한 로컬 저장소를 보다 효과적으로 관리할 수 있습니다. 임시 저장소 개요, 유형 및 관리에 대한 자세한 내용은 임시 저장소 이해를 참조하세요.

1.2.2. 영구 스토리지

컨테이너에 배포된 상태 저장 애플리케이션에는 영구 저장소가 필요합니다. OpenShift Container Platform은 클러스터 관리자가 영구 스토리지를 프로비저닝할 수 있도록 영구 볼륨(PV)이라는 사전 프로비저닝된 스토리지 프레임워크를 사용합니다. 이러한 볼륨 내부의 데이터는 개별 포드의 수명 주기를 넘어 존재할 수 있습니다. 개발자는 영구 볼륨 클레임(PVC)을 사용하여 스토리지 요구 사항을 요청할 수 있습니다. 영구 저장소 개요, 구성 및 수명 주기에 대한 자세한 내용은 영구 저장소 이해를 참조하세요.

1.3. CSI(Container Storage Interface)

CSI는 다양한 컨테이너 오케스트레이션(CO) 시스템에서 컨테이너 스토리지를 관리하기 위한 API 사양입니다. 기본 스토리지 인프라에 대한 구체적인 지식이 없어도 컨테이너 네이티브 환경 내에서 스토리지 볼륨을 관리할 수 있습니다. CSI를 사용하면 사용하는 스토리지 공급업체에 관계없이 다양한 컨테이너 오케스트레이션 시스템에서 스토리지가 균일하게 작동합니다. CSI에 대한 자세한 내용은 CSI(Container Storage Interface) 사용을 참조하십시오.

1.4. 동적 프로비저닝

동적 프로비저닝을 사용하면 필요에 따라 스토리지 볼륨을 생성할 수 있으므로 클러스터 관리자가 스토리지를 미리 프로비저닝할 필요가 없습니다. 동적 프로비저닝에 대한 자세한 내용은 동적 프로비저닝을 참조하세요.

2장. 임시 스토리지 이해

2.1. 개요

영구 스토리지 외에도 Pod 및 컨테이너는 작업을 위해 임시 또는 임시 로컬 스토리지가 필요할 수 있습니다. 이러한 임시 스토리지의 수명은 개별 Pod의 수명 이상으로 연장되지 않으며 이 임시 스토리지는 여러 Pod 사이에서 공유할 수 없습니다.

Pod는 스크래치 공간, 캐싱 및 로그를 위해 임시 로컬 스토리지를 사용합니다. 로컬 스토리지 회계 및 격리 부족과 관련한 문제는 다음과 같습니다.

  • Pod는 사용 가능한 로컬 저장소의 용량을 감지할 수 없습니다.
  • Pod는 보장되는 로컬 스토리지를 요청할 수 없습니다.
  • 로컬 스토리지는 최선의 노력을 기울이는 리소스입니다.
  • 로컬 저장소가 다른 Pod로 채워지면 Pod가 퇴출될 수 있으며, 그 후에는 충분한 저장소가 회수될 때까지 새로운 Pod가 허용되지 않습니다.

영구 볼륨에 대해 임시 스토리지는 구조화되지 않으며 시스템에서 실행되는 모든 Pod와 시스템, 컨테이너 런타임 및 OpenShift Container Platform의 다른 사용에서 공간을 공유합니다. 임시 스토리지 프레임워크를 사용하면 Pod에서 일시적인 로컬 스토리지 요구를 지정할 수 있습니다. 또한, OpenShift Container Platform은 적절한 Pod를 예약하고 로컬 스토리지를 과도하게 사용하지 않도록 노드를 보호할 수 있습니다.

임시 저장소 프레임워크를 사용하면 관리자와 개발자가 로컬 저장소를 보다 효과적으로 관리할 수 있지만 I/O 처리량과 지연 시간은 직접적인 영향을 받지 않습니다.

2.2. 임시 스토리지 유형

임시 로컬 스토리지는 항상 기본 파티션에서 사용할 수 있습니다. 기본 파티션을 생성하는 방법에는 루트 및 런타임이라는 두 가지 기본적인 방법이 있습니다.

루트

이 파티션에는 기본적으로 kubelet 루트 디렉터리인 /var/lib/kubelet//var/log/ 디렉터리가 있습니다. 이 파티션은 사용자 Pod, OS, Kubernetes 시스템 데몬 간에 공유할 수 있습니다. 이 파티션은 EmptyDir 볼륨, 컨테이너 로그, 이미지 계층 및 container-wriable 계층을 통해 Pod에서 사용할 수 있습니다. kubelet은 이 파티션의 공유 액세스 및 격리를 관리합니다. 이 파티션은 임시입니다. 애플리케이션은 이 파티션에서 디스크 IOPS와 같은 성능 SLA를 기대할 수 없습니다.

런타임

런타임에서 오버레이 파일 시스템에 사용할 수 있는 선택적 파티션입니다. OpenShift Container Platform에서는 이 파티션에 대한 격리와 함께 공유 액세스를 식별하고 제공합니다. 컨테이너 이미지 계층 및 쓰기 가능한 계층이 여기에 저장됩니다. 런타임 파티션이 있는 경우 루트 파티션은 이미지 계층 또는 기타 쓰기 가능한 스토리지를 유지하지 않습니다.

2.3. 임시 데이터 스토리지 관리

클러스터 관리자는 비종료 상태의 모든 Pod에서 임시 스토리지에 대한 제한 범위 및 요청 수를 정의하는 할당량을 설정하여 프로젝트 내에서 임시 스토리지를 관리할 수 있습니다. 개발자는 Pod 및 컨테이너 수준에서 이러한 컴퓨팅 리소스에 대한 요청 및 제한을 설정할 수도 있습니다.

요청과 제한을 지정하여 로컬 임시 저장소를 관리할 수 있습니다. Pod의 각 컨테이너는 다음을 지정할 수 있습니다.

  • spec.containers[].resources.limits.ephemeral-storage
  • spec.containers[].resources.requests.ephemeral-storage

2.3.1. 임시 저장 한도 및 요청 단위

임시 저장소에 대한 제한과 요청은 바이트 수량으로 측정됩니다. 다음 접미사 중 하나를 사용하여 저장을 일반 정수 또는 고정 소수점 숫자로 표현할 수 있습니다: E, P, T, G, M, k. 2의 거듭제곱을 사용할 수도 있습니다: Ei, Pi, Ti, Gi, Mi, Ki.

예를 들어 다음 양은 모두 1289748, 129e6, 129M 및 123Mi의 약 동일한 값을 나타냅니다.

중요

각 바이트 수량에 대한 접미사는 대소문자를 구분합니다. 반드시 올바른 대소문자를 사용하세요. 대소문자를 구분하는 "M"을 사용하세요(예: "400M"). 이렇게 하면 요청을 400메가바이트로 설정할 수 있습니다. 400메비바이트를 요청하려면 대소문자를 구분하여 "400Mi"를 사용하세요. 임시 저장소로 "400m"을 지정하면 저장소 요청은 0.4바이트에 불과합니다.

2.3.2. 임시 저장소 요청 및 제한 예

다음 예제 구성 파일은 두 개의 컨테이너가 있는 포드를 보여줍니다.

  • 각 컨테이너는 2GiB의 로컬 임시 저장소를 요청합니다.
  • 각 컨테이너에는 로컬 임시 저장소의 제한이 4GiB입니다.
  • 포드 수준에서 kubelet은 해당 포드에 있는 모든 컨테이너의 한도를 더하여 전체 포드 저장 한도를 계산합니다.

    • 이 경우, 포드 수준의 총 스토리지 사용량은 모든 컨테이너의 디스크 사용량과 포드의 emptyDir 볼륨의 합계입니다.
    • 따라서 포드는 로컬 임시 저장소에 4GiB를 요청하고 로컬 임시 저장소에 8GiB의 제한을 갖습니다.

할당량 및 제한이 있는 임시 저장소 구성의 예

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 
1

      limits:
        ephemeral-storage: "4Gi" 
2

    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}
Copy to Clipboard Toggle word wrap

1
로컬 임시 저장소에 대한 컨테이너 요청입니다.
2
로컬 임시 저장소에 대한 컨테이너 제한입니다.

2.3.3. 임시 스토리지 구성 효과 Pod 예약 및 제거

Pod 사양의 설정은 스케줄러가 Pod 스케줄링을 결정하는 방식과 kubelet이 Pod를 제거하는 시점에 모두 영향을 미칩니다.

  • 첫째, 스케줄러는 스케줄된 컨테이너의 리소스 요청 합계가 노드의 용량보다 작도록 보장합니다. 이 경우, 노드의 사용 가능한 임시 저장소(할당 가능한 리소스)가 4GiB 이상인 경우에만 포드를 노드에 할당할 수 있습니다.
  • 두 번째로, 컨테이너 수준에서 첫 번째 컨테이너가 리소스 제한을 설정했기 때문에 Kubelet 추방 관리자는 이 컨테이너의 디스크 사용량을 측정하고 컨테이너의 저장 사용량이 제한(4GiB)을 초과하면 Pod를 추방합니다. kubelet 추방 관리자는 전체 사용량이 전체 Pod 저장 용량 한도(8GiB)를 초과하는 경우에도 해당 Pod를 추방 대상으로 표시합니다.

프로젝트에 대한 할당량 정의에 대한 자세한 내용은 프로젝트별 할당량 설정을 참조하세요.

2.4. 임시 스토리지 모니터링

/bin/df를 임시 컨테이너 데이터가 위치하는 볼륨에서 임시 스토리지의 사용을 모니터링하는 도구를 사용할 수 있으며, 이는 /var/lib/kubelet/var/lib/containers입니다. 클러스터 관리자가 /var/lib/containers를 별도의 디스크에 배치한 경우에는 df 명령을 사용하여 /var/lib/kubelet에서 전용으로 사용할 수 있는 공간을 표시할 수 있습니다.

/var/lib에서 사용된 공간 및 사용할 수 있는 공간을 사람이 읽을 수 있는 값으로 표시하려면 다음 명령을 입력합니다.

$ df -h /var/lib
Copy to Clipboard Toggle word wrap

출력에는 /var/lib에서의 임시 스토리지 사용량이 표시됩니다.

출력 예

Filesystem  Size  Used Avail Use% Mounted on
/dev/disk/by-partuuid/4cd1448a-01    69G   32G   34G  49% /
Copy to Clipboard Toggle word wrap

3장. 영구 스토리지 이해

3.1. 영구 스토리지 개요

스토리지 관리는 컴퓨팅 리소스 관리와 다릅니다. OpenShift Container Platform에서는 Kubernetes PV(영구 볼륨) 프레임워크를 사용하여 클러스터 관리자가 클러스터의 영구 스토리지를 프로비저닝할 수 있습니다. 개발자는 PVC(영구 볼륨 클레임)를 사용하여 기본 스토리지 인프라를 구체적으로 잘 몰라도 PV 리소스를 요청할 수 있습니다.

PVC는 프로젝트별로 고유하며 PV를 사용하는 방법과 같이 개발자가 생성 및 사용할 수 있습니다. 자체 PV 리소스는 단일 프로젝트로 범위가 지정되지 않으며, 전체 OpenShift Container Platform 클러스터에서 공유되고 모든 프로젝트에서 요청할 수 있습니다. PV가 PVC에 바인딩된 후에는 해당 PV를 다른 PVC에 바인딩할 수 없습니다. 이는 바인딩 프로젝트인 단일 네임스페이스로 바인딩된 PV의 범위를 지정하는 효과가 있으며, 이는 바인딩된 프로젝트의 범위가 됩니다.

PV는 PersistentVolume API 오브젝트로 정의되면, 이는 클러스터 관리자가 정적으로 프로비저닝하거나 StorageClass 오브젝트를 사용하여 동적으로 프로비저닝한 클러스터에서의 기존 스토리지 조각을 나타냅니다. 그리고 노드가 클러스터 리소스인 것과 마찬가지로 클러스터의 리소스입니다.

PV는 Volumes과 같은 볼륨 플러그인이지만 PV를 사용하는 개별 Pod와는 독립적인 라이프사이클이 있습니다. PV 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템에서 스토리지 구현의 세부 정보를 캡처합니다.

중요

인프라의 스토리지의 고가용성은 기본 스토리지 공급자가 담당합니다.

PVC는 PersistentVolumeClaim API 오브젝트에 의해 정의되며, 개발자의 스토리지 요청을 나타냅니다. Pod는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용하는 점에서 Pod와 유사합니다. 예를 들어, Pod는 CPU 및 메모리와 같은 특정 리소스를 요청할 수 있지만 PVC는 특정 스토리지 용량 및 액세스 모드를 요청할 수 있습니다. 예를 들어, Pod는 1회 읽기-쓰기 또는 여러 번 읽기 전용으로 마운트될 수 있습니다.

3.2. 볼륨 및 클레임의 라이프사이클

PV는 클러스터의 리소스입니다. PVC는 그러한 리소스에 대한 요청이며, 리소스에 대한 클레임을 검사하는 역할을 합니다. PV와 PVC 간의 상호 작용에는 다음과 같은 라이프사이클이 있습니다.

3.2.1. 스토리지 프로비저닝

PVC에 정의된 개발자의 요청에 대한 응답으로 클러스터 관리자는 스토리지 및 일치하는 PV를 프로비저닝하는 하나 이상의 동적 프로비저너를 구성합니다.

다른 방법으로 클러스터 관리자는 사용할 수 있는 실제 스토리지의 세부 정보를 전달하는 여러 PV를 사전에 생성할 수 있습니다. PV는 API에 위치하며 사용할 수 있습니다.

3.2.2. 클레임 바인딩

PVC를 생성할 때 스토리지의 특정 용량을 요청하고, 필요한 액세스 모드를 지정하며, 스토리지를 설명 및 분류하는 스토리지 클래스를 만듭니다. 마스터의 제어 루프는 새 PVC를 감시하고 새 PVC를 적절한 PV에 바인딩합니다. 적절한 PV가 없으면 스토리지 클래스를 위한 프로비저너가 PV를 1개 생성합니다.

전체 PV의 크기는 PVC 크기를 초과할 수 있습니다. 이는 특히 수동으로 프로비저닝된 PV의 경우 더욱 그러합니다. 초과를 최소화하기 위해 OpenShift Container Platform은 기타 모든 조건과 일치하는 최소 PV로 바인딩됩니다.

일치하는 볼륨이 없거나 스토리지 클래스에 서비스를 제공하는 사용할 수 있는 프로비저너로 생성할 수 없는 경우 클레임은 영구적으로 바인딩되지 않습니다. 일치하는 볼륨을 사용할 수 있을 때 클레임이 바인딩됩니다. 예를 들어, 수동으로 프로비저닝된 50Gi 볼륨이 있는 클러스터는 100Gi 요청하는 PVC와 일치하지 않습니다. 100Gi PV가 클러스터에 추가되면 PVC를 바인딩할 수 있습니다.

3.2.3. Pod 및 클레임된 PV 사용

Pod는 클레임을 볼륨으로 사용합니다. 클러스터는 클레임을 검사하여 바인딩된 볼륨을 찾고 Pod에 해당 볼륨을 마운트합니다. 여러 액세스 모드를 지원하는 그러한 볼륨의 경우 Pod에서 클레임을 볼륨으로 사용할 때 적용되는 모드를 지정해야 합니다.

클레임이 있고 해당 클레임이 바인딩되면, 바인딩된 PV는 필요한 동안 사용자의 소유가 됩니다. Pod의 볼륨 블록에 persistentVolumeClaim을 포함하여 Pod를 예약하고 클레임된 PV에 액세스할 수 있습니다.

참고

파일 수가 많은 영구 볼륨을 포드에 연결하면 해당 포드가 실패하거나 시작하는 데 시간이 오래 걸릴 수 있습니다. 자세한 내용은 OpenShift에서 파일 수가 많은 영구 볼륨을 사용할 때 포드가 시작되지 않거나 "준비" 상태에 도달하는 데 지나치게 오랜 시간이 걸리는 이유는 무엇입니까?를 참조하세요.

3.2.4. 사용 중 스토리지 오브젝트 보호

사용 중 스토리지 오브젝트 보호 기능은 Pod에서 사용 중인 PVC와 PVC에 바인딩된 PC가 시스템에서 제거되지 않도록 합니다. 제거되면 데이터가 손실될 수 있습니다.

사용 중 스토리지 오브젝트 보호는 기본적으로 활성화됩니다.

참고

PVC를 사용하는 Pod 오브젝트가 존재하는 경우 PVC는 Pod에 의해 활성 사용 중이 됩니다.

사용자가 Pod에서 활성 사용 중인 PVC를 삭제하면 PVC가 즉시 제거되지 않습니다. 모든 Pod에서 PVC를 더 이상 활성 사용하지 않을 때까지 PVC의 제거가 연기됩니다. 또한, 클러스터 관리자가 PVC에 바인딩된 PV를 삭제하는 경우에도 PV가 즉시 제거되지 않습니다. PV가 더 이상 PVC에 바인딩되지 않을 때까지 PV 제거가 연기됩니다.

3.2.5. 영구 볼륨 해제

볼륨 사용 작업이 끝나면 API에서 PVC 오브젝트를 삭제하여 리소스를 회수할 수 있습니다. 클레임이 삭제되었지만 다른 클레임에서 아직 사용할 수 없을 때 볼륨은 해제된 것으로 간주됩니다. 이전 클레임의 데이터는 볼륨에 남아 있으며 정책에 따라 처리되어야 합니다.

3.2.6. 영구 볼륨 회수 정책

영구 볼륨 회수 정책은 해제된 볼륨에서 수행할 작업을 클러스터에 명령합니다. 볼륨 회수 정책은 Retain, Recycle 또는 Delete일 수 있습니다.

  • Retain 정책을 유지하면 이를 지원하는 해당 볼륨 플러그인에 대한 리소스를 수동으로 회수할 수 있습니다.
  • Recycle 회수 정책은 볼륨이 클레임에서 해제되면 바인딩되지 않은 영구 볼륨 풀로 다시 재활용합니다.
중요

OpenShift Container Platform 4에서는 Recycle 회수 정책이 사용되지 않습니다. 기능을 향상하기 위해 동적 프로비저닝이 권장됩니다.

  • 회수 정책 삭제는 OpenShift Container Platform의 PersistentVolume 개체와 Amazon Elastic Block Store(Amazon EBS) 또는 VMware vSphere와 같은 외부 인프라의 관련 스토리지 자산을 모두 삭제합니다.
참고

동적으로 프로비저닝된 볼륨은 항상 삭제됩니다.

3.2.7. 수동으로 영구 볼륨 회수

PVC(영구 볼륨 클레임)가 삭제되어도 PV(영구 볼륨)는 계속 존재하며 "해제됨"으로 간주됩니다. 그러나 이전 클레임의 데이터가 볼륨에 남아 있으므로 다른 클레임에서 PV를 아직 사용할 수 없습니다.

절차

클러스터 관리자로 PV를 수동으로 회수하려면 다음을 수행합니다.

  1. 다음 명령을 실행하여 PV를 삭제합니다.

    $ oc delete pv <pv_name>
    Copy to Clipboard Toggle word wrap

    AWS EBS, GCE PD, Azure Disk 또는 Cinder 볼륨과 같은 외부 인프라의 연결된 스토리지 자산은 PV가 삭제된 후에도 계속 존재합니다.

  2. 연결된 스토리지 자산에서 데이터를 정리합니다.
  3. 연결된 스토리지 자산을 삭제합니다. 대안으로, 동일한 스토리지 자산을 재사용하려면, 스토리지 자산 정의를 사용하여 새 PV를 생성합니다.

이제 회수된 PV를 다른 PVC에서 사용할 수 있습니다.

3.2.8. 영구 볼륨의 회수 정책 변경

영구 볼륨의 회수 정책을 변경하려면 다음을 수행합니다.

  1. 클러스터의 영구 볼륨을 나열합니다.

    $ oc get pv
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
     pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
     pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
     pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3    manual                     3s
    Copy to Clipboard Toggle word wrap

  2. 영구 볼륨 중 하나를 선택하고 다음과 같이 회수 정책을 변경합니다.

    $ oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
    Copy to Clipboard Toggle word wrap
  3. 선택한 영구 볼륨에 올바른 정책이 있는지 확인합니다.

    $ oc get pv
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
     pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
     pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
     pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3    manual                     3s
    Copy to Clipboard Toggle word wrap

    이전 출력에서 default/claim3 클레임에 바인딩된 볼륨이 이제 Retain 회수 정책을 갖습니다. 사용자가 default/claim3 클레임을 삭제할 때 볼륨이 자동으로 삭제되지 않습니다.

3.3. PV(영구 볼륨)

각 PV에는 사양상태가 포함됩니다. 이는 볼륨의 사양과 상태이고 예는 다음과 같습니다.

PersistentVolume 오브젝트 정의 예

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 
1

spec:
  capacity:
    storage: 5Gi 
2

  accessModes:
    - ReadWriteOnce 
3

  persistentVolumeReclaimPolicy: Retain 
4

  ...
status:
  ...
Copy to Clipboard Toggle word wrap

1
영구 볼륨의 이름입니다.
2
볼륨에서 사용할 수 있는 스토리지의 용량입니다.
3
읽기-쓰기 및 마운트 권한을 정의하는 액세스 모드입니다.
4
해제된 후 리소스를 처리하는 방법을 나타내는 회수 정책입니다.

다음 명령을 실행하면 PV에 바인딩된 PVC의 이름을 볼 수 있습니다.

$ oc get pv <pv_name> -o jsonpath='{.spec.claimRef.name}'
Copy to Clipboard Toggle word wrap

3.3.1. PV 유형

OpenShift Container Platform은 다음과 같은 영구 볼륨 플러그인을 지원합니다.

  • 기본적으로 설치되는 AWS Elastic Block Store(EBS).
  • AWS Elastic File Store(EFS)
  • Azure Disk
  • Azure File
  • Cinder
  • 파이버 채널
  • GCP 영구 디스크
  • GCP 파일스토어
  • IBM Power Virtual Server Block
  • IBM Cloud® VPC Block
  • HostPath
  • iSCSI
  • 로컬 볼륨
  • NFS
  • OpenStack Manila
  • Red Hat OpenShift Data Foundation
  • CIFS/SMB
  • VMware vSphere

3.3.2. 용량

일반적으로 PV(영구 볼륨)에는 특정 스토리지 용량이 있습니다. 이는 PV의 용량 속성을 사용하여 설정됩니다.

현재는 스토리지 용량이 설정 또는 요청할 수 있는 유일한 리소스뿐입니다. 향후 속성에는 IOPS, 처리량 등이 포함될 수 있습니다.

3.3.3. 액세스 모드

영구 볼륨은 리소스 공급자가 지원하는 방식으로 호스트에 볼륨을 마운트될 수 있습니다. 공급자에 따라 기능이 다르며 각 PV의 액세스 모드는 해당 볼륨에서 지원하는 특정 모드로 설정됩니다. 예를 들어, NFS에서는 여러 읽기-쓰기 클라이언트를 지원할 수 있지만 특정 NFS PV는 서버에서 읽기 전용으로 내보낼 수 있습니다. 각 PV는 특정 PV의 기능을 설명하는 자체 액세스 모드 세트를 가져옵니다.

클레임은 액세스 모드가 유사한 볼륨과 매칭됩니다. 유일하게 일치하는 두 가지 기준은 액세스 모드와 크기입니다. 클레임의 액세스 모드는 요청을 나타냅니다. 따라서 더 많이 부여될 수 있지만 절대로 부족하게는 부여되지 않습니다. 예를 들어, 클레임 요청이 RWO이지만 사용 가능한 유일한 볼륨이 NFS PV(RWO+ROX+RWX)인 경우, RWO를 지원하므로 클레임이 NFS와 일치하게 됩니다.

항상 직접 일치가 먼저 시도됩니다. 볼륨의 모드는 사용자의 요청과 일치하거나 더 많은 모드를 포함해야 합니다. 크기는 예상되는 크기보다 크거나 같아야 합니다. NFS 및 iSCSI와 같은 두 개의 볼륨 유형에 동일한 액세스 모드 세트가 있는 경우 둘 중 하나를 해당 모드와 클레임과 일치시킬 수 있습니다. 볼륨 유형과 특정 유형을 선택할 수 있는 순서는 없습니다.

모드가 동일한 모든 볼륨이 그룹화된 후 크기 오름차순으로 크기가 정렬됩니다. 바인더는 모드가 일치하는 그룹을 가져온 후 크기가 일치하는 그룹을 찾을 때까지 크기 순서대로 각 그룹에 대해 반복합니다.

중요

볼륨 액세스 모드는 볼륨 기능을 설명합니다. 제한 조건이 적용되지 않습니다. 리소스를 잘못된 사용으로 인한 런타임 오류는 스토리지 공급자가 처리합니다. 공급자에서의 오류는 런타임 시 마운트 오류로 표시됩니다.

예를 들어, NFS는 ReadWriteOnce 액세스 모드를 제공합니다. 볼륨의 ROX 기능을 사용하려면 클레임을 ReadOnlyMany 로 표시합니다.

iSCSI 및 파이버 채널 볼륨은 현재 펜싱 메커니즘을 지원하지 않습니다. 볼륨을 한 번에 하나씩만 사용하는지 확인해야 합니다. 노드 드레이닝과 같은 특정 상황에서는 두 개의 노드에서 볼륨을 동시에 사용할 수 있습니다. 노드를 비우기 전에 볼륨을 사용하는 포드를 삭제합니다.

다음 표에는 액세스 모드가 나열되어 있습니다.

Expand
표 3.1. 액세스 모드
액세스 모드CLI 약어설명

ReadWriteOnce

RWO

볼륨은 단일 노드에서 읽기-쓰기로 마운트할 수 있습니다.

ReadWriteOncePod [1]

RWOP

볼륨은 단일 노드의 단일 포드에 의해 읽기-쓰기로 마운트될 수 있습니다.

ReadOnlyMany

ROX

볼륨은 여러 노드에서 읽기 전용으로 마운트할 수 있습니다.

ReadWriteMany

RWX

볼륨은 여러 노드에서 읽기-쓰기로 마운트할 수 있습니다.

  1. RWOP는 SELinux 마운트 기능을 사용합니다. 이 기능은 드라이버에 따라 달라지며 AWS EBS, Azure Disk, GCP PD, IBM Cloud Block Storage 볼륨, Cinder, vSphere 및 Red Hat OpenShift Data Foundation에서 기본적으로 활성화되어 있습니다. 타사 드라이버의 경우 스토리지 공급업체에 문의하세요.
Expand
표 3.2. 영구 볼륨에 지원되는 액세스 모드
볼륨 플러그인ReadWriteOnce [1]ReadWriteOncePodReadOnlyManyReadWriteMany

AWS EBS [2]

 ✅

 ✅

AWS EFS

 ✅

 ✅

 ✅

 ✅

Azure File

 ✅

 ✅

 ✅

Azure Disk

 ✅

 ✅

CIFS/SMB

 ✅

 ✅

 ✅

 ✅

Cinder

 ✅

 ✅

파이버 채널

 ✅

 ✅

  ✅ [3]

GCP 영구 디스크

 ✅ [4]

 ✅

 ✅ [4]

GCP 파일스토어

 ✅

 ✅

 ✅

HostPath

 ✅

IBM Power Virtual Server 디스크

 ✅

 ✅

  ✅

IBM Cloud® VPC 디스크

 ✅

iSCSI

 ✅

 ✅

  ✅ [3]

로컬 볼륨

 ✅

LVM 스토리지

 ✅

 ✅

NFS

 ✅

 ✅

 ✅

OpenStack Manila

 ✅

Red Hat OpenShift Data Foundation

 ✅

 ✅

VMware vSphere

 ✅

  ✅ [5]

  1. ReadWriteOnce(RWO) 볼륨은 여러 노드에 마운트할 수 없습니다. 시스템이 이미 실패한 노드에 할당되어 있기 때문에, 노드가 실패하면 시스템은 연결된 RWO 볼륨을 새 노드에 마운트하는 것을 허용하지 않습니다. 이로 인해 다중 연결 오류 메시지가 표시되면 동적 영구 볼륨이 연결된 경우와 같이 중요한 워크로드에서의 데이터가 손실되는 것을 방지하기 위해 종료되거나 충돌이 발생한 노드에서 Pod를 삭제해야 합니다.
  2. AWS EBS 기반 Pod에 재생성 배포 전략을 사용합니다.
  3. 원시 블록 볼륨만이 파이버 채널 및 iSCSI에 대한 ReadWriteMany (RWX) 액세스 모드를 지원합니다. 자세한 내용은 "블록 볼륨 지원"을 참조하세요.
  4. GCP 하이퍼디스크 균형 디스크의 경우:

    • 지원되는 액세스 모드는 다음과 같습니다.

      • ReadWriteOnce
      • ReadWriteMany
    • ReadWriteMany 액세스 모드가 활성화된 디스크의 경우 복제 및 스냅샷 기능이 비활성화됩니다.
    • ReadWriteMany 에서 단일 하이퍼디스크 균형 디스크 볼륨을 최대 8개의 인스턴스에 연결할 수 있습니다.
    • ReadWriteMany 에서 디스크 크기를 조정하려면 모든 인스턴스에서 디스크를 분리해야 합니다.
    • 추가적인 제한 사항 .
  5. 기본 vSphere 환경이 vSAN 파일 서비스를 지원하는 경우 OpenShift Container Platform에서 설치한 vSphere Container Storage Interface(CSI) Driver Operator는 RWX(ReadWriteMany) 볼륨의 프로비저닝을 지원합니다. vSAN 파일 서비스가 구성되어 있지 않고 RWX를 요청하면 볼륨이 생성되지 않고 오류가 기록됩니다. 자세한 내용은 "컨테이너 스토리지 인터페이스 사용" → "VMware vSphere CSI 드라이버 운영자"를 참조하세요.

3.3.4. 단계

볼륨은 다음 단계 중 하나에서 찾을 수 있습니다.

Expand
표 3.3. 볼륨 단계
단계설명

Available

아직 클레임에 바인딩되지 않은 여유 리소스입니다.

Bound

볼륨이 클레임에 바인딩됩니다.

해제됨

클레임이 삭제되었지만, 리소스가 아직 클러스터에 의해 회수되지 않았습니다.

실패

볼륨에서 자동 회수가 실패했습니다.

3.3.4.1. 마지막 단계 전환 시간

LastPhaseTransitionTime 필드에는 지속적 볼륨(PV)이 다른 단계( pv.Status.Phase )로 전환될 때마다 업데이트되는 타임스탬프가 있습니다. PV의 마지막 단계 전환 시간을 찾으려면 다음 명령을 실행하세요.

$ oc get pv <pv_name> -o json | jq '.status.lastPhaseTransitionTime' 
1
Copy to Clipboard Toggle word wrap
1
마지막 단계 전환을 보고 싶은 PV의 이름을 지정하세요.
3.3.4.2. 마운트 옵션

mountOptions 속성을 사용하여 PV를 마운트하는 동안 마운트 옵션을 지정할 수 있습니다.

예를 들면 다음과 같습니다.

마운트 옵션 예

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: 
1

    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default
Copy to Clipboard Toggle word wrap

1
지정된 마운트 옵션이 PV를 디스크에 마운트하는 동안 사용됩니다.

다음 PV 유형에서는 마운트 옵션을 지원합니다.

  • AWS Elastic Block Store (EBS)
  • AWS 탄력적 파일 스토리지(EFS)
  • Azure Disk
  • Azure File
  • Cinder
  • GCE 영구 디스크
  • iSCSI
  • 로컬 볼륨
  • NFS
  • Red Hat OpenShift Data Foundation(Ceph RBD만 해당)
  • CIFS/SMB
  • VMware vSphere
참고

파이버 채널 및 HostPath PV는 마운트 옵션을 지원하지 않습니다.

3.4. 영구 볼륨 클레임

PersistentVolumeClaim 오브젝트에는 specstatus가 포함되며, 이는 PVC(영구 볼륨 클레임)의 사양과 상태이고, 예를 들면 다음과 같습니다.

PersistentVolumeClaim 오브젝트 정의 예

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim 
1

spec:
  accessModes:
    - ReadWriteOnce 
2

  resources:
    requests:
      storage: 8Gi 
3

  storageClassName: gold 
4

status:
  ...
Copy to Clipboard Toggle word wrap

1
PVC의 이름입니다.
2
읽기-쓰기 및 마운트 권한을 정의하는 액세스 모드입니다.
3
PVC에서 사용할 수 있는 스토리지 용량입니다.
4
클레임에 필요한 StorageClass 의 이름입니다.

3.4.1. 스토리지 클래스

선택 사항으로 클레임은 storageClassName 속성에 스토리지 클래스의 이름을 지정하여 특정 스토리지 클래스를 요청할 수 있습니다. PVC와 storageClassName이 동일하고 요청된 클래스의 PV만 PVC에 바인딩할 수 있습니다. 클러스터 관리자는 동적 프로비저너를 구성하여 하나 이상의 스토리지 클래스에 서비스를 제공할 수 있습니다. 클러스터 관리자는 PVC의 사양과 일치하는 PV를 생성할 수 있습니다.

중요

클러스터 스토리지 작업자는 사용 중인 플랫폼에 따라 기본 스토리지 클래스를 설치할 수 있습니다. 이 스토리지 클래스는 Operator가 소유하고 제어합니다. 주석 및 레이블 정의 외에는 삭제하거나 변경할 수 없습니다. 다른 동작이 필요한 경우 사용자 정의 스토리지 클래스를 정의해야 합니다.

클러스터 관리자는 모든 PVC의 기본 스토리지 클래스도 설정할 수도 있습니다. 기본 스토리지 클래스가 구성된 경우 PVC는 ""로 설정된 StorageClass 또는 storageClassName 주석이 스토리지 클래스를 제외하고 PV에 바인딩되도록 명시적으로 요청해야 합니다.

참고

두 개 이상의 스토리지 클래스가 기본값으로 표시되면 storageClassName이 명시적으로 지정된 경우에만 PVC를 생성할 수 있습니다. 따라서 1개의 스토리지 클래스만 기본값으로 설정해야 합니다.

3.4.2. 액세스 모드

클레임은 특정 액세스 모드로 스토리지를 요청할 때 볼륨과 동일한 규칙을 사용합니다.

3.4.3. 리소스

Pod와 같은 클레임은 특정 리소스 수량을 요청할 수 있습니다. 이 경우 요청은 스토리지에 대한 요청입니다. 동일한 리소스 모델이 볼륨 및 클레임에 적용됩니다.

3.4.4. 클레임을 볼륨으로

클레임을 볼륨으로 사용하여 Pod 액세스 스토리지 클레임은 클레임을 사용하는 포드와 동일한 네임스페이스에 존재해야 합니다. 클러스터는 Pod의 네임스페이스에서 클레임을 검색하고 이를 사용하여 클레임을 지원하는 PersistentVolume을 가져옵니다. 볼륨은 호스트에 마운트되며, 예를 들면 다음과 같습니다.

호스트 및 Pod에 볼륨 마운트 예

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" 
1

        name: mypd 
2

  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim 
3
Copy to Clipboard Toggle word wrap

1
Pod 내부에 볼륨을 마운트하는 경로입니다.
2
마운트할 볼륨의 이름입니다. 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너가 호스트 /dev/pts 파일과 같이 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다.
3
동일한 네임스페이스에 있는 사용할 PVC의 이름입니다.

3.4.5. PVC 사용 통계 보기

영구 볼륨 클레임(PVC)에 대한 사용 통계를 볼 수 있습니다.

중요

PVC 사용 통계 명령은 기술 미리보기 기능일 뿐입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

3.4.5.1. PVC 사용 통계를 보려면 사용자 권한이 필요합니다.

PVC 사용 통계를 보려면 필요한 권한이 있어야 합니다.

필요한 권한으로 로그인하려면:

  • 관리자 권한이 있는 경우 관리자로 로그인하세요.
  • 관리자 권한이 없는 경우:

    1. 다음 명령을 실행하여 클러스터 역할을 만들고 사용자에게 추가하세요.

      $ oc create clusterrole routes-view --verb=get,list --resource=routes
      $ oc adm policy add-cluster-role-to-user routes-view <user-name> 
      1
      
      $ oc adm policy add-cluster-role-to-user cluster-monitoring-view <user-name> 
      2
      Copy to Clipboard Toggle word wrap
      1 2
      사용자의 이름.
3.4.5.2. PVC 사용 통계 보기
  • 클러스터 전체의 통계를 보려면 다음 명령을 실행하세요.

    $ oc adm top pvc -A
    Copy to Clipboard Toggle word wrap

    예제 명령 출력

    NAMESPACE     NAME         USAGE(%)
    namespace-1   data-etcd-1  3.82%
    namespace-1   data-etcd-0  3.81%
    namespace-1   data-etcd-2  3.81%
    namespace-2   mypvc-fs-gp3 0.00%
    default       mypvc-fs     98.36%
    Copy to Clipboard Toggle word wrap

  • 지정된 네임스페이스에 대한 PVC 사용 통계를 보려면 다음 명령을 실행하세요.

    $ oc adm top pvc -n <namespace-name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <네임스페이스 이름> 은 지정된 네임스페이스의 이름입니다.

    예제 명령 출력

    NAMESPACE     NAME        USAGE(%)
    namespace-1   data-etcd-2 3.81% 
    1
    
    namespace-1   data-etcd-0 3.81%
    namespace-1   data-etcd-1 3.82%
    Copy to Clipboard Toggle word wrap

    1
    이 예에서 지정된 네임스페이스는 namespace-1 입니다.
  • 지정된 PVC와 지정된 네임스페이스에 대한 사용 통계를 보려면 다음 명령을 실행하세요.

    $ oc adm top pvc <pvc-name> -n <namespace-name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    여기서 <pvc-name> 은 지정된 PVC의 이름이고 <namespace-name>은 지정된 네임스페이스의 이름입니다.

    예제 명령 출력

    NAMESPACE   NAME        USAGE(%)
    namespace-1 data-etcd-0 3.81% 
    1
    Copy to Clipboard Toggle word wrap

    1
    이 예에서 지정된 네임스페이스는 namespace-1 이고 지정된 PVC는 data-etcd-0 입니다.

3.4.6. 볼륨 속성 클래스

볼륨 속성 클래스는 관리자가 제공하는 저장소 "클래스"를 설명할 수 있는 방법을 제공합니다. 다양한 클래스는 다양한 서비스 품질 수준에 해당할 수 있습니다.

중요

볼륨 속성 클래스는 기술 미리 보기 기능일 뿐입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OpenShift Container Platform의 볼륨 속성 클래스는 AWS Elastic Block Storage(EBS) 및 Google Cloud Platform(GCP) 영구 디스크(PD) 컨테이너 스토리지 인터페이스(CSI)에서만 사용할 수 있습니다.

영구 볼륨 클레임(PVC)에 볼륨 속성 클래스를 적용할 수 있습니다. 클러스터에서 새로운 볼륨 속성 클래스를 사용할 수 있게 되면 사용자는 필요에 따라 새로운 볼륨 속성 클래스로 PVC를 업데이트할 수 있습니다.

볼륨 속성 클래스에는 해당 클래스에 속한 볼륨을 설명하는 매개변수가 있습니다. 매개변수를 생략하면 볼륨 프로비저닝 시 기본값이 사용됩니다. 매개변수가 생략된 다른 볼륨 속성 클래스로 PVC를 적용하는 경우 CSI 드라이버 구현에 따라 매개변수의 기본값이 사용될 수 있습니다. 자세한 내용은 관련 CSI 드라이버 문서를 참조하세요.

3.4.6.1. 제한

볼륨 속성 클래스에는 다음과 같은 제한 사항이 있습니다.

  • GCP PD를 사용하면 볼륨 속성 클래스를 사용한 볼륨 수정은 하이퍼디스크 균형 디스크 유형에만 가능합니다.
  • VolumeAttributesClass 에 대해 정의할 수 있는 매개변수는 최대 512개입니다.
  • 키와 값을 포함한 매개변수 객체의 총 길이는 256KiB를 초과할 수 없습니다.
  • PVC에 볼륨 속성 클래스를 적용하는 경우 해당 PVC에 적용된 볼륨 속성 클래스를 변경할 수 있지만 PVC에서 삭제할 수는 없습니다. PVC에서 볼륨 속성 클래스를 삭제하려면 PVC를 삭제한 다음 PVC를 다시 만들어야 합니다.
  • 볼륨 속성 클래스 매개변수는 편집할 수 없습니다. Volume Attributes Class 매개변수를 변경해야 하는 경우 원하는 매개변수를 사용하여 새 Volume Attributes Class를 생성한 다음 PVC에 적용합니다.
3.4.6.2. 볼륨 속성 클래스 활성화

볼륨 속성 클래스는 기본적으로 활성화되어 있지 않습니다.

볼륨 속성 클래스를 활성화하려면 FeatureGates를 사용하여 OpenShift Container Platform 기능 활성화 섹션의 절차를 따르십시오.

3.4.6.3. 볼륨 속성 클래스 정의

다음은 AWS EBS의 Volume Attributes Class YAML 파일의 예입니다.

VolumeAttributesClass AWE EBS 정의 예

apiVersion: storage.k8s.io/v1beta1
kind: VolumeAttributesClass 
1

metadata:
  name: silver 
2

driverName: ebs.csi.aws.com 
3

parameters:
  iops: "300"
  throughput: "125"
  type: io2 
4

  ...
Copy to Clipboard Toggle word wrap

1
오브젝트를 Volumes 속성 클래스로 정의합니다.
2
VolumeAttributesClass 의 이름입니다. 이 예제에서는 "silver"입니다.
3
PV(영구 볼륨) 프로비저닝에 사용되는 볼륨 플러그인을 결정하는 프로비저너입니다. 이 예에서는 AWS EBS의 경우 "ebs.csi.aws.com"입니다.
4
디스크 유형

다음은 GPC PD용 Volume Attributes Class YAML 파일의 예입니다.

VolumeAttributesClass GPC PD 정의 예

apiVersion: storage.k8s.io/v1beta1
kind: VolumeAttributesClass 
1

metadata:
  name: silver 
2

driverName: pd.csi.storage.gke.io 
3

parameters:
  iops: "3000"
  throughput: "150Mi"
  ...
Copy to Clipboard Toggle word wrap

1
오브젝트를 Volumes 속성 클래스로 정의합니다.
2
VolumeAttributesClass 의 이름입니다. 이 예제에서는 "silver"입니다.
3
PV(영구 볼륨) 프로비저닝에 사용되는 볼륨 플러그인을 결정하는 프로비저너입니다. 이 예에서 GPC PD의 경우 "pd.csi.storage.gke.io"입니다.
3.4.6.4. PVC에 볼륨 속성 클래스 적용

새로 생성된 PVC 외에도 볼륨 속성 클래스를 사용하여 기존 바인딩된 PVC를 업데이트할 수도 있습니다.

PVC에 볼륨 속성 클래스를 적용하려면 다음을 수행합니다.

  • PVC의 volumeAttributesClassName 매개변수를 Volume Attributes Class의 이름으로 설정합니다.

    볼륨 속성 클래스를 지정하는 PVC 정의 예

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: test-pv-claim
    spec:volumeAttributesClassName: silver 
    1
    Copy to Clipboard Toggle word wrap

    1
    이 PVC에 볼륨 속성 클래스 "silver"를 사용하여 지정합니다.
3.4.6.5. 볼륨 속성 클래스 삭제

PVC에서 사용하는 볼륨 속성 클래스를 삭제할 수 없습니다.

PVC에서 여전히 사용 중인 Volume Attributes 클래스를 삭제하려고 하면 볼륨 속성 클래스를 사용하는 모든 리소스가 업데이트되지 않을 때까지 명령이 완료되지 않습니다.

볼륨 속성 클래스를 삭제하려면 다음을 수행합니다.

  1. 다음 명령을 실행하여 볼륨 속성 클래스를 사용하는 PVC를 검색합니다.

    $ oc get pvc -A -o jsonpath='{range .items[?(@.spec.volumeAttributesClassName=="<vac-name>")]}{.metadata.name}{"\n"}{end}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <vac-name> = 볼륨 속성 클래스 이름

    샘플 명령 출력

    $ mypvc
    Copy to Clipboard Toggle word wrap

  2. 그 다음에는 다음 중 하나를 선택하세요.

    • PVC의 volumeAttributesClassName 매개변수에 다른 볼륨 속성 클래스 이름을 지정합니다.

      볼륨 속성 클래스를 지정하는 PVC 정의 예제

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
      name: mypvc
      spec:volumeAttributesClassName: silver 
      1
      Copy to Clipboard Toggle word wrap

      1
      다른 볼륨 속성 클래스를 지정합니다. 이 예에서는 "은"입니다.

      또는

    • 다음 명령을 실행하여 볼륨 속성 클래스를 지정하는 모든 PVC를 삭제합니다.

      $ oc delete pvc <pvc-name> 
      1
      Copy to Clipboard Toggle word wrap
      1
      삭제하려는 PVC의 이름입니다.
  3. 이제 볼륨 속성 클래스가 더 이상 PVC에서 사용되지 않으므로 다음 명령을 실행하여 볼륨 속성 클래스를 삭제합니다.

    $ oc delete vac <vac-name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    삭제하려는 볼륨 속성 클래스의 이름입니다.

3.5. 블록 볼륨 지원

OpenShift Container Platform은 원시 블록 볼륨을 정적으로 프로비저닝할 수 있습니다. 이러한 볼륨에는 파일 시스템이 없으며 디스크에 직접 쓰거나 자체 스토리지 서비스를 구현하는 애플리케이션에 성능 이점을 제공할 수 있습니다.

원시 블록 볼륨은 PV 및 PVC 사양에 volumeMode:Block을 지정하여 프로비저닝됩니다.

중요

권한이 부여된 컨테이너를 허용하려면 원시 블록 볼륨을 사용하는 Pod를 구성해야 합니다.

다음 표는 블록 볼륨을 지원하는 볼륨 플러그인을 보여줍니다.

Expand
표 3.4. 블록 볼륨 지원
볼륨 플러그인수동 프로비저닝동적 프로비저닝모두 지원됨

Amazon Elastic Block Store(Amazon EBS)

Amazon Elastic File Storage(Amazon EFS)

   

Azure Disk

Azure File

   

Cinder

파이버 채널

 

GCP

HostPath

   

IBM Cloud Block Storage 볼륨

iSCSI

 

로컬 볼륨

 

LVM 스토리지

NFS

   

Red Hat OpenShift Data Foundation

CIFS/SMB

VMware vSphere

중요

수동으로 프로비저닝할 수 있지만 완전히 지원되지 않는 블록 볼륨을 사용하는 것은 기술 미리 보기 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

3.5.1. 블록 볼륨 예

PV 예

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 
1

  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false
Copy to Clipboard Toggle word wrap

1
이 PV가 원시 블록 볼륨임을 나타내려면 volumeModeBlock으로 설정해야 합니다.

PVC 예

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 
1

  resources:
    requests:
      storage: 10Gi
Copy to Clipboard Toggle word wrap

1
원시 블록 PVC가 요청되었음을 나타내려면 volumeModeBlock으로 설정해야 합니다.

Pod 사양 예

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:  
1

        - name: data
          devicePath: /dev/xvda 
2

  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc 
3
Copy to Clipboard Toggle word wrap

1
블록 장치에서는 volumeMounts 대신 volumeDevices가 사용됩니다. PersistentVolumeClaim 소스만 원시 블록 볼륨과 함께 사용할 수 있습니다.
2
mountPath 대신 devicePath가 원시 블록이 시스템에 매핑되는 물리 장치의 경로를 나타냅니다.
3
볼륨 소스는 persistentVolumeClaim 유형이어야 하며 예상되는 PVC의 이름과 일치해야 합니다.
Expand
표 3.5. volumeMode에 대해 허용되는 값
기본

파일 시스템

블록

아니요

Expand
표 3.6. 블록 볼륨에 대한 바인딩 시나리오
PV volumeModePVC volumeMode바인딩 결과

파일 시스템

파일 시스템

바인딩

지정되지 않음

지정되지 않음

바인딩

파일 시스템

지정되지 않음

바인딩

지정되지 않음

파일 시스템

바인딩

블록

블록

바인딩

지정되지 않음

블록

바인딩되지 않음

블록

지정되지 않음

바인딩되지 않음

파일 시스템

블록

바인딩되지 않음

블록

파일 시스템

바인딩되지 않음

중요

값을 지정하지 않으면 Filesystem의 기본값이 사용됩니다.

3.6. fsGroup을 사용하여 Pod 타임아웃 감소

스토리지 볼륨에 여러 파일(~1TiB 이상)이 포함된 경우 Pod 시간 초과가 발생할 수 있습니다.

이는 기본적으로 OpenShift Container Platform이 볼륨이 마운트될 때 포드의 securityContext 에 지정된 fsGroup 과 일치하도록 각 볼륨의 콘텐츠에 대한 소유권과 권한을 재귀적으로 변경하기 때문에 발생할 수 있습니다. 볼륨이 큰 경우 소유권과 권한을 확인하고 변경하는 데 시간이 많이 걸리고 Pod 시작이 느려질 수 있습니다. securityContext 내부의 fsGroupChangePolicy 필드를 사용하여 OpenShift Container Platform이 볼륨의 소유권과 권한을 확인하고 관리하는 방식을 제어할 수 있습니다.

fsGroupChangePolicy는 볼륨이 포드 내부에 노출되기 전에 볼륨의 소유권과 권한을 변경하기 위한 동작을 정의합니다. 이 필드는 fsGroup 이 제어하는 소유권과 권한을 지원하는 볼륨 유형에만 적용됩니다. 이 필드에는 두 가지 가능한 값이 있습니다.

  • OnRootMismatch : 루트 디렉토리의 권한 및 소유권이 볼륨의 예상 권한과 일치하지 않는 경우에만 권한 및 소유권을 변경합니다. 이를 통해 볼륨의 소유권과 권한을 변경하는 데 걸리는 시간을 단축하여 Pod 시간 초과를 줄일 수 있습니다.
  • 항상 : 볼륨이 마운트될 때 항상 볼륨의 권한과 소유권을 변경합니다.

fsGroupChangePolicy 예제

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch" 
1

  ...
Copy to Clipboard Toggle word wrap

1
OnRootMismatch는 재귀적 권한 변경을 건너뛰도록 지정하여 Pod 시간 초과 문제를 방지하는 데 도움이 됩니다.
참고

fsGroupChangePolicyfield는 secret, configMap, emptydir과 같은 임시 볼륨 유형에는 영향을 미치지 않습니다.

4장. 영구 스토리지 구성

4.1. AWS Elastic Block Store를 사용하는 영구저장장치

OpenShift Container Platform은 Amazon Elastic Block Store(EBS) 볼륨을 지원합니다. Amazon EC2를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다.

Kubernetes 영구 볼륨 프레임워크를 사용하면 관리자는 영구 스토리지로 클러스터를 프로비저닝하고 사용자가 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다. Amazon EBS 볼륨을 동적으로 프로비저닝할 수 있습니다. 영구 볼륨은 단일 프로젝트 또는 네임스페이스에 바인딩되지 않으며, OpenShift Container Platform 클러스터에서 공유할 수 있습니다. 영구 볼륨 클레임은 프로젝트 또는 네임스페이스에 고유하며 사용자가 요청할 수 있습니다. AWS에서 컨테이너 지속형 볼륨을 암호화하기 위해 KMS 키를 정의할 수 있습니다. 기본적으로 OpenShift Container Platform 버전 4.10 이상을 사용하여 새로 생성된 클러스터는 gp3 스토리지와 AWS EBS CSI 드라이버를 사용합니다.

중요

인프라의 스토리지의 고가용성은 기본 스토리지 공급자가 담당합니다.

중요

OpenShift Container Platform 4.12 이상에서는 AWS Block 인트리 볼륨 플러그인을 해당 CSI 드라이버로 자동 마이그레이션합니다.

CSI 자동 마이그레이션이 원활해야 합니다. 마이그레이션은 영구 볼륨, 영구 볼륨 클레임 및 스토리지 클래스와 같은 기존 API 오브젝트를 사용하는 방법을 변경하지 않습니다. 마이그레이션에 대한 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

4.1.1. EBS 스토리지 클래스 생성

스토리지 클래스는 스토리지 수준 및 사용량을 구분하고 조정하는 데 사용됩니다. 스토리지 클래스를 정의하면 사용자는 동적으로 프로비저닝된 영구 볼륨을 얻을 수 있습니다.

4.1.2. 영구 볼륨 클레임 생성

사전 요구 사항

OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 스토리지영구 볼륨 클레임을 클릭합니다.
  2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.
  3. 표시되는 페이지에 원하는 옵션을 정의합니다.

    1. 드롭다운 메뉴에서 이전에 만든 스토리지 클래스를 선택합니다.
    2. 스토리지 클레임의 고유한 이름을 입력합니다.
    3. 액세스 모드를 선택합니다. 이 선택은 저장소 클레임에 대한 읽기 및 쓰기 액세스를 결정합니다.
    4. 스토리지 클레임의 크기를 정의합니다.
  4. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.

4.1.3. 볼륨 형식

OpenShift Container Platform이 볼륨을 마운트하고 컨테이너에 전달하기 전에 볼륨에 영구 볼륨 정의의 fsType 매개변수에 지정된 파일 시스템이 포함되어 있는지 확인합니다. 장치가 파일 시스템으로 포맷되지 않으면 장치의 모든 데이터가 삭제되고 장치는 지정된 파일 시스템에서 자동으로 포맷됩니다.

이 검증을 통해 포맷되지 않은 AWS 볼륨을 영구 볼륨으로 사용할 수 있습니다. OpenShift Container Platform이 처음 사용하기 전에 해당 볼륨을 포맷하기 때문입니다.

4.1.4. 노드의 최대 EBS 볼륨 수

기본적으로 OpenShift Container Platform은 노드 1개에 연결된 최대 39개의 EBS 볼륨을 지원합니다. 이 제한은 AWS 볼륨 제한과 일치합니다. 볼륨 제한은 인스턴스 유형에 따라 다릅니다.

중요

클러스터 관리자는 in-tree 또는 CSI(Container Storage Interface) 볼륨과 해당 스토리지 클래스를 사용할 수 있지만, 두 볼륨을 동시에 사용하지 않아야 합니다. 첨부된 EBS 볼륨의 최대 개수는 트리 내 볼륨과 CSI 볼륨에 대해 별도로 계산됩니다. 즉, 각 유형별로 최대 39개의 EBS 볼륨을 가질 수 있습니다.

트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 추가 스토리지 옵션에 액세스하는 방법에 대한 자세한 내용은 AWS Elastic Block Store CSI 드라이버 운영자를 참조하세요.

4.1.5. KMS 키를 사용하여 AWS에서 컨테이너 영구 볼륨 암호화

AWS에 컨테이너 지속형 볼륨을 암호화하기 위해 KMS 키를 정의하는 것은 AWS에 배포할 때 명시적인 규정 준수 및 보안 지침이 있는 경우에 유용합니다.

사전 요구 사항

  • 기본 인프라에는 저장소가 있어야 합니다.
  • AWS에서 고객 KMS 키를 생성해야 합니다.

프로세스

  1. 스토리지 클래스를 만듭니다.

    $ cat << EOF | oc create -f -
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <storage-class-name> 
    1
    
    parameters:
      fsType: ext4 
    2
    
      encrypted: "true"
      kmsKeyId: keyvalue 
    3
    
    provisioner: ebs.csi.aws.com
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer
    EOF
    Copy to Clipboard Toggle word wrap
    1
    저장 클래스의 이름을 지정합니다.
    2
    프로비저닝된 볼륨에 생성되는 파일 시스템입니다.
    3
    컨테이너 지속형 볼륨을 암호화할 때 사용할 키의 전체 Amazon 리소스 이름(ARN)을 지정합니다. 키를 제공하지 않고 암호화된 필드가 true 로 설정된 경우 기본 KMS 키가 사용됩니다. AWS 설명서에서 AWS에서 키 ID와 키 ARN 찾기를 참조하세요.
  2. KMS 키를 지정하는 스토리지 클래스로 영구 볼륨 클레임(PVC)을 만듭니다.

    $ cat << EOF | oc create -f -
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mypvc
    spec:
      accessModes:
        - ReadWriteOnce
      volumeMode: Filesystem
      storageClassName: <storage-class-name>
      resources:
        requests:
          storage: 1Gi
    EOF
    Copy to Clipboard Toggle word wrap
  3. PVC를 사용하기 위한 작업 컨테이너를 만듭니다.

    $ cat << EOF | oc create -f -
    kind: Pod
    metadata:
      name: mypod
    spec:
      containers:
        - name: httpd
          image: quay.io/centos7/httpd-24-centos7
          ports:
            - containerPort: 80
          volumeMounts:
            - mountPath: /mnt/storage
              name: data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: mypvc
    EOF
    Copy to Clipboard Toggle word wrap

4.2. Azure를 사용하는 영구 스토리지

OpenShift Container Platform은 Microsoft Azure Disk 볼륨을 지원합니다. Azure를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. Kubernetes 및 Azure에 대해 어느 정도 익숙한 것으로 가정합니다. Kubernetes 영구 볼륨 프레임워크를 사용하면 관리자는 영구 스토리지로 클러스터를 프로비저닝하고 사용자가 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다. Azure 디스크 볼륨은 동적으로 프로비저닝할 수 있습니다. 영구 볼륨은 단일 프로젝트 또는 네임스페이스에 바인딩되지 않으며, OpenShift Container Platform 클러스터에서 공유할 수 있습니다. 영구 볼륨 클레임은 프로젝트 또는 네임스페이스에 고유하며 사용자가 요청할 수 있습니다.

중요

OpenShift Container Platform 4.11 이상에서는 Azure Disk 인트리 볼륨 플러그인을 해당 CSI 드라이버로 자동 마이그레이션합니다.

CSI 자동 마이그레이션이 원활해야 합니다. 마이그레이션은 영구 볼륨, 영구 볼륨 클레임 및 스토리지 클래스와 같은 기존 API 오브젝트를 사용하는 방법을 변경하지 않습니다. 마이그레이션에 대한 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

중요

인프라의 스토리지의 고가용성은 기본 스토리지 공급자가 담당합니다.

4.2.1. Azure 스토리지 클래스 생성

스토리지 클래스는 스토리지 수준 및 사용량을 구분하고 조정하는 데 사용됩니다. 스토리지 클래스를 정의하면 사용자는 동적으로 프로비저닝된 영구 볼륨을 얻을 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 스토리지스토리지 클래스를 클릭합니다.
  2. 스토리지 클래스 개요에서 스토리지 클래스 만들기를 클릭합니다.
  3. 표시되는 페이지에 원하는 옵션을 정의합니다.

    1. 스토리지 클래스를 참조할 이름을 입력합니다.
    2. 선택적 설명을 입력합니다.
    3. 회수 정책을 선택합니다.
    4. 드롭다운 목록에서 kubernetes.io/azure-disk를 선택합니다.

      1. 스토리지 계정 유형을 입력합니다. 이는 Azure 스토리지 계정 SKU 계층에 해당합니다. 유효한 옵션은 Premium_LRS , PremiumV2_LRS , Standard_LRS , StandardSSD_LRSUltraSSD_LRS 입니다.

        중요

        skuname PremiumV2_LRS는 모든 지역에서 지원되지 않으며, 일부 지원되는 지역에서는 모든 가용성 영역이 지원되지 않습니다. 자세한 내용은 Azure 문서를 참조하세요.

      2. 계정 종류를 입력합니다. 유효한 옵션은 shared, dedicatedmanaged입니다.

        중요

        Red Hat은 스토리지 클래스에서 kind: Managed의 사용만 지원합니다.

        SharedDedicated를 사용하여 Azure는 관리되지 않은 디스크를 생성합니다. 반면 OpenShift Container Platform은 머신 OS(root) 디스크의 관리 디스크를 생성합니다. Azure Disk는 노드에서 관리 및 관리되지 않은 디스크를 모두 사용하도록 허용하지 않으므로 Shared 또는 Dedicated로 생성된 관리되지 않은 디스크를 OpenShift Container Platform 노드에 연결할 수 없습니다.

    5. 원하는 대로 스토리지 클래스에 대한 추가 매개변수를 입력합니다.
  4. 생성을 클릭하여 스토리지 클래스를 생성합니다.

4.2.2. 영구 볼륨 클레임 생성

사전 요구 사항

OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 스토리지영구 볼륨 클레임을 클릭합니다.
  2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.
  3. 표시되는 페이지에 원하는 옵션을 정의합니다.

    1. 드롭다운 메뉴에서 이전에 만든 스토리지 클래스를 선택합니다.
    2. 스토리지 클레임의 고유한 이름을 입력합니다.
    3. 액세스 모드를 선택합니다. 이 선택은 저장소 클레임에 대한 읽기 및 쓰기 액세스를 결정합니다.
    4. 스토리지 클레임의 크기를 정의합니다.
  4. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.

4.2.3. 볼륨 형식

OpenShift Container Platform이 볼륨을 마운트하고 컨테이너에 전달하기 전에 영구 볼륨 정의에 fsType 매개변수에 의해 지정된 파일 시스템이 포함되어 있는지 확인합니다. 장치가 파일 시스템으로 포맷되지 않으면 장치의 모든 데이터가 삭제되고 장치는 지정된 파일 시스템에서 자동으로 포맷됩니다.

이를 통해 OpenShift Container Platform이 처음 사용하기 전에 포맷되기 때문에 형식화되지 않은 Azure 볼륨을 영구 볼륨으로 사용할 수 있습니다.

Ultra Disks가 있는 머신을 배포하는 Azure에서 실행되는 머신 세트를 만들 수 있습니다. Ultra 디스크는 가장 까다로운 데이터 워크로드에 사용하기 위한 고성능 스토리지입니다.

트리 내 플러그인과 CSI 드라이버는 모두 PVC를 사용하여 Ultra Disks를 활성화합니다. PVC를 생성하지 않고도 Ultra Disks가 있는 머신을 데이터 디스크로 배포할 수도 있습니다.

4.2.4.1. 머신 세트를 사용하여 울트라 디스크가 있는 머신 생성

Azure에서 Ultra Disks가 있는 머신을 배포하려면 머신 세트 YAML 파일을 편집하세요.

사전 요구 사항

  • 기존 Microsoft Azure 클러스터가 있어야 합니다.

프로세스

  1. 기존 Azure MachineSet 사용자 지정 리소스(CR)를 복사하고 다음 명령을 실행하여 편집합니다.

    $ oc edit machineset <machine_set_name>
    Copy to Clipboard Toggle word wrap

    여기서 <machine_set_name> 은 Ultra Disks를 사용하여 머신을 프로비저닝하려는 머신 세트입니다.

  2. 다음 줄을 표시된 위치에 추가합니다.

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    spec:
      template:
        spec:
          metadata:
            labels:
              disk: ultrassd 
    1
    
          providerSpec:
            value:
              ultraSSDCapability: Enabled 
    2
    Copy to Clipboard Toggle word wrap
    1
    이 머신 세트에서 생성된 노드를 선택하는 데 사용할 레이블을 지정합니다. 이 절차에서는 이 값에 대해 disk.ultrassd를 사용합니다.
    2
    이 라인은 울트라 디스크를 사용할 수 있습니다.
  3. 다음 명령을 실행하여 업데이트된 구성을 사용하여 머신 세트를 만듭니다.

    $ oc create -f <machine_set_name>.yaml
    Copy to Clipboard Toggle word wrap
  4. 다음 YAML 정의를 포함하는 스토리지 클래스를 만듭니다.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: ultra-disk-sc 
    1
    
    parameters:
      cachingMode: None
      diskIopsReadWrite: "2000" 
    2
    
      diskMbpsReadWrite: "320" 
    3
    
      kind: managed
      skuname: UltraSSD_LRS
    provisioner: disk.csi.azure.com 
    4
    
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer 
    5
    Copy to Clipboard Toggle word wrap
    1
    저장 클래스의 이름을 지정합니다. 이 절차에서는 이 값에 Ultra-disk-sc 를 사용합니다.
    2
    스토리지 클래스에 대한 IOPS 수를 지정합니다.
    3
    스토리지 클래스에 대한 처리량을 MBps 단위로 지정합니다.
    4
    Azure Kubernetes Service(AKS) 버전 1.21 이상의 경우 disk.csi.azure.com을 사용하세요. 이전 버전의 AKS의 경우 kubernetes.io/azure-disk를 사용하세요.
    5
    선택 사항: 디스크를 사용할 Pod가 생성될 때까지 기다리려면 이 매개변수를 지정합니다.
  5. 다음 YAML 정의가 포함된 ultra-disk-sc 스토리지 클래스를 참조하는 영구 볼륨 클레임(PVC)을 만듭니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: ultra-disk 
    1
    
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: ultra-disk-sc 
    2
    
      resources:
        requests:
          storage: 4Gi 
    3
    Copy to Clipboard Toggle word wrap
    1
    PVC의 이름을 지정하세요. 이 절차에서는 이 값에 Ultra-disk 를 사용합니다.
    2
    이 PVC는 ultra-disk-sc 스토리지 클래스를 참조합니다.
    3
    저장 클래스의 크기를 지정합니다. 최소값은 4Gi 입니다.
  6. 다음 YAML 정의가 포함된 Pod를 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx-ultra
    spec:
      nodeSelector:
        disk: ultrassd 
    1
    
      containers:
      - name: nginx-ultra
        image: alpine:latest
        command:
          - "sleep"
          - "infinity"
        volumeMounts:
        - mountPath: "/mnt/azure"
          name: volume
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: ultra-disk 
    2
    Copy to Clipboard Toggle word wrap
    1
    Ultra Disks를 사용할 수 있는 머신 세트의 라벨을 지정하세요. 이 절차에서는 이 값에 대해 disk.ultrassd를 사용합니다.
    2
    이 포드는 울트라 디스크 PVC를 참조합니다.

검증

  1. 다음 명령을 실행하여 머신이 생성되었는지 확인하세요.

    $ oc get machines
    Copy to Clipboard Toggle word wrap

    기계는 실행 상태여야 합니다.

  2. 실행 중이고 노드가 연결된 머신의 경우 다음 명령을 실행하여 파티션을 검증합니다.

    $ oc debug node/<node_name> -- chroot /host lsblk
    Copy to Clipboard Toggle word wrap

    이 명령에서 oc debug node/<node_name>은 노드 <node_name> 에서 디버깅 셸을 시작하고 -- 로 명령을 전달합니다. 전달된 명령 chroot /host는 기본 호스트 OS 바이너리에 대한 액세스를 제공하고, lsblk는 호스트 OS 머신에 연결된 블록 장치를 보여줍니다.

다음 단계

  • 포드 내에서 Ultra Disk를 사용하려면 마운트 지점을 사용하는 워크로드를 생성하세요. 다음 예와 유사한 YAML 파일을 만듭니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: ssd-benchmark1
    spec:
      containers:
      - name: ssd-benchmark1
        image: nginx
        ports:
          - containerPort: 80
            name: "http-server"
        volumeMounts:
        - name: lun0p1
          mountPath: "/tmp"
      volumes:
        - name: lun0p1
          hostPath:
            path: /var/lib/lun0p1
            type: DirectoryOrCreate
      nodeSelector:
        disktype: ultrassd
    Copy to Clipboard Toggle word wrap
4.2.4.2. Ultra Disks를 활성화하는 머신 세트에 대한 문제 해결 리소스

이 섹션의 정보를 활용해 발생할 수 있는 문제를 파악하고 복구하세요.

Ultra Disk로 지원되는 영구 볼륨 클레임을 마운트하는 데 문제가 있는 경우 Pod는 ContainerCreating 상태에 멈추고 경고가 발생합니다.

예를 들어, Pod를 호스팅하는 노드를 지원하는 머신에 additionalCapabilities.ultraSSDEnabled 매개변수가 설정되지 않은 경우 다음 오류 메시지가 나타납니다.

StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
Copy to Clipboard Toggle word wrap
  • 이 문제를 해결하려면 다음 명령을 실행하여 Pod를 설명하세요.

    $ oc -n <stuck_pod_namespace> describe pod <stuck_pod_name>
    Copy to Clipboard Toggle word wrap

4.3. Azure File을 사용하는 영구 스토리지

OpenShift Container Platform은 Microsoft Azure File 볼륨을 지원합니다. Azure를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. Kubernetes 및 Azure에 대해 어느 정도 익숙한 것으로 가정합니다.

Kubernetes 영구 볼륨 프레임워크를 사용하면 관리자는 영구 스토리지로 클러스터를 프로비저닝하고 사용자가 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다. Azure File 볼륨을 동적으로 프로비저닝할 수 있습니다.

영구 볼륨은 단일 프로젝트 또는 네임스페이스에 바인딩되지 않으며 OpenShift Container Platform 클러스터에서 공유할 수 있습니다. 영구 볼륨 클레임은 프로젝트 또는 네임스페이스에 고유하며 사용자가 애플리케이션에서 사용하도록 요청할 수 있습니다.

중요

인프라의 스토리지의 고가용성은 기본 스토리지 공급자가 담당합니다.

중요

Azure File 볼륨은 서버 메시지 블록을 사용합니다.

중요

OpenShift Container Platform 4.13 이상에서는 Azure 파일 트리 내 볼륨 플러그인을 해당 CSI 드라이버로 자동 마이그레이션합니다.

CSI 자동 마이그레이션이 원활해야 합니다. 마이그레이션은 영구 볼륨, 영구 볼륨 클레임 및 스토리지 클래스와 같은 기존 API 오브젝트를 사용하는 방법을 변경하지 않습니다. 마이그레이션에 대한 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

추가 리소스

4.3.1. Azure File 공유 영구 볼륨 클레임 생성

영구 볼륨 클레임을 생성하려면 먼저 Azure 계정 및 키가 포함된 Secret 오브젝트를 정의해야 합니다. 이 시크릿은 PersistentVolume 정의에 사용되며 애플리케이션에서 사용하기 위해 영구 볼륨 클레임에 의해 참조됩니다.

사전 요구 사항

  • Azure File 공유가 있습니다.
  • 이 공유에 액세스할 수 있는 인증 정보(특히 스토리지 계정 및 키)를 사용할 수 있습니다.

절차

  1. Azure File 인증 정보가 포함된 Secret 오브젝트를 생성합니다.

    $ oc create secret generic <secret-name> --from-literal=azurestorageaccountname=<storage-account> \ 
    1
    
      --from-literal=azurestorageaccountkey=<storage-account-key> 
    2
    Copy to Clipboard Toggle word wrap
    1
    Azure File 스토리지 계정 이름입니다.
    2
    Azure File 스토리지 계정 키입니다.
  2. 생성한 Secret 오브젝트를 참조하는 PersistentVolume 오브젝트를 생성합니다.

    apiVersion: "v1"
    kind: "PersistentVolume"
    metadata:
      name: "pv0001" 
    1
    
    spec:
      capacity:
        storage: "5Gi" 
    2
    
      accessModes:
        - "ReadWriteOnce"
      storageClassName: azure-file-sc
      azureFile:
        secretName: <secret-name> 
    3
    
        shareName: share-1 
    4
    
        readOnly: false
    Copy to Clipboard Toggle word wrap
    1
    영구 볼륨의 이름입니다.
    2
    이 영구 볼륨의 크기입니다.
    3
    Azure File에서 인증 정보를 공유하는 시크릿의 이름입니다.
    4
    Azure File 공유의 이름입니다.
  3. 생성한 영구 볼륨에 매핑되는 PersistentVolumeClaim 오브젝트를 생성합니다.

    apiVersion: "v1"
    kind: "PersistentVolumeClaim"
    metadata:
      name: "claim1" 
    1
    
    spec:
      accessModes:
        - "ReadWriteOnce"
      resources:
        requests:
          storage: "5Gi" 
    2
    
      storageClassName: azure-file-sc 
    3
    
      volumeName: "pv0001" 
    4
    Copy to Clipboard Toggle word wrap
    1
    영구 볼륨 클레임의 이름입니다.
    2
    이 영구 볼륨 클레임의 크기입니다.
    3
    영구 볼륨을 프로비저닝하는 데 사용되는 스토리지 클래스의 이름입니다. PersistentVolume 정의에 사용되는 스토리지 클래스를 지정합니다.
    4
    Azure File 공유를 참조하는 기존 PersistentVolume 오브젝트의 이름입니다.

4.3.2. Pod에서 Azure 파일 공유 마운트

영구 볼륨 클레임을 생성한 후 애플리케이션에 의해 내부에서 사용될 수 있습니다. 다음 예시는 Pod 내부에서 이 공유를 마운트하는 방법을 보여줍니다.

사전 요구 사항

  • 기본 Azure File 공유에 매핑된 영구 볼륨 클레임이 있습니다.

절차

  • 기존 영구 볼륨 클레임을 마운트하는 Pod를 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-name 
    1
    
    spec:
      containers:
        ...
        volumeMounts:
        - mountPath: "/data" 
    2
    
          name: azure-file-share
      volumes:
        - name: azure-file-share
          persistentVolumeClaim:
            claimName: claim1 
    3
    Copy to Clipboard Toggle word wrap
    1
    Pod의 이름입니다.
    2
    Pod 내부에서 Azure 파일 공유를 마운트하기 위한 경로입니다. 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너가 호스트 /dev/pts 파일과 같이 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다.
    3
    이전에 생성된 PersistentVolumeClaim 오브젝트의 이름입니다.

4.4. Cinder를 사용하는 영구 스토리지

OpenShift Container Platform은 OpenStack Cinder를 지원합니다. Kubernetes 및 OpenStack에 대해 어느 정도 익숙한 것으로 가정합니다.

Cinder 볼륨은 동적으로 프로비저닝할 수 있습니다. 영구 볼륨은 단일 프로젝트 또는 네임스페이스에 바인딩되지 않으며, OpenShift Container Platform 클러스터에서 공유할 수 있습니다. 영구 볼륨 클레임은 프로젝트 또는 네임스페이스에 고유하며 사용자가 요청할 수 있습니다.

중요

OpenShift Container Platform 4.11 이상에서는 Cinder 인트리 볼륨 플러그인을 해당 CSI 드라이버로 자동 마이그레이션하는 기능을 제공합니다.

CSI 자동 마이그레이션이 원활해야 합니다. 마이그레이션은 영구 볼륨, 영구 볼륨 클레임 및 스토리지 클래스와 같은 기존 API 오브젝트를 사용하는 방법을 변경하지 않습니다. 마이그레이션에 대한 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

4.4.1. Cinder를 사용한 수동 프로비저닝

OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다.

사전 요구 사항

  • Red Hat OpenStack Platform(RHOSP)에 맞게 구성된 OpenShift Container Platform
  • Cinder 볼륨 ID
4.4.1.1. 영구 볼륨 생성

OpenShift Container Platform에서 생성하기 전에 오브젝트 정의에서 PV(영구 볼륨)를 정의해야 합니다.

절차

  1. 오브젝트 정의를 파일에 저장합니다.

    cinder-persistentvolume.yaml

    apiVersion: "v1"
    kind: "PersistentVolume"
    metadata:
      name: "pv0001" 
    1
    
    spec:
      capacity:
        storage: "5Gi" 
    2
    
      accessModes:
        - "ReadWriteOnce"
      cinder: 
    3
    
        fsType: "ext3" 
    4
    
        volumeID: "f37a03aa-6212-4c62-a805-9ce139fab180" 
    5
    Copy to Clipboard Toggle word wrap

    1
    영구 볼륨 클레임 또는 Pod에서 사용되는 볼륨의 이름입니다.
    2
    이 볼륨에 할당된 스토리지의 용량입니다.
    3
    Red Hat OpenStack Platform(RHOSP) Cinder 볼륨에 대한 Cinder를 나타냅니다.
    4
    볼륨이 처음 마운트될 때 생성되는 파일 시스템입니다.
    5
    사용할 Cinder 볼륨입니다.
    중요

    볼륨이 포맷되어 프로비저닝된 후에는 fstype 매개변수 값을 변경하지 마십시오. 이 값을 변경하면 데이터가 손실되고 Pod 오류가 발생할 수 있습니다.

  2. 이전 단계에서 저장한 오브젝트 정의 파일을 생성합니다.

    $ oc create -f cinder-persistentvolume.yaml
    Copy to Clipboard Toggle word wrap
4.4.1.2. 영구 볼륨 포맷

OpenShift Container Platform은 처음 사용하기 전에 형식화되기 때문에 형식화되지 않은 Cinder 볼륨을 PV로 사용할 수 있습니다.

OpenShift Container Platform이 볼륨을 마운트하고 컨테이너에 전달하기 전, 시스템은 PV 정의에 fsType 매개변수에 의해 지정된 파일 시스템이 포함되어 있는지 확인합니다. 장치가 파일 시스템으로 포맷되지 않으면 장치의 모든 데이터가 삭제되고 장치는 지정된 파일 시스템에서 자동으로 포맷됩니다.

4.4.1.3. Cinder 볼륨 보안

애플리케이션에서 Cinder PV를 사용하는 경우 배포 구성에 대한 보안을 구성합니다.

사전 요구 사항

  • 적절한 fsGroup 전략을 사용하는 SCC를 생성해야 합니다.

절차

  1. 서비스 계정을 생성하고 SCC에 추가합니다.

    $ oc create serviceaccount <service_account>
    Copy to Clipboard Toggle word wrap
    $ oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>
    Copy to Clipboard Toggle word wrap
  2. 애플리케이션 배포 구성에서 서비스 계정 이름과 securityContext를 입력합니다.

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: frontend-1
    spec:
      replicas: 1  
    1
    
      selector:    
    2
    
        name: frontend
      template:    
    3
    
        metadata:
          labels:  
    4
    
            name: frontend 
    5
    
        spec:
          containers:
          - image: openshift/hello-openshift
            name: helloworld
            ports:
            - containerPort: 8080
              protocol: TCP
          restartPolicy: Always
          serviceAccountName: <service_account> 
    6
    
          securityContext:
            fsGroup: 7777 
    7
    Copy to Clipboard Toggle word wrap
    1
    실행할 Pod의 사본 수입니다.
    2
    실행할 Pod의 레이블 선택기입니다.
    3
    컨트롤러가 생성하는 Pod용 템플릿입니다.
    4
    Pod의 레이블입니다. 선택기 레이블에서 제공되는 레이블이 포함되어야 합니다.
    5
    매개변수를 확장한 후 최대 이름 길이는 63자입니다.
    6
    생성한 서비스 계정을 지정합니다.
    7
    Pod에 대한 fsGroup을 지정합니다.

4.5. 파이버 채널을 사용하는 영구 스토리지

OpenShift Container Platform은 파이버 채널을 지원하므로 파이버 채널 볼륨을 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. Kubernetes 및 Fibre 채널에 대해 어느 정도 익숙한 것으로 가정합니다.

중요

ARM 아키텍처 기반 인프라에서는 파이버 채널을 사용한 영구 저장소가 지원되지 않습니다.

Kubernetes 영구 볼륨 프레임워크를 사용하면 관리자는 영구 스토리지로 클러스터를 프로비저닝하고 사용자가 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다. 영구 볼륨은 단일 프로젝트 또는 네임스페이스에 바인딩되지 않으며, OpenShift Container Platform 클러스터에서 공유할 수 있습니다. 영구 볼륨 클레임은 프로젝트 또는 네임스페이스에 고유하며 사용자가 요청할 수 있습니다.

중요

인프라의 스토리지의 고가용성은 기본 스토리지 공급자가 담당합니다.

4.5.1. 프로비저닝

PersistentVolume API를 사용하여 파이버 채널 볼륨을 프로비저닝하려면 다음을 사용할 수 있어야 합니다.

  • targetWWN(파이버 채널 대상의 World Wide Names에 대한 배열).
  • 유효한 LUN 번호입니다.
  • 파일 시스템 유형입니다.

영구 볼륨과 LUN은 일대일 매핑됩니다.

사전 요구 사항

  • 파이버 채널 LUN은 기본 인프라에 있어야 합니다.

PersistentVolume 오브젝트 정의

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  fc:
    wwids: [3600508b400105e210000900000490000] 
1

    targetWWNs: ['500a0981891b8dc5', '500a0981991b8dc5'] 
2

    lun: 2 
3

    fsType: ext4
Copy to Clipboard Toggle word wrap

1
전 세계 식별자(WWID). FC WWID 또는 FC 대상 WWNLUN 의 조합을 설정해야 하지만, 두 가지를 동시에 설정할 수는 없습니다. FC WWID 식별자는 모든 저장 장치에서 고유함이 보장되고 장치에 액세스하는 데 사용되는 경로와 무관하므로 WWN 대상보다 권장됩니다. WWID 식별자는 SCSI 조회를 실행하여 장치 식별 중요 제품 데이터( 페이지 0x83 ) 또는 장치 일련 번호( 페이지 0x80 )를 검색하여 얻을 수 있습니다. FC WWID는 디스크의 데이터를 참조하기 위해 /dev/disk/by-id/ 로 식별되며, 이는 장치 경로가 변경되거나 다른 시스템에서 장치에 액세스하는 경우에도 적용됩니다.
2 3
파이버 채널 WWN은 /dev/disk/by-path/pci-<IDENTIFIER>-fc-0x<WWN>-lun-<LUN#>로 식별되지만, 앞에 0x를 포함한 WWN이 오고 이후에 -(하이픈)이 포함된 다른 경로가 있는 경로의 일부를 입력할 필요가 없습니다.
중요

볼륨이 포맷되고 프로비저닝된 후 fstype 매개변수 값을 변경하면 데이터가 손실되고 Pod 오류가 발생할 수 있습니다.

4.5.1.1. 디스크 할당량 강제 적용

LUN 파티션을 사용하여 디스크 할당량 및 크기 제약 조건을 강제 적용합니다. 각 LUN은 단일 영구 볼륨에 매핑되며 고유한 이름을 영구 볼륨에 사용해야 합니다.

이렇게 하면 최종 사용자가 10Gi와 같은 특정 용량에 의해 영구 스토리지를 요청하고 해당 볼륨과 동등한 용량과 일치시킬 수 있습니다.

4.5.1.2. 파이버 채널 볼륨 보안

사용자는 영구 볼륨 클레임을 사용하여 스토리지를 요청합니다. 이 클레임은 사용자의 네임스페이스에만 존재하며, 동일한 네임스페이스 내의 Pod에서만 참조할 수 있습니다. 네임스페이스에서 영구 볼륨에 대한 액세스를 시도하면 Pod가 실패하게 됩니다.

각 파이버 채널 LUN은 클러스터의 모든 노드에서 액세스할 수 있어야 합니다.

4.6. FlexVolume을 사용하는 영구 스토리지

중요

FlexVolume은 더 이상 지원되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

CSI(Out-of-tree Container Storage Interface) 드라이버는 OpenShift Container Platform에서 볼륨 드라이버를 작성하는 것이 좋습니다. FlexVolume 드라이버 관리자는 CSI 드라이버를 구현하고 FlexVolume 사용자를 CSI로 이동해야 합니다. FlexVolume 사용자는 워크로드를 CSI 드라이버로 이동해야 합니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

OpenShift Container Platform은 드라이버와 인터페이스하기 위해 실행 가능 모델을 사용하는 트리 외부 플러그인인 FlexVolume을 지원합니다.

내장 플러그인이 없는 백엔드의 스토리지를 사용하려면 FlexVolume 드라이버를 통해 OpenShift Container Platform을 확장하고 애플리케이션에 영구 스토리지를 제공할 수 있습니다.

Pod는 flexvolume in-tree 플러그인을 통해 FlexVolume 드라이버와 상호 작용합니다.

4.6.1. FlexVolume 드라이버 정보

FlexVolume 드라이버는 클러스터의 모든 노드의 올바르게 정의된 디렉터리에 위치하는 실행 파일입니다. flexVolume을 갖는 PersistentVolume 오브젝트가 소스로 표시되는 볼륨을 마운트하거나 마운트 해제해야 할 때마다 OpenShift Container Platform이 FlexVolume 드라이버를 호출합니다.

중요

FlexVolume용 OpenShift Container Platform에서는 연결 및 분리 작업이 지원되지 않습니다.

4.6.2. FlexVolume 드라이버 예

FlexVolume 드라이버의 첫 번째 명령줄 인수는 항상 작업 이름입니다. 다른 매개 변수는 각 작업에 따라 다릅니다. 대부분의 작업에서는 JSON(JavaScript Object Notation) 문자열을 매개변수로 사용합니다. 이 매개변수는 전체 JSON 문자열이며 JSON 데이터가 있는 파일 이름은 아닙니다.

FlexVolume 드라이버에는 다음이 포함됩니다.

  • 모든 flexVolume.options.
  • fsTypereadwrite와 같은 kubernetes.io/ 접두사가 붙은 flexVolume의 일부 옵션.
  • 설정된 경우, kubernetes.io/secret/이 접두사로 사용되는 참조된 시크릿의 콘텐츠

FlexVolume 드라이버 JSON 입력 예

{
	"fooServer": "192.168.0.1:1234", 
1

        "fooVolumeName": "bar",
	"kubernetes.io/fsType": "ext4", 
2

	"kubernetes.io/readwrite": "ro", 
3

	"kubernetes.io/secret/<key name>": "<key value>", 
4

	"kubernetes.io/secret/<another key name>": "<another key value>",
}
Copy to Clipboard Toggle word wrap

1
flexVolume.options의 모든 옵션.
2
flexVolume.fsType의 값.
3
flexVolume.readOnly에 따른 Ro/rw.
4
flexVolume.secretRef에서 참조하는 시크릿의 모든 키 및 해당 값.

OpenShift Container Platform은 드라이버의 표준 출력에서 JSON 데이터를 예상합니다. 지정하지 않으면, 출력이 작업 결과를 설명합니다.

FlexVolume 드라이버 기본 출력 예

{
	"status": "<Success/Failure/Not supported>",
	"message": "<Reason for success/failure>"
}
Copy to Clipboard Toggle word wrap

드라이버의 종료 코드는 성공의 경우 0이고 오류의 경우 1이어야 합니다.

작업은 idempotent여야 합니다. 즉, 이미 마운트된 볼륨의 마운트의 경우 작업이 성공적으로 수행되어야 합니다.

4.6.3. FlexVolume 드라이버 설치

OpenShift Container Platform 확장에 사용되는 FlexVolume 드라이버는 노드에서만 실행됩니다. FlexVolumes를 구현하려면 호출할 작업 목록 및 설치 경로만 있으면 됩니다.

사전 요구 사항

  • FlexVolume 드라이버는 다음 작업을 구현해야 합니다.

    init

    드라이버를 초기화합니다. 이는 모든 노드를 초기화하는 동안 호출됩니다.

    • 인수: 없음
    • 실행 위치: 노드
    • 예상 출력: 기본 JSON
    Mount

    디렉터리에 볼륨을 마운트합니다. 여기에는 장치를 검색한 다음 장치를 마운트하는 등 볼륨을 마운트하는 데 필요한 모든 항목이 포함됩니다.

    • 인수: <mount-dir> <json>
    • 실행 위치: 노드
    • 예상 출력: 기본 JSON
    unmount

    디렉터리에서 볼륨의 마운트를 해제합니다. 여기에는 마운트 해제 후 볼륨을 정리하는 데 필요한 모든 항목이 포함됩니다.

    • 인수: <mount-dir>
    • 실행 위치: 노드
    • 예상 출력: 기본 JSON
    mountdevice
    개별 Pod가 마운트를 바인딩할 수 있는 디렉터리에 볼륨의 장치를 마운트합니다.

이 호출은 FlexVolume 사양에 지정된 "시크릿"을 전달하지 않습니다. 드라이버에 시크릿이 필요한 경우 이 호출을 구현하지 마십시오.

  • 인수: <mount-dir> <json>
  • 실행 위치: 노드
  • 예상 출력: 기본 JSON

    unmountdevice
    디렉터리에서 볼륨의 장치를 마운트 해제합니다.
  • 인수: <mount-dir>
  • 실행 위치: 노드
  • 예상 출력: 기본 JSON

    • 다른 모든 작업은 {"status": "Not supported"}1의 종료 코드와 함께 JSON을 반환해야 합니다.

절차

FlexVolume 드라이버를 설치하려면 다음을 수행합니다.

  1. 실행 가능한 파일이 클러스터의 모든 노드에 있는지 확인합니다.
  2. 볼륨 플러그인 경로(/etc/kubernetes/kubelet-plugins/volume/exec/<vendor>~<driver>/<driver>)에 실행 가능 파일을 배치합니다.

예를 들어, foo 스토리지용 FlexVolume 드라이버를 설치하려면 실행 파일을 /etc/kubernetes/kubelet-plugins/volume/exec/openshift.com~foo/foo에 배치합니다.

4.6.4. FlexVolume 드라이버를 사용한 스토리지 사용

OpenShift Container Platform의 각 PersistentVolume 오브젝트는 볼륨과 같이 스토리지 백엔드에서 1개의 스토리지 자산을 나타냅니다.

절차

  • PersistentVolume 오브젝트를 사용하여 설치된 스토리지를 참조합니다.

FlexVolume 드라이버를 사용한 영구 볼륨 오브젝트 정의 예

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 
1

spec:
  capacity:
    storage: 1Gi 
2

  accessModes:
    - ReadWriteOnce
  flexVolume:
    driver: openshift.com/foo 
3

    fsType: "ext4" 
4

    secretRef: foo-secret 
5

    readOnly: true 
6

    options: 
7

      fooServer: 192.168.0.1:1234
      fooVolumeName: bar
Copy to Clipboard Toggle word wrap

1
볼륨의 이름입니다. 영구 볼륨 클레임을 통해 또는 Pod에서 식별되는 방법입니다. 이 이름은 백엔드 스토리지의 볼륨 이름과 다를 수 있습니다.
2
이 볼륨에 할당된 스토리지의 용량입니다.
3
드라이버의 이름입니다. 이 필드는 필수입니다.
4
볼륨에 존재하는 파일 시스템입니다. 이 필드는 선택 사항입니다.
5
시크릿에 대한 참조입니다. 이 시크릿의 키와 값은 호출 시 FlexVolume 드라이버에 제공됩니다. 이 필드는 선택 사항입니다.
6
읽기 전용 플래그입니다. 이 필드는 선택 사항입니다.
7
FlexVolume 드라이버에 대한 추가 옵션입니다. options 필드에 있는 사용자가 지정한 플래그 외에도 다음 플래그도 실행 파일에 전달됩니다.
"fsType":"<FS type>",
"readwrite":"<rw>",
"secret/key1":"<secret1>"
...
"secret/keyN":"<secretN>"
Copy to Clipboard Toggle word wrap
참고

시크릿은 호출을 마운트하거나 마운트 해제하기 위해서만 전달됩니다.

4.7. GCE 영구 디스크를 사용하는 스토리지

OpenShift Container Platform은 gcePD(GCE 영구 디스크 볼륨)를 지원합니다. GCE를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. Kubernetes 및 GCE에 대해 어느 정도 익숙한 것으로 가정합니다.

Kubernetes 영구 볼륨 프레임워크를 사용하면 관리자는 영구 스토리지로 클러스터를 프로비저닝하고 사용자가 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다.

GCE 영구 디스크 볼륨은 동적으로 프로비저닝할 수 있습니다.

영구 볼륨은 단일 프로젝트 또는 네임스페이스에 바인딩되지 않으며, OpenShift Container Platform 클러스터에서 공유할 수 있습니다. 영구 볼륨 클레임은 프로젝트 또는 네임스페이스에 고유하며 사용자가 요청할 수 있습니다.

중요

OpenShift Container Platform 4.12 이상에서는 동등한 CSI 드라이버로 GCE Persist Disk in-tree 볼륨 플러그인에 대한 자동 마이그레이션을 제공합니다.

CSI 자동 마이그레이션이 원활해야 합니다. 마이그레이션은 영구 볼륨, 영구 볼륨 클레임 및 스토리지 클래스와 같은 기존 API 오브젝트를 사용하는 방법을 변경하지 않습니다.

마이그레이션에 대한 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

중요

인프라의 스토리지의 고가용성은 기본 스토리지 공급자가 담당합니다.

4.7.1. GCE 스토리지 클래스 생성

스토리지 클래스는 스토리지 수준 및 사용량을 구분하고 조정하는 데 사용됩니다. 스토리지 클래스를 정의하면 사용자는 동적으로 프로비저닝된 영구 볼륨을 얻을 수 있습니다.

4.7.2. 영구 볼륨 클레임 생성

사전 요구 사항

OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다.

프로세스

  1. OpenShift Container Platform 콘솔에서 스토리지영구 볼륨 클레임을 클릭합니다.
  2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.
  3. 표시되는 페이지에 원하는 옵션을 정의합니다.

    1. 드롭다운 메뉴에서 이전에 생성한 스토리지 클래스를 선택합니다.
    2. 스토리지 클레임의 고유한 이름을 입력합니다.
    3. 액세스 모드를 선택합니다. 이 선택에 따라 스토리지 클레임에 대한 읽기 및 쓰기 액세스가 결정됩니다.
    4. 스토리지 클레임의 크기를 정의합니다.
  4. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.

4.7.3. 볼륨 형식

OpenShift Container Platform이 볼륨을 마운트하고 컨테이너에 전달하기 전에 영구 볼륨 정의에 fsType 매개변수에 의해 지정된 파일 시스템이 포함되어 있는지 확인합니다. 장치가 파일 시스템으로 포맷되지 않으면 장치의 모든 데이터가 삭제되고 장치는 지정된 파일 시스템에서 자동으로 포맷됩니다.

이 확인을 사용하면 OpenShift Container Platform이 처음 사용하기 전에 포맷되므로 포맷되지 않은 GCE 볼륨을 영구 볼륨으로 사용할 수 있습니다.

4.8. iSCSI를 사용하는 영구 스토리지

iSCSI를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. Kubernetes 및 iSCSI에 대해 어느 정도 익숙한 것으로 가정합니다.

Kubernetes 영구 볼륨 프레임워크를 사용하면 관리자는 영구 스토리지로 클러스터를 프로비저닝하고 사용자가 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다.

중요

인프라의 스토리지의 고가용성은 기본 스토리지 공급자가 담당합니다.

중요

Amazon Web Services에서 iSCSI를 사용하는 경우 iSCSI 포트의 노드 간 TCP 트래픽을 포함하도록 기본 보안 정책을 업데이트해야 합니다. 기본적으로 해당 포트는 8603260입니다.

중요

사용자는 iscsi-initiator-utils 패키지를 설치하고 /etc/iscsi/initiatorname.iscsi 에 이니시에이터 이름을 구성하여 iSCSI 이니시에이터가 모든 OpenShift Container Platform 노드에 이미 구성되어 있는지 확인해야 합니다. iscsi-initiator-utils 패키지는 RHCOS(Red Hat Enterprise Linux CoreOS)를 사용하는 배포에 이미 설치되어 있습니다.

자세한 내용은 스토리지 장치 관리를 참조하십시오.

4.8.1. 프로비저닝

OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있는지 확인합니다. iSCSI에는 iSCSI 대상 포털, 유효한 IQN(iSCSI Qualified Name), 유효한 LUN 번호, 파일 시스템 유형 및 PersistentVolume API만 있으면 됩니다.

PersistentVolume 오브젝트 정의

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
     targetPortal: 10.16.154.81:3260
     iqn: iqn.2014-12.example.server:storage.target00
     lun: 0
     fsType: 'ext4'
Copy to Clipboard Toggle word wrap

4.8.2. 디스크 할당량 강제 적용

LUN 파티션을 사용하여 디스크 할당량 및 크기 제약 조건을 강제 적용합니다. 각 LUN은 1개의 영구 볼륨입니다. Kubernetes는 영구 볼륨에 고유 이름을 강제 적용합니다.

이렇게 하면 최종 사용자가 10Gi와 같은 특정 용량에 의해 영구 스토리지를 요청하고 해당 볼륨과 동등한 용량과 일치시킬 수 있습니다.

4.8.3. iSCSI 볼륨 보안

사용자는 PersistentVolumeClaim 오브젝트를 사용하여 스토리지를 요청합니다. 이 클레임은 사용자의 네임스페이스에만 존재하며, 동일한 네임스페이스 내의 Pod에서만 참조할 수 있습니다. 네임스페이스에서 영구 볼륨 클레임에 대한 액세스를 시도하면 Pod가 실패하게 됩니다.

각 iSCSI LUN은 클러스터의 모든 노드에서 액세스할 수 있어야 합니다.

4.8.3.1. CHAP(Challenge Handshake Authentication Protocol) 구성

선택적으로 OpenShift Container Platform은 CHAP을 사용하여 iSCSI 대상에 자신을 인증할 수 있습니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    fsType: ext4
    chapAuthDiscovery: true 
1

    chapAuthSession: true 
2

    secretRef:
      name: chap-secret 
3
Copy to Clipboard Toggle word wrap
1
iSCSI 검색의 CHAP 인증을 활성화합니다.
2
iSCSI 세션의 CHAP 인증을 활성화합니다.
3
사용자 이름 + 암호로 시크릿 오브젝트의 이름을 지정합니다. 이 Secret 오브젝트는 참조된 볼륨을 사용할 수 있는 모든 네임스페이스에서 사용할 수 있어야 합니다.

4.8.4. iSCSI 다중 경로

iSCSI 기반 스토리지의 경우 두 개 이상의 대상 포털 IP 주소에 동일한 IQN을 사용하여 여러 경로를 구성할 수 있습니다. 경로의 구성 요소 중 하나 이상에 실패하면 다중 경로를 통해 영구 볼륨에 액세스할 수 있습니다.

Pod 사양에 다중 경로를 지정하려면 portals 필드를 사용합니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260'] 
1

    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    fsType: ext4
    readOnly: false
Copy to Clipboard Toggle word wrap
1
portals 필드를 사용하여 추가 대상 포털을 추가합니다.

4.8.5. iSCSI 사용자 정의 이니시에이터 IQN

iSCSI 대상이 특정 IQN으로 제한되는 경우 사용자 정의 이니시에이터 IQN(iSCSI Qualified Name)을 구성하지만 iSCSI PV가 연결된 노드는 이러한 IQN을 갖는 것이 보장되지 않습니다.

사용자 정의 이니시에이터 IQN을 지정하려면 initiatorName 필드를 사용합니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: iscsi-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  iscsi:
    targetPortal: 10.0.0.1:3260
    portals: ['10.0.2.16:3260', '10.0.2.17:3260', '10.0.2.18:3260']
    iqn: iqn.2016-04.test.com:storage.target00
    lun: 0
    initiatorName: iqn.2016-04.test.com:custom.iqn 
1

    fsType: ext4
    readOnly: false
Copy to Clipboard Toggle word wrap
1
이니시에이터의 이름을 지정합니다.

4.9. NFS를 사용하는 영구저장장치

OpenShift Container Platform 클러스터는 NFS를 사용하는 영구 스토리지와 함께 프로비저닝될 수 있습니다. PV(영구 볼륨) 및 PVC(영구 볼륨 클레임)는 프로젝트 전체에서 볼륨을 공유하는 편리한 방법을 제공합니다. PV 정의에 포함된 NFS 관련 정보는 Pod 정의에서 직접 정의될 수 있지만, 이렇게 하면 볼륨이 별도의 클러스터 리소스로 생성되지 않아 볼륨에서 충돌이 발생할 수 있습니다.

4.9.1. 프로비저닝

OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다. NFS 볼륨을 프로비저닝하려면, NFS 서버 목록 및 내보내기 경로만 있으면 됩니다.

절차

  1. PV에 대한 오브젝트 정의를 생성합니다.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv0001 
    1
    
    spec:
      capacity:
        storage: 5Gi 
    2
    
      accessModes:
      - ReadWriteOnce 
    3
    
      nfs: 
    4
    
        path: /tmp 
    5
    
        server: 172.17.0.2 
    6
    
      persistentVolumeReclaimPolicy: Retain 
    7
    Copy to Clipboard Toggle word wrap
    1
    볼륨의 이름입니다. 이는 다양한 oc <command> pod에서 PV ID입니다.
    2
    이 볼륨에 할당된 스토리지의 용량입니다.
    3
    볼륨에 대한 액세스를 제어하는 것으로 표시되지만 실제로 레이블에 사용되며 PVC를 PV에 연결하는 데 사용됩니다. 현재는 accessModes를 기반으로 하는 액세스 규칙이 적용되지 않습니다.
    4
    사용 중인 볼륨 유형입니다(이 경우 nfs 플러그인).
    5
    NFS 서버에서 내보낸 경로입니다.
    6
    NFS 서버의 호스트 이름 또는 IP 주소입니다.
    7
    PV의 회수 정책입니다. 이는 릴리스될 때 볼륨에 발생하는 작업을 정의합니다.
    참고

    각 NFS 볼륨은 클러스터의 모든 스케줄링 가능한 노드에서 마운트할 수 있어야 합니다.

  2. PV가 생성되었는지 확인합니다.

    $ oc get pv
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
    pv0001   <none>    5Gi          RWO           Available                    31s
    Copy to Clipboard Toggle word wrap

  3. 새 PV에 바인딩하는 영구 볼륨 클레임을 생성합니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: nfs-claim1
    spec:
      accessModes:
        - ReadWriteOnce 
    1
    
      resources:
        requests:
          storage: 5Gi 
    2
    
      volumeName: pv0001
      storageClassName: ""
    Copy to Clipboard Toggle word wrap
    1
    액세스 모드는 보안을 적용하지 않고 PV를 PVC에 일치시키기 위한 레이블 역할을 합니다.
    2
    이 클레임에서는 5Gi 이상의 용량을 제공하는 PV를 찾습니다.
  4. 영구 볼륨 클레임이 생성되었는지 확인합니다.

    $ oc get pvc
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    nfs-claim1   Bound    pv0001   5Gi        RWO                           2m
    Copy to Clipboard Toggle word wrap

4.9.2. 디스크 할당량 강제 적용

디스크 파티션을 사용하여 디스크 할당량 및 크기 제약 조건을 적용할 수 있습니다. 각 파티션은 자체 내보내기일 수 있습니다. 각 내보내기는 1개의 PV입니다. OpenShift Container Platform은 PV에 고유한 이름을 적용하지만 NFS 볼륨 서버와 경로의 고유성은 관리자에 따라 다릅니다.

이렇게 하면 개발자가 10Gi와 같은 특정 용량에 의해 영구 스토리지를 요청하고 해당 볼륨과 동등한 용량과 일치시킬 수 있습니다.

4.9.3. NFS 볼륨 보안

이 섹션에서는 일치하는 권한 및 SELinux 고려 사항을 포함하여 NFS 볼륨 보안에 대해 설명합니다. 사용자는 POSIX 권한, 프로세스 UID, 추가 그룹 및 SELinux의 기본 사항을 이해하고 있어야 합니다.

개발자는 Pod 정의의 volumes 섹션에서 직접 PVC 또는 NFS 볼륨 플러그인을 참조하여 NFS 스토리지를 요청합니다.

NFS 서버의 /etc/exports 파일에 액세스할 수 있는 NFS 디렉터리가 있습니다. 대상 NFS 디렉터리에는 POSIX 소유자 및 그룹 ID가 있습니다. OpenShift Container Platform NFS 플러그인은 내보낸 NFS 디렉터리에 있는 동일한 POSIX 소유권 및 권한과 함께 컨테이너의 NFS 디렉터리를 마운트합니다. 그러나 컨테이너는 원하는 동작인 NFS 마운트의 소유자와 동일한 유효 UID로 실행되지 않습니다.

예를 들어, 대상 NFS 디렉터리가 NFS 서버에 다음과 같이 표시되는 경우:

$ ls -lZ /opt/nfs -d
Copy to Clipboard Toggle word wrap

출력 예

drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0   /opt/nfs
Copy to Clipboard Toggle word wrap

$ id nfsnobody
Copy to Clipboard Toggle word wrap

출력 예

uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)
Copy to Clipboard Toggle word wrap

그러면 컨테이너가 SELinux 레이블과 일치하고 65534, nfsnobody 소유자 또는 디렉터리에 액세스하려면 추가 그룹의 5555와 함께 실행해야 합니다.

참고

65534의 소유자 ID는 예시와 같이 사용됩니다. NFS의 root_squash는 UID가 0루트를 UID가 65534nfsnobody로 매핑하지만, NFS 내보내기에는 임의의 소유자 ID가 있을 수 있습니다. NFS를 내보내려면 소유자 65534가 필요하지 않습니다.

4.9.3.1. 그룹 ID

NFS 내보내기 권한 변경 옵션이 아닐 경우 NFS 액세스를 처리하는 권장 방법은 추가 그룹을 사용하는 것입니다. OpenShift Container Platform의 추가 그룹은 공유 스토리지에 사용되며 NFS가 그 예입니다. 반면 iSCSI와 같은 블록 스토리지는 Pod의 securityContext에 있는 fsGroup SCC 전략과 fsGroup 값을 사용합니다.

참고

영구 스토리지에 액세스하려면, 일반적으로 추가 그룹 ID vs 사용자 ID를 사용하는 것이 좋습니다.

예시의 대상 NFS 디렉터리의 그룹 ID가 5555이므로 Pod는 Pod의 securityContext 정의에서 supplementalGroups를 사용하여 해당 그룹 ID를 정의할 수 있습니다. 예를 들면 다음과 같습니다.

spec:
  containers:
    - name:
    ...
  securityContext: 
1

    supplementalGroups: [5555] 
2
Copy to Clipboard Toggle word wrap
1
SecurityContext는 특정 컨테이너의 하위가 아닌 Pod 수준에서 정의해야 합니다.
2
Pod에 정의된 GID 배열입니다. 이 경우 배열에는 1개의 요소가 있습니다. 추가 GID는 쉼표로 구분됩니다.

Pod 요구사항을 충족할 수 있는 사용자 지정 SCC가 없는 경우 Pod는 restricted SCC와 일치할 수 있습니다. 이 SCC에는 supplementalGroups 전략이 RunAsAny로 설정되어 있으므로, 범위를 확인하지 않고 제공되는 그룹 ID가 승인됩니다.

그 결과 위의 Pod에서 승인이 전달 및 실행됩니다. 그러나 그룹 ID 범위 확인이 필요한 경우에는 사용자 지정 SCC를 사용하는 것이 좋습니다. 사용자 지정 SCC를 생성하면 최소 및 최대 그룹 ID가 정의되고, 그룹 ID 범위 확인이 적용되며, 5555 그룹 ID가 허용될 수 있습니다.

참고

사용자 정의 SCC를 사용하려면 먼저 적절한 서비스 계정에 추가해야 합니다. 예를 들어, Pod 사양에 다른 값이 지정된 경우를 제외하고 지정된 프로젝트에서 기본 서비스 계정을 사용하십시오.

4.9.3.2. 사용자 ID

사용자 ID는 컨테이너 이미지 또는 Pod 정의에 정의할 수 있습니다.

참고

일반적으로 사용자 ID를 사용하는 대신 추가 그룹 ID를 사용하여 영구 스토리지에 대한 액세스 권한을 얻는 것이 좋습니다.

위에 표시된 예시 NFS 디렉터리에서 컨테이너는 UID가 65534로 설정되고, 현재 그룹 ID를 무시해야 하므로 다음을 Pod 정의에 추가할 수 있습니다.

spec:
  containers: 
1

  - name:
  ...
    securityContext:
      runAsUser: 65534 
2
Copy to Clipboard Toggle word wrap
1
Pod에는 각 컨테이너에 특정 securityContext 정의와 Pod에 정의된 모든 컨테이너에 적용되는 Pod의 securityContext 정의가 포함됩니다.
2
65534nfsnobody 사용자입니다.

프로젝트가 default이고 SCC가 restricted라고 가정하면 Pod에서 요청한 대로 65534의 사용자 ID가 허용되지 않습니다. 따라서 Pod가 다음과 같은 이유로 실패합니다.

  • 65534가 사용자 ID로 요청되었습니다.
  • Pod에서 사용 가능한 모든 SCC를 검사하여 어떤 SCC에서 65534의 사용자 ID가 허용되는지 확인합니다. SCC의 모든 정책을 확인하는 동안 여기에는 중요한 사항은 사용자 ID입니다.
  • 사용 가능한 모든 SCC는 runAsUser 전략에서 MustRunAsRange를 사용하므로 UID 범위 검사가 필요합니다.
  • 65534는 SCC 또는 프로젝트의 사용자 ID 범위에 포함되어 있지 않습니다.

일반적으로 사전 정의된 SCC를 수정하지 않는 것이 좋습니다. 이 상황을 해결하기 위해 선호되는 방법은 사용자 정의 SCC를 생성하는 것입니다. 따라서 최소 및 최대 사용자 ID가 정의되고 UID 범위 검사가 여전히 적용되며, 65534의 UID가 허용됩니다.

참고

사용자 정의 SCC를 사용하려면 먼저 적절한 서비스 계정에 추가해야 합니다. 예를 들어, Pod 사양에 다른 값이 지정된 경우를 제외하고 지정된 프로젝트에서 기본 서비스 계정을 사용하십시오.

4.9.3.3. SELinux

RHEL(Red Hat Enterprise Linux) 및 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템은 기본적으로 원격 NFS 서버에서 SELinux를 사용하도록 구성됩니다.

RHEL 이외 및 비RHCOS 시스템의 경우 SELinux는 Pod에서 원격 NFS 서버로 쓰기를 허용하지 않습니다. NFS 볼륨이 올바르게 마운트되지만 읽기 전용입니다. 다음 절차에 따라 올바른 SELinux 권한을 활성화해야 합니다.

사전 요구 사항

  • container-selinux 패키지가 설치되어 있어야 합니다. 이 패키지는 virt_use_nfs SELinux 부울을 제공합니다.

절차

  • 다음 명령을 사용하여 virt_use_nfs 부울을 활성화합니다. -P 옵션을 사용하면 재부팅할 때 이 부울을 지속적으로 사용할 수 있습니다.

    # setsebool -P virt_use_nfs 1
    Copy to Clipboard Toggle word wrap
4.9.3.4. 내보내기 설정

컨테이너 사용자가 볼륨을 읽고 쓸 수 있도록 하려면 NFS 서버의 내보낸 각 볼륨은 다음 조건을 준수해야 합니다.

  • 모든 내보내는 다음 형식을 사용하여 내보내야 합니다.

    /<example_fs> *(rw,root_squash)
    Copy to Clipboard Toggle word wrap
  • 마운트 옵션으로 트래픽을 허용하도록 방화벽을 구성해야 합니다.

    • NFSv4의 경우 기본 포트 2049(nfs)를 구성합니다.

      NFSv4

      # iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT
      Copy to Clipboard Toggle word wrap

    • NFSv3의 경우 2049(nfs), 20048(mountd) 및 111(portmapper)의 포트 3개가 있습니다.

      NFSv3

      # iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT
      Copy to Clipboard Toggle word wrap

      # iptables -I INPUT 1 -p tcp --dport 20048 -j ACCEPT
      Copy to Clipboard Toggle word wrap
      # iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPT
      Copy to Clipboard Toggle word wrap
  • 대상 Pod에서 액세스할 수 있도록 NFS 내보내기 및 디렉터리를 설정해야 합니다. 컨테이너의 기본 UID에 표시된 대로 내보내기를 컨테이너의 기본 UID로 설정하거나 위 그룹 ID에 표시된 대로 supplementalGroups를 사용하여 Pod 그룹 액세스 권한을 제공합니다.

4.9.4. 리소스 회수

NFS는 OpenShift Container Platform Recyclable 플러그인 인터페이스를 구현합니다. 자동 프로세스는 각 영구 볼륨에 설정된 정책에 따라 복구 작업을 처리합니다.

기본적으로 PV는 Retain으로 설정됩니다.

PVC에 대한 클레임이 삭제되고 PV가 해제되면 PV 오브젝트를 재사용해서는 안 됩니다. 대신 원래 볼륨과 동일한 기본 볼륨 세부 정보를 사용하여 새 PV를 생성해야 합니다.

예를 들어, 관리자가 이름이 nfs1인 PV를 생성합니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs1
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"
Copy to Clipboard Toggle word wrap

사용자가 PVC1을 생성하여 nfs1에 바인딩합니다. 그리고 사용자가 PVC1에서 nfs1 클레임을 해제합니다. 그러면 nfs1Released 상태가 됩니다. 관리자가 동일한 NFS 공유를 사용하려면 동일한 NFS 서버 세부 정보를 사용하여 새 PV를 생성해야 하지만 다른 PV 이름을 사용해야 합니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs2
spec:
  capacity:
    storage: 1Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.1
    path: "/"
Copy to Clipboard Toggle word wrap

원래 PV를 삭제하고 동일한 이름으로 다시 생성하는 것은 권장되지 않습니다. Released에서 Available로 PV의 상태를 수동으로 변경하면 오류가 발생하거나 데이터가 손실될 수 있습니다.

4.9.5. 추가 구성 및 문제 해결

사용되는 NFS 버전과 구성 방법에 따라 적절한 내보내기 및 보안 매핑에 필요한 추가 구성 단계가 있을 수 있습니다. 다음은 적용되는 몇 가지입니다.

Expand

NFSv4 마운트에서 소유권이 nobody:nobody인 모든 파일이 올바르게 표시되지 않습니다.

  • 이는 NFS의 /etc/idmapd.conf에 있는 ID 매핑 설정으로 인한 것일 수 있습니다.
  • 이 Red Hat 해결책을 참조하십시오.

NFSv4에서 ID 매핑 비활성화

  • NFS 서버에서 다음 명령을 실행합니다.

    # echo 'Y' > /sys/module/nfsd/parameters/nfs4_disable_idmapping
    Copy to Clipboard Toggle word wrap

4.10. Red Hat OpenShift Data Foundation

Red Hat OpenShift Container Storage는 내부 또는 하이브리드 클라우드 환경에서 파일, 블록 및 객체 스토리지를 지원하는 OpenShift Container Platform의 영구 스토리지 제공 업체입니다. Red Hat 스토리지 솔루션인 Red Hat OpenShift Container Storage는 배포, 관리 및 모니터링을 위해 OpenShift Container Platform과 완전히 통합되어 있습니다. 자세한 내용은 Red Hat OpenShift Data Foundation 설명서를 참조하십시오.

중요

OpenShift Container Platform과 함께 설치되는 가상 머신을 호스팅하는 하이퍼컨버지드 노드를 사용하는 가상화용 RHHI(Red Hat Hyperconverged Infrastructure)의 상단에 위치하는 OpenShift Container Storage는 지원되는 구성이 아닙니다. 지원되는 플랫폼에 대한 자세한 내용은 Red Hat OpenShift Data Foundation 지원 및 상호 운용성 가이드를 참조하십시오.

4.11. VMware vSphere 볼륨을 사용하는 영구 스토리지

OpenShift Container Platform을 사용하면 VMware vSphere의 VMDK(가상 머신 디스크) 볼륨을 사용할 수 있습니다. VMware vSphere를 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. Kubernetes 및 VMware vSphere에 대해 어느 정도 익숙한 것으로 가정합니다.

VMware vSphere 볼륨은 동적으로 프로비저닝할 수 있습니다. OpenShift Container Platform은 vSphere에서 디스크를 생성하고 이 디스크를 올바른 이미지에 연결합니다.

참고

OpenShift Container Platform은 새 볼륨을 독립 영구 디스크로 프로비저닝하여 클러스터의 모든 노드에서 볼륨을 자유롭게 연결 및 분리합니다. 결과적으로 스냅샷을 사용하는 볼륨을 백업하거나 스냅샷에서 볼륨을 복원할 수 없습니다. 자세한 내용은 스냅 샷 제한 을 참조하십시오.

Kubernetes 영구 볼륨 프레임워크를 사용하면 관리자는 영구 스토리지로 클러스터를 프로비저닝하고 사용자가 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다.

영구 볼륨은 단일 프로젝트 또는 네임스페이스에 바인딩되지 않으며, OpenShift Container Platform 클러스터에서 공유할 수 있습니다. 영구 볼륨 클레임은 프로젝트 또는 네임스페이스에 고유하며 사용자가 요청할 수 있습니다.

중요

새로운 설치의 경우 OpenShift Container Platform 4.13 이상에서는 vSphere in-tree 볼륨 플러그인에 대한 자동 마이그레이션을 동등한 CSI 드라이버로 제공합니다. OpenShift Container Platform 4.15 이상으로 업데이트하면 자동 마이그레이션도 제공됩니다. 업데이트 및 마이그레이션에 대한 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

CSI 자동 마이그레이션이 원활해야 합니다. 마이그레이션은 영구 볼륨, 영구 볼륨 클레임 및 스토리지 클래스와 같은 기존 API 오브젝트를 사용하는 방법을 변경하지 않습니다.

4.11.1. 동적으로 VMware vSphere 볼륨 프로비저닝

동적으로 VMware vSphere 볼륨 프로비저닝은 권장되는 방법입니다.

4.11.2. 사전 요구 사항

  • 사용하는 구성 요소의 요구사항을 충족하는 VMware vSphere 버전 6 인스턴스에 OpenShift Container Platform 클러스터가 설치되어 있어야 합니다. vSphere 버전 지원에 대한 자세한 내용은 vSphere에 클러스터 설치를 참조하십시오.

다음 절차 중 하나를 사용하여 기본 스토리지 클래스를 사용하여 이러한 볼륨을 동적으로 프로비저닝할 수 있습니다.

4.11.2.1. UI를 사용하여 VMware vSphere 볼륨을 동적으로 프로비저닝

OpenShift Container Platform은 볼륨을 프로비저닝하기 위해 thin 디스크 형식을 사용하는 이름이 thin인 기본 스토리지 클래스를 설치합니다.

사전 요구 사항

  • OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다.

절차

  1. OpenShift Container Platform 콘솔에서 스토리지영구 볼륨 클레임을 클릭합니다.
  2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.
  3. 결과 페이지에 필요한 옵션을 정의합니다.

    1. thin 스토리지 클래스를 선택합니다.
    2. 스토리지 클레임의 고유한 이름을 입력합니다.
    3. 액세스 모드를 선택하여 생성된 스토리지 클레임에 대한 읽기 및 쓰기 액세스를 결정합니다.
    4. 스토리지 클레임의 크기를 정의합니다.
  4. 만들기를 클릭하여 영구 볼륨 클레임을 생성하고 영구 볼륨을 생성합니다.
4.11.2.2. CLI를 사용하여 VMware vSphere 볼륨을 동적으로 프로비저닝

OpenShift Container Platform은 볼륨 프로비저닝에 thin 디스크 형식을 사용하는 이름이 thin인 기본 StorageClass를 설치합니다.

사전 요구 사항

  • OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다.

절차(CLI)

  1. 다음 콘텐츠와 함께 pvc.yaml 파일을 생성하여 VMware vSphere PersistentVolumeClaim을 정의할 수 있습니다.

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: pvc 
    1
    
    spec:
      accessModes:
      - ReadWriteOnce 
    2
    
      resources:
        requests:
          storage: 1Gi 
    3
    Copy to Clipboard Toggle word wrap
    1
    영구 볼륨 오브젝트를 표시하는 고유한 이름입니다.
    2
    영구 볼륨 클레임의 액세스 모드입니다. ReadWriteOnce를 사용하면 단일 노드에서 읽기 및 쓰기 권한으로 볼륨을 마운트할 수 있습니다.
    3
    영구 볼륨 클레임의 크기입니다.
  2. 다음 명령을 입력하여 파일에서 PersistentVolumeClaim 객체를 만듭니다.

    $ oc create -f pvc.yaml
    Copy to Clipboard Toggle word wrap

4.11.3. 정적으로 프로비저닝 VMware vSphere 볼륨

VMware vSphere 볼륨을 정적으로 프로비저닝하려면 영구 볼륨 프레임워크를 참조하기 위해 가상 머신 디스크를 생성해야 합니다.

사전 요구 사항

  • OpenShift Container Platform에서 볼륨으로 마운트하기 전에 기본 인프라에 스토리지가 있어야 합니다.

절차

  1. 가상 머신 디스크를 생성합니다. VMDK(가상 머신 디스크)는 정적으로 VMware vSphere 볼륨을 프로비저닝하기 전에 수동으로 생성해야 합니다. 다음 방법 중 하나를 사용합니다.

    • vmkfstools를 사용하여 생성합니다. SSH(Secure Shell)를 통해 ESX에 액세스한 후 다음 명령을 사용하여 VMDK 볼륨을 생성합니다.

      $ vmkfstools -c <size> /vmfs/volumes/<datastore-name>/volumes/<disk-name>.vmdk
      Copy to Clipboard Toggle word wrap
    • vmware-diskmanager를 사용하여 생성합니다.

      $ shell vmware-vdiskmanager -c -t 0 -s <size> -a lsilogic <disk-name>.vmdk
      Copy to Clipboard Toggle word wrap
  2. VMDK를 참조하는 영구 볼륨을 생성합니다. PersistentVolume 오브젝트 정의를 사용하여 pv1.yaml 파일을 생성합니다.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv1 
    1
    
    spec:
      capacity:
        storage: 1Gi 
    2
    
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      vsphereVolume: 
    3
    
        volumePath: "[datastore1] volumes/myDisk"  
    4
    
        fsType: ext4  
    5
    Copy to Clipboard Toggle word wrap
    1
    볼륨의 이름입니다. 이 이름을 사용하여 영구 볼륨 클레임 또는 Pod에 의해 식별됩니다.
    2
    이 볼륨에 할당된 스토리지의 용량입니다.
    3
    vSphere 볼륨을 위해 vsphereVolume과 함께 사용되는 볼륨 유형입니다. 레이블은 vSphere VMDK 볼륨을 Pod에 마운트하는 데 사용됩니다. 볼륨의 내용은 마운트 해제 시 보존됩니다. 볼륨 유형은 VMFS 및 VSAN 데이터 저장소를 지원합니다.
    4
    사용할 기존 VMDK 볼륨입니다. vmkfstools를 사용하는 경우 이전에 설명된 대로 볼륨 정의에서 데이터 저장소의 이름을 대괄호 []로 감싸야 합니다.
    5
    마운트할 파일 시스템 유형입니다. 예를 들어, ext4, xfs 또는 기타 파일 시스템이 이에 해당합니다.
    중요

    볼륨이 포맷 및 프로비저닝된 후 fsType 매개변수 값을 변경하면 데이터가 손실되거나 Pod 오류가 발생할 수 있습니다.

  3. 파일에서 PersistentVolume 오브젝트를 만듭니다.

    $ oc create -f pv1.yaml
    Copy to Clipboard Toggle word wrap
  4. 이전 단계에서 생성한 영구 볼륨 클레임에 매핑되는 영구 볼륨 클레임을 생성합니다. PersistentVolumeClaim 오브젝트 정의를 사용하여 pvc1.yaml 파일을 생성합니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc1 
    1
    
    spec:
      accessModes:
        - ReadWriteOnce 
    2
    
      resources:
       requests:
         storage: "1Gi" 
    3
    
      volumeName: pv1 
    4
    Copy to Clipboard Toggle word wrap
    1
    영구 볼륨 오브젝트를 표시하는 고유한 이름입니다.
    2
    영구 볼륨 클레임의 액세스 모드입니다. ReadWriteOnce를 사용하면 단일 노드에서 읽기 및 쓰기 권한으로 볼륨을 마운트할 수 있습니다.
    3
    영구 볼륨 클레임의 크기입니다.
    4
    기존 영구 볼륨의 이름입니다.
  5. 파일에서 PersistentVolumeClaim 오브젝트를 만듭니다.

    $ oc create -f pvc1.yaml
    Copy to Clipboard Toggle word wrap
4.11.3.1. VMware vSphere 볼륨 포맷

OpenShift Container Platform이 볼륨을 마운트하고 컨테이너에 전달하기 전에 PersistentVolume(PV) 정의에 있는 fsType 매개변수 값에 의해 지정된 파일 시스템이 볼륨에 포함되어 있는지 확인합니다. 장치가 파일 시스템으로 포맷되지 않으면 장치의 모든 데이터가 삭제되고 장치는 지정된 파일 시스템에서 자동으로 포맷됩니다.

OpenShift Container Platform은 처음 사용하기 전에 포맷되므로 vSphere 볼륨을 PV로 사용할 수 있습니다.

5장. 로컬 스토리지를 사용한 영구 스토리지

5.1. 로컬 스토리지 개요

다음 솔루션을 사용하여 로컬 스토리지를 프로비저닝할 수 있습니다.

  • 호스트패스 프로비저너(HPP)
  • 로컬 스토리지 운영자(LSO)
  • 논리 볼륨 관리자(LVM) 스토리지
주의

이러한 솔루션은 노드 로컬 스토리지 프로비저닝만 지원합니다. 작업 부하는 저장소를 제공하는 노드에 바인딩됩니다. 노드를 사용할 수 없게 되면 작업 부하도 사용할 수 없게 됩니다. 노드 장애가 발생해도 워크로드 가용성을 유지하려면 활성 또는 수동 복제 메커니즘을 통해 스토리지 데이터 복제를 보장해야 합니다.

5.1.1. HostPath Provisioner 기능 개요

HostPath Provisioner(HPP)를 사용하여 다음 작업을 수행할 수 있습니다.

  • 로컬 스토리지를 프로비저닝하기 위해 호스트 파일 시스템 경로를 스토리지 클래스에 매핑합니다.
  • 저장소 소비를 위해 노드의 파일 시스템 경로를 구성하기 위해 저장소 클래스를 정적으로 생성합니다.
  • 스토리지 클래스에 따라 영구 볼륨(PV)을 정적으로 프로비저닝합니다.
  • 기본 스토리지 토폴로지를 파악하면서 워크로드와 PersistentVolumeClaims(PVC)를 생성합니다.
참고

HPP는 업스트림 Kubernetes에서 사용할 수 있습니다. 하지만 상류 Kubernetes의 HPP를 사용하는 것은 권장되지 않습니다.

5.1.2. 로컬 스토리지 운영자 기능 개요

LSO(Local Storage Operator)를 사용하여 다음 작업을 수행할 수 있습니다.

  • 장치 구성을 수정하지 않고 저장 장치(디스크 또는 파티션)를 저장 클래스에 할당합니다.
  • LocalVolume 사용자 정의 리소스(CR)를 구성하여 PV 및 스토리지 클래스를 정적으로 프로비저닝합니다.
  • 기본 스토리지 토폴로지를 파악하면서 워크로드와 PVC를 생성합니다.
참고

LSO는 Red Hat에서 개발하고 제공합니다.

5.1.3. LVM 스토리지 기능 개요

LVM(논리 볼륨 관리자) 스토리지를 사용하여 다음 작업을 수행할 수 있습니다.

  • 저장 장치(디스크 또는 파티션)를 lvm2 볼륨 그룹으로 구성하고 볼륨 그룹을 스토리지 클래스로 노출합니다.
  • 노드 토폴로지를 고려하지 않고 PVC를 사용하여 워크로드를 생성하고 스토리지를 요청합니다.

LVM 스토리지는 TopoLVM CSI 드라이버를 사용하여 토폴로지의 노드에 스토리지 공간을 동적으로 할당하고 PV를 프로비저닝합니다.

참고

LVM 스토리지는 Red Hat에서 개발하고 유지관리합니다. LVM 스토리지와 함께 제공되는 CSI 드라이버는 업스트림 프로젝트인 "topolvm"입니다.

5.1.4. LVM 스토리지, LSO, HPP 비교

다음 섹션에서는 로컬 스토리지를 프로비저닝하기 위해 LVM 스토리지, 로컬 스토리지 운영자(LSO), HostPath 프로비저너(HPP)가 제공하는 기능을 비교합니다.

5.1.4.1. 스토리지 유형 및 파일 시스템에 대한 지원 비교

다음 표는 로컬 스토리지를 프로비저닝하기 위해 LVM 스토리지, 로컬 스토리지 운영자(LSO), 호스트 경로 프로비저너(HPP)가 제공하는 스토리지 유형과 파일 시스템에 대한 지원을 비교합니다.

Expand
표 5.1. 스토리지 유형 및 파일 시스템에 대한 지원 비교
기능성LVM 스토리지LSOHPP

블록 스토리지 지원

제공됨

없음

파일 저장 지원

제공됨

제공됨

제공됨

객체 저장소 지원 [1]

없음

없음

없음

사용 가능한 파일 시스템

ext4, xfs

ext4, xfs

노드에서 사용 가능한 마운트된 시스템이 지원됩니다.

  1. 어떤 솔루션(LVM 스토리지, LSO, HPP)도 개체 스토리지를 지원하지 않습니다. 따라서 개체 스토리지를 사용하려면 Red Hat OpenShift Data Foundation의 MultiClusterGateway 와 같은 S3 개체 스토리지 솔루션이 필요합니다. 모든 솔루션은 S3 개체 스토리지 솔루션을 위한 기반 스토리지 공급자 역할을 할 수 있습니다.
5.1.4.2. 핵심 기능 지원 비교

다음 표에서는 LVM 스토리지, 로컬 스토리지 운영자(LSO), HostPath 프로비저너(HPP)가 로컬 스토리지 프로비저닝을 위한 핵심 기능을 지원하는 방식을 비교합니다.

Expand
표 5.2. 핵심 기능 지원 비교
기능성LVM 스토리지LSOHPP

자동 파일 시스템 포맷 지원

제공됨

제공됨

해당 없음

동적 프로비저닝 지원

제공됨

없음

없음

소프트웨어 Redundant Array of Independent Disks(RAID) 어레이 사용 지원

제공됨

4.15 이상에서 지원됩니다.

제공됨

제공됨

투명한 디스크 암호화 지원

제공됨

4.16 이상에서 지원됩니다.

제공됨

제공됨

볼륨 기반 디스크 암호화 지원

없음

없음

아니요

연결 해제된 설치 지원

제공됨

제공됨

제공됨

PVC 확장 지원

제공됨

없음

없음

볼륨 스냅샷 및 볼륨 복제 지원

제공됨

없음

없음

씬 프로비저닝 지원

제공됨

장치는 기본적으로 씬 프로비저닝됩니다.

제공됨

씬 프로비저닝 볼륨을 가리키도록 장치를 구성할 수 있습니다.

제공됨

씬 프로비저닝된 볼륨을 가리키도록 경로를 구성할 수 있습니다.

자동 디스크 검색 및 설정 지원

제공됨

자동 디스크 검색은 설치 및 런타임 중에 사용할 수 있습니다. 기존 스토리지 클래스의 스토리지 용량을 늘리기 위해 LVMCluster 사용자 정의 리소스(CR)에 디스크를 동적으로 추가할 수도 있습니다.

기술 프리뷰

설치 중에 자동 디스크 검색이 가능합니다.

없음

5.1.4.3. 성능 및 격리 기능 비교

다음 표는 로컬 스토리지 프로비저닝에서 LVM 스토리지, 로컬 스토리지 운영자(LSO), 호스트경로 프로비저너(HPP)의 성능과 격리 기능을 비교한 것입니다.

Expand
표 5.3. 성능 및 격리 기능 비교
기능성LVM 스토리지LSOHPP

성능

동일한 스토리지 클래스를 사용하는 모든 워크로드에는 I/O 속도가 공유됩니다.

블록 스토리지는 직접적인 I/O 작업을 허용합니다.

씬 프로비저닝은 성능에 영향을 미칠 수 있습니다.

I/O는 LSO 구성에 따라 달라집니다.

블록 스토리지는 직접적인 I/O 작업을 허용합니다.

동일한 스토리지 클래스를 사용하는 모든 워크로드에는 I/O 속도가 공유됩니다.

기본 파일 시스템이 부과하는 제한은 I/O 속도에 영향을 미칠 수 있습니다.

격리 경계 [1]

LVM 논리 볼륨(LV)

HPP에 비해 더 높은 수준의 격리를 제공합니다.

LVM 논리 볼륨(LV)

HPP에 비해 더 높은 수준의 격리를 제공합니다.

파일 시스템 경로

LSO 및 LVM 스토리지에 비해 낮은 수준의 격리를 제공합니다.

  1. 격리 경계는 로컬 스토리지 리소스를 사용하는 서로 다른 작업 부하나 애플리케이션 간의 분리 수준을 말합니다.
5.1.4.4. 추가 기능 지원 비교

다음 표는 로컬 스토리지를 프로비저닝하기 위해 LVM 스토리지, 로컬 스토리지 운영자(LSO), 호스트경로 프로비저너(HPP)가 제공하는 추가 기능을 비교한 것입니다.

Expand
표 5.4. 추가 기능 지원 비교
기능성LVM 스토리지LSOHPP

일반 임시 볼륨 지원

제공됨

없음

없음

CSI 인라인 임시 볼륨 지원

없음

없음

없음

스토리지 토폴로지 지원

제공됨

CSI 노드 토폴로지 지원

제공됨

LSO는 노드 허용 오차를 통해 스토리지 토폴로지에 대한 부분적인 지원을 제공합니다.

없음

RWX( ReadWriteMany ) 액세스 모드 지원 [1]

없음

없음

없음

  1. 모든 솔루션(LVM Storage, LSO 및 HPP)에는 RWO( ReadWriteOnce ) 액세스 모드가 있습니다. RWO 액세스 모드를 사용하면 동일한 노드의 여러 Pod에서 액세스할 수 있습니다.

5.2. 로컬 블록을 사용하는 영구 스토리지

OpenShift Container Platform은 로컬 볼륨을 사용하여 영구 스토리지를 통해 프로비저닝될 수 있습니다. 로컬 영구 볼륨을 사용하면 표준 영구 볼륨 클레임 인터페이스를 사용하여 디스크 또는 파티션과 같은 로컬 스토리지 장치에 액세스할 수 있습니다.

시스템에서 볼륨 노드 제약 조건을 인식하고 있기 때문에 로컬 볼륨은 노드에 수동으로 Pod를 예약하지 않고 사용할 수 있습니다. 그러나 로컬 볼륨은 여전히 기본 노드의 가용성에 따라 달라지며 일부 애플리케이션에는 적합하지 않습니다.

참고

로컬 볼륨은 정적으로 생성된 영구 볼륨으로 사용할 수 있습니다.

5.2.1. Local Storage Operator 설치

Local Storage Operator는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. 다음 절차에 따라 이 Operator를 설치하고 구성하여 클러스터에서 로컬 볼륨을 활성화합니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔 또는 CLI(명령줄 인터페이스)에 액세스할 수 있습니다.

절차

  1. openshift-local-storage 프로젝트를 생성합니다.

    $ oc adm new-project openshift-local-storage
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: 인프라 노드에서 로컬 스토리지 생성을 허용합니다.

    Local Storage Operator를 사용하여 로깅 및 모니터링과 같은 구성 요소를 지원하는 인프라 노드에 볼륨을 생성할 수 있습니다.

    Local Storage Operator에 작업자 노드가 아닌 인프라 노드가 포함되도록 기본 노드 선택기를 조정해야 합니다.

    Local Storage Operator가 클러스터 전체 기본 선택기를 상속하지 못하도록 하려면 다음 명령을 입력합니다.

    $ oc annotate namespace openshift-local-storage openshift.io/node-selector=''
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 단일 노드 배포의 CPU 관리 풀에서 로컬 스토리지를 실행할 수 있습니다.

    단일 노드 배포에서 Local Storage Operator를 사용하고 management 풀에 속하는 CPU를 사용할 수 있습니다. 관리 워크로드 파티셔닝을 사용하는 단일 노드 설치에서 이 단계를 수행합니다.

    Local Storage Operator가 관리 CPU 풀에서 실행되도록 하려면 다음 명령을 실행합니다.

    $ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'
    Copy to Clipboard Toggle word wrap

UI에서

웹 콘솔에서 Local Storage Operator를 설치하려면 다음 단계를 따르십시오.

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. OperatorsOperatorHub로 이동합니다.
  3. Local Storage를 필터 상자에 입력하여 Local Storage Operator를 찾습니다.
  4. 설치를 클릭합니다.
  5. Operator 설치 페이지에서 클러스터의 특정 네임스페이스를 선택합니다. 드롭다운 메뉴에서 openshift-local-storage를 선택합니다.
  6. 업데이트 채널승인 전략 값을 원하는 값으로 조정합니다.
  7. 설치를 클릭합니다.

완료되면 Local Storage Operator가 웹 콘솔의 설치된 Operator 섹션에 나열됩니다.

CLI에서

  1. CLI에서 Local Storage Operator를 설치합니다.

    1. openshift-local-storage.yaml과 같은 Local Storage Operator의 Operator 그룹 및 서브스크립션을 정의하는 오브젝트 YAML 파일을 생성합니다.

      예: openshift-local-storage.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: local-operator-group
        namespace: openshift-local-storage
      spec:
        targetNamespaces:
          - openshift-local-storage
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: local-storage-operator
        namespace: openshift-local-storage
      spec:
        channel: stable
        installPlanApproval: Automatic 
      1
      
        name: local-storage-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap

      1
      설치 계획에 대한 사용자 승인 정책입니다.
  2. 다음 명령을 입력하여 Local Storage Operator 오브젝트를 생성합니다.

    $ oc apply -f openshift-local-storage.yaml
    Copy to Clipboard Toggle word wrap

    이 시점에서 OLM(Operator Lifecycle Manager)은 Local Storage Operator를 인식합니다. Operator의 ClusterServiceVersion (CSV)이 대상 네임스페이스에 표시되고 Operator가 제공한 API를 작성할 수 있어야 합니다.

  3. 모든 Pod 및 Local Storage Operator가 생성되었는지 확인하여 로컬 스토리지 설치를 확인합니다.

    1. 필요한 모든 Pod가 생성되었는지 확인합니다.

      $ oc -n openshift-local-storage get pods
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                      READY   STATUS    RESTARTS   AGE
      local-storage-operator-746bf599c9-vlt5t   1/1     Running   0          19m
      Copy to Clipboard Toggle word wrap

    2. CSV(ClusterServiceVersion) YAML 매니페스트를 확인하여 openshift-local-storage 프로젝트에서 Local Storage Operator를 사용할 수 있는지 확인합니다.

      $ oc get csvs -n openshift-local-storage
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                         DISPLAY         VERSION               REPLACES   PHASE
      local-storage-operator.4.2.26-202003230335   Local Storage   4.2.26-202003230335              Succeeded
      Copy to Clipboard Toggle word wrap

모든 확인이 통과되면 Local Storage Operator가 성공적으로 설치됩니다.

5.2.2. Local Storage Operator를 사용하여 로컬 볼륨을 프로비저닝

동적 프로비저닝을 통해 로컬 볼륨을 생성할 수 없습니다. 대신 Local Storage Operator에서 영구 볼륨을 생성할 수 있습니다. 로컬 볼륨 프로비저너는 정의된 리소스에 지정된 경로에서 모든 파일 시스템 또는 블록 볼륨 장치를 찾습니다.

사전 요구 사항

  • Local Storage Operator가 설치되어 있습니다.
  • 다음 조건을 충족하는 로컬 디스크가 있습니다.

    • 노드에 연결되어 있습니다.
    • 마운트되지 않았습니다.
    • 파티션이 포함되어 있지 않습니다.

프로세스

  1. 로컬 볼륨 리소스를 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.

    참고

    동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 영구 볼륨(PV)이 생성됩니다.

    예: Filesystem

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 
    1
    
    spec:
      nodeSelector: 
    2
    
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-140-183
              - ip-10-0-158-139
              - ip-10-0-164-33
      storageClassDevices:
        - storageClassName: "local-sc" 
    3
    
          forceWipeDevicesAndDestroyAllData: false 
    4
    
          volumeMode: Filesystem 
    5
    
          fsType: xfs 
    6
    
          devicePaths: 
    7
    
            - /path/to/device 
    8
    Copy to Clipboard Toggle word wrap

    1
    Local Storage Operator가 설치된 네임스페이스입니다.
    2
    선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는 oc get node에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다.
    3
    영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다. Local Storage Operator가 존재하지 않는 경우 스토리지 클래스를 자동으로 생성합니다. 이 로컬 볼륨 세트를 고유하게 식별하는 스토리지 클래스를 사용해야 합니다.
    4
    이 설정은 로컬 스토리지 운영자(LSO) 프로비저닝에 사용할 디스크를 준비하기 위해 파티션 테이블 서명(매직 문자열)을 제거하는 wipefs를 호출할지 여부를 정의합니다. 서명 이외의 다른 데이터는 삭제되지 않습니다. 기본값은 "false"입니다( wipefs가 호출되지 않음). 이전 데이터가 재사용되어야 하는 디스크에 남아 있는 경우, forceWipeDevicesAndDestroyAllData를 "true"로 설정하면 유용할 수 있습니다. 이러한 시나리오에서 이 필드를 true로 설정하면 관리자가 디스크를 수동으로 지울 필요가 없습니다. 이러한 사례로는 노드를 여러 번 재배포할 수 있는 단일 노드 OpenShift(SNO) 클러스터 환경이나 이전 데이터를 개체 스토리지 장치(OSD)로 사용할 계획인 디스크에 그대로 둘 수 있는 OpenShift Data Foundation(ODF)을 사용하는 경우가 있습니다.
    5
    로컬 볼륨의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.
    참고

    원시 블록 볼륨( volumeMode: Block )은 파일 시스템으로 포맷되지 않았습니다. Pod에서 실행되는 모든 애플리케이션이 원시 블록 장치를 사용할 수 있는 경우에만 이 모드를 사용합니다.

    6
    로컬 볼륨이 처음 마운트될 때 생성되는 파일 시스템입니다.
    7
    선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.
    8
    이 값을 LocalVolume 리소스의 실제 로컬 디스크 파일 경로(예: /dev/disk/ by-id /wwn )로 바꿉니다. 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.
    참고

    RHEL KVM과 함께 OpenShift Container Platform을 실행하는 경우 VM 디스크에 일련 번호를 할당해야 합니다. 그렇지 않으면 재부팅 후 VM 디스크를 식별할 수 없습니다. virsh edit <VM> 명령을 사용하여 <serial>mydisk</serial> 정의를 추가할 수 있습니다.

    예: 블록

    apiVersion: "local.storage.openshift.io/v1"
    kind: "LocalVolume"
    metadata:
      name: "local-disks"
      namespace: "openshift-local-storage" 
    1
    
    spec:
      nodeSelector: 
    2
    
        nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-136-143
              - ip-10-0-140-255
              - ip-10-0-144-180
      storageClassDevices:
        - storageClassName: "local-sc" 
    3
    
          forceWipeDevicesAndDestroyAllData: false 
    4
    
          volumeMode: Block 
    5
    
          devicePaths: 
    6
    
            - /path/to/device 
    7
    Copy to Clipboard Toggle word wrap

    1
    Local Storage Operator가 설치된 네임스페이스입니다.
    2
    선택 사항: 로컬 스토리지 볼륨이 연결된 노드 목록이 포함된 노드 선택기입니다. 이 예에서는 oc get node에서 가져온 노드 호스트 이름을 사용합니다. 값을 정의하지 않으면 Local Storage Operator에서 사용 가능한 모든 노드에서 일치하는 디스크를 찾습니다.
    3
    영구 볼륨 오브젝트를 생성할 때 사용할 스토리지 클래스의 이름입니다.
    4
    이 설정은 로컬 스토리지 운영자(LSO) 프로비저닝에 사용할 디스크를 준비하기 위해 파티션 테이블 서명(매직 문자열)을 제거하는 wipefs를 호출할지 여부를 정의합니다. 서명 이외의 다른 데이터는 삭제되지 않습니다. 기본값은 "false"입니다( wipefs가 호출되지 않음). 이전 데이터가 재사용되어야 하는 디스크에 남아 있는 경우, forceWipeDevicesAndDestroyAllData를 "true"로 설정하면 유용할 수 있습니다. 이러한 시나리오에서 이 필드를 true로 설정하면 관리자가 디스크를 수동으로 지울 필요가 없습니다. 이러한 사례로는 노드를 여러 번 재배포할 수 있는 단일 노드 OpenShift(SNO) 클러스터 환경이나 이전 데이터를 개체 스토리지 장치(OSD)로 사용할 계획인 디스크에 그대로 둘 수 있는 OpenShift Data Foundation(ODF)을 사용하는 경우가 있습니다.
    5
    로컬 볼륨의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.
    6
    선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.
    7
    이 값을 LocalVolume 리소스의 실제 로컬 디스크 파일 경로(예: dev/disk/ by-id /wwn )로 바꿉니다. 프로비저너가 배포되면 이러한 로컬 디스크에 PV가 생성됩니다.
    참고

    RHEL KVM과 함께 OpenShift Container Platform을 실행하는 경우 VM 디스크에 일련 번호를 할당해야 합니다. 그렇지 않으면 재부팅 후 VM 디스크를 식별할 수 없습니다. virsh edit <VM> 명령을 사용하여 <serial>mydisk</serial> 정의를 추가할 수 있습니다.

  2. OpenShift Container Platform 클러스터에 로컬 볼륨 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.

    $ oc create -f <local-volume>.yaml
    Copy to Clipboard Toggle word wrap
  3. 프로비저너가 생성되었고 해당 데몬 세트가 생성되었는지 확인합니다.

    $ oc get all -n openshift-local-storage
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                          READY   STATUS    RESTARTS   AGE
    pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
    pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
    pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
    pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
    
    NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
    service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
    
    NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
    
    NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/local-storage-operator   1/1     1            1           14m
    
    NAME                                                DESIRED   CURRENT   READY   AGE
    replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m
    Copy to Clipboard Toggle word wrap

    필요한 데몬 세트 프로세스 및 현재 개수를 기록해 둡니다. 0의 개수는 레이블 선택기가 유효하지 않음을 나타냅니다.

  4. 영구 볼륨이 생성되었는지 확인합니다.

    $ oc get pv
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
    local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
    local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
    local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m
    Copy to Clipboard Toggle word wrap

중요

LocalVolume 오브젝트 편집은 안전하지 않은 작업이므로 이를 수행하면 기존 영구 볼륨의 fsType 또는 volumeMode가 변경되지 않습니다.

5.2.3. Local Storage Operator없이 로컬 볼륨 프로비저닝

동적 프로비저닝을 통해 로컬 볼륨을 생성할 수 없습니다. 대신 개체 정의에서 영구 볼륨(PV)을 정의하여 영구 볼륨을 생성할 수 있습니다. 로컬 볼륨 프로비저너는 정의된 리소스에 지정된 경로에서 모든 파일 시스템 또는 블록 볼륨 장치를 찾습니다.

중요

PVC가 삭제될 때 PV를 수동으로 프로비저닝하면 PV를 재사용할 때 데이터 누출의 위험이 발생할 수 있습니다. Local Storage Operator는 로컬 PV를 프로비저닝할 때 장치의 라이프 사이클을 자동화하는 것이 좋습니다.

사전 요구 사항

  • 로컬 디스크가 OpenShift Container Platform 노드에 연결되어 있습니다.

프로세스

  1. PV를 정의합니다. PersistentVolume 오브젝트 정의로 example-pv-filesystem.yaml 또는 example-pv-block.yaml과 같은 파일을 생성합니다. 이 리소스는 로컬 볼륨에 대한 노드 및 경로를 정의해야 합니다.

    참고

    동일한 장치에 다른 스토리지 클래스 이름을 사용하지 마십시오. 이렇게 하면 여러 PV가 생성됩니다.

    example-pv-filesystem.yaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: example-pv-filesystem
    spec:
      capacity:
        storage: 100Gi
      volumeMode: Filesystem 
    1
    
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: local-sc 
    2
    
      local:
        path: /dev/xvdf 
    3
    
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - example-node
    Copy to Clipboard Toggle word wrap

    1
    PV의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.
    2
    PV 리소스를 생성할 때 사용할 스토리지 클래스의 이름입니다. 이 PV 세트를 고유하게 식별하는 스토리지 클래스를 사용합니다.
    3
    선택할 로컬 저장 장치 목록이 포함된 경로 또는 디렉토리입니다. Filesystem volumeMode 를 사용해서만 디렉토리를 지정할 수 있습니다.
    참고

    원시 블록 볼륨(volumeMode: block)은 파일 시스템과 함께 포맷되지 않습니다. Pod에서 실행되는 모든 애플리케이션이 원시 블록 장치를 사용할 수 있는 경우에만 이 모드를 사용합니다.

    example-pv-block.yaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: example-pv-block
    spec:
      capacity:
        storage: 100Gi
      volumeMode: Block 
    1
    
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      storageClassName: local-sc 
    2
    
      local:
        path: /dev/xvdf 
    3
    
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - example-node
    Copy to Clipboard Toggle word wrap

    1
    PV의 유형을 정의하는 Filesystem 또는 Block 중 하나에 해당 볼륨 모드입니다.
    2
    PV 리소스를 생성할 때 사용할 스토리지 클래스의 이름입니다. 이 PV 세트를 고유하게 식별하는 스토리지 클래스를 사용해야 합니다.
    3
    선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.
  2. OpenShift Container Platform 클러스터에 PV 리소스를 생성합니다. 방금 생성한 파일을 지정합니다.

    $ oc create -f <example-pv>.yaml
    Copy to Clipboard Toggle word wrap
  3. 로컬 PV가 생성되었는지 확인합니다.

    $ oc get pv
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS    REASON   AGE
    example-pv-filesystem   100Gi      RWO            Delete           Available                        local-sc            3m47s
    example-pv1             1Gi        RWO            Delete           Bound       local-storage/pvc1   local-sc            12h
    example-pv2             1Gi        RWO            Delete           Bound       local-storage/pvc2   local-sc            12h
    example-pv3             1Gi        RWO            Delete           Bound       local-storage/pvc3   local-sc            12h
    Copy to Clipboard Toggle word wrap

5.2.4. 로컬 볼륨 영구 볼륨 클레임 생성

로컬 볼륨은 Pod가 액세스할 수 있는 영구 볼륨 클레임(PVC)으로서 정적으로 생성되어야 합니다.

사전 요구 사항

  • 영구 볼륨은 로컬 볼륨 프로비저너를 사용하여 생성됩니다.

절차

  1. 해당 스토리지 클래스를 사용하여 PVC를 생성합니다.

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: local-pvc-name 
    1
    
    spec:
      accessModes:
      - ReadWriteOnce
      volumeMode: Filesystem 
    2
    
      resources:
        requests:
          storage: 100Gi 
    3
    
      storageClassName: local-sc 
    4
    Copy to Clipboard Toggle word wrap
    1
    PVC의 이름입니다.
    2
    PVC의 유형입니다. 기본값은 Filesystem입니다.
    3
    PVC에서 사용할 수 있는 스토리지 용량입니다.
    4
    클레임에 필요한 스토리지 클래스의 이름입니다.
  2. 방금 작성한 파일을 지정하여 OpenShift Container Platform 클러스터에서 PVC를 생성합니다.

    $ oc create -f <local-pvc>.yaml
    Copy to Clipboard Toggle word wrap

5.2.5. 로컬 클레임 연결

로컬 볼륨이 영구 볼륨 클레임에 매핑된 후 리소스 내부에서 지정할 수 있습니다.

사전 요구 사항

  • 동일한 네임스페이스에 영구 볼륨 클레임이 있어야 합니다.

절차

  1. 리소스 사양에 정의된 클레임을 포함합니다. 다음 예시는 Pod 내에서 영구 볼륨 클레임을 선언합니다.

    apiVersion: v1
    kind: Pod
    spec:
    # ...
      containers:
        volumeMounts:
        - name: local-disks 
    1
    
          mountPath: /data 
    2
    
      volumes:
      - name: local-disks
        persistentVolumeClaim:
          claimName: local-pvc-name 
    3
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    마운트할 볼륨의 이름입니다.
    2
    볼륨이 마운트된 Pod 내부의 경로입니다. 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너가 호스트 /dev/pts 파일과 같이 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다.
    3
    사용할 기존 영구 볼륨 클레임의 이름입니다.
  2. 방금 생성한 파일을 지정하여 OpenShift Container Platform 클러스터에 리소스를 생성합니다.

    $ oc create -f <local-pod>.yaml
    Copy to Clipboard Toggle word wrap

5.2.6. 로컬 스토리지 장치에 대한 검색 및 프로비저닝 자동화

로컬 스토리지 Operator는 로컬 스토리지 검색 및 프로비저닝을 자동화합니다. 이 기능을 사용하면 배포 중에 연결된 장치가 있는 베어 메탈, VMware 또는 AWS 스토어 인스턴스와 같이 동적 프로비저닝을 사용할 수 없는 경우 설치를 단순화할 수 있습니다.

중요

자동 검색 및 프로비저닝은 기술 프리뷰 기능 전용입니다. Technology Preview 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

중요

Red Hat OpenShift Data Foundation을 온프레미스에 배포하거나 플랫폼에 독립적인 배포에 사용하는 경우 자동 검색 및 프로비저닝이 완벽하게 지원됩니다.

다음 절차에 따라 로컬 장치를 자동으로 검색하고 선택한 장치에 대한 로컬 볼륨을 자동으로 프로비저닝하십시오.

주의

LocalVolumeSet 객체를 사용할 때는 주의하세요. 로컬 디스크에서 영구 볼륨(PV)을 자동으로 프로비저닝하는 경우 로컬 PV가 일치하는 모든 장치를 클레임할 수 있습니다. LocalVolumeSet 객체를 사용하는 경우 로컬 스토리지 운영자가 노드의 로컬 장치를 관리하는 유일한 엔터티인지 확인하세요. 노드를 두 번 이상 대상으로 하는 LocalVolumeSet 의 여러 인스턴스를 생성할 수 없습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있어야 합니다.
  • Local Storage Operator가 설치되어 있습니다.
  • OpenShift Container Platform 노드에 로컬 디스크가 연결되어 있습니다.
  • OpenShift Container Platform 웹 콘솔과 oc 명령줄 인터페이스(CLI)에 액세스할 수 있습니다.

절차

  1. 웹 콘솔에서 로컬 장치를 자동으로 검색할 수 있도록 하려면 다음을 수행합니다.

    1. Operators설치된 Operators를 클릭합니다.
    2. openshift-local-storage 네임스페이스에서 로컬 스토리지를 클릭합니다.
    3. 로컬 볼륨 검색 탭을 클릭합니다.
    4. 로컬 볼륨 검색 만들기를 클릭한 다음 양식 보기 또는 YAML 보기를 선택합니다.
    5. LocalVolumeDiscovery 오브젝트 매개변수를 구성합니다.
    6. 생성을 클릭합니다.

      로컬 스토리지 운영자는 auto-discover-devices 라는 이름의 로컬 볼륨 검색 인스턴스를 생성합니다.

  2. 노드에 사용 가능한 장치 목록을 표시하려면 다음을 수행합니다.

    1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
    2. 컴퓨팅노드로 이동합니다.
    3. 열기를 원하는 노드 이름을 클릭합니다. "노드 세부 정보" 페이지가 표시됩니다.
    4. 선택한 장치 목록을 표시하려면 디스크 탭을 선택합니다.

      로컬 디스크가 추가되거나 제거되면 장치 목록이 지속적으로 업데이트됩니다. 장치를 이름, 상태, 유형, 모델, 용량 및 모드로 필터링할 수 있습니다.

  3. 웹 콘솔에서 발견된 장치에 대한 로컬 볼륨을 자동으로 프로비저닝하려면 다음을 수행합니다.

    1. Operator설치된 Operator로 이동하고 Operator 목록에서 로컬 스토리지를 선택합니다.
    2. 로컬 볼륨 세트로컬 볼륨 세트 만들기를 선택합니다.
    3. 볼륨 세트 이름과 스토리지 클래스 이름을 입력합니다.
    4. 그에 따라 필터를 적용하려면 모든 노드 또는 노드 선택을 선택합니다.

      참고

      모든 노드 또는 노드 선택을 사용하여 필터링하는지의 여부와 관계없이 작업자 노드만 사용할 수 있습니다.

    5. 로컬 볼륨 세트에 적용할 디스크 유형, 모드, 크기 및 제한을 선택하고 만들기를 클릭합니다.

      몇 분 후에 “Operator 조정됨”을 나타내는 메시지가 표시됩니다.

  4. 대신 CLI에서 검색된 장치에 대한 로컬 볼륨을 프로비저닝하려면 다음을 수행합니다.

    1. 다음 예와 같이 local-volume-set.yaml과 같은 로컬 볼륨 세트를 정의하는 오브젝트 YAML 파일을 생성합니다.

      apiVersion: local.storage.openshift.io/v1alpha1
      kind: LocalVolumeSet
      metadata:
        name: example-autodetect
      spec:
        nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                    - worker-0
                    - worker-1
        storageClassName: local-sc 
      1
      
        volumeMode: Filesystem
        fsType: ext4
        maxDeviceCount: 10
        deviceInclusionSpec:
          deviceTypes: 
      2
      
            - disk
            - part
          deviceMechanicalProperties:
            - NonRotational
          minSize: 10G
          maxSize: 100G
          models:
            - SAMSUNG
            - Crucial_CT525MX3
          vendors:
            - ATA
            - ST2000LM
      Copy to Clipboard Toggle word wrap
      1
      검색된 장치에서 프로비저닝된 영구 볼륨에 대해 생성된 스토리지 클래스를 결정합니다. Local Storage Operator가 존재하지 않는 경우 스토리지 클래스를 자동으로 생성합니다. 이 로컬 볼륨 세트를 고유하게 식별하는 스토리지 클래스를 사용해야 합니다.
      2
      로컬 볼륨 세트 기능을 사용할 때 Local Storage Operator는 논리 볼륨 관리(LVM) 장치 사용을 지원하지 않습니다.
    2. 로컬 볼륨 세트 오브젝트를 생성합니다.

      $ oc apply -f local-volume-set.yaml
      Copy to Clipboard Toggle word wrap
    3. 로컬 영구 볼륨이 스토리지 클래스를 기반으로 동적으로 프로비저닝되었는지 확인합니다.

      $ oc get pv
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
      local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
      local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
      local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m
      Copy to Clipboard Toggle word wrap

참고

결과는 노드에서 제거된 후 삭제됩니다. 심볼릭 링크는 수동으로 제거해야 합니다.

5.2.7. Local Storage Operator Pod에서 허용 오차 사용

테인트를 노드에 적용하여 일반 워크로드를 실행하지 못하도록 할 수 있습니다. Local Storage Operator가 테인트된 노드를 사용하도록 허용하려면 Pod 또는 DaemonSet 정의에 허용 오차를 추가해야 합니다. 그러면 생성된 리소스가 이러한 테인트된 노드에서 실행될 수 있습니다.

LocalVolume 리소스를 통해 Local Storage Operator Pod에 허용 오차를 적용하고 노드 사양을 통해 노드에 테인트를 적용합니다. 노드의 테인트는 해당 테인트를 허용하지 않는 모든 Pod를 거절하도록 노드에 지시합니다. 다른 Pod에 없는 특정 테인트를 사용하면 Local Storage Operator Pod가 해당 노드에서도 실행될 수 있습니다.

중요

테인트 및 허용 오차는 key, value 및 effect로 구성되어 있습니다. 인수로는 key=value:effect로 표시됩니다. Operator는 이러한 매개 변수 중 하나를 비워두는 것을 허용합니다.

사전 요구 사항

  • Local Storage Operator가 설치되어 있습니다.
  • 로컬 디스크는 테인트와 함께 OpenShift Container Platform 노드에 연결되어 있습니다.
  • 테인트된 노드는 로컬 스토리지를 프로비저닝해야 합니다.

절차

테인트된 노드에서 스케줄링을 위해 로컬 볼륨을 구성하려면 다음을 수행하십시오.

  1. 다음 예와 같이 Pod를 정의하는 YAML 파일을 수정하고 LocalVolume 사양을 추가합니다.

      apiVersion: "local.storage.openshift.io/v1"
      kind: "LocalVolume"
      metadata:
        name: "local-disks"
        namespace: "openshift-local-storage"
      spec:
        tolerations:
          - key: localstorage 
    1
    
            operator: Equal 
    2
    
            value: "localstorage" 
    3
    
        storageClassDevices:
            - storageClassName: "local-sc"
              volumeMode: Block 
    4
    
              devicePaths: 
    5
    
                - /dev/xvdg
    Copy to Clipboard Toggle word wrap
    1
    노드에 추가한 키를 지정합니다.
    2
    / 매개변수가 일치할 것을 요구하도록 Equal Operator를 지정합니다. Operator가 Exists인 경우 시스템은 키가 존재하는지 확인하고 값을 무시합니다. Operator가 Equal 이면 키와 값이 일치해야 합니다.
    3
    테인트된 노드의 로컬 값을 지정합니다.
    4
    볼륨 모드(파일 시스템 또는 블록)는 로컬 볼륨의 유형을 정의합니다.
    5
    선택할 로컬 스토리지 장치 목록이 포함된 경로입니다.
  2. 선택 사항: 테인트된 노드에만 로컬 영구 볼륨을 생성하려면 다음 예와 같이 YAML 파일을 수정하고 LocalVolume 사양을 추가합니다.

    spec:
      tolerations:
        - key: node-role.kubernetes.io/master
          operator: Exists
    Copy to Clipboard Toggle word wrap

정의된 허용 오차가 결과 데몬 세트로 전달되어, 지정된 테인트를 포함하는 노드에 대해 디스크 제조 업체 및 프로비저너 Pod를 생성할 수 있습니다.

5.2.8. Local Storage Operator 지표

OpenShift Container Platform은 Local Storage Operator에 대한 다음 지표를 제공합니다.

  • lso_discovery_disk_count: 각 노드에서 발견된 총 장치 수
  • lso_lvset_provisioned_PV_count: LocalVolumeSet 개체에서 생성한 총 PV 수
  • lso_lvset_unmatched_disk_count: 기준 불일치로 인해 Local Storage Operator가 프로비저닝을 위해 선택하지 않은 총 디스크 수
  • lso_lvset_orphaned_symlink_count: LocalVolumeSet 개체 기준과 더 이상 일치하지 않는 PV가 있는 장치 수
  • lso_lv_orphaned_symlink_count: LocalVolume 오브젝트 기준과 더 이상 일치하지 않는 PV가 있는 장치 수
  • lso_lv_provisioned_PV_count: LocalVolume의 프로비저닝된 총 PV 수

이러한 측정 항목을 사용하려면 다음 중 하나를 수행하여 측정 항목을 활성화하세요.

  • 웹 콘솔에서 OperatorHub 의 Local Storage Operator를 설치할 때, 이 네임스페이스에서 Operator가 권장하는 클러스터 모니터링 사용 확인란을 선택합니다.
  • 다음 명령을 실행하여 Operator 네임스페이스에 openshift.io/cluster-monitoring=true 레이블을 수동으로 추가합니다.

    $ oc label ns/openshift-local-storage openshift.io/cluster-monitoring=true
    Copy to Clipboard Toggle word wrap

메트릭에 대한 자세한 내용은 관리자로서 메트릭에 액세스를 참조하세요.

5.2.9. Local Storage Operator 리소스 삭제

5.2.9.1. 로컬 볼륨 또는 로컬 볼륨 세트 제거

가끔 로컬 볼륨(LV)과 로컬 볼륨 세트(LVS)를 삭제해야 할 때가 있습니다.

사전 요구 사항

  • 영구 볼륨(PV)은 해제됨 또는 사용 가능 상태여야 합니다.

    주의

    아직 사용 중인 영구 볼륨을 삭제하면 데이터 손실 또는 손상이 발생할 수 있습니다.

프로세스

LV 또는 LVS를 삭제하려면 다음 단계를 완료하세요.

  1. 삭제되는 LV 또는 LVS가 소유한 바인딩된 PV가 있는 경우 해당 영구 볼륨 클레임(PVC)을 삭제하여 PV를 해제합니다.

    1. 특정 LV 또는 LVS가 소유한 바인딩된 PV를 찾으려면 다음 명령을 실행하세요.

      $ oc get pv --selector storage.openshift.com/owner-name=<LV_LVS_name> 
      1
      Copy to Clipboard Toggle word wrap
      1
      <LV_LVS_name> 은 LV 또는 LVS의 이름입니다.

      출력 예

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                 STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
      local-pv-3fa1c73    5Gi        RWO            Delete           Available                         slow           <unset>                          28s
      local-pv-1cec77cf   30Gi       RWX            Retain           Bound       openshift/storage     my-sc          <unset>                          168d
      Copy to Clipboard Toggle word wrap

      바운드 PV는 바운드 상태를 가지며, 해당 PVC는 CLAIM 열에 나타납니다. 이전 예에서 PV local-pv-1cec77cf 는 바인딩되고 해당 PVC는 openshift/storage 입니다.

    2. 다음 명령을 실행하여 삭제되는 LV 또는 LVS가 소유한 바인딩된 PV의 해당 PVC를 삭제합니다.

      $ oc delete pvc <name>
      Copy to Clipboard Toggle word wrap

      이 예에서는 PVC openshift/storage를 삭제합니다.

  2. 다음 명령을 실행하여 LV 또는 LVS를 삭제합니다.

    LV 삭제 명령

    $ oc delete lv <name>
    Copy to Clipboard Toggle word wrap

    또는

    LVS 삭제 명령

    $ oc delete lvs <name>
    Copy to Clipboard Toggle word wrap

  3. LV 또는 LVS가 소유한 PV에 보존 회수 정책이 있는 경우 중요한 데이터를 백업한 후 PV를 삭제하세요.

    참고

    삭제 정책이 적용된 PV는 LV 또는 LVS를 삭제하면 자동으로 삭제됩니다.

    1. Retain Reclaim 정책이 있는 PV를 찾으려면 다음 명령을 실행하세요.

      $ oc get pv
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS   REASON   AGE
      local-pv-1cec77cf   30Gi       RWX            Retain           Available                        my-sc                   168d
      Copy to Clipboard Toggle word wrap

      이 예에서 PV local-pv-1cec77cf 에는 Retain reclaim 정책이 있으므로 수동으로 삭제해야 합니다.

    2. 이 볼륨의 중요한 데이터는 백업해 두세요.
    3. 다음 명령을 실행하여 PV를 삭제합니다.

      $ oc delete pv <name>
      Copy to Clipboard Toggle word wrap

      이 예에서는 PV local-pv-1cec77cf를 삭제합니다.

5.2.9.2. Local Storage Operator 설치 제거

Local Storage Operator의 설치를 제거하려면 openshift-local-storage 프로젝트에서 Operator 및 모든 생성된 리소스를 제거해야 합니다.

주의

로컬 스토리지 PV를 아직 사용 중 일 때 Local Storage Operator의 설치를 제거하는 것은 권장되지 않습니다. Operator 제거 후 PV는 유지되지만, PV 및 로컬 스토리지 리소스를 제거하지 않고 Operator를 제거한 후 다시 설치하면 알 수 없는 동작이 발생할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.

프로세스

  1. 다음 명령을 실행하여 프로젝트에 설치된 localvolume , localvolumeset , localvolumediscovery 와 같은 로컬 볼륨 리소스를 삭제합니다.

    $ oc delete localvolume --all --all-namespaces
    Copy to Clipboard Toggle word wrap
    $ oc delete localvolumeset --all --all-namespaces
    Copy to Clipboard Toggle word wrap
    $ oc delete localvolumediscovery --all --all-namespaces
    Copy to Clipboard Toggle word wrap
  2. 웹 콘솔에서 Local Storage Operator의 설치를 제거합니다.

    1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
    2. Operators설치된 Operator로 이동합니다.
    3. Local Storage를 필터 상자에 입력하여 Local Storage Operator를 찾습니다.
    4. Local Storage Operator 끝에 있는 옵션 메뉴 kebab 를 클릭합니다.
    5. Operator 제거를 클릭합니다.
    6. 표시되는 창에서 제거를 클릭합니다.
  3. Local Storage Operator에서 생성한 PV는 삭제될 때까지 클러스터에 남아 있습니다. 이러한 볼륨이 더 이상 사용되지 않으면 다음 명령을 실행하여 해당 볼륨을 삭제합니다.

    $ oc delete pv <pv-name>
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 openshift-local-storage 프로젝트를 삭제합니다.

    $ oc delete project openshift-local-storage
    Copy to Clipboard Toggle word wrap

5.3. hostPath를 사용하는 영구 스토리지

OpenShift Container Platform 클러스터의 hostPath 볼륨은 호스트 노드 파일 시스템의 파일 또는 디렉터리를 Pod에 마운트합니다. 대부분의 Pod에는 hostPath 볼륨이 필요하지 않지만 테스트에 필요한 빠른 옵션을 제공합니다.

중요

클러스터 관리자는 권한으로 실행되도록 Pod를 구성해야 합니다. 이를 통해 동일한 노드의 Pod에 액세스 권한이 부여됩니다.

5.3.1. 개요

OpenShift Container Platform은 단일 노드 클러스터에서 개발 및 테스트를 위해 hostPath 마운트를 지원합니다.

프로덕션 클러스터에서는 hostPath를 사용할 수 없습니다. 대신, 클러스터 관리자는 GCE 영구 디스크 볼륨, NFS 공유 또는 Amazon EBS 볼륨과 같은 네트워크 리소스를 프로비저닝합니다. 네트워크 리소스는 스토리지 클래스 사용을 지원하여 동적 프로비저닝을 설정합니다.

hostPath 볼륨은 정적으로 프로비저닝해야 합니다.

중요

컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너에 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다. 다음 예는 /host의 컨테이너에 마운트되는 호스트의 / 디렉터리를 보여줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: test-host-mount
spec:
  containers:
  - image: registry.access.redhat.com/ubi9/ubi
    name: test-container
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /host
      name: host-slash
  volumes:
   - name: host-slash
     hostPath:
       path: /
       type: ''
Copy to Clipboard Toggle word wrap

5.3.2. 정적으로 hostPath 볼륨을 프로비저닝

hostPath 볼륨을 사용하는 Pod는 수동(정적) 프로비저닝을 통해 참조해야 합니다.

프로세스

  1. PersistentVolume 객체 정의를 사용하여 pv.yaml 파일을 만들어 영구 볼륨(PV)을 정의합니다.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: task-pv-volume 
    1
    
      labels:
        type: local
    spec:
      storageClassName: manual 
    2
    
      capacity:
        storage: 5Gi
      accessModes:
        - ReadWriteOnce 
    3
    
      persistentVolumeReclaimPolicy: Retain
      hostPath:
        path: "/mnt/data" 
    4
    Copy to Clipboard Toggle word wrap
    1
    볼륨의 이름입니다. 이 이름은 볼륨이 영구 볼륨(PV) 클레임이나 포드에 의해 식별되는 방식입니다.
    2
    PV에 지속적 볼륨 클레임(PVC) 요청을 바인딩하는 데 사용됩니다.
    3
    볼륨은 단일 노드에서 읽기-쓰기로 마운트할 수 있습니다.
    4
    구성 파일은 볼륨이 클러스터 노드의 /mnt/data에 있음을 지정합니다. 호스트 시스템이 손상되는 것을 방지하려면 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마세요. /host를 사용하여 호스트를 안전하게 마운트할 수 있습니다.
  2. 파일에서 PV를 생성합니다.

    $ oc create -f pv.yaml
    Copy to Clipboard Toggle word wrap
  3. PersistentVolumeClaim 객체 정의를 사용하여 pvc.yaml 파일을 만들어 PVC를 정의합니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: task-pvc-volume
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
      storageClassName: manual
    Copy to Clipboard Toggle word wrap
  4. 파일에서 PVC를 생성합니다.

    $ oc create -f pvc.yaml
    Copy to Clipboard Toggle word wrap

5.3.3. 권한이 있는 Pod에서 hostPath 공유 마운트

영구 볼륨 클레임을 생성한 후 애플리케이션에 의해 내부에서 사용될 수 있습니다. 다음 예시는 Pod 내부에서 이 공유를 마운트하는 방법을 보여줍니다.

사전 요구 사항

  • 기본 hostPath 공유에 매핑된 영구 볼륨 클레임이 있습니다.

절차

  • 기존 영구 볼륨 클레임을 마운트하는 권한이 있는 Pod를 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: pod-name 
    1
    
    spec:
      containers:
        ...
        securityContext:
          privileged: true 
    2
    
        volumeMounts:
        - mountPath: /data 
    3
    
          name: hostpath-privileged
      ...
      securityContext: {}
      volumes:
        - name: hostpath-privileged
          persistentVolumeClaim:
            claimName: task-pvc-volume 
    4
    Copy to Clipboard Toggle word wrap
    1
    Pod의 이름입니다.
    2
    노드의 스토리지에 액세스하려면 Pod는 권한 있음으로 실행해야 합니다.
    3
    권한이 있는 Pod 내부에서 호스트 경로 공유를 마운트하기 위한 경로입니다. 컨테이너 루트, / 또는 호스트와 컨테이너에서 동일한 경로에 마운트하지 마십시오. 컨테이너가 호스트 /dev/pts 파일과 같이 충분한 권한이 있는 경우 호스트 시스템이 손상될 수 있습니다. /host를 사용하여 호스트를 마운트하는 것이 안전합니다.
    4
    이전에 생성된 PersistentVolumeClaim 오브젝트의 이름입니다.

5.4. Logical Volume Manager Storage를 사용한 영구 저장소

논리 볼륨 관리자(LVM) 스토리지는 TopoLVM CSI 드라이버를 통해 LVM2를 사용하여 리소스가 제한된 클러스터에서 로컬 스토리지를 동적으로 프로비저닝합니다.

LVM 스토리지를 사용하여 볼륨 그룹, 영구 볼륨 클레임(PVC), 볼륨 스냅샷 및 볼륨 복제본을 만들 수 있습니다.

5.4.1. 논리 볼륨 관리자 스토리지 설치

OpenShift Container Platform 클러스터에 LVM(Logical Volume Manager) 스토리지를 설치하고 워크로드에 맞게 스토리지를 동적으로 프로비저닝하도록 구성할 수 있습니다.

OpenShift Container Platform CLI( oc ), OpenShift Container Platform 웹 콘솔 또는 Red Hat Advanced Cluster Management(RHACM)를 사용하여 LVM 스토리지를 설치할 수 있습니다.

주의

다중 노드 클러스터에서 LVM 스토리지를 사용하는 경우 LVM 스토리지는 로컬 스토리지 프로비저닝만 지원합니다. LVM 스토리지는 노드 간 스토리지 데이터 복제 메커니즘을 지원하지 않습니다. 단일 장애 지점을 방지하려면 활성 또는 수동 복제 메커니즘을 통해 저장소 데이터 복제를 보장해야 합니다.

5.4.1.1. LVM 스토리지 설치를 위한 필수 구성 요소

LVM 스토리지를 설치하기 위한 전제 조건은 다음과 같습니다.

  • 최소 10millCPU와 100MiB의 RAM이 있는지 확인하세요.
  • 모든 관리 클러스터에 스토리지 프로비저닝에 사용되는 전용 디스크가 있는지 확인하세요. LVM 스토리지는 비어 있고 파일 시스템 서명이 없는 디스크만 사용합니다. 디스크가 비어 있고 파일 시스템 서명이 없는지 확인하려면 사용하기 전에 디스크를 지웁니다.
  • 이전 LVM 스토리지 설치에서 구성한 스토리지 장치를 재사용할 수 있는 개인 CI 환경에 LVM 스토리지를 설치하기 전에 사용하지 않는 디스크를 지웠는지 확인하세요. LVM 스토리지를 설치하기 전에 디스크를 지우지 않으면 수동 개입 없이 디스크를 재사용할 수 없습니다.

    참고

    사용 중인 디스크는 지울 수 없습니다.

  • Red Hat Advanced Cluster Management(RHACM)를 사용하여 LVM 스토리지를 설치하려면 OpenShift Container Platform 클러스터에 RHACM을 설치했는지 확인하세요. "RHACM을 사용하여 LVM 스토리지 설치" 섹션을 참조하십시오.
5.4.1.2. CLI를 사용하여 LVM 스토리지 설치

클러스터 관리자는 OpenShift CLI를 사용하여 LVM 스토리지를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 및 운영자 설치 권한이 있는 사용자로 OpenShift Container Platform에 로그인했습니다.

프로세스

  1. 네임스페이스를 생성하기 위한 구성을 포함하는 YAML 파일을 만듭니다.

    네임스페이스 생성을 위한 YAML 구성 예

    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/audit: privileged
        pod-security.kubernetes.io/warn: privileged
      name: openshift-storage
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 네임스페이스를 생성합니다.

    $ oc create -f <file_name>
    Copy to Clipboard Toggle word wrap
  3. OperatorGroup CR YAML 파일을 만듭니다.

    예제 OperatorGroup CR

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-storage-operatorgroup
      namespace: openshift-storage
    spec:
      targetNamespaces:
      - openshift-storage
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다.

    $ oc create -f <file_name>
    Copy to Clipboard Toggle word wrap
  5. 구독 CR YAML 파일을 만듭니다.

    구독 CR 예시

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: lvms
      namespace: openshift-storage
    spec:
      installPlanApproval: Automatic
      name: lvms-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 구독 CR을 만듭니다.

    $ oc create -f <file_name>
    Copy to Clipboard Toggle word wrap

검증

  1. LVM 스토리지가 설치되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc get csv -n openshift-storage -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

    출력 예

    Name                         Phase
    4.13.0-202301261535          Succeeded
    Copy to Clipboard Toggle word wrap

5.4.1.3. 웹 콘솔을 사용하여 LVM 스토리지 설치

OpenShift Container Platform 웹 콘솔을 사용하여 LVM 스토리지를 설치할 수 있습니다.

사전 요구 사항

  • 클러스터에 접근할 수 있습니다.
  • 클러스터 관리자 및 운영자 설치 권한이 있으면 OpenShift Container Platform에 액세스할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators → OperatorHub를 클릭합니다.
  3. OperatorHub 페이지에서 LVM Storage 를 클릭합니다.
  4. 운영자 설치 페이지에서 다음 옵션을 설정하세요.

    1. 채널을 stable-4.19 로 업데이트합니다.
    2. 클러스터의 특정 네임스페이스 로서의 설치 모드 .
    3. Operator가 권장하는 네임스페이스인 openshift-storage를 설치했습니다 . openshift-storage 네임스페이스가 없으면 운영자 설치 중에 생성됩니다.
    4. 업데이트 승인자동 또는 수동으로 업데이트합니다.

      참고

      자동 업데이트를 선택하면 OLM(Operator Lifecycle Manager)이 아무런 개입 없이 실행 중인 LVM 스토리지 인스턴스를 자동으로 업데이트합니다.

      수동 업데이트를 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 LVM 스토리지를 최신 버전으로 업데이트하기 위한 업데이트 요청을 수동으로 승인해야 합니다.

  5. 선택 사항: 이 네임스페이스에서 운영자가 권장하는 클러스터 모니터링 사용 확인란을 선택합니다.
  6. 설치를 클릭합니다.

검증 단계

  • LVM 저장소에 녹색 확인 표시가 나타나면 설치가 성공적으로 완료되었음을 의미합니다.
5.4.1.4. 연결이 끊긴 환경에 LVM 스토리지 설치

연결이 끊긴 환경에서도 OpenShift Container Platform에 LVM 스토리지를 설치할 수 있습니다. 이 절차에서 참조하는 모든 섹션은 "추가 자료" 섹션에 링크되어 있습니다.

사전 요구 사항

  • "연결되지 않은 설치 미러링에 관하여" 섹션을 읽어보세요.
  • OpenShift Container Platform 이미지 저장소에 액세스할 수 있습니다.
  • 미러 레지스트리를 생성했습니다.

프로세스

  1. "이미지 세트 구성 생성" 절차의 단계를 따르세요. LVM 스토리지에 대한 ImageSetConfiguration 사용자 정의 리소스(CR)를 생성하려면 다음 예제 ImageSetConfiguration CR 구성을 사용할 수 있습니다.

    LVM 스토리지를 위한 ImageSetConfiguration CR 예시

    kind: ImageSetConfiguration
    apiVersion: mirror.openshift.io/v1alpha2
    archiveSize: 4 
    1
    
    storageConfig: 
    2
    
      registry:
        imageURL: example.com/mirror/oc-mirror-metadata 
    3
    
        skipTLS: false
    mirror:
      platform:
        channels:
        - name: stable-4.19 
    4
    
          type: ocp
        graph: true 
    5
    
      operators:
      - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.19 
    6
    
        packages:
        - name: lvms-operator 
    7
    
          channels:
          - name: stable 
    8
    
      additionalImages:
      - name: registry.redhat.io/ubi9/ubi:latest 
    9
    
      helm: {}
    Copy to Clipboard Toggle word wrap

    1
    이미지 세트 내 각 파일의 최대 크기(GiB)를 설정합니다.
    2
    이미지 세트를 저장할 위치를 지정하세요. 이 위치는 레지스트리나 로컬 디렉토리일 수 있습니다. Technology Preview OCI 기능을 사용하지 않는 한 storageConfig 필드를 구성해야 합니다.
    3
    레지스트리를 사용할 때 이미지 스트림의 저장 URL을 지정합니다. 자세한 내용은 왜 이미지 스트림을 사용해야 하는지 참조하세요.
    4
    OpenShift Container Platform 이미지를 검색할 채널을 지정합니다.
    5
    OpenShift Update Service(OSUS) 그래프 이미지를 생성하려면 이 필드를 true 로 설정합니다. 자세한 내용은 OpenShift 업데이트 서비스 정보를 참조하십시오.
    6
    OpenShift Container Platform 이미지를 검색할 운영자 카탈로그를 지정합니다.
    7
    이미지 세트에 포함할 Operator 패키지를 지정합니다. 이 필드가 비어 있으면 카탈로그에 있는 모든 패키지가 검색됩니다.
    8
    이미지 세트에 포함할 Operator 패키지의 채널을 지정합니다. 해당 채널에서 번들을 사용하지 않더라도 Operator 패키지의 기본 채널을 포함해야 합니다. 다음 명령을 실행하면 기본 채널을 찾을 수 있습니다: $ oc mirror list operators --catalog=<catalog_name> --package=<package_name> .
    9
    이미지 세트에 포함할 추가 이미지를 지정하세요.
  2. "미러 레지스트리에 이미지 세트 미러링" 섹션의 절차를 따르세요.
  3. "이미지 레지스트리 저장소 미러링 구성" 섹션의 절차를 따르세요.
5.4.1.5. RHACM을 사용하여 LVM 스토리지 설치

Red Hat Advanced Cluster Management(RHACM)를 사용하여 클러스터에 LVM 스토리지를 설치하려면 정책 사용자 정의 리소스(CR)를 만들어야 합니다. LVM 스토리지를 설치할 클러스터를 선택하기 위한 기준을 구성할 수도 있습니다.

참고

LVM 스토리지를 설치하기 위해 생성된 정책 CR은 정책 CR을 생성한 후 가져오거나 생성된 클러스터에도 적용됩니다.

사전 요구 사항

  • cluster-admin 및 Operator 설치 권한이 있는 계정을 사용하여 RHACM 클러스터에 액세스할 수 있습니다.
  • 각 클러스터에서 LVM 스토리지를 사용할 수 있는 전용 디스크가 있습니다.
  • 클러스터는 RHACM에서 관리해야 합니다.

프로세스

  1. OpenShift Container Platform 인증 정보를 사용하여 RHACM CLI에 로그인합니다.
  2. 네임스페이스를 생성합니다.

    $ oc create ns <namespace>
    Copy to Clipboard Toggle word wrap
  3. Policy CR YAML 파일을 생성합니다.

    LVM 스토리지를 설치하고 구성하는 Policy CR의 예

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-install-lvms
    spec:
      clusterConditions:
      - status: "True"
        type: ManagedClusterConditionAvailable
      clusterSelector: 
    1
    
        matchExpressions:
        - key: mykey
          operator: In
          values:
          - myvalue
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-install-lvms
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-install-lvms
    subjects:
    - apiGroup: policy.open-cluster-management.io
      kind: Policy
      name: install-lvms
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      annotations:
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
        policy.open-cluster-management.io/standards: NIST SP 800-53
      name: install-lvms
    spec:
      disabled: false
      remediationAction: enforce
      policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: install-lvms
          spec:
            object-templates:
            - complianceType: musthave
              objectDefinition: 
    2
    
                apiVersion: v1
                kind: Namespace
                metadata:
                  labels:
                    openshift.io/cluster-monitoring: "true"
                    pod-security.kubernetes.io/enforce: privileged
                    pod-security.kubernetes.io/audit: privileged
                    pod-security.kubernetes.io/warn: privileged
                  name: openshift-storage
            - complianceType: musthave
              objectDefinition: 
    3
    
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: openshift-storage-operatorgroup
                  namespace: openshift-storage
                spec:
                  targetNamespaces:
                  - openshift-storage
            - complianceType: musthave
              objectDefinition: 
    4
    
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: lvms
                  namespace: openshift-storage
                spec:
                  installPlanApproval: Automatic
                  name: lvms-operator
                  source: redhat-operators
                  sourceNamespace: openshift-marketplace
            remediationAction: enforce
            severity: low
    Copy to Clipboard Toggle word wrap

    1
    LVM 스토리지를 설치하려는 클러스터에 구성된 라벨과 일치하도록 PlacementRule.spec.clusterSelectorkey 필드 및 values 필드를 설정합니다.
    2
    네임스페이스 구성.
    3
    OperatorGroup CR 구성입니다.
    4
    서브스크립션 CR 구성입니다.
  4. 다음 명령을 실행하여 Policy CR을 생성합니다.

    $ oc create -f <file_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    Policy CR을 생성할 때 PlacementRule CR에 구성된 선택 기준과 일치하는 클러스터에서 다음 사용자 정의 리소스가 생성됩니다.

    • 네임스페이스
    • OperatorGroup
    • 서브스크립션

5.4.2. LVMCluster 사용자 정의 리소스 정보

다음 작업을 수행하도록 LVMCluster CR을 구성할 수 있습니다.

  • PVC(영구 볼륨 클레임)를 프로비저닝하는 데 사용할 수 있는 LVM 볼륨 그룹을 생성합니다.
  • LVM 볼륨 그룹에 추가할 장치 목록을 구성합니다.
  • LVM 볼륨 그룹을 생성할 노드와 볼륨 그룹에 대한 thin 풀 구성을 선택하도록 요구 사항을 구성합니다.
  • 선택한 장치를 강제로 지웁니다.

LVM 스토리지를 설치한 후 LVMCluster CR(사용자 정의 리소스)을 생성해야 합니다.

LVMCluster CR YAML 파일의 예

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: my-lvmcluster
spec:
  tolerations:
  - effect: NoSchedule
    key: xyz
    operator: Equal
    value: "true"
  storage:
    deviceClasses:
    - name: vg1
      fstype: ext4 
1

      default: true
      nodeSelector: 
2

        nodeSelectorTerms:
        - matchExpressions:
          - key: mykey
            operator: In
            values:
            - ssd
      deviceSelector: 
3

        paths:
        - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
        optionalPaths:
        - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:90:00.0-nvme-1
        forceWipeDevicesAndDestroyAllData: true
      thinPoolConfig:
        name: thin-pool-1
        sizePercent: 90 
4

        overprovisionRatio: 10
        chunkSize: 128Ki 
5

        chunkSizeCalculationPolicy: Static 
6

        metadataSize: 1Gi 
7

        metadataSizeCalculationPolicy: Host 
8
Copy to Clipboard Toggle word wrap

1 2 3 4 5 6 7 8
선택적 필드입니다.
LVMCluster CR의 필드에 대한 설명

LVMCluster CR 필드는 다음 표에 설명되어 있습니다.

Expand
표 5.5. LVMCluster CR 필드
필드유형설명

spec.storage.deviceClasses

array

로컬 스토리지 장치를 LVM 볼륨 그룹에 할당하는 구성이 포함되어 있습니다.

LVM Storage는 사용자가 생성하는 각 장치 클래스에 대한 스토리지 클래스 및 볼륨 스냅샷 클래스를 생성합니다.

deviceClasses.name

string

LVM 볼륨 그룹(VG)의 이름을 지정합니다.

이전 설치에서 만든 볼륨 그룹을 재사용하도록 이 필드를 구성할 수도 있습니다. 자세한 내용은 "이전 LVM 스토리지 설치에서 볼륨 그룹 재사용"을 참조하세요.

deviceClasses.fstype

string

이 필드를 ext4 또는 xfs 로 설정합니다. 기본적으로 이 필드는 xfs 로 설정됩니다.

deviceClasses.default

boolean

장치 클래스가 기본값임을 나타내려면 이 필드를 true 로 설정합니다. 그렇지 않으면 false 로 설정할 수 있습니다. 단일 기본 장치 클래스만 구성할 수 있습니다.

deviceClasses.nodeSelector

object

LVM 볼륨 그룹을 만들 노드를 선택하는 구성이 포함되어 있습니다. 이 필드가 비어 있으면 스케줄 테인트가 없는 모든 노드가 고려됩니다.

control-plane 노드에서 LVM Storage는 클러스터에서 새 노드가 활성화될 때 추가 작업자 노드를 감지하고 사용합니다.

nodeSelector.nodeSelectorTerms

array

노드를 선택하는 데 사용되는 요구 사항을 구성합니다.

deviceClasses.deviceSelector

object

다음 작업을 수행할 구성이 포함되어 있습니다.

  • LVM 볼륨 그룹에 추가할 장치의 경로를 지정합니다.
  • LVM 볼륨 그룹에 추가된 장치를 강제로 지웁니다.

자세한 내용은 "볼륨 그룹에 장치 추가 정보"를 참조하십시오.

deviceSelector.paths

array

장치 경로를 지정합니다.

이 필드에 지정된 장치 경로가 없거나 LVM Storage에서 장치가 지원되지 않는 경우 LVMCluster CR은 Failed 상태로 이동합니다.

deviceSelector.optionalPaths

array

선택적 장치 경로를 지정합니다.

이 필드에 지정된 장치 경로가 없거나 LVM 스토리지에서 장치가 지원되지 않는 경우 LVM 스토리지는 오류가 발생하지 않고 장치를 무시합니다.

deviceSelector. forceWipeDevicesAndDestroyAllData

boolean

LVM 스토리지는 비어 있고 파일 시스템 서명이 포함되지 않은 디스크만 사용합니다. 디스크가 비어 있고 파일 시스템 서명을 포함하지 않도록 하려면 디스크를 사용하기 전에 초기화하십시오.

선택한 장치를 강제로 지우려면 이 필드를 true 로 설정합니다. 기본적으로 이 필드는 false 로 설정됩니다.

주의

이 필드가 true 로 설정되면 LVM 스토리지가 장치의 이전 데이터를 모두 지웁니다. 이 기능을 주의해서 사용하십시오.

장치를 제거하면 다음 조건이 충족되는 경우 데이터 무결성의 불일치가 발생할 수 있습니다.

  • 장치가 스왑 공간으로 사용되고 있습니다.
  • 장치는 RAID 배열의 일부입니다.
  • 장치가 마운트됩니다.

이러한 조건 중 하나라도 true인 경우 디스크를 강제로 지우지 마십시오. 대신 디스크를 수동으로 초기화해야 합니다.

deviceClasses.thinPoolConfig

object

LVM 볼륨 그룹에 씬 풀을 만드는 구성이 포함되어 있습니다.

이 필드를 제외하면 논리 볼륨이 씩 프로비저닝됩니다.

씩 프로비저닝된 스토리지 사용에는 다음과 같은 제한 사항이 포함됩니다.

  • 볼륨 복제에 대한 COW(Copy-On-Write) 지원이 없습니다.
  • 스냅샷 클래스를 지원하지 않습니다.
  • 과도한 프로비저닝을 지원하지 않습니다. 결과적으로 PVC( PersistentVolumeClaims )의 프로비저닝된 용량이 볼륨 그룹에서 즉시 줄어듭니다.
  • thin 메트릭을 지원하지 않습니다. 씩 프로비저닝된 장치는 볼륨 그룹 지표만 지원합니다.

thinPoolConfig.name

string

씬 풀의 이름을 지정합니다.

thinPoolConfig.sizePercent

integer

씬 풀을 생성하기 위해 LVM 볼륨 그룹의 공간 백분율을 지정합니다.

기본적으로 이 필드는 90으로 설정됩니다. 설정할 수 있는 최소값은 10이고, 최대값은 90입니다.

thinPoolConfig.overprovisionRatio

integer

씬 풀에서 사용 가능한 스토리지를 기준으로 추가 스토리지를 프로비저닝할 수 있는 요소를 지정합니다.

예를 들어, 이 필드를 10으로 설정하면 씬 풀에서 사용 가능한 스토리지 양의 최대 10배를 프로비저닝할 수 있습니다. LVM 클러스터가 생성된 후에 이 필드를 수정할 수 있습니다.

매개변수를 업데이트하려면 다음 작업 중 하나를 수행하세요.

  • LVM 클러스터를 편집하려면 다음 명령을 실행하세요.
$ oc edit lvmcluster <lvmcluster_name>
Copy to Clipboard Toggle word wrap
  • 패치를 적용하려면 다음 명령을 실행하세요.
$ oc patch lvmcluster <lvmcluster_name> -p <patch_file.yaml>
Copy to Clipboard Toggle word wrap

과도한 프로비저닝을 비활성화하려면 이 필드를 1로 설정합니다.

thinPoolConfig.chunkSize

integer

씬 풀에 대한 정적으로 계산된 청크 크기를 지정합니다. 이 필드는 ChunkSizeCalculationPolicy 필드가 Static 으로 설정된 경우에만 사용됩니다. lvm2 의 기본 제한 사항으로 인해 이 필드의 값은 64KiB~1GiB 범위 내에서 구성되어야 합니다.

이 필드를 구성하지 않고 ChunkSizeCalculationPolicy 필드가 Static 으로 설정된 경우 기본 청크 크기는 128KiB로 설정됩니다.

자세한 내용은 "청크 크기 개요"를 참조하세요.

thinPoolConfig.chunkSizeCalculationPolicy

string

기본 볼륨 그룹의 청크 크기를 계산하는 정책을 지정합니다. 이 필드를 정적 또는 호스트 로 설정할 수 있습니다. 기본적으로 이 필드는 Static 으로 설정됩니다.

이 필드를 Static 으로 설정하면 청크 크기가 chunkSize 필드 값으로 설정됩니다. chunkSize 필드가 구성되지 않으면 청크 크기는 128KiB로 설정됩니다.

이 필드가 호스트 로 설정되면 청크 크기는 lvm.conf 파일의 구성에 따라 계산됩니다.

자세한 내용은 "LVM 스토리지에 사용되는 장치의 크기를 구성하는 데 대한 제한 사항"을 참조하세요.

thinPoolConfig.metadataSize

integer

씬 풀의 메타데이터 크기를 지정합니다. MetadataSizeCalculationPolicy 필드가 Static 으로 설정된 경우에만 이 필드를 구성할 수 있습니다.

이 필드가 구성되지 않고 MetadataSizeCalculationPolicy 필드가 Static 으로 설정된 경우 기본 메타데이터 크기는 1GiB로 설정됩니다.

lvm2 의 기본 제한으로 인해 이 필드의 값은 2MiB~16GiB 범위에서 구성되어야 합니다. 업데이트 중에만 이 필드의 값을 늘릴 수 있습니다.

thinPoolConfig.metadataSizeCalculationPolicy

string

기본 볼륨 그룹의 메타데이터 크기를 계산하는 정책을 지정합니다. 이 필드를 정적 또는 호스트 로 설정할 수 있습니다. 기본적으로 이 필드는 호스트 로 설정됩니다.

이 필드를 Static 으로 설정하면 메타데이터 크기는 thinPoolConfig.metadataSize 필드 값을 기준으로 계산됩니다.

이 필드가 호스트 로 설정되면 메타데이터 크기는 lvm2 설정을 기준으로 계산됩니다.

5.4.2.1. LVM 스토리지에 사용되는 장치 크기 구성에 대한 제한 사항

LVM 스토리지를 사용하여 스토리지를 프로비저닝하는 데 사용할 수 있는 장치의 크기를 구성하는 데 대한 제한 사항은 다음과 같습니다.

  • 프로비저닝할 수 있는 총 스토리지 크기는 기본 LVM(Logical Volume Manager) 씬 풀의 크기와 과도한 프로비저닝 요소에 따라 제한됩니다.
  • 논리 볼륨의 크기는 물리적 확장자(PE)와 논리적 확장자(LE)의 크기에 따라 달라집니다.

    • 물리적 및 논리적 장치를 생성하는 동안 PE와 LE의 크기를 정의할 수 있습니다.
    • 기본 PE 및 LE 크기는 4MB입니다.
    • PE의 크기가 늘어나면 LVM의 최대 크기는 커널 제한과 디스크 공간에 따라 결정됩니다.

다음 표에서는 정적 및 호스트 구성에 대한 청크 크기 및 볼륨 크기 제한을 설명합니다.

Expand
표 5.6. 테스트된 구성
매개변수현재의

청크 크기

128키로바이트

최대 볼륨 크기

32티비

Expand
표 5.7. 정적 구성에 대한 이론적인 크기 제한
매개변수최소값최대값

청크 크기

64키로바이트

1기가바이트

볼륨 크기

기본 Red Hat Enterprise Linux CoreOS(RHCOS) 시스템의 최소 크기입니다.

기본 RHCOS 시스템의 최대 크기.

Expand
표 5.8. 호스트 구성에 대한 이론적인 크기 제한
매개변수현재의

청크 크기

이 값은 lvm.conf 파일의 구성을 기반으로 합니다. 기본적으로 이 값은 128KiB로 설정됩니다.

최대 볼륨 크기

기본 RHCOS 시스템의 최대 볼륨 크기와 같습니다.

최소 볼륨 크기

기본 RHCOS 시스템의 최소 볼륨 크기와 동일합니다.

5.4.2.2. 볼륨 그룹에 장치 추가에 관하여

LVMCluster CR의 deviceSelector 필드에는 논리 볼륨 관리자(LVM) 볼륨 그룹에 추가하려는 장치의 경로를 지정하는 구성이 포함되어 있습니다.

deviceSelector.paths 필드, deviceSelector.optionalPaths 필드 또는 둘 다에서 장치 경로를 지정할 수 있습니다. deviceSelector.paths 필드와 deviceSelector.optionalPaths 필드 모두에서 장치 경로를 지정하지 않으면 LVM 스토리지는 지원되는 미사용 장치를 볼륨 그룹(VG)에 추가합니다.

주의

/dev/sdX 와 같은 상징적 이름을 사용하여 디스크를 참조하는 것은 피하는 것이 좋습니다. 이러한 이름은 RHCOS 내에서 재부팅할 때마다 변경될 수 있습니다. 대신, 일관된 디스크 식별을 보장하려면 /dev/disk/by-path/ 또는 /dev/disk/by-id/ 와 같은 안정적인 명명 체계를 사용해야 합니다.

이러한 변경으로 인해 모니터링이 각 노드의 설치 장치에 대한 정보를 수집하는 경우 기존 자동화 워크플로를 조정해야 할 수도 있습니다.

자세한 내용은 RHEL 문서를 참조하세요.

deviceSelector 필드에 RAID(Redundant Array of Independent Disks) 어레이 경로를 추가하여 RAID 어레이를 LVM 스토리지와 통합할 수 있습니다. mdadm 유틸리티를 사용하여 RAID 어레이를 생성할 수 있습니다. LVM 스토리지는 소프트웨어 RAID 생성을 지원하지 않습니다.

참고

OpenShift Container Platform 설치 중에만 RAID 어레이를 만들 수 있습니다. RAID 어레이를 만드는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

볼륨 그룹에 암호화된 장치를 추가할 수도 있습니다. OpenShift Container Platform 설치 중에 클러스터 노드에서 디스크 암호화를 활성화할 수 있습니다. 장치를 암호화한 후 deviceSelector 필드에서 LUKS로 암호화된 장치의 경로를 지정할 수 있습니다. 디스크 암호화에 대한 자세한 내용은 "디스크 암호화 정보" 및 "디스크 암호화 및 미러링 구성"을 참조하세요.

VG에 추가하려는 장치는 LVM 스토리지에서 지원되어야 합니다. 지원되지 않는 장치에 대한 자세한 내용은 "LVM 스토리지에서 지원하지 않는 장치"를 참조하세요.

LVM 스토리지는 다음 조건이 충족되는 경우에만 VG에 장치를 추가합니다.

  • 장치 경로가 존재합니다.
  • 이 장치는 LVM 스토리지에서 지원됩니다.
중요

VG에 장치를 추가한 후에는 해당 장치를 제거할 수 없습니다.

LVM 스토리지는 동적 장치 검색을 지원합니다. LVMCluster CR에 deviceSelector 필드를 추가하지 않으면 LVM Storage는 장치를 사용할 수 있게 되면 자동으로 VG에 새 장치를 추가합니다.

주의

다음과 같은 이유로 동적 장치 검색을 통해 VG에 장치를 추가하는 것은 권장되지 않습니다.

  • VG에 추가할 생각이 없는 새 장치를 추가하면 LVM 스토리지는 동적 장치 검색을 통해 해당 장치를 VG에 자동으로 추가합니다.
  • LVM 스토리지가 동적 장치 검색을 통해 VG에 장치를 추가하는 경우, LVM 스토리지는 노드에서 장치를 제거하는 데 제한을 두지 않습니다. VG에 이미 추가된 장치를 제거하거나 업데이트하면 VG가 중단될 수 있습니다. 이로 인해 데이터 손실이 발생할 수도 있고, 수동 노드 수정이 필요할 수도 있습니다.
5.4.2.3. LVM 스토리지에서 지원하지 않는 장치

LVMCluster 사용자 정의 리소스(CR)의 deviceSelector 필드에 장치 경로를 추가할 때 해당 장치가 LVM 스토리지에서 지원되는지 확인하세요. 지원되지 않는 장치에 대한 경로를 추가하면 LVM 스토리지는 논리 볼륨 관리의 복잡성을 피하기 위해 해당 장치를 제외합니다.

deviceSelector 필드에 장치 경로를 지정하지 않으면 LVM 스토리지는 지원하는 사용되지 않는 장치만 추가합니다.

참고

장치에 대한 정보를 얻으려면 다음 명령을 실행하세요.

$ lsblk --paths --json -o \
NAME,ROTA,TYPE,SIZE,MODEL,VENDOR,RO,STATE,KNAME,SERIAL,PARTLABEL,FSTYPE
Copy to Clipboard Toggle word wrap

LVM 스토리지는 다음 장치를 지원하지 않습니다.

읽기 전용 장치
ro 매개변수가 true 로 설정된 장치.
정지된 장치
상태 매개변수가 일시 중단 으로 설정된 장치입니다.
ROM 장치
유형 매개변수가 rom 으로 설정된 장치입니다.
LVM 파티션 장치
유형 매개변수가 lvm 으로 설정된 장치입니다.
잘못된 파티션 레이블이 있는 장치
partlabel 매개변수가 bios , boot 또는 reserved 로 설정된 장치입니다.
잘못된 파일 시스템이 있는 장치

fstype 매개변수가 null 또는 LVM2_member가 아닌 다른 값으로 설정된 장치입니다.

중요

LVM 저장소는 장치에 자식 장치가 없는 경우에만 fstype 매개변수가 LVM2_member 로 설정된 장치를 지원합니다.

다른 볼륨 그룹의 일부인 장치

장치의 볼륨 그룹에 대한 정보를 얻으려면 다음 명령을 실행하세요.

$ pvs <device-name> 
1
Copy to Clipboard Toggle word wrap
1
<장치 이름>을 장치 이름으로 바꾸세요.
바인드 마운트가 있는 장치

장치의 마운트 지점을 얻으려면 다음 명령을 실행하세요.

$ cat /proc/1/mountinfo | grep <device-name> 
1
Copy to Clipboard Toggle word wrap
1
<장치 이름>을 장치 이름으로 바꾸세요.
자식 장치가 포함된 장치
참고

예상치 못한 동작을 방지하려면 LVM 스토리지에서 장치를 사용하기 전에 장치를 지우는 것이 좋습니다.

5.4.3. LVMCluster 사용자 정의 리소스를 만드는 방법

OpenShift CLI( oc ) 또는 OpenShift Container Platform 웹 콘솔을 사용하여 LVMCluster 사용자 정의 리소스(CR)를 만들 수 있습니다. Red Hat Advanced Cluster Management(RHACM)를 사용하여 LVM 스토리지를 설치한 경우 RHACM을 사용하여 LVMCluster CR을 생성할 수도 있습니다.

중요

LVM Storage Operator를 설치한 것과 동일한 네임스페이스에 LVMCluster CR을 만들어야 합니다. 기본적으로 이 네임스페이스는 openshift-storage 입니다.

LVMCluster CR을 생성하면 LVM Storage는 다음과 같은 시스템 관리 CR을 생성합니다.

  • 각 장치 클래스에 대한 storageClassvolumeSnapshotClass .

    참고

    LVM 스토리지는 lvms-<device_class_name> 형식으로 스토리지 클래스와 볼륨 스냅샷 클래스의 이름을 구성합니다. 여기서 <device_class_name>LVMCluster CR의 deviceClasses.name 필드의 값입니다. 예를 들어, deviceClasses.name 필드가 vg1로 설정된 경우 스토리지 클래스와 볼륨 스냅샷 클래스의 이름은 lvms-vg1 입니다.

  • LVMVolumeGroup : 이 CR은 LVM 볼륨 그룹에 의해 지원되는 특정 유형의 영구 볼륨(PV)입니다. 여러 노드에 걸쳐 개별 볼륨 그룹을 추적합니다.
  • LVMVolumeGroupNodeStatus : 이 CR은 노드의 볼륨 그룹 상태를 추적합니다.
5.4.3.1. 이전 LVM 스토리지 설치에서 볼륨 그룹 재사용

새로운 VG를 생성하는 대신 이전 LVM 스토리지 설치에서 기존 볼륨 그룹(VG)을 재사용할 수 있습니다.

VG만 재사용할 수 있고 VG와 연관된 논리 볼륨은 재사용할 수 없습니다.

중요

이 절차는 LVMCluster 사용자 정의 리소스(CR)를 생성하는 동안에만 수행할 수 있습니다.

사전 요구 사항

  • 재사용하려는 VG는 손상되어서는 안 됩니다.
  • 재사용하려는 VG에는 lvms 태그가 있어야 합니다. LVM 객체에 태그를 추가하는 방법에 대한 자세한 내용은 태그를 사용하여 LVM 객체 그룹화를 참조하세요.

프로세스

  1. LVMCluster CR YAML 파일을 엽니다.
  2. 다음 예에 설명된 대로 LVMCluster CR 매개변수를 구성합니다.

    LVMCluster CR YAML 파일 예시

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
    # ...
      storage:
        deviceClasses:
        - name: vg1  
    1
    
          fstype: ext4 
    2
    
          default: true
          deviceSelector: 
    3
    
    # ...
            forceWipeDevicesAndDestroyAllData: false 
    4
    
          thinPoolConfig: 
    5
    
    # ...
          nodeSelector: 
    6
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    이 필드를 이전 LVM 스토리지 설치의 VG 이름으로 설정합니다.
    2
    이 필드를 ext4 또는 xfs 로 설정합니다. 기본적으로 이 필드는 xfs 로 설정됩니다.
    3
    deviceSelector 필드에 새 장치 경로를 지정하여 재사용하려는 새 장치를 VG에 추가할 수 있습니다. VG에 새 장치를 추가하지 않으려면 현재 LVM 스토리지 설치의 deviceSelector 구성이 이전 LVM 스토리지 설치의 구성과 동일한지 확인하세요.
    4
    이 필드를 true 로 설정하면 LVM 스토리지는 VG에 추가된 장치의 모든 데이터를 지웁니다.
    5
    재사용하려는 VG의 thinPoolConfig 구성을 유지하려면 현재 LVM 스토리지 설치의 thinPoolConfig 구성이 이전 LVM 스토리지 설치의 thinPoolConfig 구성과 동일한지 확인하세요. 그렇지 않으면 필요에 따라 thinPoolConfig 필드를 구성할 수 있습니다.
    6
    LVM 볼륨 그룹을 생성할 노드를 선택하기 위한 요구 사항을 구성합니다. 이 필드가 비어 있으면 스케줄 없는 오염이 없는 모든 노드가 고려됩니다.
  3. LVMCluster CR YAML 파일을 저장합니다.
참고

볼륨 그룹의 일부인 장치를 보려면 다음 명령을 실행하세요.

$ pvs -S vgname=<vg_name> 
1
Copy to Clipboard Toggle word wrap
1
<vg_name>을 볼륨 그룹의 이름으로 바꾸세요.
5.4.3.2. CLI를 사용하여 LVMCluster CR 만들기

OpenShift CLI( oc )를 사용하여 작업자 노드에서 LVMCluster 사용자 정의 리소스(CR)를 만들 수 있습니다.

중요

OpenShift Container Platform 클러스터에서는 LVMCluster 사용자 정의 리소스(CR)의 인스턴스를 하나만 만들 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 사용자로 OpenShift Container Platform에 로그인했습니다.
  • LVM 스토리지를 설치했습니다.
  • 클러스터에 워커 노드를 설치했습니다.
  • "LVMCluster 사용자 정의 리소스에 대한 정보" 섹션을 읽어보세요.

프로세스

  1. LVMCluster 사용자 정의 리소스(CR) YAML 파일을 만듭니다.

    LVMCluster CR YAML 파일 예시

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
    # ...
      storage:
        deviceClasses: 
    1
    
    # ...
          nodeSelector: 
    2
    
    # ...
          deviceSelector: 
    3
    
    # ...
          thinPoolConfig: 
    4
    
    # ...
    Copy to Clipboard Toggle word wrap

    1
    로컬 스토리지 장치를 LVM 볼륨 그룹에 할당하기 위한 구성이 포함되어 있습니다.
    2
    LVM 볼륨 그룹을 생성할 노드를 선택하기 위한 구성이 포함되어 있습니다. 이 필드가 비어 있으면 스케줄 없는 오염이 없는 모든 노드가 고려됩니다.
    3
    LVM 볼륨 그룹에 추가하려는 장치의 경로를 지정하고 LVM 볼륨 그룹에 추가된 장치를 강제로 삭제하는 구성이 포함되어 있습니다.
    4
    LVM 볼륨 그룹에 씬 풀을 생성하기 위한 구성이 포함되어 있습니다. 이 필드를 제외하면 논리 볼륨은 두꺼운 프로비저닝이 적용됩니다.
  2. 다음 명령을 실행하여 LVMCluster CR을 만듭니다.

    $ oc create -f <file_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    lvmcluster/lvmcluster created
    Copy to Clipboard Toggle word wrap

검증

  1. LVMCluster CR이 준비 상태인지 확인하세요.

    $ oc get lvmclusters.lvm.topolvm.io -o jsonpath='{.items[*].status}' -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    {"deviceClassStatuses": 
    1
    
    [
      {
        "name": "vg1",
        "nodeStatus": [ 
    2
    
            {
                "devices": [ 
    3
    
                    "/dev/nvme0n1",
                    "/dev/nvme1n1",
                    "/dev/nvme2n1"
                ],
                "node": "kube-node", 
    4
    
                "status": "Ready" 
    5
    
            }
        ]
      }
    ]
    "state":"Ready"} 
    6
    Copy to Clipboard Toggle word wrap

    1
    장치 클래스의 상태입니다.
    2
    각 노드의 LVM 볼륨 그룹의 상태입니다.
    3
    LVM 볼륨 그룹을 만드는 데 사용된 장치 목록입니다.
    4
    장치 클래스가 생성된 노드입니다.
    5
    노드의 LVM 볼륨 그룹 상태입니다.
    6
    LVMCluster CR의 상태입니다.
    참고

    LVMCluster CR이 실패 상태인 경우 상태 필드에서 실패 이유를 볼 수 있습니다.

    실패 이유가 포함된 상태 필드의 예:

    status:
      deviceClassStatuses:
        - name: vg1
          nodeStatus:
            - node: my-node-1.example.com
              reason: no available devices found for volume group
              status: Failed
      state: Failed
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: 각 장치 클래스에 대해 LVM 스토리지에서 생성된 스토리지 클래스를 보려면 다음 명령을 실행하세요.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME          PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    lvms-vg1      topolvm.io           Delete          WaitForFirstConsumer   true                   31m
    Copy to Clipboard Toggle word wrap

  3. 선택 사항: LVM 스토리지에서 각 장치 클래스에 대해 생성된 볼륨 스냅샷 클래스를 보려면 다음 명령을 실행하세요.

    $ oc get volumesnapshotclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME          DRIVER               DELETIONPOLICY   AGE
    lvms-vg1      topolvm.io           Delete           24h
    Copy to Clipboard Toggle word wrap

5.4.3.3. 웹 콘솔을 사용하여 LVMCluster CR 만들기

OpenShift Container Platform 웹 콘솔을 사용하여 워커 노드에서 LVMCluster CR을 만들 수 있습니다.

중요

OpenShift Container Platform 클러스터에서는 LVMCluster 사용자 정의 리소스(CR)의 인스턴스를 하나만 만들 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한으로 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • LVM 스토리지를 설치했습니다.
  • 클러스터에 워커 노드를 설치했습니다.
  • "LVMCluster 사용자 정의 리소스에 대한 정보" 섹션을 읽어보세요.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators설치된 Operators를 클릭합니다.
  3. openshift-storage 네임스페이스에서 LVM 스토리지를 클릭합니다.
  4. LVMCluster 만들기를 클릭하고 양식 보기 또는 YAML 보기를 선택합니다.
  5. 필요한 LVMCluster CR 매개변수를 구성합니다.
  6. Create를 클릭합니다.
  7. 선택 사항: LVMCLuster CR을 편집하려면 다음 작업을 수행하세요.

    1. LVMCluster 탭을 클릭합니다.
    2. Actions 메뉴에서 Edit LVMCluster 를 선택합니다.
    3. YAML을 클릭하고 필요한 LVMCLuster CR 매개변수를 편집합니다.
    4. 저장을 클릭합니다.

검증

  1. LVMCluster 페이지에서 LVMCluster CR이 준비 상태인지 확인하세요.
  2. 선택 사항: LVM 스토리지에서 각 장치 클래스에 대해 생성된 사용 가능한 스토리지 클래스를 보려면 스토리지스토리지 클래스를 클릭합니다.
  3. 선택 사항: LVM 스토리지에서 각 장치 클래스에 대해 생성된 사용 가능한 볼륨 스냅샷 클래스를 보려면 스토리지VolumeSnapshotClasses를 클릭합니다.
5.4.3.4. RHACM을 사용하여 LVMCluster CR 만들기

RHACM을 사용하여 LVM 스토리지를 설치한 후에는 LVMCluster 사용자 정의 리소스(CR)를 생성해야 합니다.

사전 요구 사항

  • RHACM을 사용하여 LVM 스토리지를 설치했습니다.
  • 클러스터 관리자 권한이 있는 계정을 사용하여 RHACM 클러스터에 액세스할 수 있습니다.
  • "LVMCluster 사용자 정의 리소스에 대한 정보" 섹션을 읽어보세요.

프로세스

  1. OpenShift Container Platform 자격 증명을 사용하여 RHACM CLI에 로그인합니다.
  2. LVMCluster CR을 생성하기 위한 구성을 사용하여 ConfigurationPolicy CR YAML 파일을 만듭니다.

    LVMCluster CR을 생성하기 위한 ConfigurationPolicy CR YAML 파일 예시

    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: lvms
    spec:
      object-templates:
      - complianceType: musthave
        objectDefinition:
          apiVersion: lvm.topolvm.io/v1alpha1
          kind: LVMCluster
          metadata:
            name: my-lvmcluster
            namespace: openshift-storage
          spec:
            storage:
              deviceClasses: 
    1
    
    # ...
                deviceSelector: 
    2
    
    # ...
                thinPoolConfig: 
    3
    
    # ...
                nodeSelector: 
    4
    
    # ...
      remediationAction: enforce
      severity: low
    Copy to Clipboard Toggle word wrap

    1
    로컬 스토리지 장치를 LVM 볼륨 그룹에 할당하기 위한 구성이 포함되어 있습니다.
    2
    LVM 볼륨 그룹에 추가하려는 장치의 경로를 지정하고 LVM 볼륨 그룹에 추가된 장치를 강제로 삭제하는 구성이 포함되어 있습니다.
    3
    LVM 볼륨 그룹에 씬 풀을 생성하기 위한 구성이 포함되어 있습니다. 이 필드를 제외하면 논리 볼륨은 두꺼운 프로비저닝이 적용됩니다.
    4
    LVM 볼륨 그룹을 생성할 노드를 선택하기 위한 구성이 포함되어 있습니다. 이 필드가 비어 있으면 스케줄 없는 오염이 없는 모든 노드가 고려됩니다.
  3. 다음 명령을 실행하여 ConfigurationPolicy CR을 만듭니다.

    $ oc create -f <file_name> -n <cluster_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    LVM 스토리지가 설치된 OpenShift Container Platform 클러스터의 네임스페이스입니다.

5.4.4. LVMCluster 사용자 정의 리소스를 삭제하는 방법

OpenShift CLI( oc ) 또는 OpenShift Container Platform 웹 콘솔을 사용하여 LVMCluster 사용자 정의 리소스(CR)를 삭제할 수 있습니다. Red Hat Advanced Cluster Management(RHACM)를 사용하여 LVM 스토리지를 설치한 경우 RHACM을 사용하여 LVMCluster CR을 삭제할 수도 있습니다.

LVMCluster CR을 삭제하면 LVM Storage는 다음 CR을 삭제합니다.

  • storageClass
  • volumeSnapshotClass
  • LVMVolumeGroup
  • LVMVolumeGroupNodeStatus
5.4.4.1. CLI를 사용하여 LVMCluster CR 삭제

OpenShift CLI( oc )를 사용하여 LVMCluster 사용자 정의 리소스(CR)를 삭제할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.
  • LVM 스토리지에서 프로비저닝된 영구 볼륨 클레임(PVC), 볼륨 스냅샷 및 볼륨 복제본을 삭제했습니다. 또한 이러한 리소스를 사용하는 애플리케이션도 삭제했습니다.

프로세스

  1. OpenShift CLI( oc )에 로그인합니다.
  2. 다음 명령을 실행하여 LVMCluster CR을 삭제합니다.

    $ oc delete lvmcluster <lvm_cluster_name> -n openshift-storage
    Copy to Clipboard Toggle word wrap

검증

  • LVMCluster CR이 삭제되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc get lvmcluster -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    No resources found in openshift-storage namespace.
    Copy to Clipboard Toggle word wrap

5.4.4.2. 웹 콘솔을 사용하여 LVMCluster CR 삭제

OpenShift Container Platform 웹 콘솔을 사용하여 LVMCluster 사용자 정의 리소스(CR)를 삭제할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.
  • LVM 스토리지에서 프로비저닝된 영구 볼륨 클레임(PVC), 볼륨 스냅샷 및 볼륨 복제본을 삭제했습니다. 또한 이러한 리소스를 사용하는 애플리케이션도 삭제했습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. 설치된 모든 운영자를 보려면 운영자설치된 운영자를 클릭하세요.
  3. openshift-storage 네임스페이스에서 LVM 스토리지를 클릭합니다.
  4. LVMCluster 탭을 클릭합니다.
  5. 작업 에서 LVMCluster 삭제를 선택합니다.
  6. 삭제를 클릭합니다.

검증

  • LVMCluster 페이지에서 LVMCluster CR이 삭제되었는지 확인하세요.
5.4.4.3. RHACM을 사용하여 LVMCluster CR 삭제

Red Hat Advanced Cluster Management(RHACM)를 사용하여 LVM 스토리지를 설치한 경우 RHACM을 사용하여 LVMCluster CR을 삭제할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 RHACM 클러스터에 액세스할 수 있습니다.
  • LVM 스토리지에서 프로비저닝된 영구 볼륨 클레임(PVC), 볼륨 스냅샷 및 볼륨 복제본을 삭제했습니다. 또한 이러한 리소스를 사용하는 애플리케이션도 삭제했습니다.

프로세스

  1. OpenShift Container Platform 자격 증명을 사용하여 RHACM CLI에 로그인합니다.
  2. LVMCluster CR에 대해 생성된 ConfigurationPolicy CR YAML 파일을 삭제합니다.

    $ oc delete -f <file_name> -n <cluster_namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    LVM 스토리지가 설치된 OpenShift Container Platform 클러스터의 네임스페이스입니다.
  3. LVMCluster CR을 삭제하려면 정책 CR YAML 파일을 만듭니다.

    LVMCluster CR을 삭제하기 위한 정책 CR 예

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-lvmcluster-delete
      annotations:
        policy.open-cluster-management.io/standards: NIST SP 800-53
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    spec:
      remediationAction: enforce
      disabled: false
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-lvmcluster-removal
            spec:
              remediationAction: enforce 
    1
    
              severity: low
              object-templates:
                - complianceType: mustnothave
                  objectDefinition:
                    kind: LVMCluster
                    apiVersion: lvm.topolvm.io/v1alpha1
                    metadata:
                      name: my-lvmcluster
                      namespace: openshift-storage 
    2
    
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-policy-lvmcluster-delete
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-policy-lvmcluster-delete
    subjects:
      - apiGroup: policy.open-cluster-management.io
        kind: Policy
        name: policy-lvmcluster-delete
    ---
    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-policy-lvmcluster-delete
    spec:
      clusterConditions:
        - status: "True"
          type: ManagedClusterConditionAvailable
      clusterSelector: 
    3
    
        matchExpressions:
          - key: mykey
            operator: In
            values:
              - myvalue
    Copy to Clipboard Toggle word wrap

    1
    policy-templatespec.remediationActionspec.remediationAction 의 이전 매개변수 값으로 재정의됩니다.
    2
    네임스페이스 필드에는 openshift-storage 값이 있어야 합니다.
    3
    클러스터를 선택하기 위한 요구 사항을 구성합니다. 선택 기준과 일치하는 클러스터에서 LVM 스토리지가 제거됩니다.
  4. 다음 명령을 실행하여 정책 CR을 만듭니다.

    $ oc create -f <file_name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  5. LVMCluster CR이 삭제되었는지 확인하려면 Policy CR YAML 파일을 만듭니다.

    LVMCluster CR이 삭제되었는지 확인하기 위한 정책 CR 예

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-lvmcluster-inform
      annotations:
        policy.open-cluster-management.io/standards: NIST SP 800-53
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    spec:
      remediationAction: inform
      disabled: false
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-lvmcluster-removal-inform
            spec:
              remediationAction: inform 
    1
    
              severity: low
              object-templates:
                - complianceType: mustnothave
                  objectDefinition:
                    kind: LVMCluster
                    apiVersion: lvm.topolvm.io/v1alpha1
                    metadata:
                      name: my-lvmcluster
                      namespace: openshift-storage 
    2
    
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-policy-lvmcluster-check
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-policy-lvmcluster-check
    subjects:
      - apiGroup: policy.open-cluster-management.io
        kind: Policy
        name: policy-lvmcluster-inform
    ---
    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-policy-lvmcluster-check
    spec:
      clusterConditions:
        - status: "True"
          type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
          - key: mykey
            operator: In
            values:
              - myvalue
    Copy to Clipboard Toggle word wrap

    1
    정책 템플릿 spec.remediationAction은 spec.remediationAction 에 대한 이전 매개변수 값으로 재정의됩니다.
    2
    네임스페이스 필드에는 openshift-storage 값이 있어야 합니다.
  6. 다음 명령을 실행하여 정책 CR을 만듭니다.

    $ oc create -f <file_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 정책 CR의 상태를 확인하세요.

    $ oc get policy -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                       REMEDIATION ACTION   COMPLIANCE STATE   AGE
    policy-lvmcluster-delete   enforce              Compliant          15m
    policy-lvmcluster-inform   inform               Compliant          15m
    Copy to Clipboard Toggle word wrap

    중요

    정책 CR은 준수 상태여야 합니다.

5.4.5. 스토리지 프로비저닝

LVMCluster 사용자 정의 리소스(CR)를 사용하여 LVM 볼륨 그룹을 만든 후에는 영구 볼륨 클레임(PVC)을 만들어 스토리지를 프로비저닝할 수 있습니다.

각 파일 시스템 유형에 대해 요청할 수 있는 최소 저장 크기는 다음과 같습니다.

  • 블록 : 8MiB
  • xfs : 300MiB
  • ext4: 32 MiB

PVC를 생성하려면 PersistentVolumeClaim 객체를 생성해야 합니다.

사전 요구 사항

  • LVMCluster CR을 생성했습니다.

프로세스

  1. OpenShift CLI( oc )에 로그인합니다.
  2. PersistentVolumeClaim 객체를 생성합니다.

    PersistentVolumeClaim 오브젝트의 예

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: lvm-block-1 
    1
    
      namespace: default
    spec:
      accessModes:
        - ReadWriteOnce
      volumeMode: Block 
    2
    
      resources:
        requests:
          storage: 10Gi 
    3
    
        limits:
          storage: 20Gi 
    4
    
      storageClassName: lvms-vg1 
    5
    Copy to Clipboard Toggle word wrap

    1
    PVC의 이름을 지정하세요.
    2
    블록 PVC를 생성하려면 이 필드를 블록 으로 설정합니다. 파일 PVC를 생성하려면 이 필드를 파일 시스템 으로 설정합니다.
    3
    저장 크기를 지정하세요. 값이 최소 저장 크기보다 작으면 요청된 저장 크기가 최소 저장 크기로 반올림됩니다. 프로비저닝할 수 있는 총 스토리지 크기는 LVM(Logical Volume Manager) 씬 풀의 크기와 과도한 프로비저닝 요소에 따라 제한됩니다.
    4
    선택 사항: 저장 한도를 지정합니다. 이 필드를 최소 저장 크기보다 크거나 같은 값으로 설정합니다. 그렇지 않으면 PVC 생성이 오류와 함께 실패합니다.
    5
    storageClassName 필드의 값은 lvms-<device_class_name> 형식이어야 하며, 여기서 <device_class_name>은 LVMCluster CR의 deviceClasses.name 필드의 값입니다. 예를 들어 deviceClasses.name 필드가 Cryostat1로 설정된 경우 storageClassName 필드를 lvms- vg1 로 설정해야 합니다.
    참고

    저장 클래스의 volumeBindingMode 필드가 WaitForFirstConsumer 로 설정됩니다.

  3. 다음 명령을 실행하여 PVC를 생성합니다.

    # oc create -f <file_name> -n <application_namespace>
    Copy to Clipboard Toggle word wrap
    참고

    생성된 PVC는 해당 PVC를 사용하는 포드를 배포할 때까지 보류 상태로 유지됩니다.

검증

  • PVC가 생성되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc get pvc -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvm-block-1   Bound    pvc-e90169a8-fd71-4eea-93b8-817155f60e47   1Gi        RWO            lvms-vg1       5s
    Copy to Clipboard Toggle word wrap

5.4.6. 클러스터 저장소를 확장하는 방법

OpenShift Container Platform은 베어 메탈 사용자 프로비저닝 인프라의 클러스터에 대한 추가 워커 노드를 지원합니다. 사용 가능한 스토리지가 있는 새로운 워커 노드를 추가하거나 기존 워커 노드에 새로운 장치를 추가하여 클러스터의 스토리지를 확장할 수 있습니다.

논리 볼륨 관리자(LVM) 스토리지는 노드가 활성화되면 추가 워커 노드를 감지하여 사용합니다.

클러스터의 기존 워커 노드에 새 장치를 추가하려면 LVMCluster 사용자 정의 리소스(CR)의 deviceSelector 필드에 새 장치의 경로를 추가해야 합니다.

중요

LVMCluster CR을 생성하는 동안에만 LVMCluster CR에 deviceSelector 필드를 추가할 수 있습니다. LVMCluster CR을 생성하는 동안 deviceSelector 필드를 추가하지 않은 경우 LVMCluster CR을 삭제하고 deviceSelector 필드가 포함된 새 LVMCluster CR을 생성해야 합니다.

LVMCluster CR에 deviceSelector 필드를 추가하지 않으면 LVM Storage는 장치를 사용할 수 있을 때 자동으로 새 장치를 추가합니다.

참고

LVM 스토리지는 지원되는 장치만 추가합니다. 지원되지 않는 장치에 대한 자세한 내용은 "LVM 스토리지에서 지원하지 않는 장치"를 참조하세요.

5.4.6.1. CLI를 사용하여 클러스터 저장소 확장

OpenShift CLI( oc )를 사용하여 클러스터의 워커 노드의 저장 용량을 확장할 수 있습니다.

사전 요구 사항

  • 각 클러스터에는 논리 볼륨 관리자(LVM) 스토리지에서 사용할 수 있는 추가 미사용 장치가 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • LVMCluster 사용자 정의 리소스(CR)를 생성했습니다.

프로세스

  1. 다음 명령을 실행하여 LVMCluster CR을 편집합니다.

    $ oc edit <lvmcluster_file_name> -n <namespace>
    Copy to Clipboard Toggle word wrap
  2. deviceSelector 필드에 새 장치의 경로를 추가합니다.

    LVMCluster CR 예제

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
      storage:
        deviceClasses:
    # ...
          deviceSelector: 
    1
    
            paths: 
    2
    
            - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
            optionalPaths: 
    3
    
            - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:90:00.0-nvme-1
    # ...
    Copy to Clipboard Toggle word wrap

    1
    LVM 볼륨 그룹에 추가하려는 장치의 경로를 지정하는 구성이 포함되어 있습니다. 경로 필드, 선택적 경로 필드 또는 둘 다에 장치 경로를 지정할 수 있습니다. pathsoptionalPaths 모두에 장치 경로를 지정하지 않으면 LVM(논리 볼륨 관리자) 스토리지는 지원되는 사용되지 않는 장치를 LVM 볼륨 그룹에 추가합니다. LVM 스토리지는 다음 조건이 충족되는 경우에만 장치를 LVM 볼륨 그룹에 추가합니다.
    • 장치 경로가 존재합니다.
    • 이 장치는 LVM 스토리지에서 지원됩니다. 지원되지 않는 장치에 대한 자세한 내용은 "LVM 스토리지에서 지원하지 않는 장치"를 참조하세요.
    2
    장치 경로를 지정합니다. 이 필드에 지정된 장치 경로가 존재하지 않거나 장치가 LVM 스토리지에서 지원되지 않는 경우 LVMCluster CR은 실패 상태로 전환됩니다.
    3
    선택적인 장치 경로를 지정합니다. 이 필드에 지정된 장치 경로가 존재하지 않거나 장치가 LVM 저장소에서 지원되지 않는 경우, LVM 저장소는 오류를 발생시키지 않고 해당 장치를 무시합니다.
    중요

    장치가 LVM 볼륨 그룹에 추가된 후에는 제거할 수 없습니다.

  3. LVMCluster CR을 저장합니다.
5.4.6.2. 웹 콘솔을 사용하여 클러스터 스토리지 확장

OpenShift Container Platform 웹 콘솔을 사용하여 클러스터에서 작업자 노드의 스토리지 용량을 확장할 수 있습니다.

사전 요구 사항

  • 각 클러스터에 LVM(Logical Volume Manager) 스토리지에서 사용할 추가 사용되지 않는 장치가 있습니다.
  • LVMCluster CR(사용자 정의 리소스)을 생성했습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators설치된 Operators를 클릭합니다.
  3. openshift-storage 네임스페이스에서 LVM Storage 를 클릭합니다.
  4. LVMCluster 탭을 클릭하여 클러스터에서 생성된 LVMCluster CR을 확인합니다.
  5. Actions 메뉴에서 Edit LVMCluster 를 선택합니다.
  6. YAML 탭을 클릭합니다.
  7. LVMCluster CR을 편집하여 deviceSelector 필드에 새 장치 경로를 추가합니다.

    LVMCluster CR의 예

    apiVersion: lvm.topolvm.io/v1alpha1
    kind: LVMCluster
    metadata:
      name: my-lvmcluster
    spec:
      storage:
        deviceClasses:
    # ...
          deviceSelector: 
    1
    
            paths: 
    2
    
            - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
            optionalPaths: 
    3
    
            - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
            - /dev/disk/by-path/pci-0000:90:00.0-nvme-1
    # ...
    Copy to Clipboard Toggle word wrap

    1
    LVM 볼륨 그룹에 추가할 장치의 경로를 지정하는 구성이 포함되어 있습니다. paths 필드, optionalPaths 필드 또는 둘 다에서 장치 경로를 지정할 수 있습니다. 경로와 optionalPaths 모두에 장치 경로를 지정하지 않으면 LVM(Logical Volume Manager) 스토리지에서 지원되는 사용되지 않는 장치가 LVM 볼륨 그룹에 추가됩니다. LVM 스토리지는 다음 조건이 충족되는 경우에만 LVM 볼륨 그룹에 장치를 추가합니다.
    • 장치 경로가 있습니다.
    • 장치는 LVM 스토리지에서 지원합니다. 지원되지 않는 장치에 대한 자세한 내용은 "LVM Storage에서 지원되지 않는 장치"를 참조하십시오.
    2
    장치 경로를 지정합니다. 이 필드에 지정된 장치 경로가 없거나 LVM Storage에서 장치가 지원되지 않는 경우 LVMCluster CR은 Failed 상태로 이동합니다.
    3
    선택적 장치 경로를 지정합니다. 이 필드에 지정된 장치 경로가 없거나 LVM 스토리지에서 장치가 지원되지 않는 경우 LVM 스토리지는 오류가 발생하지 않고 장치를 무시합니다.
    중요

    장치를 LVM 볼륨 그룹에 추가한 후에는 제거할 수 없습니다.

  8. 저장을 클릭합니다.
5.4.6.3. RHACM을 사용하여 클러스터 스토리지 확장

RHACM을 사용하여 클러스터에서 작업자 노드의 스토리지 용량을 확장할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 RHACM 클러스터에 액세스할 수 있습니다.
  • RHACM을 사용하여 LVMCluster CR(사용자 정의 리소스)을 생성했습니다.
  • 각 클러스터에 LVM(Logical Volume Manager) 스토리지에서 사용할 추가 사용되지 않는 장치가 있습니다.

프로세스

  1. OpenShift Container Platform 인증 정보를 사용하여 RHACM CLI에 로그인합니다.
  2. 다음 명령을 실행하여 RHACM을 사용하여 생성한 LVMCluster CR을 편집합니다.

    $ oc edit -f <file_name> -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    & lt;file_name& gt;을 LVMCluster CR의 이름으로 바꿉니다.
  3. LVMCluster CR에서 deviceSelector 필드의 새 장치에 경로를 추가합니다.

    LVMCluster CR의 예

    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: lvms
    spec:
      object-templates:
         - complianceType: musthave
           objectDefinition:
             apiVersion: lvm.topolvm.io/v1alpha1
             kind: LVMCluster
             metadata:
               name: my-lvmcluster
               namespace: openshift-storage
             spec:
               storage:
                 deviceClasses:
    # ...
                   deviceSelector: 
    1
    
                     paths: 
    2
    
                     - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
                     optionalPaths: 
    3
    
                     - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
    # ...
    Copy to Clipboard Toggle word wrap

    1
    LVM 볼륨 그룹에 추가할 장치의 경로를 지정하는 구성이 포함되어 있습니다. paths 필드, optionalPaths 필드 또는 둘 다에서 장치 경로를 지정할 수 있습니다. 경로와 optionalPaths 모두에 장치 경로를 지정하지 않으면 LVM(Logical Volume Manager) 스토리지에서 지원되는 사용되지 않는 장치가 LVM 볼륨 그룹에 추가됩니다. LVM 스토리지는 다음 조건이 충족되는 경우에만 LVM 볼륨 그룹에 장치를 추가합니다.
    • 장치 경로가 있습니다.
    • 장치는 LVM 스토리지에서 지원합니다. 지원되지 않는 장치에 대한 자세한 내용은 "LVM Storage에서 지원되지 않는 장치"를 참조하십시오.
    2
    장치 경로를 지정합니다. 이 필드에 지정된 장치 경로가 없거나 LVM Storage에서 장치가 지원되지 않는 경우 LVMCluster CR은 Failed 상태로 이동합니다.
    3
    선택적 장치 경로를 지정합니다. 이 필드에 지정된 장치 경로가 없거나 LVM 스토리지에서 장치가 지원되지 않는 경우 LVM 스토리지는 오류가 발생하지 않고 장치를 무시합니다.
    중요

    장치를 LVM 볼륨 그룹에 추가한 후에는 제거할 수 없습니다.

  4. LVMCluster CR을 저장합니다.

5.4.7. 영구 볼륨 클레임 확장

클러스터 스토리지를 확장한 후 기존 PVC(영구 볼륨 클레임)를 확장할 수 있습니다.

PVC를 확장하려면 PVC의 storage 필드를 업데이트해야 합니다.

사전 요구 사항

  • 동적 프로비저닝이 사용됩니다.
  • PVC와 연결된 StorageClass 오브젝트에는 allowVolumeExpansion 필드가 true 로 설정되어 있습니다.

프로세스

  1. OpenShift CLI(oc)에 로그인합니다.
  2. 다음 명령을 실행하여 spec.resources.requests.storage 필드의 값을 현재 값보다 큰 값으로 업데이트합니다.

    $ oc patch pvc <pvc_name> -n <application_namespace> \ 
    1
    
      --type=merge -p \ '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}}' 
    2
    Copy to Clipboard Toggle word wrap
    1
    & lt;pvc_name >을 확장하려는 PVC 이름으로 바꿉니다.
    2
    & lt;desired_size& gt;를 새 크기로 교체하여 PVC를 확장합니다.

검증

  • 크기 조정이 완료되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get pvc <pvc_name> -n <application_namespace> -o=jsonpath={.status.capacity.storage}
    Copy to Clipboard Toggle word wrap

    LVM 스토리지는 확장 중에 PVC에 Resizing 조건을 추가합니다. PVC 확장 후 Resizing 조건을 삭제합니다.

5.4.8. 영구 볼륨 클레임 삭제

OpenShift CLI(oc)를 사용하여 PVC(영구 볼륨 클레임)를 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.

프로세스

  1. OpenShift CLI(oc)에 로그인합니다.
  2. 다음 명령을 실행하여 PVC를 적용합니다.

    $ oc delete pvc <pvc_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

검증

  • PVC가 삭제되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get pvc -n <namespace>
    Copy to Clipboard Toggle word wrap

    삭제된 PVC는 이 명령의 출력에 표시되지 않아야 합니다.

5.4.9. 볼륨 스냅샷 정보

LVM 스토리지에서 프로비저닝하는 PVC(영구 볼륨 클레임)의 스냅샷을 생성할 수 있습니다.

볼륨 스냅샷을 사용하여 다음 작업을 수행할 수 있습니다.

  • 애플리케이션 데이터를 백업합니다.

    중요

    볼륨 스냅샷은 원래 데이터와 동일한 장치에 있습니다. 볼륨 스냅샷을 백업으로 사용하려면 스냅샷을 안전한 위치로 이동해야 합니다. OADP(OpenShift API for Data Protection) 백업 및 복원 솔루션을 사용할 수 있습니다. OADP에 대한 자세한 내용은 "OADP 기능"을 참조하십시오.

  • 볼륨 스냅샷을 만든 상태로 되돌립니다.
참고

볼륨 복제의 볼륨 스냅샷을 생성할 수도 있습니다.

LVM 스토리지에는 다중 노드 토폴로지에서 볼륨 스냅샷을 생성하기 위한 다음과 같은 제한 사항이 있습니다.

  • 볼륨 스냅샷 생성은 LVM 씬 풀 기능을 기반으로 합니다.
  • 볼륨 스냅샷을 생성한 후 노드에 원래 데이터 소스를 추가로 업데이트하기 위한 추가 스토리지 공간이 있어야 합니다.
  • 원래 데이터 소스를 배포한 노드에서만 볼륨 스냅샷을 생성할 수 있습니다.
  • 스냅샷 데이터를 사용하는 PVC를 사용하는 Pod는 원래 데이터 소스를 배포한 노드에서만 예약할 수 있습니다.
5.4.9.2. 볼륨 스냅샷 생성

씬 풀의 사용 가능한 용량 및 초과 프로비저닝 제한을 기반으로 볼륨 스냅샷을 생성할 수 있습니다. 볼륨 스냅샷을 생성하려면 VolumeSnapshotClass 오브젝트를 생성해야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.
  • PVC(영구 볼륨 클레임)가 Bound 상태인지 확인합니다. 이는 일관된 스냅샷에 필요합니다.
  • PVC에 대한 모든 I/O를 중지했습니다.

프로세스

  1. OpenShift CLI(oc)에 로그인합니다.
  2. VolumeSnapshot 오브젝트를 생성합니다.

    VolumeSnapshot 오브젝트의 예

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: lvm-block-1-snap 
    1
    
    spec:
      source:
        persistentVolumeClaimName: lvm-block-1 
    2
    
      volumeSnapshotClassName: lvms-vg1 
    3
    Copy to Clipboard Toggle word wrap

    1
    볼륨 스냅샷의 이름을 지정합니다.
    2
    소스 PVC의 이름을 지정합니다. LVM 스토리지는 이 PVC의 스냅샷을 생성합니다.
    3
    이 필드를 볼륨 스냅샷 클래스의 이름으로 설정합니다.
    참고

    사용 가능한 볼륨 스냅샷 클래스 목록을 가져오려면 다음 명령을 실행합니다.

    $ oc get volumesnapshotclass
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 소스 PVC를 생성한 네임스페이스에 볼륨 스냅샷을 생성합니다.

    $ oc create -f <file_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    LVM 스토리지는 볼륨 스냅샷으로 PVC의 읽기 전용 사본을 생성합니다.

검증

  • 볼륨 스냅샷이 생성되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get volumesnapshot -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME               READYTOUSE   SOURCEPVC     SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS   SNAPSHOTCONTENT                                    CREATIONTIME   AGE
    lvm-block-1-snap   true         lvms-test-1                           1Gi           lvms-vg1        snapcontent-af409f97-55fc-40cf-975f-71e44fa2ca91   19s            19s
    Copy to Clipboard Toggle word wrap

    생성한 볼륨 스냅샷의 READYTOUSE 필드 값은 true 여야 합니다.

5.4.9.3. 볼륨 스냅샷 복원

볼륨 스냅샷을 복원하려면 dataSource.name 필드가 볼륨 스냅샷 이름으로 설정된 PVC(영구 볼륨 클레임)를 생성해야 합니다.

복원된 PVC는 볼륨 스냅샷 및 소스 PVC와 독립적입니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.
  • 볼륨 스냅샷을 생성했습니다.

프로세스

  1. OpenShift CLI(oc)에 로그인합니다.
  2. 볼륨 스냅샷을 복원하려면 구성으로 PersistentVolumeClaim 오브젝트를 생성합니다.

    볼륨 스냅샷을 복원하는 PersistentVolumeClaim 오브젝트의 예

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: lvm-block-1-restore
    spec:
      accessModes:
      - ReadWriteOnce
      volumeMode: Block
      Resources:
        Requests:
          storage: 2Gi 
    1
    
      storageClassName: lvms-vg1 
    2
    
      dataSource:
        name: lvm-block-1-snap 
    3
    
        kind: VolumeSnapshot
        apiGroup: snapshot.storage.k8s.io
    Copy to Clipboard Toggle word wrap

    1
    복원된 PVC의 스토리지 크기를 지정합니다. 요청된 PVC의 스토리지 크기는 복원하려는 볼륨 스냅샷의 stoage 크기보다 크거나 같아야 합니다. 더 큰 PVC가 필요한 경우 볼륨 스냅샷을 복원한 후 PVC의 크기를 조정할 수도 있습니다.
    2
    복원하려는 볼륨 스냅샷의 소스 PVC에 있는 storageClassName 필드 값으로 이 필드를 설정합니다.
    3
    이 필드를 복원할 볼륨 스냅샷의 이름으로 설정합니다.
  3. 다음 명령을 실행하여 볼륨 스냅샷을 생성한 네임스페이스에 PVC를 생성합니다.

    $ oc create -f <file_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

검증

  • 볼륨 스냅샷이 복원되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get pvc -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvm-block-1-restore   Bound    pvc-e90169a8-fd71-4eea-93b8-817155f60e47   1Gi        RWO            lvms-vg1       5s
    Copy to Clipboard Toggle word wrap

5.4.9.4. 볼륨 스냅샷 삭제

PVC(영구 볼륨 클레임)의 볼륨 스냅샷을 삭제할 수 있습니다.

중요

PVC(영구 볼륨 클레임)를 삭제하면 LVM 스토리지가 PVC의 스냅샷이 아닌 PVC만 삭제합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.
  • 삭제할 볼륨 snpashot이 사용되지 않는지 확인했습니다.

프로세스

  1. OpenShift CLI(oc)에 로그인합니다.
  2. 다음 명령을 실행하여 볼륨 스냅샷을 삭제합니다.

    $ oc delete volumesnapshot <volume_snapshot_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

검증

  • 볼륨 스냅샷이 삭제되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc get volumesnapshot -n <namespace>
    Copy to Clipboard Toggle word wrap

    삭제된 볼륨 스냅샷은 이 명령의 출력에 나타나서는 안 됩니다.

5.4.10. 볼륨 클론에 관하여

볼륨 복제본은 기존 영구 볼륨 클레임(PVC)의 복제본입니다. 볼륨 복제본을 생성하여 데이터의 특정 시점 복사본을 만들 수 있습니다.

5.4.10.1. 다중 노드 토폴로지에서 볼륨 복제본 생성에 대한 제한 사항

LVM 스토리지는 다중 노드 토폴로지에서 볼륨 복제본을 생성하는 데 다음과 같은 제한 사항이 있습니다.

  • 볼륨 복제본 생성은 LVM 씬 풀 기능을 기반으로 합니다.
  • 원본 데이터 소스를 추가로 업데이트하기 위해 볼륨 복제본을 만든 후에는 노드에 추가 저장소가 있어야 합니다.
  • 원래 데이터 소스를 배포한 노드에서만 볼륨 복제본을 만들 수 있습니다.
  • 복제 데이터를 사용하는 PVC에 의존하는 Pod는 원본 데이터 소스를 배포한 노드에서만 예약할 수 있습니다.
5.4.10.2. 볼륨 복제본 생성

영구 볼륨 클레임(PVC)의 복제본을 만들려면 소스 PVC를 만든 네임스페이스에 PersistentVolumeClaim 객체를 만들어야 합니다.

중요

복제된 PVC에는 쓰기 권한이 있습니다.

사전 요구 사항

  • 소스 PVC가 Bound 상태인지 확인했습니다. 이는 일관된 복제본을 위해 필요합니다.

프로세스

  1. OpenShift CLI( oc )에 로그인합니다.
  2. PersistentVolumeClaim 객체를 생성합니다.

    볼륨 복제본을 생성하기 위한 PersistentVolumeClaim 개체의 예

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: lvm-pvc-clone
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: lvms-vg1 
    1
    
      volumeMode: Filesystem 
    2
    
      dataSource:
        kind: PersistentVolumeClaim
        name: lvm-pvc 
    3
    
      resources:
        requests:
          storage: 1Gi 
    4
    Copy to Clipboard Toggle word wrap

    1
    이 필드를 소스 PVC의 storageClassName 필드 값으로 설정합니다.
    2
    이 필드를 소스 PVC의 volumeMode 필드로 설정합니다.
    3
    소스 PVC의 이름을 지정합니다.
    4
    복제된 PVC의 저장 크기를 지정합니다. 복제된 PVC의 저장 크기는 소스 PVC의 저장 크기보다 크거나 같아야 합니다.
  3. 다음 명령을 실행하여 소스 PVC를 생성한 네임스페이스에 PVC를 생성합니다.

    $ oc create -f <file_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

검증

  • 볼륨 복제본이 생성되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc get pvc -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvm-block-1-clone   Bound    pvc-e90169a8-fd71-4eea-93b8-817155f60e47   1Gi        RWO            lvms-vg1       5s
    Copy to Clipboard Toggle word wrap

5.4.10.3. 볼륨 복제본 삭제

볼륨 복제본을 삭제할 수 있습니다.

중요

영구 볼륨 클레임(PVC)을 삭제하면 LVM 스토리지는 소스 영구 볼륨 클레임(PVC)만 삭제하고 PVC 복제본은 삭제하지 않습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.

프로세스

  1. OpenShift CLI( oc )에 로그인합니다.
  2. 다음 명령을 실행하여 복제된 PVC를 삭제합니다.

    # oc delete pvc <clone_pvc_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

검증

  • 볼륨 복제본이 삭제되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc get pvc -n <namespace>
    Copy to Clipboard Toggle word wrap

    삭제된 볼륨 복제본은 이 명령의 출력에 나타나서는 안 됩니다.

5.4.11. LVM 스토리지 업데이트

OpenShift Container Platform 버전과의 호환성을 보장하기 위해 LVM 스토리지를 업데이트할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 업데이트했습니다.
  • 이전 버전의 LVM 스토리지를 설치했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 계정을 사용하여 클러스터에 액세스할 수 있습니다.

프로세스

  1. OpenShift CLI( oc )에 로그인합니다.
  2. 다음 명령을 실행하여 LVM 스토리지를 설치하는 동안 생성한 구독 사용자 정의 리소스(CR)를 업데이트합니다.

    $ oc patch subscription lvms-operator -n openshift-storage --type merge --patch '{"spec":{"channel":"<update_channel>"}}' 
    1
    Copy to Clipboard Toggle word wrap
    1
    <update_channel>을 설치하려는 LVM 스토리지 버전으로 바꾸세요. 예를 들어, stable-4.19 .
  3. 다음 명령을 실행하여 업데이트 이벤트를 보고 설치가 완료되었는지 확인하세요.

    $ oc get events -n openshift-storage
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    8m13s       Normal    RequirementsUnknown   clusterserviceversion/lvms-operator.v4.19   requirements not yet checked
    8m11s       Normal    RequirementsNotMet    clusterserviceversion/lvms-operator.v4.19   one or more requirements couldn't be found
    7m50s       Normal    AllRequirementsMet    clusterserviceversion/lvms-operator.v4.19   all requirements found, attempting install
    7m50s       Normal    InstallSucceeded      clusterserviceversion/lvms-operator.v4.19   waiting for install components to report healthy
    7m49s       Normal    InstallWaiting        clusterserviceversion/lvms-operator.v4.19   installing: waiting for deployment lvms-operator to become ready: deployment "lvms-operator" waiting for 1 outdated replica(s) to be terminated
    7m39s       Normal    InstallSucceeded      clusterserviceversion/lvms-operator.v4.19   install strategy completed with no errors
    ...
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 LVM 스토리지 버전을 확인하세요.

    $ oc get subscription lvms-operator -n openshift-storage -o jsonpath='{.status.installedCSV}'
    Copy to Clipboard Toggle word wrap

    출력 예

    lvms-operator.v4.19
    Copy to Clipboard Toggle word wrap

5.4.12. LVM 스토리지 모니터링

클러스터 모니터링을 활성화하려면 LVM 스토리지를 설치한 네임스페이스에 다음 레이블을 추가해야 합니다.

openshift.io/cluster-monitoring=true
Copy to Clipboard Toggle word wrap
중요

RHACM에서 클러스터 모니터링을 활성화하는 방법에 대한 자세한 내용은 관찰 가능성사용자 지정 메트릭 추가를 참조하세요.

5.4.12.1. 지표

메트릭을 확인하여 LVM 스토리지를 모니터링할 수 있습니다.

다음 표에서는 topolvm 메트릭을 설명합니다.

Expand
표 5.9. topolvm 메트릭
경고설명

topolvm_thinpool_data_percent

LVM 씬풀에서 사용된 데이터 공간의 백분율을 나타냅니다.

topolvm_thinpool_metadata_percent

LVM 씬풀에서 사용된 메타데이터 공간의 백분율을 나타냅니다.

topolvm_thinpool_size_bytes

LVM 씬 풀의 크기를 바이트 단위로 나타냅니다.

topolvm_volumegroup_available_bytes

LVM 볼륨 그룹의 사용 가능한 공간을 바이트 단위로 나타냅니다.

topolvm_volumegroup_size_bytes

LVM 볼륨 그룹의 크기를 바이트 단위로 나타냅니다.

topolvm_thinpool_overprovisioned_available

LVM 씬 풀의 사용 가능한 초과 프로비저닝 크기를 바이트 단위로 나타냅니다.

참고

메트릭은 10분마다 업데이트되거나 씬 풀에서 새로운 논리 볼륨 생성과 같은 변경 사항이 있을 때마다 업데이트됩니다.

5.4.12.2. 알림

씬 풀과 볼륨 그룹이 최대 저장 용량에 도달하면 추가 작업이 실패합니다. 이로 인해 데이터 손실이 발생할 수 있습니다.

LVM 스토리지는 씬 풀과 볼륨 그룹의 사용량이 특정 값을 초과하면 다음 알림을 보냅니다.

Expand
표 5.10. LVM 스토리지 경고
경고설명

VolumeGroupUsageAtThresholdNearFull

이 경고는 노드에서 볼륨 그룹과 씬 풀 사용량이 모두 75%를 초과할 때 발생합니다. 데이터 삭제 또는 볼륨 그룹 확장이 필요합니다.

VolumeGroupUsageAtThresholdCritical

이 경고는 노드에서 볼륨 그룹과 씬 풀 사용량이 모두 85%를 초과할 때 발생합니다. 이 경우 볼륨 그룹이 심각하게 가득 찼습니다. 데이터 삭제 또는 볼륨 그룹 확장이 필요합니다.

ThinPoolDataUsageAtThresholdNearFull

이 경고는 볼륨 그룹의 씬 풀 데이터 사용량이 노드에서 75%를 초과할 때 발생합니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다.

ThinPoolDataUsageAtThresholdCritical

이 경고는 노드에서 볼륨 그룹의 씬 풀 데이터 사용량이 85%를 초과할 때 발생합니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다.

ThinPoolMetaDataUsageAtThresholdNearFull

이 경고는 노드에서 볼륨 그룹의 씬 풀 메타데이터 사용량이 75%를 초과할 때 발생합니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다.

ThinPoolMetaDataUsageAtThresholdCritical

이 경고는 노드에서 볼륨 그룹의 씬 풀 메타데이터 사용량이 85%를 초과할 때 발생합니다. 데이터 삭제 또는 씬 풀 확장이 필요합니다.

5.4.13. CLI를 사용하여 LVM 스토리지 제거

OpenShift CLI( oc )를 사용하여 LVM 스토리지를 제거할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 oc 에 로그인했습니다.
  • LVM 스토리지에서 프로비저닝된 영구 볼륨 클레임(PVC), 볼륨 스냅샷 및 볼륨 복제본을 삭제했습니다. 또한 이러한 리소스를 사용하는 애플리케이션도 삭제했습니다.
  • LVMCluster 사용자 정의 리소스(CR)를 삭제했습니다.

프로세스

  1. 다음 명령을 실행하여 LVM Storage Operator의 currentCSV 값을 가져옵니다.

    $ oc get subscription.operators.coreos.com lvms-operator -n <namespace> -o yaml | grep currentCSV
    Copy to Clipboard Toggle word wrap

    출력 예

    currentCSV: lvms-operator.v4.15.3
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 구독을 삭제합니다.

    $ oc delete subscription.operators.coreos.com lvms-operator -n <namespace>
    Copy to Clipboard Toggle word wrap

    출력 예

    subscription.operators.coreos.com "lvms-operator" deleted
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 대상 네임스페이스에서 LVM 스토리지 운영자에 대한 CSV를 삭제합니다.

    $ oc delete clusterserviceversion <currentCSV> -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <currentCSV>를 LVM Storage Operator의 currentCSV 값으로 바꿉니다.

    출력 예

    clusterserviceversion.operators.coreos.com "lvms-operator.v4.15.3" deleted
    Copy to Clipboard Toggle word wrap

검증

  • LVM Storage Operator가 제거되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get csv -n <namespace>
    Copy to Clipboard Toggle word wrap

    LVM Storage Operator가 성공적으로 제거된 경우 이 명령의 출력에 나타나지 않습니다.

5.4.14. 웹 콘솔을 사용하여 LVM 스토리지 설치 제거

OpenShift Container Platform 웹 콘솔을 사용하여 LVM 스토리지를 제거할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 OpenShift Container Platform에 액세스할 수 있습니다.
  • LVM 스토리지에서 프로비저닝된 영구 볼륨 클레임(PVC), 볼륨 스냅샷 및 볼륨 복제본을 삭제했습니다. 또한 이러한 리소스를 사용하는 애플리케이션도 삭제했습니다.
  • LVMCluster 사용자 정의 리소스(CR)를 삭제했습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators설치된 Operators를 클릭합니다.
  3. openshift-storage 네임스페이스에서 LVM 스토리지를 클릭합니다.
  4. 세부 정보 탭을 클릭합니다.
  5. 작업 메뉴에서 Operator 제거를 선택합니다.
  6. 선택 사항: 메시지가 표시되면 이 연산자의 모든 피연산자 인스턴스 삭제 확인란을 선택하여 LVM 저장소의 피연산자 인스턴스를 삭제합니다.
  7. 제거를 클릭합니다.

5.4.15. RHACM을 사용하여 설치된 LVM 스토리지 제거

RHACM을 사용하여 설치한 LVM 스토리지를 제거하려면 LVM 스토리지 설치 및 구성을 위해 생성한 RHACM 정책 사용자 정의 리소스(CR)를 삭제해야 합니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 RHACM 클러스터에 액세스할 수 있습니다.
  • LVM 스토리지에서 프로비저닝된 영구 볼륨 클레임(PVC), 볼륨 스냅샷 및 볼륨 복제본을 삭제했습니다. 또한 이러한 리소스를 사용하는 애플리케이션도 삭제했습니다.
  • RHACM을 사용하여 생성한 LVMCluster CR을 삭제했습니다.

프로세스

  1. OpenShift CLI( oc )에 로그인합니다.
  2. 다음 명령을 사용하여 LVM 스토리지를 설치하고 구성하기 위해 생성한 RHACM 정책 CR을 삭제합니다.

    $ oc delete -f <policy> -n <namespace> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <정책>을 Policy CR YAML 파일의 이름으로 바꾸세요.
  3. LVM 스토리지를 제거하기 위한 구성을 포함하는 정책 CR YAML 파일을 만듭니다.

    LVM 스토리지를 제거하기 위한 정책 CR 예시

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement-uninstall-lvms
    spec:
      clusterConditions:
      - status: "True"
        type: ManagedClusterConditionAvailable
      clusterSelector:
        matchExpressions:
        - key: mykey
          operator: In
          values:
          - myvalue
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding-uninstall-lvms
    placementRef:
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
      name: placement-uninstall-lvms
    subjects:
    - apiGroup: policy.open-cluster-management.io
      kind: Policy
      name: uninstall-lvms
    ---
    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      annotations:
        policy.open-cluster-management.io/categories: CM Configuration Management
        policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
        policy.open-cluster-management.io/standards: NIST SP 800-53
      name: uninstall-lvms
    spec:
      disabled: false
      policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: uninstall-lvms
          spec:
            object-templates:
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: v1
                kind: Namespace
                metadata:
                  name: openshift-storage
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: openshift-storage-operatorgroup
                  namespace: openshift-storage
                spec:
                  targetNamespaces:
                  - openshift-storage
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: lvms-operator
                  namespace: openshift-storage
            remediationAction: enforce
            severity: low
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: ConfigurationPolicy
          metadata:
            name: policy-remove-lvms-crds
          spec:
            object-templates:
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: logicalvolumes.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmclusters.lvm.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmvolumegroupnodestatuses.lvm.topolvm.io
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: apiextensions.k8s.io/v1
                kind: CustomResourceDefinition
                metadata:
                  name: lvmvolumegroups.lvm.topolvm.io
            remediationAction: enforce
            severity: high
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 정책 CR을 만듭니다.

    $ oc create -f <policy> -ns <namespace>
    Copy to Clipboard Toggle word wrap

5.4.16. must-gather를 사용하여 로그 파일 및 진단 정보 다운로드

LVM 스토리지가 문제를 자동으로 해결할 수 없는 경우, must-gather 도구를 사용하여 로그 파일과 진단 정보를 수집합니다. 그러면 귀하 또는 Red Hat 지원팀이 문제를 검토하고 해결책을 결정할 수 있습니다.

프로세스

  • LVM 스토리지 클러스터에 연결된 클라이언트에서 must-gather 명령을 실행합니다.

    $ oc adm must-gather --image=registry.redhat.io/lvms4/lvms-must-gather-rhel9:v4.19 --dest-dir=<directory_name>
    Copy to Clipboard Toggle word wrap

5.4.17. 영구 저장소 문제 해결

LVM(논리 볼륨 관리자) 스토리지를 사용하여 영구 스토리지를 구성하는 동안 문제 해결이 필요한 여러 가지 문제가 발생할 수 있습니다.

5.4.17.1. 보류 상태에 갇힌 PVC 조사

지속적인 볼륨 클레임(PVC)은 다음과 같은 이유로 보류 상태에 멈출 수 있습니다.

  • 컴퓨팅 리소스가 부족합니다.
  • 네트워크 문제.
  • 저장 클래스 또는 노드 선택기가 일치하지 않습니다.
  • 사용 가능한 영구 볼륨(PV)이 없습니다.
  • PV가 있는 노드는 준비 안 됨 상태입니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 사용자로 OpenShift CLI( oc )에 로그인했습니다.

프로세스

  1. 다음 명령을 실행하여 PVC 목록을 검색합니다.

    $ oc get pvc
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    lvms-test   Pending                                      lvms-vg1       11s
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 보류 상태에 갇힌 PVC와 관련된 이벤트를 검사하세요.

    $ oc describe pvc <pvc_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <pvc_name>을 PVC 이름으로 바꿉니다. 예를 들어, lvms-vg1 .

    출력 예

    Type     Reason              Age               From                         Message
    ----     ------              ----              ----                         -------
    Warning  ProvisioningFailed  4s (x2 over 17s)  persistentvolume-controller  storageclass.storage.k8s.io "lvms-vg1" not found
    Copy to Clipboard Toggle word wrap

5.4.17.2. 누락된 스토리지 클래스에서 복구

스토리지 클래스를 찾을 수 없다는 오류가 발생하면 LVMCluster 사용자 정의 리소스(CR)를 확인하고 모든 논리 볼륨 관리자(LVM) 스토리지 포드가 실행 상태인지 확인하세요.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 사용자로 OpenShift CLI( oc )에 로그인했습니다.

프로세스

  1. 다음 명령을 실행하여 LVMCluster CR이 있는지 확인하세요.

    $ oc get lvmcluster -n openshift-storage
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME            AGE
    my-lvmcluster   65m
    Copy to Clipboard Toggle word wrap

  2. LVMCluster CR이 없으면 LVMCluster CR을 만듭니다. 자세한 내용은 "LVMCluster 사용자 정의 리소스를 만드는 방법"을 참조하세요.
  3. openshift-storage 네임스페이스에서 다음 명령을 실행하여 모든 LVM 스토리지 포드가 실행 상태인지 확인합니다.

    $ oc get pods -n openshift-storage
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                  READY   STATUS    RESTARTS      AGE
    lvms-operator-7b9fb858cb-6nsml        3/3     Running   0             70m
    topolvm-controller-5dd9cf78b5-7wwr2   5/5     Running   0             66m
    topolvm-node-dr26h                    4/4     Running   0             66m
    vg-manager-r6zdv                      1/1     Running   0             66m
    Copy to Clipboard Toggle word wrap

    이 명령의 출력에는 다음 포드의 실행 중인 인스턴스가 포함되어야 합니다.

    • lvms-operator
    • vg-manager

      vg-manager 포드가 구성 파일을 로드하는 동안 멈추는 경우, LVM 스토리지에 사용할 수 있는 디스크를 찾지 못해서 발생합니다. 이 문제를 해결하는 데 필요한 정보를 검색하려면 다음 명령을 실행하여 vg-manager Pod의 로그를 검토하세요.

      $ oc logs -l app.kubernetes.io/component=vg-manager -n openshift-storage
      Copy to Clipboard Toggle word wrap
5.4.17.3. 노드 장애 복구

클러스터의 노드 오류로 인해 지속적 볼륨 클레임(PVC)이 보류 상태에 멈출 수 있습니다.

실패한 노드를 식별하려면 topolvm-node Pod의 재시작 횟수를 조사하면 됩니다. 재시작 횟수가 증가했다는 것은 기본 노드에 문제가 있을 가능성이 있음을 나타내며, 이에 대한 추가 조사와 문제 해결이 필요할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 사용자로 OpenShift CLI( oc )에 로그인했습니다.

프로세스

  • 다음 명령을 실행하여 topolvm-node Pod 인스턴스의 재시작 횟수를 살펴보세요.

    $ oc get pods -n openshift-storage
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                  READY   STATUS    RESTARTS      AGE
    lvms-operator-7b9fb858cb-6nsml        3/3     Running   0             70m
    topolvm-controller-5dd9cf78b5-7wwr2   5/5     Running   0             66m
    topolvm-node-dr26h                    4/4     Running   0             66m
    topolvm-node-54as8                    4/4     Running   0             66m
    topolvm-node-78fft                    4/4     Running   17 (8s ago)   66m
    vg-manager-r6zdv                      1/1     Running   0             66m
    vg-manager-990ut                      1/1     Running   0             66m
    vg-manager-an118                      1/1     Running   0             66m
    Copy to Clipboard Toggle word wrap

다음 단계

  • 노드에서 문제를 해결한 후에도 PVC가 보류 상태에 갇힌 경우 강제 정리를 수행해야 합니다. 자세한 내용은 "강제 정리 수행"을 참조하세요.
5.4.17.4. 디스크 장애 복구

영구 볼륨 클레임(PVC)과 관련된 이벤트를 검사하는 동안 실패 메시지가 표시되면 기본 볼륨이나 디스크에 문제가 있을 수 있습니다.

디스크 및 볼륨 프로비저닝 문제는 <storage_class_name> 스토리지 클래스로 볼륨을 프로비저닝하는 데 실패했습니다 와 같은 일반적인 오류 메시지와 함께 발생합니다. 일반적인 오류 메시지 다음에 특정 볼륨 오류 오류 메시지가 나타납니다.

다음 표에서는 볼륨 실패 오류 메시지를 설명합니다.

Expand
표 5.11. 볼륨 실패 오류 메시지
오류 메시지설명

볼륨 존재 확인에 실패했습니다.

볼륨이 이미 존재하는지 확인하는 데 문제가 있음을 나타냅니다. 볼륨 검증 실패는 네트워크 연결 문제나 기타 오류로 인해 발생할 수 있습니다.

볼륨을 바인딩하지 못했습니다

사용 가능한 영구 볼륨(PV)이 PVC의 요구 사항과 일치하지 않으면 볼륨을 바인딩하지 못할 수 있습니다.

실패한 마운트 또는 실패한 첨부 볼륨

이 오류는 볼륨을 노드에 마운트하려고 할 때 문제가 발생했음을 나타냅니다. 디스크에 오류가 발생한 경우 포드가 PVC를 사용하려고 할 때 이 오류가 나타날 수 있습니다.

FailedUnMount

이 오류는 노드에서 볼륨을 마운트 해제하려고 할 때 문제가 발생했음을 나타냅니다. 디스크에 오류가 발생한 경우 포드가 PVC를 사용하려고 할 때 이 오류가 나타날 수 있습니다.

볼륨은 이미 한 노드에만 독점적으로 연결되어 있으므로 다른 노드에 연결할 수 없습니다.

이 오류는 ReadWriteMany 액세스 모드를 지원하지 않는 스토리지 솔루션에서 나타날 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 사용자로 OpenShift CLI( oc )에 로그인했습니다.

프로세스

  1. 다음 명령을 실행하여 PVC와 관련된 이벤트를 검사합니다.

    $ oc describe pvc <pvc_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <pvc_name>을 PVC 이름으로 바꿉니다.
  2. 문제가 발생한 호스트에 직접 연결을 설정합니다.
  3. 디스크 문제를 해결하세요.

다음 단계

  • 디스크 문제를 해결한 후에도 볼륨 오류 메시지가 지속되거나 반복되는 경우 강제 정리를 수행해야 합니다. 자세한 내용은 "강제 정리 수행"을 참조하세요.
5.4.17.5. 강제 청소 수행

문제 해결 절차를 완료한 후에도 디스크 또는 노드 관련 문제가 지속되면 강제 정리를 수행해야 합니다. 강제 정리는 지속적인 문제를 해결하고 논리 볼륨 관리자(LVM) 스토리지의 적절한 기능을 보장하는 데 사용됩니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 클러스터 관리자 권한이 있는 사용자로 OpenShift CLI( oc )에 로그인했습니다.
  • LVM 스토리지를 사용하여 생성된 모든 영구 볼륨 클레임(PVC)을 삭제했습니다.
  • LVM 스토리지를 사용하여 생성된 PVC를 사용하는 포드를 중지했습니다.

프로세스

  1. 다음 명령을 실행하여 openshift-storage 네임스페이스로 전환합니다.

    $ oc project openshift-storage
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 LogicalVolume 사용자 정의 리소스(CR)가 있는지 확인하세요.

    $ oc get logicalvolume
    Copy to Clipboard Toggle word wrap
    1. LogicalVolume CR이 있는 경우 다음 명령을 실행하여 해당 CR을 삭제합니다.

      $ oc delete logicalvolume <name> 
      1
      Copy to Clipboard Toggle word wrap
      1
      <이름>을 LogicalVolume CR의 이름으로 바꾸세요.
    2. LogicalVolume CR을 삭제한 후 다음 명령을 실행하여 종료자를 제거합니다.

      $ oc patch logicalvolume <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 
      1
      Copy to Clipboard Toggle word wrap
      1
      <이름>을 LogicalVolume CR의 이름으로 바꾸세요.
  3. 다음 명령을 실행하여 LVMVolumeGroup CR이 있는지 확인하세요.

    $ oc get lvmvolumegroup
    Copy to Clipboard Toggle word wrap
    1. LVMVolumeGroup CR이 있는 경우 다음 명령을 실행하여 해당 CR을 삭제합니다.

      $ oc delete lvmvolumegroup <name> 
      1
      Copy to Clipboard Toggle word wrap
      1
      <이름>을 LVMVolumeGroup CR의 이름으로 바꾸세요.
    2. LVMVolumeGroup CR을 삭제한 후 다음 명령을 실행하여 종료자를 제거합니다.

      $ oc patch lvmvolumegroup <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 
      1
      Copy to Clipboard Toggle word wrap
      1
      <이름>을 LVMVolumeGroup CR의 이름으로 바꾸세요.
  4. 다음 명령을 실행하여 LVMVolumeGroupNodeStatus CR을 삭제합니다.

    $ oc delete lvmvolumegroupnodestatus --all
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 LVMCluster CR을 삭제합니다.

    $ oc delete lvmcluster --all
    Copy to Clipboard Toggle word wrap
    1. LVMCluster CR을 삭제한 후 다음 명령을 실행하여 종료자를 제거합니다.

      $ oc patch lvmcluster <name> -p '{"metadata":{"finalizers":[]}}' --type=merge 
      1
      Copy to Clipboard Toggle word wrap
      1
      <이름>을 LVMCluster CR의 이름으로 바꾸세요.

6장. CSI(Container Storage Interface) 사용

6.1. CSI 볼륨 구성

CSI(Container Storage Interface)를 사용하면 OpenShift Container Platform이 CSI 인터페이스를 영구 스토리지로 구현하는 스토리지 백엔드에서 스토리지를 사용할 수 있습니다.

참고

OpenShift Container Platform 4.19는 CSI 사양 의 버전 1.6.0을 지원합니다.

6.1.1. CSI 아키텍처

CSI 드라이버는 일반적으로 컨테이너 이미지로 제공됩니다. 이러한 컨테이너는 OpenShift Container Platform이 실행되는 위치를 인식하지 못합니다. OpenShift Container Platform에서 CSI 호환 스토리지 백엔드를 사용하려면 클러스터 관리자가 OpenShift Container Platform과 스토리지 드라이버 간의 브리지 역할을 하는 여러 구성 요소를 배포해야 합니다.

다음 다이어그램에서는 OpenShift Container Platform 클러스터의 Pod에서 실행되는 구성 요소에 대한 상위 수준 개요를 설명합니다.

다른 스토리지 백엔드에 대해 여러 CSI 드라이버를 실행할 수 있습니다. 각 드라이버에는 드라이버 및 CSI 등록 기관과 함께 자체 외부 컨트롤러 배포 및 데몬 세트가 필요합니다.

6.1.1.1. 외부 CSI 컨트롤러

외부 CSI 컨트롤러는 5개의 컨테이너가 있는 하나 이상의 Pod를 배포하는 배포입니다.

  • 스냅샷터 컨테이너는 VolumeSnapshotVolumeSnapshotContent 객체를 감시하고 VolumeSnapshotContent 객체의 생성 및 삭제를 담당합니다.
  • 크기 조절 컨테이너는 PersistentVolumeClaim 업데이트를 감시하고 PersistentVolumeClaim 개체에 대한 추가 저장소를 요청하는 경우 CSI 엔드포인트에 대해 ControllerExpandVolume 작업을 트리거하는 사이드카 컨테이너입니다.
  • 외부 CSI 연결 컨테이너는 OpenShift Container Platform의 attachdetach 호출을 CSI 드라이버에 대한 각 ControllerPublishControllerUnpublish 호출로 변환합니다.
  • OpenShift Container Platform으로부터의 provisiondelete 호출을 CSI 드라이버의 해당 CreateVolumeDeleteVolume 호출로 변환하는 외부 CSI 프로비저너 컨테이너입니다.
  • CSI 드라이버 컨테이너입니다.

CSI 연결 및 CSI 프로비저너 컨테이너는 UNIX 도메인 소켓을 사용해 CSI 드라이버 컨테이너와 통신하여 CSI 통신이 Pod를 종료하지 않도록 합니다. Pod 외부에서 CSI 드라이버에 액세스할 수 없습니다.

참고

attach, detach, provision, delete 작업에는 일반적으로 스토리지 백엔드에 인증 정보를 사용하려면 CSI 드라이버가 필요합니다. 컴퓨팅 노드의 심각한 보안 위반 시 인증 정보가 사용자 프로세스에 유출되지 않도록 인프라 노드에서 CSI 컨트롤러 Pod를 실행합니다.

참고

외부 연결에서는 타사 attach 또는 detach 작업을 지원하지 않는 CSI 드라이버에서도 실행해야 합니다. 외부 연결은 CSI 드라이버에 ControllerPublish 또는 ControllerUnpublish 작업을 발행하지 않습니다. 그러나 필요한 OpenShift Container Platform 연결 API를 구현하려면 실행해야 합니다.

6.1.1.2. CSI 드라이버 데몬 세트

CSI 드라이버 데몬 세트는 OpenShift Container Platform이 CSI 드라이버에서 제공한 스토리지를 노드에 마운트하고 사용자 워크로드(Pod)에서 PV(영구 볼륨)로 사용할 수 있는 모든 노드에서 Pod를 실행합니다. CSI 드라이버가 설치된 Pod에는 다음 컨테이너가 포함되어 있습니다.

  • CSI 드라이버 등록 기관. CSI 드라이버를 노드에서 실행 중인 openshift-node 서비스에 등록합니다. 노드에서 실행되는 openshift-node 프로세스는 노드에서 사용 가능한 UNIX 도메인 소켓을 사용하여 CSI 드라이버와 직접 연결합니다.
  • CSI 드라이버.

노드에 배포된 CSI 드라이버는 스토리지 백엔드에 최대한 적은 수의 인증 정보가 있어야 합니다. OpenShift Container Platform은 NodePublish / NodeUnpublishNodeStage / NodeUnstage 와 같은 CSI 호출의 노드 플러그인 세트가 구현된 경우에만 이러한 호출을 사용합니다.

6.1.2. OpenShift Container Platform에서 지원되는 CSI 드라이버

OpenShift Container Platform은 기본적으로 특정 CSI 드라이버를 설치하여 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 저장 옵션을 제공합니다.

지원되는 스토리지 자산에 마운트된 CSI 프로비저닝 영구 볼륨을 생성하기 위해 OpenShift Container Platform은 기본적으로 필요한 CSI 드라이버 Operator, CSI 드라이버 및 필요한 스토리지 클래스를 설치합니다. Operator 및 드라이버의 기본 네임스페이스에 대한 자세한 내용은 특정 CSI Driver Operator 설명서를 참조하십시오.

중요

AWS EFS 및 GCP Filestore CSI 드라이버는 기본적으로 설치되지 않으므로 수동으로 설치해야 합니다. AWS EFS CSI 드라이버를 설치하는 방법에 대한 지침은 AWS Elastic File Service CSI 드라이버 운영자 설정을 참조하세요. GCP Filestore CSI 드라이버를 설치하는 방법에 대한 지침은 Google Compute Platform Filestore CSI 드라이버 운영자를 참조하세요.

다음 표에서는 OpenShift Container Platform과 함께 설치되고 OpenShift Container Platform에서 지원하는 CSI 드라이버와 볼륨 스냅샷 및 크기 조정 등 해당 드라이버가 지원하는 CSI 기능을 설명합니다.

중요

다음 표에 CSI 드라이버가 나열되어 있지 않으면 CSI 스토리지 공급업체에서 제공하는 설치 지침에 따라 지원되는 CSI 기능을 사용해야 합니다.

Expand
표 6.1. OpenShift Container Platform에서 지원되는 CSI 드라이버 및 기능
CSI 드라이버CSI 볼륨 스냅샷CSI 볼륨 그룹 스냅샷 [1]CSI 복제CSI 크기 조정인라인 임시 볼륨

AWS EBS

 ✅

 ✅

AWS EFS

Google Compute Platform(GCP) 영구 디스크(PD)

  ✅

[2]

 ✅

GCP 파일스토어

 ✅

 ✅

IBM Power® 가상 서버 블록

 ✅

IBM Cloud® Block

 ✅[3]

 ✅[3]

LVM 스토리지

 ✅

 ✅

 ✅

Microsoft Azure Disk

 ✅

 ✅

 ✅

Microsoft Azure Stack Hub

 ✅

 ✅

 ✅

Microsoft Azure File

 ✅[4]

 ✅[4]

 ✅

 ✅

OpenStack Cinder

 ✅

 ✅

 ✅

OpenShift Data Foundation

 ✅

 ✅

 ✅

 ✅

OpenStack Manila

 ✅

 ✅

공유 리소스

 ✅

CIFS/SMB

 ✅

VMware vSphere

 ✅[5]

 ✅[6]

1.

중요

CSI 볼륨 그룹 스냅샷은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

2.

  • 스토리지 풀이 있는 하이퍼 디스크 분산 디스크에서 복제가 지원되지 않습니다.

3.

  • 오프라인 스냅샷 또는 크기 조정을 지원하지 않습니다. 볼륨은 실행 중인 Pod에 연결해야 합니다.

4.

  • Azure 파일 복제는 NFS 프로토콜을 지원하지 않습니다. SMB 프로토콜을 사용하는 azurefile-csi 스토리지 클래스를 지원합니다.
  • Azure File 복제 및 스냅샷은 기술 프리뷰 기능입니다.
중요

Azure File CSI 복제 및 스냅샷은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

5.

  • vCenter Server 및 ESXi 모두에 vSphere 버전 7.0 업데이트 3 이상이 필요합니다.
  • fileshare 볼륨을 지원하지 않습니다.

6.

  • 온라인 확장은 vSphere 버전 7.0 업데이트 2 이상에서 지원됩니다.

6.1.3. 동적 프로비저닝

영구 스토리지의 동적 프로비저닝은 CSI 드라이버 및 기본 스토리지 백엔드의 기능에 따라 달라집니다. CSI 드라이버 공급자는 OpenShift Container Platform에서 스토리지 클래스와 구성에 사용 가능한 매개변수를 생성하는 방법을 설명해야 합니다.

동적 프로비저닝을 사용하도록 생성된 스토리지 클래스를 구성할 수 있습니다.

절차

  • 설치된 CSI 드라이버에서 특수 스토리지 클래스가 필요하지 않은 모든 PVC를 프로비저닝하는 기본 스토리지 클래스를 생성합니다.

    # oc create -f - << EOF
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <storage-class> 
    1
    
      annotations:
        storageclass.kubernetes.io/is-default-class: "true"
    provisioner: <provisioner-name> 
    2
    
    parameters:
      csi.storage.k8s.io/fstype: xfs  
    3
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    생성할 스토리지 클래스의 이름입니다.
    2
    설치된 CSI 드라이버의 이름입니다.
    3
    vSphere CSI 드라이버는 XFS 및 Ext4를 포함하여 기본 Red Hat Core 운영 체제 릴리스에서 지원하는 모든 파일 시스템을 지원합니다.

6.1.4. CSI 드라이버 사용 예

다음 예시는 템플릿을 변경하지 않고 기본 MySQL 템플릿을 설치합니다.

사전 요구 사항

  • CSI 드라이버가 배포되었습니다.
  • 동적 프로비저닝을 위해 스토리지 클래스가 생성되었습니다.

절차

  • MySQL 템플릿을 생성합니다.

    # oc new-app mysql-persistent
    Copy to Clipboard Toggle word wrap

    출력 예

    --> Deploying template "openshift/mysql-persistent" to project default
    ...
    Copy to Clipboard Toggle word wrap

    # oc get pvc
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME              STATUS    VOLUME                                   CAPACITY
    ACCESS MODES   STORAGECLASS   AGE
    mysql             Bound     kubernetes-dynamic-pv-3271ffcb4e1811e8   1Gi
    RWO            cinder         3s
    Copy to Clipboard Toggle word wrap

6.1.5. 볼륨 팝업기

볼륨 팝업은 PVC(영구 볼륨 클레임) 사양의 datasource 필드를 사용하여 미리 채워진 볼륨을 생성합니다.

볼륨 채우기는 현재 활성화되어 있으며 기술 프리뷰 기능으로 지원됩니다. 그러나 OpenShift Container Platform에는 볼륨 팝업기가 제공되지 않습니다.

중요

볼륨 팝업은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

볼륨 팝업기에 대한 자세한 내용은 Kubernetes 볼륨 팝업기를 참조하십시오.

6.2. CSI 인라인 임시 볼륨

CSI(Container Storage Interface) 인라인 임시 볼륨을 사용하여 Pod가 배포되고 Pod가 제거될 때 인라인 임시 볼륨을 생성하는 Pod 사양을 정의할 수 있습니다.

이 기능은 지원되는 CSI(Container Storage Interface) 드라이버에서만 사용할 수 있습니다.

  • Azure File CSI 드라이버
  • 보안 저장소 CSI 드라이버

6.2.1. CSI 인라인 임시 볼륨 개요

일반적으로 CSI(Container Storage Interface) 드라이버에서 지원하는 볼륨은 PersistentVolumePersistentVolumeClaim 오브젝트 조합에서만 사용할 수 있습니다.

이 기능을 사용하면 PersistentVolume 오브젝트가 아닌 Pod 사양에 직접 CSI 볼륨을 지정할 수 있습니다. 인라인 볼륨은 임시 볼륨이며 Pod를 다시 시작하면 유지되지 않습니다.

6.2.1.1. 지원 제한
중요

이제 Red Hat OpenShift 1.1 빌드 에서 공유 리소스 CSI 드라이버 기능을 사용할 수 있습니다. 이 기능은 이제 OpenShift Container Platform 4.18 이상에서 제거되었습니다. 이 기능을 사용하려면 Red Hat OpenShift 1.1 이상에서 빌드를 사용하고 있는지 확인합니다.

기본적으로 OpenShift Container Platform에서는 다음과 같은 제한이 있는 CSI 인라인 임시 볼륨을 지원합니다.

  • CSI 드라이버에서만 지원을 사용할 수 있습니다. In-tree 및 FlexVolumes는 지원되지 않습니다.
  • 커뮤니티 또는 스토리지 벤더는 이러한 볼륨을 지원하는 다른 CSI 드라이버를 제공합니다. CSI 드라이버에서 제공하는 설치 지침을 따르십시오.

CSI 드라이버는 임시 용량을 포함하여 인라인 볼륨 기능을 구현하지 못할 수 있습니다. 자세한 내용은 CSI 드라이버 설명서를 참조하십시오.

6.2.2. CSI 볼륨 Admission 플러그인

CSI(Container Storage Interface) 볼륨 Admission 플러그인을 사용하면 Pod 승인 시 CSI 볼륨을 프로비저닝할 수 있는 개별 CSI 드라이버 사용을 제한할 수 있습니다. 관리자는 csi-ephemeral-volume-profile 레이블을 추가할 수 있으며 이 레이블은 Admission 플러그인에서 검사하고 시행, 경고 및 감사 결정에 사용됩니다.

6.2.2.1. 개요

관리자는 CSI 볼륨 Admission 플러그인을 사용하기 위해 다음 예와 같이 CSI 드라이버의 유효 Pod 보안 프로필을 선언하는 CSIDriver 오브젝트에 security.openshift.io/csi-ephemeral-volume-profile 라벨을 추가합니다.

kind: CSIDriver
metadata:
  name: csi.mydriver.company.org
  labels:
    security.openshift.io/csi-ephemeral-volume-profile: restricted 
1
Copy to Clipboard Toggle word wrap
1
csi-ephemeral-volume-profile 라벨을 "제한된"으로 설정된 CSI 드라이버 오브젝트 YAML 파일

이 "효율 프로파일"은 Pod의 네임스페이스가 Pod 보안 표준에 의해 관리될 때 Pod에서 CSI 드라이버를 사용하여 CSI 임시 볼륨을 마운트할 수 있다고 통신합니다.

CSI 볼륨 Admission 플러그인은 Pod가 생성되면 Pod 볼륨을 검사합니다. CSI 볼륨을 사용하는 기존 Pod는 영향을 받지 않습니다. Pod에서 CSI(Container Storage Interface) 볼륨을 사용하는 경우 플러그인은 CSIDriver 오브젝트를 조회하고 csi-ephemeral-volume-profile 라벨을 검사한 다음 적용, 경고 및 감사 결정에 레이블의 값을 사용합니다.

6.2.2.2. Pod 보안 프로필 적용

CSI 드라이버에 csi-ephemeral-volume-profile 레이블이 있는 경우 CSI 드라이버를 사용하여 CSI 드라이버를 사용하여 CSI 임시 볼륨을 마운트하는 Pod는 Pod 보안 표준을 동일한 권한 이상으로 적용하는 네임스페이스에서 실행해야 합니다. 네임스페이스가 보다 제한적인 표준을 적용하는 경우 CSI 볼륨 Admission 플러그인에서 허용을 거부합니다. 다음 표에서는 지정된 라벨 값에 대한 다양한 Pod 보안 프로필에 대한 적용 동작을 설명합니다.

Expand
표 6.2. Pod 보안 프로필 적용
Pod 보안 프로필드라이버 레이블: restricted드라이버 레이블: baseline드라이버 레이블: privileged

restricted

Allowed

Denied

Denied

기준

Allowed

Allowed

Denied

privileged

Allowed

Allowed

Allowed

6.2.2.3. Pod 보안 프로필 경고

CSI 볼륨 Admission 플러그인은 CSI 드라이버의 유효 프로필이 Pod 네임스페이스에 대한 Pod 보안 경고 프로필보다 더 허용되는 경우 경고할 수 있습니다. 다음 표는 지정된 라벨 값에 대해 다양한 Pod 보안 프로필에 대한 경고가 발생하는 경우를 보여줍니다.

Expand
표 6.3. Pod 보안 프로필 경고
Pod 보안 프로필드라이버 레이블: restricted드라이버 레이블: baseline드라이버 레이블: privileged

restricted

No warning

Warning

Warning

기준

No warning

No warning

Warning

privileged

No warning

No warning

No warning

6.2.2.4. Pod 보안 프로필 감사

CSI 드라이버의 유효 프로필이 Pod 네임스페이스의 Pod 보안 감사 프로필보다 더 많은 경우 CSI 볼륨 Admission 플러그인은 Pod에 감사 주석을 적용할 수 있습니다. 다음 표는 지정된 라벨 값에 대해 다양한 Pod 보안 프로필에 적용되는 audit 주석을 보여줍니다.

Expand
표 6.4. Pod 보안 프로필 감사
Pod 보안 프로필드라이버 레이블: restricted드라이버 레이블: baseline드라이버 레이블: privileged

restricted

No audit

Audit

Audit

기준

No audit

No audit

Audit

privileged

No audit

No audit

No audit

6.2.2.5. CSI 볼륨 Admission 플러그인의 기본 동작

CSI 임시 볼륨에 대해 참조된 CSI 드라이버에 csi-ephemeral-volume-profile 레이블이 없는 경우 CSI 볼륨 Admission 플러그인은 드라이버에 적용, 경고 및 감사 동작을 위한 권한 있는 프로필이 있는 것으로 간주합니다. 마찬가지로 Pod의 네임스페이스에 Pod 보안 승인 라벨이 설정되지 않은 경우 Admission 플러그인은 restricted 프로필이 적용, 경고 및 감사 결정에 허용되는 것으로 간주합니다. 따라서 라벨이 설정되지 않은 경우 기본적으로 해당 CSI 드라이버를 사용하는 CSI 임시 볼륨은 권한 있는 네임스페이스에서만 사용할 수 있습니다.

OpenShift Container Platform과 함께 제공되고 임시 볼륨을 지원하는 CSI 드라이버에는 csi-ephemeral-volume-profile 라벨에 적절한 기본값이 설정되어 있습니다.

  • Azure File CSI 드라이버: privileged

필요한 경우 관리자는 레이블의 기본값을 변경할 수 있습니다.

6.2.3. Pod 사양에 CSI 인라인 임시 볼륨 포함

OpenShift Container Platform의 Pod 사양에 CSI 인라인 임시 볼륨을 포함할 수 있습니다. 런타임 시 중첩된 인라인 볼륨은 관련 Pod의 임시 라이프사이클을 따라 CSI 드라이버가 Pod를 생성 및 삭제할 때 볼륨 작업의 모든 단계를 처리합니다.

절차

  1. Pod 오브젝트 정의를 생성하여 파일에 저장합니다.
  2. 파일에 CSI 인라인 임시 볼륨을 삽입합니다.

    my-csi-app.yaml

    kind: Pod
    apiVersion: v1
    metadata:
      name: my-csi-app
    spec:
      containers:
        - name: my-frontend
          image: busybox
          volumeMounts:
          - mountPath: "/data"
            name: my-csi-inline-vol
          command: [ "sleep", "1000000" ]
      volumes: 
    1
    
        - name: my-csi-inline-vol
          csi:
            driver: inline.storage.kubernetes.io
            volumeAttributes:
              foo: bar
    Copy to Clipboard Toggle word wrap

    1
    풀에서 사용되는 볼륨의 이름입니다.
  3. 이전 단계에서 저장한 오브젝트 정의 파일을 생성합니다.

    $ oc create -f my-csi-app.yaml
    Copy to Clipboard Toggle word wrap

6.3. CSI 볼륨 스냅샷

이 문서에서는 지원되는 CSI(Container Storage Interface) 드라이버로 볼륨 스냅샷을 사용하여 OpenShift Container Platform의 데이터 손실을 보호하는 방법을 설명합니다. 영구 볼륨에 대해 숙지하는 것이 좋습니다.

6.3.1. CSI 볼륨 스냅샷 개요

스냅샷은 특정 시점에서 클러스터의 스토리지 볼륨 상태를 나타냅니다. 볼륨 스냅샷을 사용하여 새 볼륨을 프로비저닝할 수 있습니다.

OpenShift Container Platform은 기본적으로 CSI(Container Storage Interface) 볼륨 스냅샷을 지원합니다. 그러나 특정 CSI 드라이버가 필요합니다.

CSI 볼륨 스냅샷을 사용하면 클러스터 관리자가 다음을 수행할 수 있습니다.

  • 스냅샷을 지원하는 타사 CSI 드라이버를 배포합니다.
  • 기존 볼륨 스냅샷에서 새 PVC(영구 볼륨 클레임)를 생성합니다.
  • 기존 PVC의 스냅샷을 가져옵니다.
  • 스냅샷을 다른 PVC로 복원합니다.
  • 기존 VM 스냅샷을 삭제합니다.

CSI 볼륨 스냅샷을 사용하면 앱 개발자가 다음을 수행할 수 있습니다.

  • 애플리케이션 또는 클러스터 수준의 스토리지 백업 솔루션을 개발하기 위한 볼륨 스냅샷을 빌드 블록으로 사용할 수 있습니다.
  • 빠르게 이전 개발 버전으로 롤백할 수 있습니다.
  • 시간마다 전체 복사를 하지 않고 스토리지를 보다 효율적으로 사용할 수 있습니다.

볼륨 스냅샷을 사용할 때는 다음에 유의하십시오.

  • CSI 드라이버에서만 지원을 사용할 수 있습니다. In-tree 및 FlexVolumes는 지원되지 않습니다.
  • OpenShift Container Platform은 일부 CSI 드라이버만 제공됩니다. OpenShift Container Platform Driver Operator가 제공하지 않는 CSI 드라이버의 경우 커뮤니티 또는 스토리지 공급 업체에서 제공하는 CSI 드라이버를 사용하는 것이 좋습니다. CSI 드라이버 공급자가 제공하는 설치 지침을 따릅니다.
  • CSI 드라이버는 볼륨 스냅샷 기능을 구현하거나 사용하지 않을 수 있습니다. 볼륨 스냅샷을 지원하는 CSI 드라이버는 csi-external-snapshotter 사이드카를 사용할 수 있습니다. 자세한 내용은 CSI 드라이버에서 제공하는 설명서를 참조하십시오.

6.3.2. CSI 스냅샷 컨트롤러 및 사이드카

OpenShift Container Platform은 컨트롤 플레인에 배포된 스냅샷 컨트롤러를 제공합니다. 또한, CSI 드라이버 벤더는 CSI 드라이버 설치 중에 설치된 Helper 컨테이너로 CSI 스냅샷 사이드카를 제공합니다.

CSI 스냅샷 컨트롤러 및 사이드카는 OpenShift Container Platform API를 통해 볼륨 스냅샷을 제공합니다. 이러한 외부 구성 요소는 클러스터에서 실행됩니다.

외부 컨트롤러는 CSI Snapshot Controller Operator에 의해 배포됩니다.

6.3.2.1. 외부 컨트롤러

CSI 스냅샷 컨트롤러는 VolumeSnapshotVolumeSnapshotContent 오브젝트를 바인딩합니다. 컨트롤러는 VolumeSnapshotContent 오브젝트를 생성 및 삭제하여 동적 프로비저닝을 관리합니다.

6.3.2.2. 외부 사이드카

CSI 드라이버 벤더는 csi-external-snapshotter 사이드카를 제공합니다. 이 컨테이너는 CSI 드라이버와 함께 배포된 별도의 Helper 컨테이너입니다. 사이드카는 CreateSnapshotDeleteSnapshot 작업을 트리거하여 스냅샷을 관리합니다. 벤더가 제공하는 설치 지침을 따르십시오.

6.3.3. CSI Snapshot Controller Operator 정보

CSI Snapshot Controller Operator는 openshift-cluster-storage-operator 네임스페이스에서 실행됩니다. 기본적으로 모든 클러스터에 CVO(Cluster Version Operator)에 의해 설치됩니다.

CSI Snapshot Controller Operator는 openshift-cluster-storage-operator 네임스페이스에서 실행되는 CSI 스냅샷 컨트롤러를 설치합니다.

6.3.3.1. 볼륨 스냅샷 CRD

OpenShift Container Platform을 설치하는 동안 CSI Snapshot Controller Operator는 snapshot.storage.k8s.io/v1 API 그룹에 다음 스냅샷 CRD(사용자 정의 리소스 정의)를 생성합니다.

VolumeSnapshotContent

클러스터 관리자가 프로비저닝한 클러스터의 볼륨으로 가져온 스냅샷입니다.

PersistentVolume 오브젝트와 유사하게 VolumeSnapshotContent CRD는 스토리지 백엔드의 실제 스냅샷을 가리키는 클러스터 리소스입니다.

수동으로 프로비저닝된 스냅샷의 경우 클러스터 관리자는 여러 VolumeSnapshotContent CRD를 생성합니다. 이는 스토리지 시스템의 실제 볼륨 스냅샷에 대한 세부 정보를 제공합니다.

VolumeSnapshotContent CRD는 네임스페이스가 제공되지 않으며 클러스터 관리자가 사용합니다.

VolumeSnapshot

PersistentVolumeClaim 오브젝트와 유사하게 VolumeSnapshot CRD는 스냅샷에 대한 개발자 요청을 정의합니다. CSI Snapshot Controller Operator는 CSI 스냅샷 컨트롤러를 실행하여 VolumeSnapshot CRD의 바인딩을 적절한 VolumeSnapshotContent CRD로 처리합니다. 바인딩은 일대일 매핑입니다.

VolumeSnapshot CRD에는 네임스페이스가 지정됩니다. 개발자는 CRD를 스냅샷에 대한 개별 요청으로 사용합니다.

VolumeSnapshotClass

클러스터 관리자는 VolumeSnapshot 오브젝트에 속한 다른 속성을 지정할 수 있습니다. 이러한 속성은 스토리지 시스템에서 동일한 볼륨에서 가져온 스냅샷과 다를 수 있으며, 이 경우 영구 볼륨 클레임의 동일한 스토리지 클래스를 사용하여 표시하지 않을 수 있습니다.

VolumeSnapshotClass CRD는 스냅샷을 생성할 때 사용할 csi-external-snapshotter 사이드카에 대한 매개변수를 정의합니다. 이를 통해 여러 옵션이 지원되는 경우 스토리지 백엔드가 어떤 종류의 스냅샷을 동적으로 생성할지 알 수 있습니다.

동적으로 프로비저닝된 스냅샷은 VolumeSnapshotClass CRD를 사용하여 스냅샷을 생성할 때 사용할 스토리지에서 제공되는 특정 매개변수를 지정합니다.

VolumeSnapshotContentClass CRD에는 네임스페이스가 지정되지 않으며, 클러스터 관리자가 사용하여 스토리지 백엔드에 대한 글로벌 구성 옵션을 활성화하기 위한 용도입니다.

6.3.4. 볼륨 스냅샷 프로비저닝

스냅샷을 프로비저닝하는 방법은 동적으로 수동의 두 가지가 있습니다.

6.3.4.1. 동적 프로비저닝

기존 스냅샷을 사용하는 대신 영구 볼륨 클레임에서 스냅샷을 동적으로 수락하도록 요청할 수 있습니다. 매개변수는 VolumeSnapshotClass CRD를 사용하여 지정됩니다.

6.3.4.2. 수동 프로비저닝

클러스터 관리자는 여러 VolumeSnapshotContent 오브젝트를 수동으로 사전 프로비저닝할 수 있습니다. 이를 통해 클러스터 사용자가 사용할 수 있는 실제 볼륨 스냅샷 세부 정보가 제공됩니다.

6.3.5. 볼륨 스냅샷 생성

VolumeSnapshot 오브젝트를 생성할 때 OpenShift Container Platform은 볼륨 스냅샷을 생성합니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터에 로그인합니다.
  • VolumeSnapshot 오브젝트를 지원하는 CSI 드라이버를 사용하여 생성된 PVC입니다.
  • 스토리지 백엔드를 프로비저닝하는 스토리지 클래스입니다.
  • 스냅샷을 사용하려는 PVC(영구 볼륨 클레임)를 사용하는 Pod가 없습니다.

    주의

    포드에서 사용 중인 PVC의 볼륨 스냅샷을 생성하면 기록되지 않은 데이터와 캐시된 데이터가 스냅샷에서 제외될 수 있습니다. 모든 데이터가 디스크에 기록되었는지 확인하려면 스냅샷을 생성하기 전에 PVC를 사용하는 포드를 삭제하세요.

프로세스

볼륨 스냅샷을 동적으로 생성하려면 다음을 수행합니다.

  1. 다음 YAML로 설명된 VolumeSnapshotClass 오브젝트로 파일을 생성합니다.

    volumesnapshotclass.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: csi-hostpath-snap
    driver: hostpath.csi.k8s.io 
    1
    
    deletionPolicy: Delete
    Copy to Clipboard Toggle word wrap

    1
    VolumeSnapshotClass 오브젝트의 스냅샷을 생성하는 데 사용되는 CSI 드라이버의 이름입니다. 이름은 스냅샷을 수행 중인 PVC를 담당하는 스토리지 클래스의 Provisioner 필드와 동일해야 합니다.
    참고

    영구 저장소를 구성하는 데 사용한 드라이버에 따라 추가 매개변수가 필요할 수 있습니다. 기존 VolumeSnapshotClass 객체를 사용할 수도 있습니다.

  2. 다음 명령을 입력하여 이전 단계에서 저장한 오브젝트를 생성합니다.

    $ oc create -f volumesnapshotclass.yaml
    Copy to Clipboard Toggle word wrap
  3. VolumeSnapshot 오브젝트를 생성합니다.

    volumesnapshot-dynamic.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: mysnap
    spec:
      volumeSnapshotClassName: csi-hostpath-snap 
    1
    
      source:
        persistentVolumeClaimName: myclaim 
    2
    Copy to Clipboard Toggle word wrap

    1
    볼륨 스냅샷의 특정 클래스에 대한 요청입니다. volumeSnapshotClassName 설정이 없으며 기본 볼륨 스냅샷 클래스가 있는 경우 기본 볼륨 스냅샷 클래스 이름을 사용하여 스냅샷이 생성됩니다. 그러나 필드가 없으며 기본 볼륨 스냅샷 클래스가 없는 경우에는 스냅샷이 생성되지 않습니다.
    2
    영구 볼륨에 바인딩된 PersistentVolumeClaim 오브젝트의 이름입니다. 이 명령은 스냅샷을 생성할 대상을 정의합니다. 스냅샷을 동적으로 프로비저닝하는 데 필요합니다.
  4. 다음 명령을 입력하여 이전 단계에서 저장한 오브젝트를 생성합니다.

    $ oc create -f volumesnapshot-dynamic.yaml
    Copy to Clipboard Toggle word wrap

스냅샷을 수동으로 프로비저닝하려면 다음을 수행합니다.

  1. 위에서 설명한 볼륨 스냅샷 클래스를 정의하는 것 외에도 volumeSnapshotContentName 매개변수 값을 스냅샷의 소스로 제공해야 합니다.

    volumesnapshot-manual.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: snapshot-demo
    spec:
      source:
        volumeSnapshotContentName: mycontent 
    1
    Copy to Clipboard Toggle word wrap

    1
    사전 프로비저닝된 스냅샷에는 volumeSnapshotContentName 매개변수가 필요합니다.
  2. 다음 명령을 입력하여 이전 단계에서 저장한 오브젝트를 생성합니다.

    $ oc create -f volumesnapshot-manual.yaml
    Copy to Clipboard Toggle word wrap

검증

클러스터에서 스냅샷을 생성한 후 스냅샷에 대한 추가 세부 정보를 사용할 수 있습니다.

  1. 생성된 볼륨 스냅샷에 대한 세부 정보를 표시하려면 다음 명령을 입력합니다.

    $ oc describe volumesnapshot mysnap
    Copy to Clipboard Toggle word wrap

    다음 예시는 mysnap 볼륨 스냅샷에 대한 세부 정보를 표시합니다.

    volumesnapshot.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: mysnap
    spec:
      source:
        persistentVolumeClaimName: myclaim
      volumeSnapshotClassName: csi-hostpath-snap
    status:
      boundVolumeSnapshotContentName: snapcontent-1af4989e-a365-4286-96f8-d5dcd65d78d6 
    1
    
      creationTime: "2020-01-29T12:24:30Z" 
    2
    
      readyToUse: true 
    3
    
      restoreSize: 500Mi
    Copy to Clipboard Toggle word wrap

    1
    컨트롤러가 생성한 실제 스토리지 콘텐츠의 포인터입니다.
    2
    스냅샷이 생성된 시간입니다. 스냅샷에는 이 표시된 시점에서 사용 가능한 볼륨 내용이 포함되어 있습니다.
    3
    값을 true로 설정하면 스냅샷을 사용하여 새 PVC로 복원할 수 있습니다.
    값을 false로 설정하면 스냅샷이 생성됩니다. 하지만 스토리지 백엔드는 스냅샷을 사용할 수 있도록 추가 작업을 수행하여 새 볼륨으로 복원해야 합니다. 예를 들어, Amazon Elastic Block Store 데이터를 다른 저렴한 위치로 이동할 수 있으며, 이 작업에는 몇 분이 걸릴 수 있습니다.
  2. 볼륨 스냅샷이 생성되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get volumesnapshotcontent
    Copy to Clipboard Toggle word wrap

    실제 컨텐츠에 대한 포인터가 표시됩니다. boundVolumeSnapshotContentName 필드가 입력된 경우 VolumeSnapshotContent 오브젝트가 존재하고 스냅샷이 생성된 것입니다.

  3. 스냅샷이 준비되었는지 확인하려면 VolumeSnapshot 오브젝트에 readyToUse: true가 있는지 확인합니다.

6.3.6. 볼륨 스냅샷 삭제

OpenShift Container Platform이 볼륨 스냅샷을 삭제하는 방법을 구성할 수 있습니다.

절차

  1. 다음 예와 같이 VolumeSnapshotClass 오브젝트에 필요한 삭제 정책을 지정합니다.

    volumesnapshotclass.yaml

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: csi-hostpath-snap
    driver: hostpath.csi.k8s.io
    deletionPolicy: Delete 
    1
    Copy to Clipboard Toggle word wrap

    1
    볼륨 스냅샷을 삭제할 때 Delete 값이 설정되면 VolumeSnapshotContent 오브젝트와 함께 기본 스냅샷이 삭제됩니다. Retain 값이 설정된 경우 기본 스냅샷 및 VolumeSnapshotContent 오브젝트다 모두 유지됩니다.
    Retain 값이 설정되고 해당 VolumeSnapshotContent 오브젝트를 삭제하지 않고 VolumeSnapshot 오브젝트가 삭제되면 해당 콘텐츠는 그대로 유지됩니다. 스냅샷 자체는 스토리지 백엔드에서도 유지됩니다.
  2. 다음 명령을 입력하여 볼륨 스냅샷을 삭제합니다.

    $ oc delete volumesnapshot <volumesnapshot_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <volumesnapshot_name>을 삭제하려는 볼륨 스냅샷의 이름으로 바꾸세요.

    출력 예

    volumesnapshot.snapshot.storage.k8s.io "mysnapshot" deleted
    Copy to Clipboard Toggle word wrap

  3. 삭제 정책이 Retain으로 설정된 경우 다음 명령을 입력하여 볼륨 스냅샷 콘텐츠를 삭제합니다.

    $ oc delete volumesnapshotcontent <volumesnapshotcontent_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <volumesnapshotcontent_name>을 삭제하려는 콘텐츠로 바꾸세요.
  4. 선택 사항: VolumeSnapshot 오브젝트가 성공적으로 삭제되지 않으면 삭제 작업이 계속될 수 있도록 다음 명령을 입력하여 남은 리소스의 종료자를 제거합니다.

    중요

    VolumeSnapshot 오브젝트에 대한 영구 볼륨 클레임 또는 볼륨 스냅샷 콘텐츠에서 기존 참조가 없음을 확신할 수 있는 경우에만 종료자를 제거하십시오. --force 옵션을 사용하면 모든 종료자가 제거될 때까지 삭제 작업에서 스냅샷 오브젝트를 삭제하지 않습니다.

    $ oc patch -n $PROJECT volumesnapshot/$NAME --type=merge -p '{"metadata": {"finalizers":null}}'
    Copy to Clipboard Toggle word wrap

    출력 예

    volumesnapshotclass.snapshot.storage.k8s.io "csi-ocs-rbd-snapclass" deleted
    Copy to Clipboard Toggle word wrap

    종료자가 제거되고 볼륨 스냅샷이 삭제됩니다.

6.3.7. 볼륨 스냅샷 복원

VolumeSnapshot CRD 콘텐츠를 사용하여 기존 볼륨을 이전 상태로 복원할 수 있습니다.

VolumeSnapshot CRD가 바인딩되고 readyToUse 값이 true 로 설정되면 해당 리소스를 사용하여 스냅샷의 데이터로 미리 채워진 새 볼륨을 프로비저닝할 수 있습니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터에 로그인합니다.
  • 볼륨 스냅샷을 지원하는 컨테이너 스토리지 인터페이스(CSI) 드라이버를 사용하여 생성된 영구 볼륨 클레임(PVC)입니다.
  • 스토리지 백엔드를 프로비저닝하는 스토리지 클래스입니다.
  • 볼륨 스냅샷이 생성되어 사용할 준비가 되었습니다.

프로세스

  1. 다음과 같이 PVC에서 VolumeSnapshot 데이터 소스를 지정합니다.

    pvc-restore.yaml

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: myclaim-restore
    spec:
      storageClassName: csi-hostpath-sc
      dataSource:
        name: mysnap 
    1
    
        kind: VolumeSnapshot 
    2
    
        apiGroup: snapshot.storage.k8s.io 
    3
    
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
    Copy to Clipboard Toggle word wrap

    1
    소스로 사용할 스냅샷을 나타내는 VolumeSnapshot 오브젝트의 이름입니다.
    2
    VolumeSnapshot 값으로 설정해야 합니다.
    3
    snapshot.storage.k8s.io 값으로 설정해야 합니다.
  2. 다음 명령을 입력하여 PVC를 생성합니다.

    $ oc create -f pvc-restore.yaml
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 입력하여 복원된 PVC가 생성되었는지 확인합니다.

    $ oc get pvc
    Copy to Clipboard Toggle word wrap

    myclaim-restore와 같은 새 PVC가 표시됩니다.

6.3.8. vSphere의 최대 스냅샷 수 변경

vSphere Container Storage Interface(CSI)에서 볼륨당 스냅샷의 기본 최대 개수는 3개입니다. 볼륨당 최대 32개까지 변경할 수 있습니다.

하지만 스냅샷 최대값을 늘리면 성능 저하가 발생하므로 더 나은 성능을 위해 볼륨당 스냅샷을 2~3개만 사용하세요.

VMware 스냅샷 성능에 대한 자세한 권장 사항은 추가 리소스를 참조하세요.

사전 요구 사항

  • 관리자 권한으로 클러스터에 접근합니다.

프로세스

  1. 다음 명령을 실행하여 현재 비밀번호를 확인하세요.

    $ oc -n openshift-cluster-csi-drivers get secret/vsphere-csi-config-secret -o jsonpath='{.data.cloud\.conf}' | base64 -d
    Copy to Clipboard Toggle word wrap

    출력 예

    # Labels with topology values are added dynamically via operator
    [Global]
    cluster-id = vsphere-01-cwv8p
    
    # Populate VCenters (multi) after here
    [VirtualCenter "vcenter.openshift.com"]
    insecure-flag           = true
    datacenters             = DEVQEdatacenter
    password                = "xxxxxxxx"
    user                    = "xxxxxxxx@devcluster.openshift.com"
    migration-datastore-url = ds:///vmfs/volumes/vsan:52c842f232751e0d-3253aadeac21ca82/
    Copy to Clipboard Toggle word wrap

    이 예에서는 스냅샷의 글로벌 최대 수가 구성되지 않았으므로 기본값 3이 적용됩니다.

  2. 다음 명령을 실행하여 스냅샷 제한을 변경하세요.

    • 글로벌 스냅샷 제한 설정:

      $ oc patch clustercsidriver/csi.vsphere.vmware.com --type=merge -p '{"spec":{"driverConfig":{"vSphere":{"globalMaxSnapshotsPerBlockVolume": 10}}}}'
      
      clustercsidriver.operator.openshift.io/csi.vsphere.vmware.com patched
      Copy to Clipboard Toggle word wrap

      이 예에서 글로벌 제한이 10(globalMaxSnapshotsPerBlockVolume 으로 설정)으로 변경됩니다.

    • 가상 볼륨 스냅샷 제한 설정:

      이 매개변수는 가상 볼륨 데이터 저장소에만 제한을 설정합니다. 가상 볼륨의 최대 스냅샷 한도는 설정된 경우 글로벌 제약 조건을 무시하지만, 설정되지 않은 경우 기본적으로 글로벌 한도가 적용됩니다.

      $ oc patch clustercsidriver/csi.vsphere.vmware.com --type=merge -p '{"spec":{"driverConfig":{"vSphere":{"granularMaxSnapshotsPerBlockVolumeInVVOL": 5}}}}'
      clustercsidriver.operator.openshift.io/csi.vsphere.vmware.com patched
      Copy to Clipboard Toggle word wrap

      이 예에서 가상 볼륨 제한은 5로 변경됩니다( granularMaxSnapshotsPerBlockVolumeInVVOL은 5로 설정됨).

    • vSAN 스냅샷 제한 설정:

      이 매개변수는 vSAN 데이터 저장소에만 한도를 설정합니다. vSAN 최대 스냅샷 한도는 설정된 경우 글로벌 제약 조건을 무시하지만, 설정되지 않은 경우 기본적으로 글로벌 한도가 적용됩니다. vSAN ESA 설정에서 최대값을 32로 설정할 수 있습니다.

      $ oc patch clustercsidriver/csi.vsphere.vmware.com --type=merge -p '{"spec":{"driverConfig":{"vSphere":{"granularMaxSnapshotsPerBlockVolumeInVSAN": 7}}}}'
      clustercsidriver.operator.openshift.io/csi.vsphere.vmware.com patched
      Copy to Clipboard Toggle word wrap

      이 예에서 vSAN 제한은 7로 변경됩니다( granularMaxSnapshotsPerBlockVolumeInVSAN 은 7로 설정됨).

검증

  • 다음 명령을 실행하여 변경 사항이 구성 맵에 반영되었는지 확인하세요.

    $ oc -n openshift-cluster-csi-drivers get secret/vsphere-csi-config-secret -o jsonpath='{.data.cloud\.conf}' | base64 -d
    Copy to Clipboard Toggle word wrap

    출력 예

    # Labels with topology values are added dynamically via operator
    [Global]
    cluster-id = vsphere-01-cwv8p
    
    # Populate VCenters (multi) after here
    [VirtualCenter "vcenter.openshift.com"]
    insecure-flag           = true
    datacenters             = DEVQEdatacenter
    password                = "xxxxxxxx"
    user                    = "xxxxxxxx@devcluster.openshift.com"
    migration-datastore-url = ds:///vmfs/volumes/vsan:52c842f232751e0d-3253aadeac21ca82/
    
    [Snapshot]
    global-max-snapshots-per-block-volume = 10 
    1
    Copy to Clipboard Toggle word wrap

    1
    global-max-snapshots-per-block-volume이 이제 10으로 설정되었습니다.

6.3.9. 추가 리소스

6.4. CSI 볼륨 그룹 스냅샷

이 문서에서는 지원되는 컨테이너 스토리지 인터페이스(CSI) 드라이버와 함께 볼륨 그룹 스냅샷을 사용하여 OpenShift Container Platform에서 데이터 손실을 방지하는 방법을 설명합니다. 지속적인 볼륨 에 대해 잘 알고 있는 것이 좋습니다.

중요

CSI 볼륨 그룹 스냅샷은 기술 미리 보기 기능에만 해당됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

이 기술 미리보기 기능을 사용하려면 기능 게이트를 사용하여 해당 기능을 활성화 해야 합니다.

6.4.1. CSI 볼륨 그룹 스냅샷 개요

스냅샷은 특정 시점에서 클러스터의 스토리지 볼륨 상태를 나타냅니다. 볼륨 스냅샷을 사용하여 새 볼륨을 프로비저닝할 수 있습니다.

볼륨 그룹 스냅샷은 레이블 선택기를 사용하여 여러 개의 영구 볼륨 클레임을 그룹화하여 스냅샷을 찍습니다. 볼륨 그룹 스냅샷은 동일한 시점에 생성된 여러 볼륨의 복사본을 나타냅니다. 이 기능은 여러 볼륨이 포함된 애플리케이션에 유용할 수 있습니다.

컨테이너 스토리지 인터페이스(CSI) 볼륨 그룹 스냅샷은 CSI 드라이버에서 지원되어야 합니다. OpenShift Data Foundation은 볼륨 그룹 스냅샷을 지원합니다.

볼륨 그룹 스냅샷은 스냅샷을 관리하기 위한 세 가지 새로운 API 객체를 제공합니다.

VolumeGroupSnapshot
여러 개의 영구 볼륨 클레임에 대한 볼륨 그룹 스냅샷 생성을 요청합니다. 여기에는 볼륨 그룹 스냅샷이 촬영된 타임스탬프, 볼륨 그룹 스냅샷을 사용할 준비가 되었는지 여부 등 볼륨 그룹 스냅샷 작업에 대한 정보가 포함되어 있습니다.
VolumeGroupSnapshotContent
동적으로 생성된 volumeGroupSnapshot에 대한 스냅샷 컨트롤러에 의해 생성됨. 여기에는 볼륨 그룹 스냅샷 ID를 포함한 볼륨 그룹 스냅샷에 대한 정보가 들어 있습니다. 이 개체는 클러스터에 프로비저닝된 리소스(그룹 스냅샷)를 나타냅니다. VolumeGroupSnapshotContent 개체는 생성된 볼륨 그룹 스냅샷에 일대일 매핑으로 바인딩됩니다.
VolumeGroupSnapshotClass
볼륨 그룹 스냅샷을 생성하는 방법(드라이버 정보, 삭제 정책 등)을 설명하기 위해 클러스터 관리자가 작성합니다.

이 세 가지 API 종류는 CRD( CustomResourceDefinitions )로 정의됩니다. CSI 드라이버가 볼륨 그룹 스냅샷을 지원하려면 이러한 CRD를 OpenShift Container Platform 클러스터에 설치해야 합니다.

6.4.2. CSI 볼륨 그룹 스냅샷 제한 사항

볼륨 그룹 스냅샷에는 다음과 같은 제한 사항이 있습니다.

  • 기존 영구 볼륨 클레임(PVC)을 스냅샷으로 표현된 이전 상태로 되돌리는 것을 지원하지 않습니다. 스냅샷에서 새 볼륨을 프로비저닝하는 것만 지원합니다.
  • 예를 들어, 충돌 일관성을 포함한 애플리케이션 일관성은 스토리지 시스템에서 제공하는 것 외에는 보장되지 않습니다. 애플리케이션 일관성에 대한 자세한 내용은 Quiesce 및 Unquiesce Hooks를 참조하세요.

6.4.3. 볼륨 그룹 스냅샷 클래스 생성

볼륨 그룹 스냅샷을 생성하려면 클러스터 관리자가 VolumeGroupSnapshotClass를 생성해야 합니다.

이 개체는 드라이버 정보, 삭제 정책 등을 포함하여 볼륨 그룹 스냅샷을 생성하는 방법을 설명합니다.

사전 요구 사항

  • 관리자 권한으로 실행 중인 OpenShift Container Platform 클러스터에 로그인했습니다.
  • 기능 게이트를 사용하여 이 기능을 활성화했습니다. 피처 게이트를 사용하는 방법에 대한 자세한 내용은 피처 게이트를 사용하여 피처 세트 활성화를 참조하세요.

프로세스

VolumeGroupSnapshotClass를 생성하려면 다음을 수행합니다.

  1. 다음 예제 파일을 사용하여 VolumeGroupSnapshotClass YAML 파일을 만듭니다.

    예제 볼륨 그룹 스냅샷 클래스 YAML 파일

    apiVersion: groupsnapshot.storage.k8s.io/v1beta1
    kind: VolumeGroupSnapshotClass 
    1
    
    metadata:
      name: csi-hostpath-groupsnapclass 
    2
    
    deletionPolicy: Delete
    driver: hostpath.csi.k8s.io
         …...
    Copy to Clipboard Toggle word wrap

    1
    VolumeGroupSnapshotClass 객체를 지정합니다.
    2
    VolumeGroupSnapshotClass 의 이름입니다.
  2. 다음 명령을 실행하여 'VolumeGroupSnapshotClass' 객체를 만듭니다.

    $ oc create -f <volume-group-snapshot-class-filename>.yaml
    Copy to Clipboard Toggle word wrap

6.4.4. 볼륨 그룹 스냅샷 생성

VolumeGroupSnapshot 객체를 생성하면 OpenShift Container Platform에서 볼륨 그룹 스냅샷을 생성합니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터에 로그인합니다.
  • 기능 게이트를 사용하여 이 기능을 활성화했습니다. 피처 게이트를 사용하는 방법에 대한 자세한 내용은 피처 게이트를 사용하여 피처 세트 활성화를 참조하세요.
  • 스냅샷을 그룹화하려는 영구 볼륨 클레임(PVC)은 VolumeGroupSnapshot 객체를 지원하는 CSI 드라이버를 사용하여 생성되었습니다.
  • 스토리지 백엔드를 프로비저닝하는 스토리지 클래스입니다.
  • 관리자가 VolumeGroupSnapshotClass 객체를 생성했습니다.

프로세스

볼륨 그룹 스냅샷을 생성하려면:

  1. 볼륨 그룹 스냅샷에 포함할 PVC를 찾거나 만듭니다.

    $ oc get pvc
    Copy to Clipboard Toggle word wrap

    예제 명령 출력

    NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
    pvc-0       Bound     pvc-a42d7ea2-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s
    pvc-1       Bound     pvc-a42d81b8-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48S
    Copy to Clipboard Toggle word wrap

    이 예제에서는 두 개의 PVC를 사용합니다.

  2. PVC가 스냅샷 그룹에 속하도록 레이블을 지정합니다.

    1. 다음 명령을 실행하여 PVC pvc-0에 라벨을 지정합니다.

      $ oc label pvc pvc-0 group=myGroup
      Copy to Clipboard Toggle word wrap

      출력 예

      persistentvolumeclaim/pvc-0 labeled
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 PVC pvc-1에 라벨을 지정합니다.

      $ oc label pvc pvc-1 group=myGroup
      Copy to Clipboard Toggle word wrap

      출력 예

      persistentvolumeclaim/pvc-1 labeled
      Copy to Clipboard Toggle word wrap

      이 예에서는 PVC "pvc-0" 및 "pvc-1"을 레이블링하여 그룹 "myGroup"에 속하도록 합니다.

  3. 볼륨 그룹 스냅샷을 지정하려면 VolumeGroupSnapshot 객체를 만듭니다.

    1. 다음 예제 파일을 사용하여 VolumeGroupSnapshot 개체 YAML 파일을 만듭니다.

      VolumeGroupSnapshot YAML 파일 예시

      apiVersion: groupsnapshot.storage.k8s.io/v1beta1
      kind: VolumeGroupSnapshot 
      1
      
      metadata:
        name: <volume-group-snapshot-name> 
      2
      
        namespace: <namespace> 
      3
      
      spec:
        volumeGroupSnapshotClassName: <volume-group-snapshot-class-name> 
      4
      
        source:
          selector:
            matchLabels:
              group: myGroup 
      5
      Copy to Clipboard Toggle word wrap

      1
      VolumeGroupSnapshot 객체는 여러 PVC에 대한 볼륨 그룹 스냅샷 생성을 요청합니다.
      2
      볼륨 그룹 스냅샷의 이름입니다.
      3
      볼륨 그룹 스냅샷에 대한 네임스페이스입니다.
      4
      VolumeGroupSnapshotClass 이름입니다. 이 개체는 관리자가 생성하며 볼륨 그룹 스냅샷을 생성하는 방법을 설명합니다.
      5
      스냅샷에 대한 원하는 PVC를 그룹화하는 데 사용되는 레이블의 이름입니다. 이 예에서는 "myGroup"입니다.
    2. 다음 명령을 실행하여 VolumeGroupSnapshot 객체를 만듭니다.

      $ oc create -f <volume-group-snapshot-filename>.yaml
      Copy to Clipboard Toggle word wrap

결과

개별 볼륨 스냅샷은 볼륨 그룹 스냅샷의 일부로 지정된 PVC 수에 따라 생성됩니다.

이러한 개별 볼륨 스냅샷은 다음 형식으로 명명됩니다: <VolumeGroupSnaphotContentUUID+volumeHandle의 해시>:

개별 볼륨 스냅샷 예시

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: snapshot-4dc1c53a29538b36e85003503a4bcac5dbde4cff59e81f1e3bb80b6c18c3fd03
  namespace: default
  ownerReferences:
  - apiVersion: groupsnapshot.storage.k8s.io/v1beta1
    kind: VolumeGroupSnapshot
    name: my-groupsnapshot
    uid: ba2d60c5-5082-4279-80c2-daa85f0af354
  resourceVersion: "124503"
  uid: c0137282-f161-4e86-92c1-c41d36c6d04c
spec:
  source:
    persistentVolumeClaimName:pvc-1
status:
  volumeGroupSnapshotName: volume-group-snapshot-name
Copy to Clipboard Toggle word wrap

이전 예에서 두 개의 개별 볼륨 스냅샷이 볼륨 그룹 스냅샷의 일부로 생성됩니다.

snapshot-4dc1c53a29538b36e85003503a4bcac5dbde4cff59e81f1e3bb80b6c18c3fd03
snapshot-fbfe59eff570171765df664280910c3bf1a4d56e233a5364cd8cb0152a35965b
Copy to Clipboard Toggle word wrap

6.4.5. 볼륨 그룹 스냅샷 복원

VolumeGroupSnapshot 사용자 정의 리소스 정의(CRD) 콘텐츠를 사용하여 기존 볼륨을 이전 상태로 복원할 수 있습니다.

기존 볼륨을 복원하려면 VolumeGroupSnapshot 의 일부인 VolumeSnapshot 개체에서 새 영구 볼륨 클레임(PVC)을 생성하도록 요청할 수 있습니다. 이렇게 하면 지정된 스냅샷의 데이터로 채워진 새 볼륨의 프로비저닝이 트리거됩니다. 볼륨 그룹 스냅샷에 포함된 모든 스냅샷에서 모든 볼륨이 생성될 때까지 이 프로세스를 반복합니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터에 로그인합니다.
  • PVC는 볼륨 그룹 스냅샷을 지원하는 CSI(Container Storage Interface) 드라이버를 사용하여 생성되었습니다.
  • 스토리지 백엔드를 프로비저닝하는 스토리지 클래스입니다.
  • 볼륨 그룹 스냅샷이 생성되어 사용할 준비가 되었습니다.

프로세스

볼륨 그룹 스냅샷에서 기존 볼륨을 이전 상태로 복원하려면 다음을 수행합니다.

  1. 다음 예와 같이 PVC에 대한 볼륨 그룹 스냅샷에서 VolumeSnapshot 데이터 소스를 지정합니다.

    PVC YAML 파일 복원 예시

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: <pvc-restore-name> 
    1
    
      namespace: <namespace> 
    2
    
    spec:
      storageClassName: csi-hostpath-sc
      dataSource:
        name: snapshot-fbfe59eff570171765df664280910c3bf1a4d56e233a5364cd8cb0152a35965b 
    3
    
        kind: VolumeSnapshot 
    4
    
        apiGroup: snapshot.storage.k8s.io 
    5
    
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
    Copy to Clipboard Toggle word wrap

    1
    복원된 PVC의 이름입니다.
    2
    네임스페이스의 이름입니다.
    3
    소스로 사용할 볼륨 그룹 스냅샷의 일부인 개별 볼륨 스냅샷의 이름입니다.
    4
    VolumeSnapshot 값으로 설정해야 합니다.
    5
    snapshot.storage.k8s.io 값으로 설정해야 합니다.
  2. 다음 명령을 실행하여 PVC를 생성합니다.

    $ oc create -f <pvc-restore-filename>.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    이전 단계에서 지정한 PVC 복원 파일의 이름입니다.
  3. 다음 명령을 실행하여 복원된 PVC가 생성되었는지 확인하세요.

    $ oc get pvc
    Copy to Clipboard Toggle word wrap

    첫 번째 단계에서 지정한 이름의 새로운 PVC가 나타납니다.

  4. 볼륨 그룹 스냅샷에 포함된 모든 스냅샷에서 모든 볼륨이 생성될 때까지 필요에 따라 절차를 반복합니다.

6.4.6. 추가 리소스

6.5. CSI 볼륨 복제

볼륨 복제는 OpenShift Container Platform의 데이터 손실을 방지하기 위해 기존 영구 볼륨을 중복합니다. 이 기능은 지원되는 CSI(Container Storage Interface) 드라이버에서만 사용할 수 있습니다. CSI 볼륨 복제본을 프로비저닝하기 전에 영구 볼륨에 대해 잘 알고 있어야 합니다.

6.5.1. CSI 볼륨 복제 개요

CSI(Container Storage Interface) 볼륨 복제는 특정 시점에서 기존 영구 볼륨이 복제됩니다.

볼륨 복제는 볼륨 스냅샷과 유사하지만 더 효율적으로 사용할 수 있습니다. 예를 들어, 클러스터 관리자는 기존 클러스터 볼륨의 다른 인스턴스를 생성하여 클러스터 볼륨을 복제할 수 있습니다.

복제는 새 빈 볼륨을 생성하지 않고 백엔드 장치에서 지정된 볼륨을 정확하게 복제합니다. 동적 프로비저닝 후 모든 표준 볼륨을 사용하는 것처럼 볼륨 복제를 사용할 수 있습니다.

복제에는 새 API 오브젝트가 필요하지 않습니다. PersistentVolumeClaim 오브젝트의 기존 dataSource 필드가 동일한 네임스페이스에서 기존 PersistentVolumeClaim의 이름을 허용하도록 확장됩니다.

6.5.1.1. 지원 제한

기본적으로 OpenShift Container Platform은 이러한 제한이 있는 CSI 볼륨 복제를 지원합니다.

  • 대상 PVC(영구 볼륨 클레임)는 소스 PVC와 동일한 네임스페이스에 있어야 합니다.
  • 복제는 다른 스토리지 클래스에서 지원됩니다.

    • 대상 볼륨은 소스와 다른 스토리지 클래스에서 동일할 수 있습니다.
    • 기본 스토리지 클래스를 사용하고 spec에서 storageClassName 을 생략할 수 있습니다.
  • CSI 드라이버에서만 지원을 사용할 수 있습니다. In-tree 및 FlexVolumes는 지원되지 않습니다.
  • CSI 드라이버가 볼륨 복제 기능을 구현하지 못할 수 있습니다. 자세한 내용은 CSI 드라이버 설명서를 참조하십시오.

6.5.2. CSI 볼륨 복제 프로비저닝

복제된 PVC(영구 볼륨 클레임) API 오브젝트를 생성할 때 CSI 볼륨 복제 프로비저닝을 트리거합니다. 복제본은 다른 PVC 콘텐츠로 미리 채워져 다른 영구 볼륨과 동일한 규칙으로 구성됩니다. 한 가지 예외는 동일한 네임스페이스에서 기존 PVC를 참조하는 dataSource를 추가해야 한다는 것입니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터에 로그인되어 있습니다.
  • 볼륨 복제를 지원하는 CSI 드라이버를 사용하여 PVC가 생성되었습니다.
  • 동적 프로비저닝을 위해 스토리지 백엔드가 구성되어 있습니다. 정적 프로비저너에서는 복제 지원을 사용할 수 없습니다.

절차

기존 PVC에서 PVC를 복제하려면 다음을 수행합니다.

  1. 다음 YAML로 설명된 PersistentVolumeClaim 오브젝트를 사용하여 파일을 생성하고 저장합니다.

    pvc-clone.yaml

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc-1-clone
      namespace: mynamespace
    spec:
      storageClassName: csi-cloning 
    1
    
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
      dataSource:
        kind: PersistentVolumeClaim
        name: pvc-1
    Copy to Clipboard Toggle word wrap

    1
    스토리지 백엔드를 프로비저닝하는 스토리지 클래스의 이름입니다. 기본 스토리지 클래스를 사용할 수 있으며 storageClassName은 사양에서 생략할 수 있습니다.
  2. 다음 명령을 실행하여 이전 단계에서 저장한 오브젝트를 생성합니다.

    $ oc create -f pvc-clone.yaml
    Copy to Clipboard Toggle word wrap

    새 PVC pvc-1-clone이 생성됩니다.

  3. 볼륨 복제가 생성되어 다음 명령을 실행하여 준비되었는지 확인합니다.

    $ oc get pvc pvc-1-clone
    Copy to Clipboard Toggle word wrap

    pvc-1-cloneBound로 표시됩니다.

    이제 새로 복제된 PVC를 사용하여 Pod를 구성할 준비가 되었습니다.

  4. YAML로 설명된 Pod 오브젝트로 파일을 생성하고 저장합니다. 예를 들면 다음과 같습니다.

    kind: Pod
    apiVersion: v1
    metadata:
      name: mypod
    spec:
      containers:
        - name: myfrontend
          image: dockerfile/nginx
          volumeMounts:
          - mountPath: "/var/www/html"
            name: mypd
      volumes:
        - name: mypd
          persistentVolumeClaim:
            claimName: pvc-1-clone 
    1
    Copy to Clipboard Toggle word wrap
    1
    CSI 볼륨 복제 작업 중에 생성된 복제 PVC입니다.

    생성된 Pod 오브젝트가 원래 dataSource PVC와 독립적으로 복제된 PVC를 사용, 복제, 삭제하거나 그 스냅샷을 생성할 준비가 되었습니다.

6.6. 기본 스토리지 클래스 관리

6.6.1. 개요

기본 저장소 클래스를 관리하면 여러 가지 목표를 달성할 수 있습니다.

  • 동적 프로비저닝을 비활성화하여 정적 프로비저닝을 적용합니다.
  • 다른 기본 저장 클래스가 있는 경우 저장 운영자가 초기 기본 저장 클래스를 다시 만들지 못하게 합니다.
  • 기본 저장소 클래스의 이름을 바꾸거나 다른 방식으로 변경

이러한 목표를 달성하려면 ClusterCSIDriver 개체의 spec.storageClassState 필드 설정을 변경합니다. 이 필드에 가능한 설정은 다음과 같습니다.

  • 관리됨 : (기본값) 컨테이너 스토리지 인터페이스(CSI) 운영자는 기본 스토리지 클래스를 적극적으로 관리하므로 클러스터 관리자가 기본 스토리지 클래스에 수행한 대부분의 수동 변경 사항이 제거되고, 수동으로 삭제하려고 하면 기본 스토리지 클래스가 계속해서 다시 생성됩니다.
  • 관리되지 않음 : 기본 저장소 클래스를 수정할 수 있습니다. CSI 운영자는 스토리지 클래스를 적극적으로 관리하지 않으므로 자동으로 생성하는 기본 스토리지 클래스를 조정하지 않습니다.
  • 제거됨 : CSI 연산자는 기본 저장 클래스를 삭제합니다.

기본 스토리지 클래스 관리 기능은 다음 컨테이너 스토리지 인터페이스(CSI) 드라이버 연산자를 통해 지원됩니다.

6.6.2. 웹 콘솔을 사용하여 기본 스토리지 클래스 관리

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.

프로세스

웹 콘솔을 사용하여 기본 스토리지 클래스를 관리하려면 다음을 수행합니다.

  1. 웹 콘솔에 로그인합니다.
  2. Administration > CustomResourceDefinitions 를 클릭합니다.
  3. CustomResourceDefinitions 페이지에서 clustercsidrivers를 입력하여 ClusterCSIDriver 오브젝트를 찾습니다.
  4. ClusterCSIDriver 를 클릭한 다음 Instances 탭을 클릭합니다.
  5. 원하는 인스턴스의 이름을 클릭한 다음 YAML 탭을 클릭합니다.
  6. Managed,Unmanaged 또는 Removed 의 값을 사용하여 spec.storageClassState 필드를 추가합니다.

    예제

    ...
    spec:
      driverConfig:
        driverType: ''
      logLevel: Normal
      managementState: Managed
      observedConfig: null
      operatorLogLevel: Normal
      storageClassState: Unmanaged 
    1
    
    ...
    Copy to Clipboard Toggle word wrap

    1
    spec.storageClassState 필드가 "Unmanaged"로 설정
  7. 저장을 클릭합니다.

6.6.3. CLI를 사용하여 기본 스토리지 클래스 관리

사전 요구 사항

  • cluster-admin 권한으로 클러스터에 액세스합니다.

프로세스

CLI를 사용하여 스토리지 클래스를 관리하려면 다음 명령을 실행합니다.

$ oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" 
1
Copy to Clipboard Toggle word wrap
1
여기서 ${STATE} 는 "제거" 또는 "관리되지 않음" 또는 "관리되지 않음"입니다.

여기서 $DRIVERNAME 은 프로비저너 이름입니다. oc get sc 명령을 실행하여 프로비저너 이름을 찾을 수 있습니다.

6.6.4. absent 또는 여러 기본 스토리지 클래스

6.6.4.1. 여러 기본 스토리지 클래스

기본이 아닌 스토리지 클래스를 기본값으로 표시하고 기존 기본 스토리지 클래스를 설정하지 않거나 기본 스토리지 클래스가 이미 있을 때 기본 스토리지 클래스를 생성하는 경우 여러 기본 스토리지 클래스가 발생할 수 있습니다. 여러 기본 스토리지 클래스가 있는 경우 기본 스토리지 클래스 pvc.spec.storageClassName=nil)를 요청하는 모든 영구 볼륨 클레임(PVC)은 해당 스토리지 클래스의 기본 상태와 관계없이 가장 최근에 생성된 기본 스토리지 클래스를 가져옵니다. 경고 대시보드에서 여러 기본 스토리지 클래스인 MultipleDefaultStorageClasses 가 있다는 경고를 받습니다.

6.6.4.2. 기본 스토리지 클래스가 없음

PVC에서 존재하지 않는 기본 스토리지 클래스를 사용하려는 두 가지 시나리오가 있습니다.

  • 관리자는 기본 스토리지 클래스를 제거하거나 기본이 아닌 것으로 표시한 다음 사용자가 기본 스토리지 클래스를 요청하는 PVC를 생성합니다.
  • 설치 중에 설치 프로그램은 아직 생성되지 않은 기본 스토리지 클래스를 요청하는 PVC를 생성합니다.

이전 시나리오에서는 PVC가 보류 중인 상태로 무기한 유지됩니다. 이 상황을 해결하려면 기본 스토리지 클래스를 생성하거나 기존 스토리지 클래스 중 하나를 기본값으로 선언합니다. 기본 스토리지 클래스가 생성되거나 선언되면 PVC에 새 기본 스토리지 클래스가 제공됩니다. 가능한 경우 PVC는 결국 정적 또는 동적으로 프로비저닝된 PV에 바인딩하고 보류 중 상태로 이동합니다.

6.6.5. 기본 스토리지 클래스 변경

다음 절차에 따라 기본 스토리지 클래스를 변경합니다.

예를 들어 두 개의 스토리지 클래스(gp2standard)가 있으며 기본 스토리지 클래스를 gp2 에서 standard로 변경하려고 합니다.

사전 요구 사항

  • cluster-admin 권한으로 클러스터에 액세스합니다.

프로세스

기본 스토리지 클래스를 변경하려면 다음을 수행합니다.

  1. 스토리지 클래스를 나열합니다.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                 TYPE
    gp3 (default)        ebs.csi.aws.com 
    1
    
    standard             ebs.csi.aws.com
    Copy to Clipboard Toggle word wrap

    1
    (default) 는 기본 스토리지 클래스를 나타냅니다.
  2. 원하는 스토리지 클래스를 기본값으로 설정합니다.

    원하는 스토리지 클래스의 경우 다음 명령을 실행하여 storageclass.kubernetes.io/is-default-class 주석을 true 로 설정합니다.

    $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
    Copy to Clipboard Toggle word wrap
    참고

    짧은 시간 동안 여러 기본 스토리지 클래스를 사용할 수 있습니다. 그러나 결국 하나의 기본 스토리지 클래스만 존재하는지 확인해야 합니다.

    여러 기본 스토리지 클래스가 있는 경우 기본 스토리지 클래스 pvc.spec.storageClassName=nil)를 요청하는 모든 영구 볼륨 클레임(PVC)은 해당 스토리지 클래스의 기본 상태와 관계없이 가장 최근에 생성된 기본 스토리지 클래스를 가져옵니다. 경고 대시보드에서 여러 기본 스토리지 클래스인 MultipleDefaultStorageClasses 가 있다는 경고를 받습니다.

  3. 이전 기본 스토리지 클래스에서 기본 스토리지 클래스 설정을 제거합니다.

    이전 기본 스토리지 클래스의 경우 다음 명령을 실행하여 storageclass.kubernetes.io/is-default-class 주석의 값을 false 로 변경합니다.

    $ oc patch storageclass gp3 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
    Copy to Clipboard Toggle word wrap
  4. 변경 사항을 확인합니다.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                 TYPE
    gp3                  ebs.csi.aws.com
    standard (default)   ebs.csi.aws.com
    Copy to Clipboard Toggle word wrap

6.7. CSI 자동 마이그레이션

일반적으로 OpenShift Container Platform과 함께 제공되는 in-tree 스토리지 드라이버는 더 이상 사용되지 않으며 동등한 CSI(Container Storage Interface) 드라이버로 교체됩니다. OpenShift Container Platform은 동등한 CSI 드라이버에 인트리 볼륨 플러그인에 대한 자동 마이그레이션을 제공합니다.

6.7.1. 개요

이 기능은 in-tree 스토리지 플러그인을 사용하여 프로비저닝된 볼륨을 CSI(Container Storage Interface) 드라이버에 자동으로 마이그레이션합니다.

이 프로세스는 데이터 마이그레이션을 수행하지 않습니다. OpenShift Container Platform은 메모리의 영구 볼륨 오브젝트만 변환합니다. 결과적으로 변환된 영구 볼륨 오브젝트는 디스크에 저장되지 않으며 내용이 변경되지도 않습니다. CSI 자동 마이그레이션이 원활해야 합니다. 이 기능을 활성화하면 기존 API 오브젝트(예: PersistentVolumes, PersistentVolumeClaims, StorageClasses)를 사용하는 방법이 변경되지 않습니다.

CSI 드라이버로 다음 인트리가 자동으로 마이그레이션됩니다.

  • Azure Disk
  • OpenStack Cinder
  • AWS(Amazon Web Services) EBS(Elastic Block Storage)
  • GCP PD(Google Compute Engine Persistent Disk)
  • Azure File
  • VMware vSphere

이러한 볼륨 유형의 CSI 마이그레이션은 일반적으로 사용 가능한 것으로 간주되며 수동 개입이 필요하지 않습니다.

CSI(In-tree 영구 볼륨) 또는 PVC(영구 볼륨 클레임)의 자동 마이그레이션은 원래의 in-tree 스토리지 플러그인에서 지원하지 않는 경우 스냅샷 또는 확장과 같은 새로운 CSI 드라이버 기능을 활성화하지 않습니다.

6.7.2. 스토리지 클래스의 영향

새로운 OpenShift Container Platform 4.13 이상의 경우 기본 스토리지 클래스는 CSI 스토리지 클래스입니다. 이 스토리지 클래스를 사용하여 프로비저닝된 모든 볼륨은 CSI PV(영구 볼륨)입니다.

4.12 및 이전 버전에서 4.13 이상으로 업그레이드된 클러스터의 경우 CSI 스토리지 클래스가 생성되며 업그레이드 전에 기본 스토리지 클래스가 설정되지 않은 경우 기본값으로 설정됩니다. 이름이 동일한 스토리지 클래스가 있는 경우 기존 스토리지 클래스는 변경되지 않은 상태로 유지됩니다. 기존 in-tree 스토리지 클래스는 그대로 유지되며 기존 in-tree PV의 볼륨 확장과 같은 특정 기능에 필요할 수 있습니다. in-tree 스토리지 플러그인을 참조하는 스토리지 클래스는 계속 작동하지만 기본 스토리지 클래스를 CSI 스토리지 클래스로 전환하는 것이 좋습니다.

기본 스토리지 클래스 를 변경하려면 기본 스토리지 클래스 변경을 참조하십시오.

6.8. AWS Elastic Block Store CSI Driver Operator

6.8.1. 개요

OpenShift Container Platform은 AWS EBS CSI 드라이버 를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI(Container Storage Interface) Operator 및 드라이버를 사용할 때는 영구 스토리지 및 CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

AWS EBS 스토리지 자산에 마운트되는 CSI 프로비저닝 PV를 생성하기 위해 OpenShift Container Platform은 openshift-cluster-csi-drivers 네임스페이스에 기본적으로 AWS EBS CSI 드라이버와 AWS EBS CSI 드라이버를 설치합니다.

  • AWS EBS CSI Driver Operator는 기본적으로 PVC를 생성하는 데 사용할 수 있는 StorageClass를 제공합니다. 필요한 경우 이 기본 스토리지 클래스를 비활성화할 수 있습니다( 기본 스토리지 클래스 관리참조). AWS Elastic Block Store를 사용하는 영구 스토리지에 설명된 대로 AWS EBS StorageClass를 생성하는 옵션이 있습니다.
  • AWS EBS CSI 드라이버를 사용하면 AWS EBS PV를 생성 및 마운트할 수 있습니다.
참고

OpenShift Container Platform 4.5 클러스터에 AWS EBS CSI Operator 및 드라이버를 설치하는 경우 OpenShift Container Platform 4.9로 업데이트하기 전에 4.5 Operator 및 드라이버를 제거해야 합니다.

6.8.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 OpenShift Container Platform 사용자 스토리지 옵션을 제공합니다.

중요

OpenShift Container Platform은 기본적으로 CSI 플러그인을 사용하여 Amazon EBS(Elastic Block Store) 스토리지를 프로비저닝합니다.

OpenShift Container Platform에서 AWS EBS 영구 볼륨을 동적으로 프로비저닝하는 방법에 대한 자세한 내용은 AWS Elastic Block Store를 사용하는 영구 스토리지를 참조하십시오.

6.8.3. 사용자 관리 암호화

사용자 관리 암호화 기능을 사용하면 OpenShift Container Platform 노드 루트 볼륨을 암호화하는 설치 중에 키를 제공하고 모든 관리 스토리지 클래스가 이러한 키를 사용하여 프로비저닝된 스토리지 볼륨을 암호화할 수 있습니다. install-config YAML 파일의 platform.<cloud_type>.defaultMachinePlatform 필드에 사용자 지정 키를 지정해야 합니다.

이 기능은 다음 스토리지 유형을 지원합니다.

  • AWS(Amazon Web Services) EBS(Elastic Block Storage)
  • Microsoft Azure Disk 스토리지
  • GCP(Google Cloud Platform) PD(영구 디스크) 스토리지
  • IBM Virtual Private Cloud (VPC) 블록 스토리지
참고

스토리지 클래스에 암호화된 키가 정의되어 있지 않은 경우 스토리지 클래스에 encrypted: "true" 만 설정합니다. AWS EBS CSI 드라이버는 기본적으로 프로비저닝된 스토리지 볼륨을 암호화하기 위해 각 리전에서 Amazon EBS에 의해 자동으로 생성되는 AWS 관리 alias/aws/ebs를 사용합니다. 또한 관리 스토리지 클래스에는 모두 encrypted: "true" 설정이 있습니다.

Amazon EBS용 사용자 관리 암호화를 사용하여 설치하는 방법에 대한 자세한 내용은 설치 구성 매개변수를 참조하십시오.

6.9. AWS Elastic File Service CSI Driver Operator

6.9.1. 개요

OpenShift Container Platform은 AWS EFS(Elastic File Service)용 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI Operator 및 드라이버를 사용할 때는 영구 스토리지CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

AWS EFS CSI Driver Operator를 설치한 후 OpenShift Container Platform은 openshift-cluster-csi-drivers 네임스페이스에 기본적으로 AWS EFS CSI Operator 및 AWS EFS CSI 드라이버를 설치합니다. 이렇게 하면 AWS EFS CSI Driver Operator에서 AWS EFS 자산에 마운트되는 CSI 프로비저닝 PV를 생성할 수 있습니다.

  • AWS EFS CSI Driver Operator 는 설치 후 PVC(영구 볼륨 클레임)를 생성하는 데 사용할 스토리지 클래스를 기본적으로 생성하지 않습니다. 그러나 AWS EFS StorageClass를 수동으로 생성할 수 있습니다. AWS EFS CSI Driver Operator는 필요에 따라 스토리지 볼륨을 생성할 수 있도록 하여 동적 볼륨 프로비저닝을 지원합니다. 이렇게 하면 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없습니다.
  • AWS EFS CSI 드라이버를 사용하면 AWS EFS PV를 생성하고 마운트할 수 있습니다.
참고

AWS EFS는 영역 볼륨이 아닌 지역 볼륨만 지원합니다.

6.9.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 OpenShift Container Platform 사용자 스토리지 옵션을 제공합니다.

6.9.3. AWS EFS CSI Driver Operator 설정

  1. AWS STS(Secure Token Service)와 함께 AWS EFS를 사용하는 경우 STS에 대한 역할 ARM(Amazon Resource Name)을 가져옵니다. 이는 AWS EFS CSI Driver Operator를 설치하는 데 필요합니다.
  2. AWS EFS CSI Driver Operator를 설치합니다.
  3. AWS EFS CSI 드라이버를 설치합니다.
6.9.3.1. 보안 토큰 서비스의 Amazon 리소스 이름 가져오기

다음 절차에서는 AWS Security Token Service(STS)에서 OpenShift Container Platform을 사용하여 AWS EFS CSI Driver Operator를 구성하기 위해 역할 ARM(Amazon Resource Name)을 가져오는 방법을 설명합니다.

중요

AWS EFS CSI Driver Operator를 설치하기 전에 다음 절차 를 수행합니다(AWS EFS CSI Driver Operator 설치 참조).

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • AWS 계정 인증 정보

프로세스

ARN 역할은 여러 가지 방법으로 얻을 수 있습니다. 다음 절차에서는 클러스터 설치와 동일한 개념 및 CCO 유틸리티(ccoctl) 바이너리 툴을 사용하는 하나의 방법을 보여줍니다.

STS를 사용하여 AWS EFS CSI Driver Operator 구성에 대한 역할 ARN을 가져오려면 다음을 수행합니다.

  1. STS를 사용하여 클러스터를 설치하는 데 사용한 OpenShift Container Platform 릴리스 이미지에서 ccoctl 을 추출합니다. 자세한 내용은 "Cloud Credential Operator 유틸리티 구성"을 참조하십시오.
  2. 다음 예와 같이 EFS CredentialsRequest YAML 파일을 생성하고 저장한 다음 credrequests 디렉터리에 배치합니다.

    예제

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: openshift-aws-efs-csi-driver
      namespace: openshift-cloud-credential-operator
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: AWSProviderSpec
        statementEntries:
        - action:
          - elasticfilesystem:*
          effect: Allow
          resource: '*'
      secretRef:
        name: aws-efs-cloud-credentials
        namespace: openshift-cluster-csi-drivers
      serviceAccountNames:
      - aws-efs-csi-driver-operator
      - aws-efs-csi-driver-controller-sa
    Copy to Clipboard Toggle word wrap

  3. ccoctl 툴을 실행하여 AWS에서 새 IAM 역할을 생성하고 로컬 파일 시스템에서 YAML 파일을 생성합니다( <path_to_ccoctl_output_dir>/manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials.yaml).

    $ ccoctl aws create-iam-roles --name=<name> --region=<aws_region> --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com
    Copy to Clipboard Toggle word wrap
    • name=<name>은 추적을 위해 생성된 클라우드 리소스에 태그를 지정하는 데 사용되는 이름입니다.
    • region=<aws_region >은 클라우드 리소스가 생성되는 AWS 리전입니다.
    • dir=<path_to_directory_with_list_of_credentials_requests>/credrequests 는 이전 단계에서 EFS CredentialsRequest 파일을 포함하는 디렉터리입니다.
    • <aws_account_id>는 AWS 계정 ID입니다.

      예제

      $ ccoctl aws create-iam-roles --name my-aws-efs --credentials-requests-dir credrequests --identity-provider-arn arn:aws:iam::123456789012:oidc-provider/my-aws-efs-oidc.s3.us-east-2.amazonaws.com
      Copy to Clipboard Toggle word wrap

      출력 예

      2022/03/21 06:24:44 Role arn:aws:iam::123456789012:role/my-aws-efs -openshift-cluster-csi-drivers-aws-efs-cloud- created
      2022/03/21 06:24:44 Saved credentials configuration to: /manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml
      2022/03/21 06:24:45 Updated Role policy for Role my-aws-efs-openshift-cluster-csi-drivers-aws-efs-cloud-
      Copy to Clipboard Toggle word wrap

  4. 이전 단계에서 예제 출력 의 첫 번째 줄에서 ARN 역할을 복사합니다. 역할 ARN은 "Role"과 "created" 사이의 역할입니다. 이 예에서 ARN 역할은 "arn:aws:iam::123456789012:role/my-aws-efs -openshift-cluster-csi-drivers-aws-efs-cloud"입니다.

    AWS EFS CSI Driver Operator를 설치할 때 ARN 역할이 필요합니다.

6.9.3.2. AWS EFS CSI Driver Operator 설치

AWS EFS CSI Driver Operator(Red Hat Operator)는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. 다음 절차에 따라 클러스터에서 AWS EFS CSI Driver Operator를 설치하고 구성합니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.

프로세스

웹 콘솔에서 AWS EFS CSI Driver Operator를 설치하려면 다음을 수행합니다.

  1. 웹 콘솔에 로그인합니다.
  2. AWS EFS CSI Operator를 설치합니다.

    1. OperatorsOperatorHub를 클릭합니다.
    2. 필터 상자에 AWS EFS CSI를 입력하여 AWS EFS CSI Operator를 찾습니다.
    3. AWS EFS CSI Driver Operator 버튼을 클릭합니다.
    중요

    AWS EFS Operator가 아닌 AWS EFS CSI Driver Operator를 선택해야 합니다. AWS EFS Operator는 커뮤니티 Operator이며 Red Hat에서 지원하지 않습니다.

    1. AWS EFS CSI Driver Operator 페이지에서 설치를 클릭합니다.
    2. Operator 설치 페이지에서 다음을 확인합니다.

      • AWS Secure Token Service(STS)와 함께 AWS EFS를 사용하는 경우 역할 ARN 필드에 Security Token Service에 대한 Amazon 리소스 이름 역할 얻기 절차의 마지막 단계에서 복사한 ARN 역할을 입력합니다.
      • 클러스터의 모든 네임스페이스(기본값)가 선택됩니다.
      • 설치된 네임스페이스openshift-cluster-csi-drivers로 설정됩니다.
    3. 설치를 클릭합니다.

      설치가 완료되면 AWS EFS CSI Operator가 웹 콘솔의 설치된 Operators 섹션에 나열됩니다.

6.9.3.3. AWS EFS CSI 드라이버 설치

AWS EFS CSI Driver Operator (Red Hat 연산자)를 설치한 후 AWS EFS CSI 드라이버를 설치합니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.

프로세스

  1. 관리CustomResourceDefinitionsClusterCSIDriver를 클릭합니다.
  2. Instances 탭에서 Create ClusterCSIDriver를 클릭합니다.
  3. 다음 YAML 파일을 사용합니다.

    apiVersion: operator.openshift.io/v1
    kind: ClusterCSIDriver
    metadata:
        name: efs.csi.aws.com
    spec:
      managementState: Managed
    Copy to Clipboard Toggle word wrap
  4. 생성을 클릭합니다.
  5. 다음 조건이 "참" 상태로 변경될 때까지 기다리세요.

    • AWSEFSDriverNodeServiceControllerAvailable
    • AWSEFSDriverControllerServiceControllerAvailable

6.9.4. AWS EFS 스토리지 클래스 생성

스토리지 클래스는 스토리지 수준 및 사용량을 구분하고 조정하는 데 사용됩니다. 스토리지 클래스를 정의하면 사용자는 동적으로 프로비저닝된 영구 볼륨을 얻을 수 있습니다.

AWS EFS CSI Driver Operator (Red Hat 연산자)는 설치 후 기본적으로 스토리지 클래스를 생성하지 않습니다. 하지만 AWS EFS 스토리지 클래스를 수동으로 생성할 수 있습니다.

6.9.4.1. 콘솔을 사용하여 AWS EFS 스토리지 클래스 생성

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 StorageStorageClasses를 클릭합니다.
  2. StorageClasses 페이지에서 StorageClass 만들기를 클릭합니다.
  3. StorageClass 페이지에서 다음 단계를 수행합니다.

    1. 스토리지 클래스를 참조할 이름을 입력합니다.
    2. 선택 사항: 설명을 입력하세요.
    3. 회수 정책을 선택합니다.
    4. Provisioner 드롭다운 목록에서 efs.csi.aws.com을 선택합니다.
    5. 선택 사항: 선택한 프로비저너에 대한 구성 매개변수를 설정합니다.
  4. 생성을 클릭합니다.
6.9.4.2. CLI를 사용하여 AWS EFS 스토리지 클래스 생성

프로세스

  • StorageClass 객체를 생성합니다.

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: efs-sc
    provisioner: efs.csi.aws.com
    parameters:
      provisioningMode: efs-ap 
    1
    
      fileSystemId: fs-a5324911 
    2
    
      directoryPerms: "700" 
    3
    
      gidRangeStart: "1000" 
    4
    
      gidRangeEnd: "2000" 
    5
    
      basePath: "/dynamic_provisioning" 
    6
    Copy to Clipboard Toggle word wrap
    1
    동적 프로비저닝을 사용하려면 provisioningModeefs-ap 이어야 합니다.
    2
    fileSystemId는 수동으로 생성한 EFS 볼륨의 ID여야 합니다.
    3
    directoryPerms는 볼륨의 루트 디렉터리에 대한 기본 권한입니다. 이 예에서는 볼륨에 소유자만 접근할 수 있습니다.
    4 5
    gidRangeStartgidRangeEnd는 AWS 액세스 지점의 GID를 설정하는 데 사용되는 POSIX 그룹 ID(GID) 범위를 설정합니다. 지정하지 않으면 기본 범위는 50000-7000000입니다. 각 프로비저닝 볼륨이므로 AWS 액세스 지점에는 이 범위의 고유한 GID가 할당됩니다.
    6
    basePath는 동적으로 프로비저닝된 볼륨을 생성하는 데 사용되는 EFS 볼륨의 디렉터리입니다. 이 경우 PV는 EFS 볼륨에서 "/dynamic_provisioning/<random uuid>"로 프로비저닝됩니다. 하위 디렉터리만 PV를 사용하는 pod에 마운트됩니다.
    참고

    클러스터 관리자는 각각 다른 EFS 볼륨을 사용하여 여러 개의 StorageClass 객체를 만들 수 있습니다.

6.9.5. AWS에서 EFS 볼륨에 대한 액세스 생성 및 구성

다음 절차에서는 OpenShift Container Platform에서 사용할 수 있도록 AWS에서 EFS 볼륨을 생성하고 구성하는 방법을 설명합니다.

사전 요구 사항

  • AWS 계정 인증 정보

프로세스

AWS에서 EFS 볼륨에 대한 액세스를 생성하고 구성하려면 다음을 수행합니다.

  1. AWS 콘솔에서 https://console.aws.amazon.com/efs을 엽니다.
  2. 파일 시스템 생성을 클릭합니다.

    • 파일 시스템의 이름을 입력합니다.
    • VPC(가상 사설 클라우드) 의 경우 OpenShift Container Platform 클러스터의 VPC(가상 사설 클라우드)를 선택합니다.
    • 다른 모든 선택 사항에 대해 기본 설정을 수락합니다.
  3. 볼륨 및 마운트 대상이 완전히 생성될 때까지 기다립니다.

    1. https://console.aws.amazon.com/efs#/file-systems로 이동합니다.
    2. 볼륨을 클릭하고 네트워크 탭에서 모든 마운트 대상이 사용 가능하게 될 때까지 기다립니다(-1-2분).
  4. 네트워크 탭에서 Security Group ID(다음 단계에서 필요함)를 복사합니다.
  5. https://console.aws.amazon.com/ec2/v2/home#SecurityGroups로 이동하여 EFS 볼륨에서 사용하는 보안 그룹을 찾습니다.
  6. 인바운드 규칙 탭에서 인바운드 규칙 편집을 클릭한 다음 다음 설정으로 새 규칙을 추가하여 OpenShift Container Platform 노드에서 EFS 볼륨에 액세스할 수 있도록 합니다.

    • 유형: NFS
    • 프로토콜: TCP
    • 포트 범위: 2049
    • 출처: 노드의 사용자 정의/IP 주소 범위 (예: "10.0.0.0/16")

      이 단계에서는 OpenShift Container Platform에서 클러스터의 NFS 포트를 사용할 수 있습니다.

  7. 규칙을 저장합니다.

6.9.6. Amazon Elastic File Storage에 대한 동적 프로비저닝

AWS EFS CSI 드라이버는 다른 CSI 드라이버보다 다양한 형태의 동적 프로비저닝을 지원합니다. 새 PV를 기존 EFS 볼륨의 하위 디렉터리로 프로비저닝합니다. PV는 서로 독립적입니다. 그러나 모두 동일한 EFS 볼륨을 공유합니다. 볼륨이 삭제되면 프로비저닝된 모든 PV도 삭제됩니다. EFS CSI 드라이버는 이러한 각 하위 디렉터리에 대한 AWS 액세스 지점을 생성합니다. AWS AccessPoint 제한으로 인해 단일 StorageClass /EFS 볼륨에서 최대 1000개의 PV만 동적으로 프로비저닝할 수 있습니다.

중요

PVC.spec.resources는 EFS에 의해 적용되지 않습니다.

아래 예제에서는 5GiB의 공간을 요청합니다. 그러나 생성된 PV는 제한적이며 페타바이트와 같이 원하는 양의 데이터를 저장할 수 있습니다. 손상된 애플리케이션이나 불량 애플리케이션도 볼륨에 너무 많은 데이터를 저장할 경우 상당한 비용이 발생할 수 있습니다.

AWS에서 EFS 볼륨 크기를 모니터링하는 것이 좋습니다.

사전 요구 사항

  • Amazon Elastic File Storage(Amazon EFS) 볼륨을 생성했습니다.
  • AWS EFS 스토리지 클래스를 생성했습니다.

프로세스

동적 프로비저닝을 활성화하려면 다음을 수행합니다.

  • 이전에 만든 StorageClass를 참조하여 평소처럼 PVC(또는 StatefulSet 또는 Template)를 만듭니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: test
    spec:
      storageClassName: efs-sc
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 5Gi
    Copy to Clipboard Toggle word wrap

동적 프로비저닝을 설정하는 데 문제가 있는 경우 AWS EFS 문제 해결을 참조하세요.

6.9.7. Amazon Elastic File Storage를 사용하여 정적 PV 만들기

동적 프로비저닝 없이 Amazon EFS(Elastic File Storage) 볼륨을 단일 PV로 사용할 수 있습니다. 전체 볼륨이 pod에 마운트됩니다.

사전 요구 사항

  • Amazon EFS 볼륨을 생성했습니다.

프로세스

  • 다음 YAML 파일을 사용하여 PV를 생성합니다.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: efs-pv
    spec:
      capacity: 
    1
    
        storage: 5Gi
      volumeMode: Filesystem
      accessModes:
        - ReadWriteMany
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      csi:
        driver: efs.csi.aws.com
        volumeHandle: fs-ae66151a 
    2
    
        volumeAttributes:
          encryptInTransit: "false" 
    3
    Copy to Clipboard Toggle word wrap
    1
    spec.capacity에는 의미가 없으며 CSI 드라이버에서 무시합니다. PVC에 바인딩할 때만 사용됩니다. 애플리케이션은 볼륨에 원하는 양의 데이터를 저장할 수 있습니다.
    2
    volumeHandle은 AWS에서 생성한 EFS 볼륨과 동일해야 합니다. 자체 액세스 지점을 제공하는 경우 volumeHandle<EFS volume ID>::<access point ID> 여야 합니다. 예: fs-6e633ada::fsap-081a1d293f0004630.
    3
    필요한 경우 전송 시 암호화를 비활성화할 수 있습니다. 암호화는 기본적으로 활성화되어 있습니다.

정적 PV를 설정하는 데 문제가 있는 경우 AWS EFS 문제 해결을 참조하세요.

6.9.8. Amazon Elastic File Storage 보안

다음 정보는 Amazon Elastic File Storage(Amazon EFS) 보안에 중요합니다.

예를 들어 앞에서 설명한 대로 동적 프로비저닝을 사용하여 액세스 지점을 사용하는 경우 Amazon은 파일의 GID를 액세스 지점의 GID로 자동으로 대체합니다. 또한 EFS는 파일 시스템 권한을 평가할 때 액세스 지점의 사용자 ID, 그룹 ID 및 보조 그룹 ID를 고려합니다. EFS는 NFS 클라이언트의 ID를 무시합니다. 액세스 지점에 대한 자세한 내용은 https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html 을 참조하십시오.

결과적으로 EFS 볼륨은 FSGroup을 자동으로 무시합니다. OpenShift Container Platform은 볼륨의 파일 GID를 FSGroup으로 대체할 수 없습니다. 마운트된 EFS 액세스 지점에 액세스할 수 있는 모든 Pod는 해당 노드의 모든 파일에 액세스할 수 있습니다.

이와 무관하게 전송 중 암호화는 기본적으로 활성화되어 있습니다. 자세한 내용은 https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html을 참조하십시오.

6.9.9. AWS EFS 스토리지 CSI 사용량 지표

6.9.9.1. 사용 지표 개요

Amazon Web Services(AWS) Elastic File Service(EFS) 스토리지 컨테이너 스토리지 인터페이스(CSI) 사용 메트릭을 사용하면 동적 또는 정적으로 프로비저닝된 EFS 볼륨이 사용하는 공간의 양을 모니터링할 수 있습니다.

중요

이 기능은 기본적으로 비활성화되어 있습니다. 메트릭을 켜면 성능이 저하될 수 있기 때문입니다.

AWS EFS 사용 지표 기능은 볼륨의 파일을 재귀적으로 탐색하여 AWS EFS CSI 드라이버에서 볼륨 지표를 수집합니다. 이러한 작업으로 인해 성능이 저하될 수 있으므로 관리자는 이 기능을 명시적으로 활성화해야 합니다.

6.9.9.2. 웹 콘솔을 사용하여 사용량 측정 항목 활성화

웹 콘솔을 사용하여 Amazon Web Services(AWS) Elastic File Service(EFS) Storage Container Storage Interface(CSI) 사용 지표를 활성화하려면 다음을 수행합니다.

  1. 관리 > CustomResourceDefinitions를 클릭합니다.
  2. CustomResourceDefinitions 페이지의 이름 드롭다운 상자 옆에 clustercsidriver를 입력합니다.
  3. CRD ClusterCSIDriver를 클릭합니다.
  4. YAML 탭을 클릭합니다.
  5. spec.aws.efsVolumeMetrics.state 에서 값을 RecursiveWalk 로 설정합니다.

    RecursiveWalk는 AWS EFS CSI 드라이버에서 볼륨 메트릭 수집이 볼륨의 파일을 재귀적으로 탐색하여 수행된다는 것을 나타냅니다.

    ClusterCSIDriver efs.csi.aws.com YAML 파일 예시

    spec:
        driverConfig:
            driverType: AWS
            aws:
                efsVolumeMetrics:
                  state: RecursiveWalk
                  recursiveWalk:
                    refreshPeriodMinutes: 100
                    fsRateLimit: 10
    Copy to Clipboard Toggle word wrap

  6. 선택 사항: 재귀적 워크가 작동하는 방식을 정의하려면 다음 필드를 설정할 수도 있습니다.

    • refreshPeriodMinutes : 볼륨 메트릭의 새로 고침 빈도를 분 단위로 지정합니다. 이 필드를 비워 두면 적절한 기본값이 선택되며, 이는 시간이 지남에 따라 변경될 수 있습니다. 현재 기본값은 240분입니다. 유효 범위는 1~43,200분입니다.
    • fsRateLimit : 파일 시스템당 고루틴에서 볼륨 메트릭을 처리하기 위한 속도 제한을 정의합니다. 이 필드를 비워 두면 적절한 기본값이 선택되며, 이는 시간이 지남에 따라 변경될 수 있습니다. 현재 기본값은 5개의 고루틴입니다. 유효한 범위는 1~100개의 고루틴입니다.
  7. 저장을 클릭합니다.
참고

AWS EFS CSI 사용 지표를 비활성화 하려면 이전 절차를 사용하지만 spec.aws.efsVolumeMetrics.state 의 경우 값을 RecursiveWalk 에서 Disabled 로 변경합니다.

6.9.9.3. CLI를 사용하여 사용량 측정 항목 활성화

CLI를 사용하여 Amazon Web Services(AWS) Elastic File Service(EFS) 스토리지 컨테이너 스토리지 인터페이스(CSI) 사용 메트릭을 활성화하려면:

  1. 다음 명령을 실행하여 ClusterCSIDriver를 편집합니다.

    $ oc edit clustercsidriver efs.csi.aws.com
    Copy to Clipboard Toggle word wrap
  2. spec.aws.efsVolumeMetrics.state 에서 값을 RecursiveWalk 로 설정합니다.

    RecursiveWalk는 AWS EFS CSI 드라이버에서 볼륨 메트릭 수집이 볼륨의 파일을 재귀적으로 탐색하여 수행된다는 것을 나타냅니다.

    ClusterCSIDriver efs.csi.aws.com YAML 파일 예시

    spec:
        driverConfig:
            driverType: AWS
            aws:
                efsVolumeMetrics:
                  state: RecursiveWalk
                  recursiveWalk:
                    refreshPeriodMinutes: 100
                    fsRateLimit: 10
    Copy to Clipboard Toggle word wrap

  3. 선택 사항: 재귀적 워크가 작동하는 방식을 정의하려면 다음 필드를 설정할 수도 있습니다.

    • refreshPeriodMinutes : 볼륨 메트릭의 새로 고침 빈도를 분 단위로 지정합니다. 이 필드를 비워 두면 적절한 기본값이 선택되며, 이는 시간이 지남에 따라 변경될 수 있습니다. 현재 기본값은 240분입니다. 유효 범위는 1~43,200분입니다.
    • fsRateLimit : 파일 시스템당 고루틴에서 볼륨 메트릭을 처리하기 위한 속도 제한을 정의합니다. 이 필드를 비워 두면 적절한 기본값이 선택되며, 이는 시간이 지남에 따라 변경될 수 있습니다. 현재 기본값은 5개의 고루틴입니다. 유효한 범위는 1~100개의 고루틴입니다.
  4. efs.csi.aws.com 개체에 대한 변경 사항을 저장합니다.
참고

AWS EFS CSI 사용 지표를 비활성화 하려면 이전 절차를 사용하지만 spec.aws.efsVolumeMetrics.state 의 경우 값을 RecursiveWalk 에서 Disabled 로 변경합니다.

6.9.10. Amazon Elastic File Storage 문제 해결

다음 정보는 Amazon Elastic File Storage(Amazon EFS) 관련 문제를 해결하는 방법에 대한 지침을 제공합니다.

  • AWS EFS Operator 및 CSI 드라이버는 openshift-cluster-csi-drivers에서 실행됩니다.
  • AWS EFS Operator 및 CSI 드라이버의 로그 수집을 시작하려면 다음 명령을 실행합니다.

    $ oc adm must-gather
    [must-gather      ] OUT Using must-gather plugin-in image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:125f183d13601537ff15b3239df95d47f0a604da2847b561151fedd699f5e3a5
    [must-gather      ] OUT namespace/openshift-must-gather-xm4wq created
    [must-gather      ] OUT clusterrolebinding.rbac.authorization.k8s.io/must-gather-2bd8x created
    [must-gather      ] OUT pod for plug-in image quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:125f183d13601537ff15b3239df95d47f0a604da2847b561151fedd699f5e3a5 created
    Copy to Clipboard Toggle word wrap
  • AWS EFS Operator 오류를 표시하려면 ClusterCSIDriver 상태를 확인합니다.

    $ oc get clustercsidriver efs.csi.aws.com -o yaml
    Copy to Clipboard Toggle word wrap
  • 볼륨을 Pod에 마운트할 수 없는 경우(다음 명령의 출력에 표시된 대로):

    $ oc describe pod
    ...
      Type     Reason       Age    From               Message
      ----     ------       ----   ----               -------
      Normal   Scheduled    2m13s  default-scheduler  Successfully assigned default/efs-app to ip-10-0-135-94.ec2.internal
      Warning  FailedMount  13s    kubelet            MountVolume.SetUp failed for volume "pvc-d7c097e6-67ec-4fae-b968-7e7056796449" : rpc error: code = DeadlineExceeded desc = context deadline exceeded 
    1
    
      Warning  FailedMount  10s    kubelet            Unable to attach or mount volumes: unmounted volumes=[persistent-storage], unattached volumes=[persistent-storage kube-api-access-9j477]: timed out waiting for the condition
    Copy to Clipboard Toggle word wrap
    1
    볼륨이 마운트되지 않았음을 나타내는 경고 메시지입니다.

    이 오류는 AWS가 OpenShift Container Platform 노드와 Amazon EFS 간의 패킷을 삭제하여 자주 발생합니다.

    다음 사항이 올바른지 확인하세요.

    • AWS 방화벽 및 보안 그룹
    • 네트워킹: 포트 번호 및 IP 주소

6.9.11. AWS EFS CSI Driver Operator 설치 제거

AWS EFS CSI Driver Operator (Red Hat 운영자)를 제거한 후에는 모든 EFS PV에 액세스할 수 없습니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.

프로세스

웹 콘솔에서 AWS EFS CSI Driver Operator를 설치 제거하려면 다음을 수행합니다.

  1. 웹 콘솔에 로그인합니다.
  2. AWS EFS PV를 사용하는 모든 애플리케이션을 중지합니다.
  3. 모든 AWS EFS PV를 삭제합니다.

    1. 스토리지영구 볼륨 클레임을 클릭합니다.
    2. AWS EFS CSI Driver Operator에서 사용 중인 각 PVC를 선택하고 PVC 오른쪽에 있는 드롭다운 메뉴를 클릭한 다음 영구 볼륨 클레임 삭제를 클릭합니다.
  4. AWS EFS CSI 드라이버를 제거합니다.

    참고

    Operator를 설치 제거하려면 CSI 드라이버를 먼저 제거해야 합니다.

    1. 관리CustomResourceDefinitionsClusterCSIDriver를 클릭합니다.
    2. 인스턴스 탭에서 efs.csi.aws.com의 맨 왼쪽에 있는 드롭다운 메뉴를 클릭한 다음 ClusterCSIDriver 삭제를 클릭합니다.
    3. 메시지가 표시되면 삭제를 클릭합니다.
  5. AWS EFS CSI Operator를 설치 제거합니다.

    1. Operators설치된 Operators를 클릭합니다.
    2. 설치된 Operators 페이지에서 스크롤하거나 AWS EFS CSI를 이름으로 검색 상자에 입력하여 Operator를 찾은 다음 클릭합니다.
    3. 설치된 Operator > Operator 세부 정보 페이지 오른쪽 상단에서 작업Operator 설치 제거를 클릭합니다.
    4. Operator 설치 제거 창이 표시되면 제거 버튼을 클릭하여 네임스페이스에서 Operator를 제거합니다. 클러스터에 Operator가 배포한 애플리케이션을 수동으로 정리해야 합니다.

      설치 제거 후 AWS EFS CSI Driver Operator는 더 이상 웹 콘솔의 설치된 Operator 섹션에 나열되지 않습니다.

참고

클러스터(openshift-install destroy cluster)를 제거하려면 먼저 AWS에서 EFS 볼륨을 삭제해야 합니다. 클러스터의 VPC를 사용하는 EFS 볼륨이 있는 경우 OpenShift Container Platform 클러스터를 삭제할 수 없습니다. Amazon에서는 이러한 VPC를 삭제할 수 없습니다.

6.10. Azure Disk CSI Driver Operator

6.10.1. 개요

OpenShift Container Platform은 Microsoft Azure Disk Storage용 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI 운영자와 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해야 합니다.

Azure Disk 저장소 자산에 마운트되는 CSI 프로비저닝 PV를 만들기 위해 OpenShift Container Platform은 기본적으로 openshift-cluster-csi-drivers 네임스페이스에 Azure Disk CSI Driver Operator와 Azure Disk CSI 드라이버를 설치합니다.

  • Azure Disk CSI Driver Operator는 영구 볼륨 클레임(PVC)을 만드는 데 사용할 수 있는 managed-csi 라는 저장소 클래스를 제공합니다. Azure Disk CSI Driver Operator는 필요에 따라 스토리지 볼륨을 생성할 수 있도록 하여 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없어 동적 볼륨 프로비저닝을 지원합니다. 원하는 경우 이 기본 저장소 클래스를 비활성화할 수 있습니다( 기본 저장소 클래스 관리 참조).
  • Azure Disk CSI 드라이버를 사용하면 Azure Disk PV를 생성 및 마운트할 수 있습니다.

6.10.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

참고

OpenShift Container Platform은 Azure Disk 인트리 볼륨 플러그인을 해당 CSI 드라이버로 자동 마이그레이션합니다. 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

6.10.3. 스토리지 계정 유형으로 스토리지 클래스 생성

스토리지 클래스는 스토리지 수준 및 사용량을 구분하고 조정하는 데 사용됩니다. 스토리지 클래스를 정의하면 동적으로 프로비저닝된 영구 볼륨을 얻을 수 있습니다.

스토리지 클래스를 생성할 때 스토리지 계정 유형을 지정할 수 있습니다. 이는 Azure 스토리지 계정 SKU 계층에 해당합니다. 유효한 옵션은 Standard_LRS , Premium_LRS , StandardSSD_LRS , UltraSSD_LRS , Premium_ZRS , StandardSSD_ZRSPremiumV2_LRS 입니다. Azure SKU 계층을 찾는 방법에 대한 자세한 내용은 SKU 유형을 참조하세요.

ZRS와 PremiumV2_LRS에는 모두 지역 제한이 있습니다. 이러한 제한 사항에 대한 자세한 내용은 ZRS 제한 사항Premium_LRS 제한 사항을 참조하세요.

사전 요구 사항

  • 관리자 권한으로 OpenShift Container Platform 클러스터에 액세스

프로세스

다음 단계에 따라 스토리지 계정 유형으로 스토리지 클래스를 만듭니다.

  1. 다음과 유사한 YAML 파일을 사용하여 스토리지 계정 유형을 지정하는 스토리지 클래스를 만듭니다.

    $ oc create -f - << EOF
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <storage-class> 
    1
    
    provisioner: disk.csi.azure.com
    parameters:
      skuName: <storage-class-account-type> 
    2
    
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer
    allowVolumeExpansion: true
    EOF
    Copy to Clipboard Toggle word wrap
    1
    저장 클래스 이름.
    2
    저장 계정 유형. 이는 Azure Storage 계정 SKU 계층인 `Standard_LRS`, Premium_LRS , StandardSSD_LRS , UltraSSD_LRS , Premium_ZRS , StandardSSD_ZRS , PremiumV2_LRS 에 해당합니다.
    참고

    PremiumV2_LRS의 경우 storageclass.parameterscachingMode: None을 지정합니다.

  2. 저장소 클래스를 나열하여 저장소 클래스가 생성되었는지 확인하세요.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    $ oc get storageclass
    NAME                    PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    azurefile-csi           file.csi.azure.com   Delete          Immediate              true                   68m
    managed-csi (default)   disk.csi.azure.com   Delete          WaitForFirstConsumer   true                   68m
    sc-prem-zrs             disk.csi.azure.com   Delete          WaitForFirstConsumer   true                   4m25s 
    1
    Copy to Clipboard Toggle word wrap

    1
    스토리지 계정 유형이 있는 새로운 스토리지 클래스입니다.

6.10.4. 사용자 관리 암호화

사용자 관리 암호화 기능을 사용하면 설치 중에 OpenShift Container Platform 노드 루트 볼륨을 암호화하는 키를 제공할 수 있으며, 모든 관리형 스토리지 클래스에서 이러한 키를 사용하여 프로비저닝된 스토리지 볼륨을 암호화할 수 있습니다. install-config YAML 파일의 platform.<cloud_type>.defaultMachinePlatform 필드에서 사용자 지정 키를 지정해야 합니다.

이 기능은 다음과 같은 저장 유형을 지원합니다.

  • Amazon Web Services(AWS) Elastic Block 스토리지(EBS)
  • Microsoft Azure 디스크 저장소
  • Google Cloud Platform(GCP) 영구 디스크(PD) 스토리지
  • IBM Virtual Private Cloud(VPC) 블록 스토리지
참고

OS(루트) 디스크가 암호화되어 있고 스토리지 클래스에 암호화된 키가 정의되어 있지 않은 경우, Azure Disk CSI 드라이버는 기본적으로 OS 디스크 암호화 키를 사용하여 프로비저닝된 스토리지 볼륨을 암호화합니다.

Azure에 대한 사용자 관리 암호화를 사용하여 설치하는 방법에 대한 자세한 내용은 Azure에 대한 사용자 관리 암호화 사용을 참조하세요.

Ultra Disks가 있는 머신을 배포하는 Azure에서 실행되는 머신 세트를 만들 수 있습니다. Ultra 디스크는 가장 까다로운 데이터 워크로드에 사용하기 위한 고성능 스토리지입니다.

트리 내 플러그인과 CSI 드라이버는 모두 PVC를 사용하여 Ultra Disks를 활성화합니다. PVC를 생성하지 않고도 Ultra Disks가 있는 머신을 데이터 디스크로 배포할 수도 있습니다.

6.10.5.1. 머신 세트를 사용하여 울트라 디스크가 있는 머신 생성

Azure에서 Ultra Disks가 있는 머신을 배포하려면 머신 세트 YAML 파일을 편집하세요.

사전 요구 사항

  • 기존 Microsoft Azure 클러스터가 있어야 합니다.

프로세스

  1. 기존 Azure MachineSet 사용자 지정 리소스(CR)를 복사하고 다음 명령을 실행하여 편집합니다.

    $ oc edit machineset <machine_set_name>
    Copy to Clipboard Toggle word wrap

    여기서 <machine_set_name> 은 Ultra Disks를 사용하여 머신을 프로비저닝하려는 머신 세트입니다.

  2. 다음 줄을 표시된 위치에 추가합니다.

    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    spec:
      template:
        spec:
          metadata:
            labels:
              disk: ultrassd 
    1
    
          providerSpec:
            value:
              ultraSSDCapability: Enabled 
    2
    Copy to Clipboard Toggle word wrap
    1
    이 머신 세트에서 생성된 노드를 선택하는 데 사용할 레이블을 지정합니다. 이 절차에서는 이 값에 대해 disk.ultrassd를 사용합니다.
    2
    이 라인은 울트라 디스크를 사용할 수 있습니다.
  3. 다음 명령을 실행하여 업데이트된 구성을 사용하여 머신 세트를 만듭니다.

    $ oc create -f <machine_set_name>.yaml
    Copy to Clipboard Toggle word wrap
  4. 다음 YAML 정의를 포함하는 스토리지 클래스를 만듭니다.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: ultra-disk-sc 
    1
    
    parameters:
      cachingMode: None
      diskIopsReadWrite: "2000" 
    2
    
      diskMbpsReadWrite: "320" 
    3
    
      kind: managed
      skuname: UltraSSD_LRS
    provisioner: disk.csi.azure.com 
    4
    
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer 
    5
    Copy to Clipboard Toggle word wrap
    1
    저장 클래스의 이름을 지정합니다. 이 절차에서는 이 값에 Ultra-disk-sc 를 사용합니다.
    2
    스토리지 클래스에 대한 IOPS 수를 지정합니다.
    3
    스토리지 클래스에 대한 처리량을 MBps 단위로 지정합니다.
    4
    Azure Kubernetes Service(AKS) 버전 1.21 이상의 경우 disk.csi.azure.com을 사용하세요. 이전 버전의 AKS의 경우 kubernetes.io/azure-disk를 사용하세요.
    5
    선택 사항: 디스크를 사용할 Pod가 생성될 때까지 기다리려면 이 매개변수를 지정합니다.
  5. 다음 YAML 정의가 포함된 ultra-disk-sc 스토리지 클래스를 참조하는 영구 볼륨 클레임(PVC)을 만듭니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: ultra-disk 
    1
    
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: ultra-disk-sc 
    2
    
      resources:
        requests:
          storage: 4Gi 
    3
    Copy to Clipboard Toggle word wrap
    1
    PVC의 이름을 지정하세요. 이 절차에서는 이 값에 Ultra-disk 를 사용합니다.
    2
    이 PVC는 ultra-disk-sc 스토리지 클래스를 참조합니다.
    3
    저장 클래스의 크기를 지정합니다. 최소값은 4Gi 입니다.
  6. 다음 YAML 정의가 포함된 Pod를 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx-ultra
    spec:
      nodeSelector:
        disk: ultrassd 
    1
    
      containers:
      - name: nginx-ultra
        image: alpine:latest
        command:
          - "sleep"
          - "infinity"
        volumeMounts:
        - mountPath: "/mnt/azure"
          name: volume
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: ultra-disk 
    2
    Copy to Clipboard Toggle word wrap
    1
    Ultra Disks를 사용할 수 있는 머신 세트의 라벨을 지정하세요. 이 절차에서는 이 값에 대해 disk.ultrassd를 사용합니다.
    2
    이 포드는 울트라 디스크 PVC를 참조합니다.

검증

  1. 다음 명령을 실행하여 머신이 생성되었는지 확인하세요.

    $ oc get machines
    Copy to Clipboard Toggle word wrap

    기계는 실행 상태여야 합니다.

  2. 실행 중이고 노드가 연결된 머신의 경우 다음 명령을 실행하여 파티션을 검증합니다.

    $ oc debug node/<node_name> -- chroot /host lsblk
    Copy to Clipboard Toggle word wrap

    이 명령에서 oc debug node/<node_name>은 노드 <node_name> 에서 디버깅 셸을 시작하고 -- 로 명령을 전달합니다. 전달된 명령 chroot /host는 기본 호스트 OS 바이너리에 대한 액세스를 제공하고, lsblk는 호스트 OS 머신에 연결된 블록 장치를 보여줍니다.

다음 단계

  • 포드 내에서 Ultra Disk를 사용하려면 마운트 지점을 사용하는 워크로드를 생성하세요. 다음 예와 유사한 YAML 파일을 만듭니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: ssd-benchmark1
    spec:
      containers:
      - name: ssd-benchmark1
        image: nginx
        ports:
          - containerPort: 80
            name: "http-server"
        volumeMounts:
        - name: lun0p1
          mountPath: "/tmp"
      volumes:
        - name: lun0p1
          hostPath:
            path: /var/lib/lun0p1
            type: DirectoryOrCreate
      nodeSelector:
        disktype: ultrassd
    Copy to Clipboard Toggle word wrap
6.10.5.2. Ultra Disks를 활성화하는 머신 세트에 대한 문제 해결 리소스

이 섹션의 정보를 활용해 발생할 수 있는 문제를 파악하고 복구하세요.

Ultra Disk로 지원되는 영구 볼륨 클레임을 마운트하는 데 문제가 있는 경우 Pod는 ContainerCreating 상태에 멈추고 경고가 발생합니다.

예를 들어, Pod를 호스팅하는 노드를 지원하는 머신에 additionalCapabilities.ultraSSDEnabled 매개변수가 설정되지 않은 경우 다음 오류 메시지가 나타납니다.

StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
Copy to Clipboard Toggle word wrap
  • 이 문제를 해결하려면 다음 명령을 실행하여 Pod를 설명하세요.

    $ oc -n <stuck_pod_namespace> describe pod <stuck_pod_name>
    Copy to Clipboard Toggle word wrap

6.11. Azure 파일 CSI 드라이버 운영자

6.11.1. 개요

OpenShift Container Platform은 Microsoft Azure File Storage용 CSI(Container Storage Interface) 드라이버를 사용하여 영구 볼륨(PV)을 프로비저닝할 수 있습니다.

CSI 운영자와 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해야 합니다.

Azure File Storage 자산에 마운트되는 CSI 프로비저닝 PV를 만들기 위해 OpenShift Container Platform은 기본적으로 openshift-cluster-csi-drivers 네임스페이스에 Azure File CSI Driver Operator와 Azure File CSI 드라이버를 설치합니다.

  • Azure File CSI Driver Operator는 영구적 볼륨 클레임(PVC)을 만드는 데 사용할 수 있는 azurefile-csi 라는 스토리지 클래스를 제공합니다. 원하는 경우 이 기본 저장소 클래스를 비활성화할 수 있습니다( 기본 저장소 클래스 관리 참조).
  • Azure File CSI 드라이버를 사용하면 Azure File PV를 만들고 탑재할 수 있습니다. Azure File CSI 드라이버는 필요에 따라 저장소 볼륨을 생성할 수 있도록 하여 동적 볼륨 프로비저닝을 지원하므로 클러스터 관리자가 저장소를 미리 프로비저닝할 필요가 없습니다.

Azure File CSI Driver Operator는 다음을 지원하지 않습니다.

  • 가상 하드 디스크(VHD)
  • SMB(서버 메시지 블록) 파일 공유를 위해 FIPS(연방 정보 처리 표준) 모드가 활성화된 노드에서 실행됩니다. 하지만 네트워크 파일 시스템(NFS)은 FIPS 모드를 지원합니다.

지원되는 기능에 대한 자세한 내용은 지원되는 CSI 드라이버 및 기능을 참조하세요.

6.11.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 OpenShift Container Platform 사용자 스토리지 옵션을 제공합니다.

6.11.3. NFS 지원

OpenShift Container Platform 4.14 이상에서는 다음 주의 사항과 함께 NFS(Network File System) Driver Operator를 지원합니다.

  • 컨트롤 플레인 노드에 예약된 Azure File NFS 볼륨을 사용하여 Pod를 생성하면 마운트가 거부됩니다.

    이 문제를 해결하려면 컨트롤 플레인 노드를 예약할 수 있고 작업자 노드에서 Pod를 실행할 수 있는 경우 nodeSelector 또는 Affinity를 사용하여 작업자 노드에서 Pod를 예약합니다.

  • FS 그룹 정책 동작:

    중요

    NFS를 사용하는 Azure File CSI는 Pod에서 요청한 fsGroupChangePolicy를 준수하지 않습니다. NFS를 사용하는 Azure File CSI는 Pod에서 요청한 정책에 관계없이 기본 OnRootMismatch FS 그룹 정책을 적용합니다.

  • Azure File CSI Operator는 NFS의 스토리지 클래스를 자동으로 생성하지 않습니다. 수동으로 생성해야 합니다. 다음과 유사한 파일을 사용합니다.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <storage-class-name> 
    1
    
    provisioner: file.csi.azure.com 
    2
    
    parameters:
      protocol: nfs 
    3
    
      skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS
    mountOptions:
      - nconnect=4
    Copy to Clipboard Toggle word wrap
    1
    스토리지 클래스 이름입니다.
    2
    Azure File CSI 공급자를 지정합니다.
    3
    NFS를 스토리지 백엔드 프로토콜로 지정합니다.

6.11.4. Azure 파일 간 서브스크립션 지원

서브스크립션 간 지원을 통해 하나의 Azure 서브스크립션에 OpenShift Container Platform 클러스터를 보유하고 CSI(Azure File Container Storage Interface) 드라이버를 사용하여 다른 Azure 서브스크립션에 Azure 파일 공유를 마운트할 수 있습니다.

중요

OpenShift Container Platform 클러스터와 Azure File 공유(사전 프로비저닝 또는 프로비저닝) 둘 다 동일한 테넌트 내에 있어야 합니다.

6.11.4.1. Azure File 서브스크립션 간 동적 프로비저닝

사전 요구 사항

  • 서비스 주체 또는 관리 ID를 하나의 서브스크립션에서 Azure ID로 사용하여 Azure에 설치된 OpenShift Container Platform 클러스터(서브스크립션 A라고 함)
  • 클러스터와 동일한 테넌트에 있는 스토리지를 사용하여 다른 서브스크립션(서브스크립션 B라고 함)에 액세스
  • Azure CLI에 로그인

프로세스

서브스크립션 간에 Azure File 동적 프로비저닝을 사용하려면 다음을 수행합니다.

  1. 다음 적용 가능한 명령을 실행하여 Azure ID(서비스 주체 또는 관리 ID)를 기록합니다. Azure ID는 이후 단계에서 필요합니다.

    • 클러스터를 설치할 때 서비스 주체 를 Azure ID로 사용하는 경우:

      $ sp_id=$(oc -n openshift-cluster-csi-drivers get secret azure-file-credentials -o jsonpath='{.data.azure_client_id}' | base64 --decode)
      
      $ az ad sp show --id ${sp_id} --query displayName --output tsv
      Copy to Clipboard Toggle word wrap
    • 클러스터를 설치할 때 관리 ID를 Azure ID로 사용하는 경우:

      $ mi_id=$(oc -n openshift-cluster-csi-drivers get secret azure-file-credentials -o jsonpath='{.data.azure_client_id}' | base64 --decode)
      
      $ az identity list --query "[?clientId=='${mi_id}'].{Name:name}" --output tsv
      Copy to Clipboard Toggle word wrap
  2. 다음 중 하나를 수행하여 Azure 파일 공유를 프로비저닝하려는 다른 구독 B의 리소스 그룹에 액세스할 수 있는 권한을 Azure ID(서비스 주체 또는 관리 ID)에 부여합니다.

    • 다음 Azure CLI 명령을 실행합니다.

      az role assignment create \
        --assignee <object-id-or-app-id> \
        --role <role-name> \
        --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <object-id-or-app-id> : 이전 단계에서 얻은 서비스 주체 또는 관리 ID(예: sp_id 또는 mi_id) 입니다.

      <역할 이름> : 역할 이름. 기여자 또는 필요한 권한이 있는 본인의 역할.

      <subscription-id> : 구독 B ID.

      <리소스 그룹 이름> : 구독 B 리소스 그룹 이름입니다.

      또는

    • Azure Portal에 로그인하고 왼쪽 메뉴에서 리소스 그룹을 클릭합니다.

      1. 구독 B에서 역할을 할당하려는 리소스 그룹을 선택합니다 . 리소스 그룹액세스 제어(IAM)역할 할당 탭을 클릭하여 현재 할당을 확인한 다음 추가 > 역할 할당 추가를 클릭합니다.
      2. 역할 탭에서 할당할 기여자 역할을 선택한 후 다음을 클릭합니다. 필요한 권한을 부여받아 자신의 역할을 만들고 선택할 수도 있습니다.
      3. 회원 탭에서:

        1. 사용자, 그룹 또는 서비스 주체(또는 관리 ID) 등 담당자 유형을 선택하여 담당자를 선택합니다.
        2. 회원 선택을 클릭하세요.
        3. 이전 단계에서 기록한 원하는 서비스 주체 또는 관리 ID를 검색하여 선택합니다.
        4. 선택을 클릭하여 확인하세요.
      4. 검토 + 할당 탭에서 설정을 검토합니다.
      5. 역할 할당을 완료하려면 검토 + 할당을 클릭하세요.

        참고

        Azure 파일 공유를 프로비저닝하는 데 특정 스토리지 계정만 사용하려는 경우 비슷한 단계를 사용하여 스토리지 계정에 액세스하기 위한 Azure ID(서비스 주체 또는 관리 ID) 권한을 얻을 수도 있습니다.

  3. 다음과 유사한 구성을 사용하여 Azure 파일 저장소 클래스를 만듭니다.

    Azure 파일 저장소 클래스 YAML 파일 예제

    allowVolumeExpansion: true
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <sc-name> 
    1
    
    mount options:
      - mfsymlinks
      - cache=strict
      - nosharesock
      - actimeo=30
    parameters:
      subscriptionID: <xxxx-xxxx-xxxx-xxxx-xxxx> 
    2
    
      resourceGroup: <resource group name> 
    3
    
      storageAccount: <storage account> 
    4
    
      skuName: <skuName> 
    5
    
    provisioner: file.csi.azure.com
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    Copy to Clipboard Toggle word wrap

    1
    저장 클래스의 이름
    2
    구독 B ID
    3
    구독 B 리소스 그룹 이름
    4
    저장 계정 이름(사용자가 직접 지정하려는 경우)
    5
    SKU 유형의 이름
  4. 다음과 유사한 구성을 사용하여 이전 단계에서 만든 Azure 파일 저장소 클래스를 지정하는 영구적 볼륨 클레임(PVC)을 만듭니다.

    PVC YAML 파일 예시

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: <pvc-name> 
    1
    
    spec:
      storageClassName: <sc-name-cross-sub> 
    2
    
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 5Gi
    Copy to Clipboard Toggle word wrap

    1
    PVC의 이름.
    2
    이전 단계에서 만든 스토리지 클래스의 이름입니다.
6.11.4.2. PV 및 PVC를 만들어 Azure File의 구독 전반에 정적 프로비저닝:

사전 요구 사항

  • 서비스 주체 또는 관리 ID를 하나의 구독(구독 A라고 함)의 Azure ID로 사용하여 Azure에 OpenShift Container Platform 클러스터를 설치했습니다.
  • 클러스터와 동일한 테넌트에 있는 스토리지를 사용하여 다른 구독(구독 B라고 함)에 액세스합니다.
  • Azure CLI에 로그인했습니다

프로세스

  1. Azure 파일 공유의 경우 리소스 그룹, 스토리지 계정, 스토리지 계정 키 및 Azure 파일 이름을 기록합니다. 이러한 값은 다음 단계에 사용됩니다.
  2. 다음 명령을 실행하여 영구 볼륨 매개변수 spec.csi.nodeStageSecretRef.name 에 대한 비밀을 만듭니다.

    $ oc create secret generic azure-storage-account-<storageaccount-name>-secret --from-literal=azurestorageaccountname="<azure-storage-account-name>" --from-literal azurestorageaccountkey="<azure-storage-account-key>" --type=Opaque
    Copy to Clipboard Toggle word wrap

    여기서: <azure-storage-account-name><azure-storage-account-key> 는 각각 1단계에서 기록한 Azure Storage 계정 이름과 키입니다.

  3. 다음 예제 파일과 유사한 구성을 사용하여 영구 볼륨(PV)을 만듭니다.

    PV YAML 파일 예시

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        pv.kubernetes.io/provisioned-by: file.csi.azure.com
      name: <pv-name> 
    1
    
    spec:
      capacity:
        storage: 10Gi 
    2
    
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      storageClassName: <sc-name> 
    3
    
      mountOptions:
        - cache=strict
        - nosharesock
        - actimeo=30
        - nobrl
      csi:
        driver: file.csi.azure.com
        volumeHandle: "{resource-group-name}#{storage-account-name}#{file-share-name}" 
    4
    
        volumeAttributes:
          shareName: <existing-file-share-name> 
    5
    
        nodeStageSecretRef:
          name: <secret-name>  
    6
    
          namespace: <secret-namespace>  
    7
    Copy to Clipboard Toggle word wrap

    1
    PV의 이름입니다.
    2
    PV의 크기입니다.
    3
    저장 클래스 이름.
    4
    클러스터의 모든 동일한 공유에 대해 volumeHandle 이 고유한지 확인하세요.
    5
    `<기존 파일 공유 이름>'에는 전체 경로가 아닌 파일 공유 이름만 사용하세요.
    6
    이전 단계에서 생성된 비밀 이름입니다.
    7
    비밀이 있는 네임스페이스입니다.
  4. 1단계에서 참조한 기존 Azure 파일 공유를 지정하는 영구적 값 클레임(PVC)을 다음과 유사한 구성을 사용하여 만듭니다.

    PVC YAML 파일 예시

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: <pvc-name> 
    1
    
    spec:
      storageClassName: <sc-name> 
    2
    
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 5Gi
    Copy to Clipboard Toggle word wrap

    1
    PVC의 이름.
    2
    이전 단계에서 PV에 대해 지정한 스토리지 클래스의 이름입니다.

스토리지 클래스를 사용하는 것이 좋습니다

구독 전반에 걸친 정적 프로비저닝의 이전 예에서 PV와 PVC에서 참조된 스토리지 클래스는 꼭 필요하지 않습니다. 정적 프로비저닝을 수행하는 데 스토리지 클래스가 필요하지 않기 때문입니다. 그러나 수동으로 생성된 PVC가 실수로 수동으로 생성된 PV와 일치하지 않아 잠재적으로 새 PV의 동적 프로비저닝이 트리거되는 경우를 방지하기 위해 스토리지 클래스를 사용하는 것이 좋습니다. 이 문제를 방지하는 다른 방법은 provisioner: kubernetes.io/no-provisioner를 사용하여 스토리지 클래스를 생성하거나 존재하지 않는 스토리지 클래스를 참조하는 것입니다. 두 경우 모두 동적 프로비저닝이 발생하지 않도록 보장합니다. 이러한 전략 중 하나를 사용하는 경우 PV와 PVC가 일치하지 않으면 PVC가 보류 상태로 유지되고 오류를 수정할 수 있습니다.

6.11.5. Azure File에 대한 정적 프로비저닝

정적 프로비저닝의 경우, 클러스터 관리자는 실제 저장소의 세부 정보를 정의하는 영구 볼륨(PV)을 만듭니다. 그러면 클러스터 사용자는 이러한 PV를 사용하는 영구 볼륨 클레임(PVC)을 만들 수 있습니다.

사전 요구 사항

  • 관리자 권한으로 OpenShift Container Platform 클러스터에 액세스

프로세스

Azure File에 정적 프로비저닝을 사용하려면:

  1. 아직 Azure 저장소 계정에 대한 비밀을 만들지 않았다면 지금 만드세요.

    이 비밀에는 Azure Storage 계정 이름과 키가 포함되어야 하며, 다음과 같은 매우 구체적인 형식과 두 개의 키-값 쌍이 있어야 합니다.

    • azurestorageaccountname: <storage_account_name>
    • azurestorageaccountkey: <account_key>

      azure-secret 이라는 이름의 비밀을 생성하려면 다음 명령을 실행하세요.

      oc create secret generic azure-secret  -n <namespace_name> --type=Opaque --from-literal=azurestorageaccountname="<storage_account_name>" --from-literal=azurestorageaccountkey="<account_key>" 
      1
       
      2
      Copy to Clipboard Toggle word wrap
      1
      <네임스페이스_이름>을 PV가 사용되는 네임스페이스로 설정합니다.
      2
      <storage_account_name><account_key> 에 대한 값을 제공하세요.
  2. 다음 예제 YAML 파일을 사용하여 PV를 만듭니다.

    PV YAML 파일 예시

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        pv.kubernetes.io/provisioned-by: file.csi.azure.com
      name: pv-azurefile
    spec:
      capacity:
        storage: 5Gi 
    1
    
      accessModes:
        - ReadWriteMany 
    2
    
      persistentVolumeReclaimPolicy: Retain 
    3
    
      storageClassName: <sc-name> 
    4
    
      mountOptions:
        - dir_mode=0777  
    5
    
        - file_mode=0777
        - uid=0
        - gid=0
        - cache=strict  
    6
    
        - nosharesock  
    7
    
        - actimeo=30  
    8
    
        - nobrl  
    9
    
      csi:
        driver: file.csi.azure.com
        volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}" 
    10
    
        volumeAttributes:
          shareName: EXISTING_FILE_SHARE_NAME  
    11
    
        nodeStageSecretRef:
          name: azure-secret 
    12
    
          namespace: <my-namespace> 
    13
    Copy to Clipboard Toggle word wrap

    1
    볼륨 크기.
    2
    접근 모드. 읽기-쓰기 및 마운트 권한을 정의합니다. 자세한 내용은 추가 리소스 에서 액세스 모드를 참조하세요.
    3
    정책 회수. 볼륨이 해제된 후 클러스터에 볼륨을 어떻게 처리할지 알려줍니다. 허용되는 값은 Retain , Recycle 또는 Delete 입니다.
    4
    저장 클래스 이름. 이 이름은 PVC가 이 특정 PV에 바인딩하는 데 사용됩니다. 정적 프로비저닝의 경우 StorageClass 객체가 존재할 필요는 없지만 PV와 PVC의 이름은 일치해야 합니다.
    5
    보안을 강화하려면 이 권한을 수정하세요.
    6
    캐시 모드. 허용되는 값은 none , strict , loose 입니다. 기본값은 strict 입니다.
    7
    재연결 경쟁의 가능성을 줄이는 데 사용됩니다.
    8
    CIFS 클라이언트가 서버에 속성 정보를 요청하기 전에 파일이나 디렉토리의 속성을 캐시하는 시간(초)입니다.
    9
    서버에 바이트 범위 잠금 요청을 보내는 것을 비활성화하고, POSIX 잠금과 관련된 문제가 있는 애플리케이션에 대해서도 비활성화합니다.
    10
    클러스터 전체에서 volumeHandle이 고유한지 확인하세요. 리소스 그룹 이름은 스토리지 계정이 있는 Azure 리소스 그룹입니다.
    11
    파일 공유 이름. 파일 공유 이름만 사용하고 전체 경로를 사용하지 마세요.
    12
    이 절차의 1단계에서 생성된 비밀의 이름을 제공하세요. 이 예에서는 azure-secret 입니다.
    13
    비밀이 생성된 네임스페이스입니다. 이는 PV가 사용되는 네임스페이스여야 합니다.
  3. 다음 예제 파일을 사용하여 PV를 참조하는 PVC를 만듭니다.

    PVC YAML 파일 예시

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: <pvc-name> 
    1
    
      namespace: <my-namespace> 
    2
    
    spec:
      volumeName: pv-azurefile 
    3
    
      storageClassName: <sc-name> 
    4
    
      accessModes:
        - ReadWriteMany 
    5
    
      resources:
        requests:
          storage: 5Gi 
    6
    Copy to Clipboard Toggle word wrap

    1
    PVC 이름.
    2
    PVC의 네임스페이스.
    3
    이전 단계에서 만든 PV의 이름입니다.
    4
    저장 클래스 이름. 이 이름은 PVC가 이 특정 PV에 바인딩하는 데 사용됩니다. 정적 프로비저닝의 경우 StorageClass 객체가 존재할 필요는 없지만 PV와 PVC의 이름은 일치해야 합니다.
    5
    접근 모드. PVC에 대한 요청된 읽기-쓰기 액세스를 정의합니다. 클레임은 특정 액세스 모드로 스토리지를 요청할 때 볼륨과 동일한 규칙을 사용합니다. 자세한 내용은 추가 리소스 에서 액세스 모드를 참조하세요.
    6
    PVC 사이즈.
  4. 다음 명령을 실행하여 PVC가 생성되고 잠시 후 바운드 상태가 되었는지 확인하세요.

    $ oc get pvc <pvc-name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    PVC의 이름입니다.

    출력 예

    NAME       STATUS    VOLUME         CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    pvc-name   Bound     pv-azurefile   5Gi        ReadWriteMany  my-sc          7m2s
    Copy to Clipboard Toggle word wrap

6.12. Azure Stack Hub CSI Driver Operator

6.12.1. 개요

OpenShift Container Platform은 Azure Stack Hub 스토리지용 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다. Azure Stack 포트폴리오의 일부인 Azure Stack Hub를 사용하면 온-프레미스 환경에서 앱을 실행하고 데이터 센터에서 Azure 서비스를 제공할 수 있습니다.

CSI 운영자와 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해야 합니다.

Azure Stack Hub 스토리지 자산에 마운트되는 CSI 프로비저닝 PV를 생성하기 위해 OpenShift Container Platform은 openshift-cluster-csi-drivers 네임스페이스에 기본적으로 Azure Stack Hub CSI 드라이버 및 Azure Stack Hub CSI 드라이버를 설치합니다.

  • Azure Stack Hub CSI Driver Operator 는 스토리지 클래스(managed-csi)에 기본 스토리지 계정 유형으로 "Standard_LRS"를 제공하여 PVC(영구 볼륨 클레임)를 생성할 수 있습니다. Azure Stack Hub CSI Driver Operator는 필요에 따라 스토리지 볼륨을 생성할 수 있도록 하여 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없어 동적 볼륨 프로비저닝을 지원합니다.
  • Azure Stack Hub CSI 드라이버를 사용하면 Azure Stack Hub PV를 생성하고 마운트할 수 있습니다.

6.12.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

6.13. GCP PD CSI Driver Operator

6.13.1. 개요

OpenShift Container Platform은 GCP(Google Cloud Platform) PD(영구 디스크) 스토리지용 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI(Container Storage Interface) Operator 및 드라이버를 사용할 때는 영구 스토리지 및 CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

GCP PD 스토리지 자산에 마운트하는 CSI(영구 볼륨)를 생성하기 위해 OpenShift Container Platform은 openshift-cluster-csi-drivers 네임스페이스에서 기본적으로 GCP PD CSI Driver Operator 및 GCP PD CSI 드라이버를 설치합니다.

  • GCP PD CSI Driver Operator: 기본적으로 Operator는 PVC를 생성하는 데 사용할 수 있는 스토리지 클래스를 제공합니다. 원하는 경우 이 기본 저장소 클래스를 비활성화할 수 있습니다( 기본 저장소 클래스 관리 참조). GCE Persistent Disk를 사용하여 영구 저장소 에 설명된 대로 GCP PD 저장소 클래스를 만드는 옵션도 있습니다.
  • GCP PD 드라이버: 이 드라이버를 사용하면 GCP PD PV를 생성 및 마운트할 수 있습니다.

    GCP PD CSI 드라이버는 베어 메탈 및 N4 머신 시리즈에 대한 C3 인스턴스 유형을 지원합니다. C3 인스턴스 유형과 N4 머신 시리즈는 하이퍼디스크 균형 디스크를 지원합니다.

OpenShift Container Platform은 GCE Persistent Disk 인트리 볼륨 플러그인을 해당 CSI 드라이버로 자동 마이그레이션합니다. 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

6.13.2. 베어 메탈 및 N4 머신 시리즈용 C3 인스턴스 유형

6.13.2.1. C3 및 N4 인스턴스 유형 제한 사항

베어 메탈 및 N4 머신 시리즈의 C3 인스턴스 유형에 대한 GCP PD CSI 드라이버 지원에는 다음과 같은 제한 사항이 있습니다.

  • 하이퍼디스크 균형 디스크를 생성하는 경우 볼륨 크기를 최소 4Gi로 설정해야 합니다. OpenShift Container Platform은 최소 크기로 반올림하지 않으므로 올바른 크기를 직접 지정해야 합니다.
  • 스토리지 풀을 사용하는 경우 볼륨 복제가 지원되지 않습니다.
  • 복제 또는 크기 조정을 위해서는 하이퍼디스크 균형 디스크의 원래 볼륨 크기가 6Gi 이상이어야 합니다.
  • 기본 저장 클래스는 standard-csi입니다.

    중요

    수동으로 저장 클래스를 생성해야 합니다.

    저장소 클래스를 만드는 방법에 대한 자세한 내용은 하이퍼디스크 균형 디스크 설정 섹션의 2단계를 참조하세요.

  • 예를 들어 N2와 N4와 같이 서로 다른 스토리지 유형을 사용하는 혼합된 가상 머신(VM)이 있는 클러스터는 지원되지 않습니다. 이는 대부분의 레거시 VM에서 하이퍼디스크 균형 디스크를 사용할 수 없기 때문입니다. 마찬가지로 일반 영구 디스크는 N4/C3 VM에서 사용할 수 없습니다.
  • c3-standard-2, c3-standard-4, n4-standard-2, n4-standard-4 노드가 있는 GCP 클러스터는 연결 가능한 최대 디스크 수(16개)를 잘못 초과할 수 있습니다( JIRA 링크 ).
  • 추가적인 제한 사항 .
6.13.2.2. 하이퍼디스크 균형 디스크에 대한 스토리지 풀 개요

Hyperdisk 스토리지 풀은 Compute Engine과 함께 사용하여 대규모 스토리지를 구축할 수 있습니다. 하이퍼디스크 스토리지 풀은 용량, 처리량, IOPS를 구매하여 모아둔 것으로, 필요에 따라 애플리케이션에 프로비저닝할 수 있습니다. 하이퍼디스크 스토리지 풀을 사용하면 풀에서 디스크를 생성하고 관리하고 여러 작업 부하에서 디스크를 사용할 수 있습니다. 디스크를 전체적으로 관리하면 예상 용량과 성능 향상을 달성하는 동시에 비용을 절감할 수 있습니다. 하이퍼디스크 스토리지 풀에서 필요한 스토리지만 사용하면 용량 예측의 복잡성이 줄어들고 수백 개의 디스크를 관리하는 것에서 단일 스토리지 풀을 관리하는 것으로 관리 업무가 간소화됩니다.

저장소 풀을 설정하려면 하이퍼디스크 균형 디스크 설정을 참조하세요.

6.13.2.3. 하이퍼디스크 균형 디스크 설정

사전 요구 사항

  • 관리자 권한으로 클러스터에 액세스

프로세스

하이퍼디스크 균형 디스크를 설정하려면 다음 단계를 완료하세요.

  1. 하이퍼디스크 균형 디스크로 프로비저닝된 연결 디스크로 GCP 클러스터를 만듭니다.
  2. 설치 중에 하이퍼디스크 균형 디스크를 지정하여 스토리지 클래스를 만듭니다.

    1. 사용자 정의를 사용하여 GCP에 클러스터 설치 섹션의 절차를 따르세요.

      install-config.yaml 파일에 다음 예제 파일을 사용하세요.

      install-config YAML 파일 예시

      apiVersion: v1
      metadata:
        name: ci-op-9976b7t2-8aa6b
      
      sshKey: |
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      baseDomain: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      platform:
        gcp:
          projectID: XXXXXXXXXXXXXXXXXXXXXX
          region: us-central1
      controlPlane:
        architecture: amd64
        name: master
        platform:
          gcp:
            type: n4-standard-4 
      1
      
            osDisk:
              diskType: hyperdisk-balanced 
      2
      
              diskSizeGB: 200
        replicas: 3
      compute:
      - architecture: amd64
        name: worker
        replicas: 3
        platform:
          gcp:
            type: n4-standard-4 
      3
      
            osDisk:
              diskType: hyperdisk-balanced 
      4
      Copy to Clipboard Toggle word wrap

      1 3
      노드 유형을 n4-standard-4로 지정합니다.
      2 4
      노드에 하이퍼디스크 균형 디스크 유형으로 백업된 루트 디스크가 있음을 지정합니다. 클러스터의 모든 노드는 동일한 디스크 유형(hyperdisks-balanced 또는 pd-*)을 사용해야 합니다.
      참고

      클러스터의 모든 노드는 하이퍼디스크 균형 볼륨을 지원해야 합니다. 혼합 노드가 있는 클러스터(예: 하이퍼디스크 균형 디스크를 사용하는 N2 및 N3)는 지원되지 않습니다.

    2. Cloud Credential Operator 유틸리티 매니페스트 통합 섹션의 3단계 후에 다음 매니페스트를 설치 프로그램에서 생성한 매니페스트 디렉터리에 복사합니다.

      • cluster_csi_driver.yaml - 기본 스토리지 클래스 생성을 거부하도록 지정합니다.
      • storageclass.yaml - 하이퍼디스크별 스토리지 클래스를 생성합니다.

        예제 클러스터 CSI 드라이버 YAML 파일

        apiVersion: operator.openshift.io/v1
        kind: "ClusterCSIDriver"
        metadata:
          name: "pd.csi.storage.gke.io"
        spec:
          logLevel: Normal
          managementState: Managed
          operatorLogLevel: Normal
          storageClassState: Unmanaged 
        1
        Copy to Clipboard Toggle word wrap

        1
        기본 OpenShift Container Platform 스토리지 클래스 생성을 비활성화하도록 지정합니다.

        예제 저장 클래스 YAML 파일

        apiVersion: storage.k8s.io/v1
        kind: StorageClass
        metadata:
          name: hyperdisk-sc 
        1
        
          annotations:
            storageclass.kubernetes.io/is-default-class: "true"
        provisioner: pd.csi.storage.gke.io 
        2
        
        volumeBindingMode: WaitForFirstConsumer
        allowVolumeExpansion: true
        reclaimPolicy: Delete
        parameters:
          type: hyperdisk-balanced 
        3
        
          replication-type: none
          provisioned-throughput-on-create: "140Mi" 
        4
        
          provisioned-iops-on-create: "3000" 
        5
        
          storage-pools: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c 
        6
        
        allowedTopologies: 
        7
        
        - matchLabelExpressions:
          - key: topology.kubernetes.io/zone
            values:
            - us-east4-c
        ...
        Copy to Clipboard Toggle word wrap

        1
        저장 클래스의 이름을 지정하세요. 이 예에서는 hyperdisk-sc 입니다.
        2
        pd.csi.storage.gke.io는 GCP CSI 프로비저너를 지정합니다.
        3
        하이퍼디스크 균형 디스크를 사용하도록 지정합니다.
        4
        "Mi" 한정자를 사용하여 MiBps 단위의 처리량 값을 지정합니다. 예를 들어, 필요한 처리량이 250MiBps인 경우 "250Mi"를 지정합니다. 값을 지정하지 않으면 용량은 디스크 유형 기본값에 따라 결정됩니다.
        5
        어떠한 한정자 없이 IOPS 값을 지정합니다. 예를 들어, 7,000 IOPS가 필요한 경우 "7000"을 지정합니다. 값을 지정하지 않으면 용량은 디스크 유형 기본값에 따라 결정됩니다.
        6
        스토리지 풀을 사용하는 경우, 사용하려는 특정 스토리지 풀 목록을 다음 형식으로 지정합니다: projects/PROJECT_ID/zones/ZONE/storagePools/STORAGE_POOL_NAME.
        7
        스토리지 풀을 사용하는 경우 allowedTopologies를 설정하여 프로비저닝된 볼륨의 토폴로지를 스토리지 풀이 있는 위치로 제한합니다. 이 예에서는 us-east4-c 입니다.
  3. 다음 예제 YAML 파일을 사용하여 하이퍼디스크별 스토리지 클래스를 사용하는 영구 볼륨 클레임(PVC)을 만듭니다.

    PVC YAML 파일 예시

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: my-pvc
    spec:
      storageClassName: hyperdisk-sc 
    1
    
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 2048Gi 
    2
    Copy to Clipboard Toggle word wrap

    1
    PVC는 스토리지 풀별 스토리지 클래스를 참조합니다. 이 예에서는 hyperdisk-sc 입니다.
    2
    하이퍼디스크 균형 볼륨의 대상 저장 용량입니다. 이 예에서는 2048Gi입니다 .
  4. 방금 만든 PVC를 사용하여 배포를 만듭니다. 배포를 사용하면 Pod가 다시 시작되고 일정이 변경된 후에도 애플리케이션이 영구 저장소에 액세스할 수 있도록 보장하는 데 도움이 됩니다.

    1. 배포를 생성하기 전에 지정된 머신 시리즈가 포함된 노드 풀이 실행 중인지 확인하세요. 그렇지 않으면 Pod가 일정을 예약하는 데 실패합니다.
    2. 다음 예제 YAML 파일을 사용하여 배포를 만듭니다.

      배포 YAML 파일의 예

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: postgres
      spec:
        selector:
          matchLabels:
            app: postgres
        template:
          metadata:
            labels:
              app: postgres
          spec:
            nodeSelector:
              cloud.google.com/machine-family: n4 
      1
      
            containers:
            - name: postgres
              image: postgres:14-alpine
              args: [ "sleep", "3600" ]
              volumeMounts:
              - name: sdk-volume
                mountPath: /usr/share/data/
            volumes:
            - name: sdk-volume
              persistentVolumeClaim:
                claimName: my-pvc 
      2
      Copy to Clipboard Toggle word wrap

      1
      기계 제품군을 지정합니다. 이 예에서는 n4 입니다.
      2
      이전 단계에서 생성된 PVC의 이름을 지정합니다. 이 예에서는 my-pfc 입니다.
    3. 다음 명령을 실행하여 배포가 성공적으로 생성되었는지 확인하세요.

      $ oc get deployment
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME       READY   UP-TO-DATE   AVAILABLE   AGE
      postgres   0/1     1            0           42s
      Copy to Clipboard Toggle word wrap

      하이퍼디스크 인스턴스가 프로비저닝을 완료하고 READY 상태를 표시하는 데 몇 분이 걸릴 수 있습니다.

    4. 다음 명령을 실행하여 PVC my-pvc가 영구 볼륨(PV)에 성공적으로 바인딩되었는지 확인하세요.

      $ oc get pvc my-pvc
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       VOLUMEATTRIBUTESCLASS  AGE
      my-pvc        Bound    pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6   2Ti        RWO            hyperdisk-sc       <unset>                2m24s
      Copy to Clipboard Toggle word wrap

    5. 하이퍼디스크 균형 디스크의 예상 구성을 확인하세요.

      $ gcloud compute disks list
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                        LOCATION        LOCATION_SCOPE  SIZE_GB  TYPE                STATUS
      instance-20240914-173145-boot               us-central1-a   zone            150      pd-standard         READY
      instance-20240914-173145-data-workspace     us-central1-a   zone            100      pd-balanced         READY
      c4a-rhel-vm                                 us-central1-a   zone            50       hyperdisk-balanced  READY 
      1
      Copy to Clipboard Toggle word wrap

      1
      하이퍼디스크 균형 디스크.
    6. 스토리지 풀을 사용하는 경우 다음 명령을 실행하여 볼륨이 스토리지 클래스 및 PVC에 지정된 대로 프로비저닝되었는지 확인하세요.

      $ gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
      pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048
      Copy to Clipboard Toggle word wrap

6.13.3. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

6.13.4. GCP PD CSI 드라이버 스토리지 클래스 매개변수

GCP(Google Cloud Platform) PD(영구 디스크) CSI(Container Storage Interface) 드라이버는 CSI 외부 프로비저너 사이드카를 컨트롤러로 사용합니다. 이 컨테이너는 CSI 드라이버와 함께 배포된 별도의 Helper 컨테이너입니다. 사이드카는 CreateVolume 작업을 트리거하여 PV(영구 볼륨)를 관리합니다.

GCP PD CSI 드라이버는 csi.storage.k8s.io/fstype 매개변수 키를 사용하여 동적 프로비저닝을 지원합니다. 다음 표에는 OpenShift Container Platform에서 지원하는 모든 GCP PD CSI 스토리지 클래스 매개변수를 설명합니다.

Expand
표 6.5. CreateVolume 매개 변수
매개변수기본설명

type

pd-ssd , pd-standard 또는 pd-balanced

pd-standard

표준 PV 또는 솔리드 스테이트 드라이브 PV 중 하나를 선택할 수 있습니다.

드라이버는 값의 유효성을 검사하지 않으므로 가능한 모든 값이 허용됩니다.

replication-type

none 또는 regional-pd

none

존 또는 지역 PV 중 하나를 선택할 수 있습니다.

disk-encryption-kms-key

새 디스크를 암호화하는 데 사용할 키가 정규화된 리소스 식별자입니다.

빈 문자열

CMEK(고객 관리 암호화 키)를 사용하여 새 디스크를 암호화합니다.

6.13.5. 사용자 정의 암호화 영구 볼륨 생성

PersistentVolumeClaim 오브젝트를 생성할 때 OpenShift Container Platform은 새 PV(영구 볼륨)를 프로비저닝하고 PersistentVolume 오브젝트를 생성합니다. 새로 생성된 PV를 암호화하여 클러스터에서 PV를 보호하기 위해 GCP(Google Cloud Platform)에 사용자 지정 암호화 키를 추가할 수 있습니다.

암호화를 위해 새로 연결된 PV는 신규 또는 기존 Google Cloud KMS(키 관리 서비스) 키를 사용하여 클러스터에서 CMEK(고객 관리 암호화 키)를 사용합니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터에 로그인되어 있습니다.
  • Cloud KMS 키 링 및 키 버전이 생성되어 있습니다.

CMEK 및 Cloud KMS 리소스에 대한 자세한 내용은 CMEK(고객 관리 암호화 키) 사용을 참조하십시오.

절차

사용자 정의 PV를 생성하려면 다음 단계를 완료합니다.

  1. Cloud KMS 키를 사용하여 스토리지 클래스를 생성합니다. 다음 예시에서는 암호화된 볼륨의 동적 프로비저닝을 활성화합니다.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: csi-gce-pd-cmek
    provisioner: pd.csi.storage.gke.io
    volumeBindingMode: "WaitForFirstConsumer"
    allowVolumeExpansion: true
    parameters:
      type: pd-standard
      disk-encryption-kms-key: projects/<key-project-id>/locations/<location>/keyRings/<key-ring>/cryptoKeys/<key> 
    1
    Copy to Clipboard Toggle word wrap
    1
    이 필드는 새 디스크를 암호화하는 데 사용할 키의 리소스 식별자여야 합니다. 값은 대소문자를 구분합니다. 키 ID 값을 제공하는 방법에 대한 자세한 내용은 리소스의 ID 검색Cloud KMS 리소스 ID 가져오기를 참조하십시오.
    참고

    disk-encryption-✓s-key 매개변수를 기존 스토리지 클래스에 추가할 수 없습니다. 그러나 스토리지 클래스를 삭제하고 동일한 이름과 다른 매개변수 세트로 다시 생성할 수 있습니다. 이렇게 하는 경우 기존 클래스의 프로비저너가 pd.csi.storage.gke.io여야 합니다.

  2. oc 명령을 사용하여 OpenShift Container Platform 클러스터에 스토리지 클래스를 배포합니다.

    $ oc describe storageclass csi-gce-pd-cmek
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:                  csi-gce-pd-cmek
    IsDefaultClass:        No
    Annotations:           None
    Provisioner:           pd.csi.storage.gke.io
    Parameters:            disk-encryption-kms-key=projects/key-project-id/locations/location/keyRings/ring-name/cryptoKeys/key-name,type=pd-standard
    AllowVolumeExpansion:  true
    MountOptions:          none
    ReclaimPolicy:         Delete
    VolumeBindingMode:     WaitForFirstConsumer
    Events:                none
    Copy to Clipboard Toggle word wrap

  3. 이전 단계에서 생성한 스토리지 클래스 오브젝트의 이름과 일치하는 pvc.yaml 파일을 생성합니다.

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
        - ReadWriteOnce
      storageClassName: csi-gce-pd-cmek
      resources:
        requests:
          storage: 6Gi
    Copy to Clipboard Toggle word wrap
    참고

    새 스토리지 클래스를 기본값으로 표시한 경우 storageClassName 필드를 생략할 수 있습니다.

  4. 클러스터에 PVC를 적용합니다.

    $ oc apply -f pvc.yaml
    Copy to Clipboard Toggle word wrap
  5. PVC 상태를 가져온 후 새로 프로비저닝된 PV에 바인딩되었는지 확인합니다.

    $ oc get pvc
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
    podpvc    Bound     pvc-e36abf50-84f3-11e8-8538-42010a800002   10Gi       RWO            csi-gce-pd-cmek  9s
    Copy to Clipboard Toggle word wrap

    참고

    스토리지 클래스에 WaitForFirstConsumer로 설정된 volumeBindingMode 필드가 있는 경우 이를 확인하기 전에 PVC를 사용하도록 Pod를 생성해야 합니다.

이제 CMEK가 지원하는 PV를 OpenShift Container Platform 클러스터와 함께 사용할 준비가 되었습니다.

6.13.6. 사용자 관리 암호화

사용자 관리 암호화 기능을 사용하면 설치 중에 OpenShift Container Platform 노드 루트 볼륨을 암호화하는 키를 제공할 수 있으며, 모든 관리형 스토리지 클래스에서 이러한 키를 사용하여 프로비저닝된 스토리지 볼륨을 암호화할 수 있습니다. install-config YAML 파일의 platform.<cloud_type>.defaultMachinePlatform 필드에서 사용자 지정 키를 지정해야 합니다.

이 기능은 다음과 같은 저장 유형을 지원합니다.

  • Amazon Web Services(AWS) Elastic Block 스토리지(EBS)
  • Microsoft Azure 디스크 저장소
  • Google Cloud Platform(GCP) 영구 디스크(PD) 스토리지
  • IBM Virtual Private Cloud(VPC) 블록 스토리지

GCP PD에 대한 사용자 관리 암호화를 설치하는 방법에 대한 자세한 내용은 설치 구성 매개변수를 참조하세요.

6.14. Google Compute Platform 파일 저장소 CSI 드라이버 운영자

6.14.1. 개요

OpenShift Container Platform은 Google Compute Platform(GCP) Filestore Storage용 Container Storage Interface(CSI) 드라이버를 사용하여 영구 볼륨(PV)을 프로비저닝할 수 있습니다.

CSI 운영자와 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해야 합니다.

GCP Filestore Storage 자산에 마운트되는 CSI 프로비저닝 PV를 생성하려면 openshift-cluster-csi-drivers 네임스페이스에 GCP Filestore CSI Driver Operator와 GCP Filestore CSI 드라이버를 설치합니다.

  • GCP Filestore CSI Driver Operator는 기본적으로 스토리지 클래스를 제공하지 않지만 필요한 경우 스토리지 클래스를 만들 수 있습니다 . GCP Filestore CSI Driver Operator는 필요에 따라 스토리지 볼륨을 생성할 수 있도록 하여 동적 볼륨 프로비저닝을 지원하므로 클러스터 관리자가 스토리지를 미리 프로비저닝할 필요가 없습니다.
  • GCP Filestore CSI 드라이버를 사용하면 GCP Filestore PV를 만들고 마운트할 수 있습니다.

OpenShift Container Platform GCP Filestore는 워크로드 ID를 지원합니다. 이를 통해 사용자는 서비스 계정 키 대신 페더레이션 ID를 사용하여 Google Cloud 리소스에 액세스할 수 있습니다. GCP 워크로드 ID는 설치 중에 전역적으로 활성화해야 하며, 그런 다음 GCP Filestore CSI 드라이버 운영자에 대해 구성해야 합니다. 자세한 내용은 GCP Filestore CSI 드라이버 운영자 설치를 참조하세요.

6.14.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

6.14.3. GCP Filestore CSI 드라이버 운영자 설치

Google Compute Platform Filestore와 함께 GCP 워크로드 ID를 사용하려면 GCP Filestore 컨테이너 스토리지 인터페이스(CSI) 드라이버 운영자를 설치하는 동안 사용할 특정 매개변수를 얻어야 합니다.

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.

프로세스

워크로드 ID를 사용하여 GCP Filestore CSI Driver Operator를 설치하려면 다음을 수행하세요.

  1. 프로젝트 번호를 얻으세요:

    1. 다음 명령을 실행하여 프로젝트 ID를 얻습니다.

      $ export PROJECT_ID=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.gcp.projectID}')
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 프로젝트 ID를 사용하여 프로젝트 번호를 얻습니다.

      $ gcloud projects describe $PROJECT_ID --format="value(projectNumber)"
      Copy to Clipboard Toggle word wrap
  2. ID 풀 ID와 공급자 ID를 찾으세요.

    클러스터 설치 중에 이러한 리소스의 이름은 --name 매개변수를 사용하여 Cloud Credential Operator 유틸리티( ccoctl )에 제공됩니다. "Cloud Credential Operator 유틸리티를 사용하여 GCP 리소스 만들기"를 참조하세요.

  3. GCP Filestore Operator에 대한 워크로드 ID 리소스를 만듭니다.

    1. 다음 예제 파일을 사용하여 CredentialsRequest 파일을 만듭니다.

      예제 자격 증명 요청 YAML 파일

      apiVersion: cloudcredential.openshift.io/v1
      kind: CredentialsRequest
      metadata:
        name: openshift-gcp-filestore-csi-driver-operator
        namespace: openshift-cloud-credential-operator
        annotations:
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
      spec:
        serviceAccountNames:
        - gcp-filestore-csi-driver-operator
        - gcp-filestore-csi-driver-controller-sa
        secretRef:
          name: gcp-filestore-cloud-credentials
          namespace: openshift-cluster-csi-drivers
        providerSpec:
          apiVersion: cloudcredential.openshift.io/v1
      	kind: GCPProviderSpec
          predefinedRoles:
          - roles/file.editor
          - roles/resourcemanager.tagUser
          skipServiceCheck: true
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 CredentialsRequest 파일을 사용하여 GCP 서비스 계정을 만듭니다.

      $ ./ccoctl gcp create-service-accounts --name=<filestore-service-account> \
      1
      
        --workload-identity-pool=<workload-identity-pool> \
      2
      
        --workload-identity-provider=<workload-identity-provider> \
      3
      
        --project=<project-id> \
      4
      
        --credentials-requests-dir=/tmp/credreq 
      5
      Copy to Clipboard Toggle word wrap
      1
      <filestore-service-account>는 사용자가 선택한 이름입니다.
      2
      <workload-identity-pool>은 위의 2단계에서 나왔습니다.
      3
      <workload-identity-provider>는 위의 2단계에서 나왔습니다.
      4
      <project-id>는 위의 1.a 단계에서 나왔습니다.
      5
      CredentialsRequest 파일이 있는 디렉토리의 이름입니다.

      출력 예

      2025/02/10 17:47:39 Credentials loaded from gcloud CLI defaults
      2025/02/10 17:47:42 IAM service account filestore-service-account-openshift-gcp-filestore-csi-driver-operator created
      2025/02/10 17:47:44 Unable to add predefined roles to IAM service account, retrying...
      2025/02/10 17:47:59 Updated policy bindings for IAM service account filestore-service-account-openshift-gcp-filestore-csi-driver-operator
      2025/02/10 17:47:59 Saved credentials configuration to: /tmp/install-dir/ 
      1
      
      openshift-cluster-csi-drivers-gcp-filestore-cloud-credentials-credentials.yaml
      Copy to Clipboard Toggle word wrap

      1
      현재 디렉토리.
    3. 다음 명령을 실행하여 새로 생성된 서비스 계정의 서비스 계정 이메일을 찾으세요.

      $ cat /tmp/install-dir/manifests/openshift-cluster-csi-drivers-gcp-filestore-cloud-credentials-credentials.yaml | yq '.data["service_account.json"]' | base64 -d | jq '.service_account_impersonation_url'
      Copy to Clipboard Toggle word wrap

      출력 예

      https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/filestore-se-openshift-g-ch8cm@openshift-gce-devel.iam.gserviceaccount.com:generateAccessToken
      Copy to Clipboard Toggle word wrap

      이 예제 출력에서 서비스 계정 이메일은 filestore-se-openshift-g-ch8cm@openshift-gce-devel.iam.gserviceaccount.com 입니다.

결과

이제 GCP Filestore CSI Driver Operator를 설치하는 데 필요한 다음 매개변수가 있습니다.

  • 프로젝트 번호 - 1.b 단계부터
  • 풀 ID - 2단계부터
  • 공급자 ID - 2단계부터
  • 서비스 계정 이메일 - 3.c 단계부터
6.14.3.2. GCP Filestore CSI 드라이버 운영자 설치

Google Compute Platform(GCP) Filestore Container Storage Interface(CSI) 드라이버 운영자는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. 다음 절차에 따라 클러스터에 GCP Filestore CSI Driver Operator를 설치하세요.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • GCP 워크로드 ID를 사용하는 경우 특정 GCP 워크로드 ID 매개변수가 필요합니다. 이전 섹션 '워크로드 ID를 사용하여 GCP Filestore CSI 드라이버 운영자 설치 준비'를 참조하세요.

프로세스

웹 콘솔에서 GCP Filestore CSI Driver Operator를 설치하려면:

  1. 웹 콘솔에 로그인합니다.
  2. 다음 명령을 실행하여 GCE 프로젝트에서 Filestore API를 활성화합니다.

    $ gcloud services enable file.googleapis.com  --project <my_gce_project> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <my_gce_project>를 Google Cloud 프로젝트로 바꿉니다.

    Google Cloud 웹 콘솔을 사용하여 이 작업을 수행할 수도 있습니다.

  3. GCP Filestore CSI Operator를 설치하세요.

    1. OperatorsOperatorHub를 클릭합니다.
    2. 필터 상자에 GCP Filestore를 입력하여 GCP Filestore CSI Operator를 찾습니다.
    3. GCP Filestore CSI 드라이버 운영자 버튼을 클릭합니다.
    4. GCP Filestore CSI Driver Operator 페이지에서 설치를 클릭합니다.
    5. Operator 설치 페이지에서 다음을 확인합니다.

      • 클러스터의 모든 네임스페이스(기본값)가 선택됩니다.
      • 설치된 네임스페이스openshift-cluster-csi-drivers로 설정됩니다.

        GCP 워크로드 ID를 사용하는 경우 워크로드 ID를 사용하여 GCP Filestore CSI 드라이버 운영자 설치 준비 섹션의 절차에서 얻은 다음 필드에 대한 값을 입력합니다.

      • GCP 프로젝트 번호
      • GCP 풀 ID
      • GCP 공급자 ID
      • GCP 서비스 계정 이메일
    6. 설치를 클릭합니다.

      설치가 완료되면 GCP Filestore CSI Operator가 웹 콘솔의 설치된 연산자 섹션에 나열됩니다.

  4. GCP Filestore CSI 드라이버를 설치하세요.

    1. 관리CustomResourceDefinitionsClusterCSIDriver를 클릭합니다.
    2. Instances 탭에서 Create ClusterCSIDriver를 클릭합니다.

      다음 YAML 파일을 사용합니다.

      apiVersion: operator.openshift.io/v1
      kind: ClusterCSIDriver
      metadata:
          name: filestore.csi.storage.gke.io
      spec:
        managementState: Managed
      Copy to Clipboard Toggle word wrap
    3. 생성을 클릭합니다.
    4. 다음 조건이 "true" 상태로 변경될 때까지 기다립니다.

      • GCPFilestoreDriverCredentialsRequestControllerAvailable
      • GCPFilestoreDriverNodeServiceControllerAvailable
      • GCPFilestoreDriverControllerServiceControllerAvailable

6.14.4. GCP Filestore 스토리지용 스토리지 클래스 생성

Operator를 설치한 후에는 Google Compute Platform(GCP) Filestore 볼륨의 동적 프로비저닝을 위한 스토리지 클래스를 생성해야 합니다.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터에 로그인했습니다.

프로세스

스토리지 클래스를 생성하려면:

  1. 다음 예제 YAML 파일을 사용하여 스토리지 클래스를 만듭니다.

    YAML 파일 예시

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: filestore-csi
    provisioner: filestore.csi.storage.gke.io
    parameters:
      connect-mode: DIRECT_PEERING 
    1
    
      network: network-name 
    2
    
    allowVolumeExpansion: true
    volumeBindingMode: WaitForFirstConsumer
    Copy to Clipboard Toggle word wrap

    1
    공유 VPC의 경우, connect-mode 매개변수를 PRIVATE_SERVICE_ACCESS 로 설정합니다. 공유되지 않는 VPC의 경우 값은 기본 설정인 DIRECT_PEERING 입니다.
    2
    Filestore 인스턴스를 생성할 GCP 가상 사설 클라우드(VPC) 네트워크의 이름을 지정합니다.
  2. Filestore 인스턴스를 생성해야 하는 VPC 네트워크의 이름을 지정합니다.

    Filestore 인스턴스를 생성할 VPC 네트워크를 지정하는 것이 좋습니다. VPC 네트워크가 지정되지 않으면 CSI(Container Storage Interface) 드라이버는 프로젝트의 기본 VPC 네트워크에 인스턴스를 생성하려고 시도합니다.

    IPI 설치에서 VPC 네트워크 이름은 일반적으로 접미사 "-network"가 붙은 클러스터 이름입니다. 하지만 UPI 설치에서는 VPC 네트워크 이름을 사용자가 선택한 값으로 지정할 수 있습니다.

    공유 VPC( connect-mode = PRIVATE_SERVICE_ACCESS )의 경우 네트워크는 전체 VPC 이름이어야 합니다. 예: projects/shared-vpc-name/global/networks/gcp-filestore-network .

    다음 명령을 사용하여 MachineSets 객체를 검사하면 VPC 네트워크 이름을 알아낼 수 있습니다.

    $ oc -n openshift-machine-api get machinesets -o yaml | grep "network:"
                - network: gcp-filestore-network
    (...)
    Copy to Clipboard Toggle word wrap

    이 예에서 이 클러스터의 VPC 네트워크 이름은 "gcp-filestore-network"입니다.

6.14.5. NFS 내보내기 옵션

기본적으로 Filestore 인스턴스는 동일한 Google Cloud 프로젝트와 가상 사설 클라우드(VPC) 네트워크를 공유하는 모든 클라이언트에 루트 수준의 읽기/쓰기 액세스 권한을 부여합니다. 네트워크 파일 시스템(NFS) 내보내기 옵션을 사용하면 이러한 액세스를 특정 IP 범위와 Filestore 인스턴스의 특정 사용자/그룹 ID로 제한할 수 있습니다. 스토리지 클래스를 생성할 때 nfs-export-options-on-create 매개변수를 사용하여 이러한 옵션을 설정할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • GCP Filestore CSI 드라이버 운영자와 GCP Filestore CSI 드라이버가 설치되었습니다.

프로세스

  1. 다음 샘플 YAML 파일과 유사한 파일을 사용하여 스토리지 클래스를 만듭니다.

    참고

    스토리지 클래스 생성에 대한 자세한 내용은 GCP Filestore Operator에 대한 스토리지 클래스 생성 섹션을 참조하세요.

    NFS 내보내기 옵션이 있는 예제 스토리지 클래스 YAML 파일

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
     name: SC-name
    provisioner: filestore.csi.storage.gke.io
    parameters:
     connect-mode: DIRECT_PEERING
     network: project-network
     nfs-export-options-on-create: '[ 
    1
    
       {
         "accessMode": "READ_WRITE", 
    2
    
         "squashMode": "NO_ROOT_SQUASH", 
    3
    
         "anonUid": 65534 
    4
    
         "anonGid": 65534 
    5
    
         "ipRanges": [ 
    6
    
           "10.0.0.0/16"
         ]
       }]'
    allowVolumeExpansion: true
    Copy to Clipboard Toggle word wrap

    1
    NFS 내보내기 옵션 매개변수
    2
    액세스 모드 : 내보낸 디렉토리에 대한 읽기 요청만 허용하는 READ_ONLY 또는 읽기 및 쓰기 요청을 모두 허용하는 READ_WRITE . 기본값은 READ_WRITE 입니다.
    3
    스쿼시 모드 : 내보낸 디렉토리에 대한 루트 액세스를 허용하는 NO_ROOT_SQUASH 또는 루트 액세스를 허용하지 않는 ROOT_SQUASH입니다. 기본값은 NO_ROOT_SQUASH 입니다.
    4
    AnonUid : 익명 사용자 ID를 나타내는 정수로 기본값은 65534입니다. AnonUid는 squashMode를 ROOT_SQUASH 로 설정해야만 설정할 수 있습니다. 그렇지 않으면 오류가 발생합니다.
    5
    AnonGid : 익명 그룹 ID를 나타내는 정수로 기본값은 65534입니다. AnonGid는 squashMode를 ROOT_SQUASH 로 설정해야만 설정할 수 있습니다. 그렇지 않으면 오류가 발생합니다.
    6
    IP 범위 : {octet1}.{octet2}.{octet3}.{octet4} 형식의 IPv4 주소 목록 또는 {octet1}.{octet2}.{octet3}.{octet4}/{마스크 크기} 형식의 CIDR 범위 목록으로, 파일 공유를 마운트할 수 있습니다. NfsExportOptions 내부와 외부 모두에서 IP 범위가 겹치는 것은 허용되지 않습니다. 겹치는 경우 오류가 반환됩니다. 모든 NFS 내보내기 옵션 중 각 FileShareConfig 에 대해 허용되는 IP 범위 또는 주소는 64개입니다.

6.14.6. 클러스터 및 GCP Filestore 삭제

일반적으로 클러스터를 파괴하면 OpenShift Container Platform 설치 프로그램은 해당 클러스터에 속한 모든 클라우드 리소스를 삭제합니다. 그러나 Google Compute Platform(GCP) Filestore 리소스의 특수한 특성으로 인해 자동 정리 프로세스가 드물게 모든 리소스를 제거하지 못할 수도 있습니다.

따라서 Red Hat에서는 클러스터 소유의 모든 Filestore 리소스가 제거 프로세스를 통해 삭제되었는지 확인할 것을 권장합니다.

프로세스

모든 GCP Filestore PVC가 삭제되었는지 확인하려면 다음을 수행합니다.

  1. GUI 또는 CLI를 사용하여 Google Cloud 계정에 액세스하세요.
  2. kubernetes-io-cluster-${CLUSTER_ID}=owned 레이블이 있는 모든 리소스를 검색합니다.

    클러스터 ID는 삭제된 클러스터에 고유하므로 해당 클러스터 ID를 가진 리소스가 남아 있지 않습니다.

  3. 남아 있는 리소스가 있는 경우에는 삭제하세요.

6.15. IBM Cloud VPC 블록 CSI 드라이버 운영자

6.15.1. 개요

OpenShift Container Platform은 IBM® Virtual Private Cloud(VPC) 블록 스토리지용 컨테이너 스토리지 인터페이스(CSI) 드라이버를 사용하여 영구 볼륨(PV)을 프로비저닝할 수 있습니다.

CSI 운영자와 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해야 합니다.

IBM Cloud® VPC Block 스토리지 자산에 마운트되는 CSI 프로비저닝 PV를 생성하기 위해 OpenShift Container Platform은 기본적으로 openshift-cluster-csi-drivers 네임스페이스에 IBM Cloud® VPC Block CSI Driver Operator와 IBM Cloud® VPC Block CSI 드라이버를 설치합니다.

  • IBM Cloud® VPC Block CSI Driver Operator는 ibmc-vpc-block-10iops-tier (기본값), ibmc-vpc-block-5iops-tier , ibmc-vpc-block-custom 이라는 세 가지 스토리지 클래스를 제공하며, 이를 사용하여 영구적 볼륨 클레임(PVC)을 생성할 수 있습니다. IBM Cloud® VPC Block CSI Driver Operator는 스토리지 볼륨을 필요에 따라 생성할 수 있도록 하여 동적 볼륨 프로비저닝을 지원하므로 클러스터 관리자가 스토리지를 미리 프로비저닝할 필요가 없습니다. 원하는 경우 이 기본 저장소 클래스를 비활성화할 수 있습니다( 기본 저장소 클래스 관리 참조).
  • IBM Cloud® VPC Block CSI 드라이버를 사용 하면 IBM Cloud® VPC Block PV를 생성하고 마운트할 수 있습니다.

6.15.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

6.15.3. 사용자 관리 암호화

사용자 관리 암호화 기능을 사용하면 설치 중에 OpenShift Container Platform 노드 루트 볼륨을 암호화하는 키를 제공할 수 있으며, 모든 관리형 스토리지 클래스에서 이러한 키를 사용하여 프로비저닝된 스토리지 볼륨을 암호화할 수 있습니다. install-config YAML 파일의 platform.<cloud_type>.defaultMachinePlatform 필드에서 사용자 지정 키를 지정해야 합니다.

이 기능은 다음과 같은 저장 유형을 지원합니다.

  • Amazon Web Services(AWS) Elastic Block 스토리지(EBS)
  • Microsoft Azure 디스크 저장소
  • Google Cloud Platform(GCP) 영구 디스크(PD) 스토리지
  • IBM Virtual Private Cloud(VPC) 블록 스토리지

IBM Cloud에서 사용자 관리 암호화를 사용하여 설치하는 방법에 대한 자세한 내용은 IBM Cloud의 사용자 관리 암호화IBM Cloud에 설치 준비를 참조하세요.

6.16. IBM Power Virtual Server Block CSI Driver Operator

6.16.1. 소개

IBM Power® Virtual Server Block CSI 드라이버는 IBM Power® Virtual Server Block CSI Driver Operator를 통해 설치되고 Operator는 library-go 를 기반으로 합니다. OpenShift Container Platform library-go 프레임워크는 사용자가 OpenShift Operator를 쉽게 빌드할 수 있는 함수 컬렉션입니다. CSI Driver Operator의 대부분의 기능은 이미 사용 가능합니다. IBM Power® Virtual Server Block CSI Driver Operator는 Cluster Storage Operator에 의해 설치됩니다. 플랫폼 유형이 Power Virtual Servers인 경우 Cluster Storage Operator는 IBM Power® Virtual Server Block CSI Driver Operator를 설치합니다.

6.16.2. 개요

OpenShift Container Platform은 IBM Power® Virtual Server Block Storage용 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI Operator 및 드라이버를 사용할 때는 영구 스토리지CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

IBM Power® Virtual Server Block 스토리지 자산에 마운트되는 CSI 프로비저닝 PV를 생성하기 위해 OpenShift Container Platform은 openshift-cluster-csi-drivers 네임스페이스에 기본적으로 IBM Power® Virtual Server Block CSI Driver Operator 및 IBM Power® Virtual Server Block CSI 드라이버를 설치합니다.

  • IBM Power® Virtual Server Block CSI Driver Operator 는 PVC(영구 볼륨 클레임)를 생성하는 데 사용할 수 있는 다른 계층에 대해 ibm-powervs-tier1 (기본값) 및 ibm-powervs-tier3 이라는 두 가지 스토리지 클래스를 제공합니다. IBM Power® Virtual Server Block CSI Driver Operator는 필요에 따라 스토리지 볼륨을 생성할 수 있으므로 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없어 동적 볼륨 프로비저닝을 지원합니다.
  • IBM Power® Virtual Server Block CSI 드라이버 를 사용하면 IBM Power® Virtual Server Block PV를 생성하고 마운트할 수 있습니다.

6.16.3. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 OpenShift Container Platform 사용자 스토리지 옵션을 제공합니다.

6.17. OpenStack Cinder CSI Driver Operator

6.17.1. 개요

OpenShift Container Platform은 OpenStack Cinder 용 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI(Container Storage Interface) Operator 및 드라이버를 사용할 때는 영구 스토리지 및 CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

OpenStack Cinder 스토리지 자산에 마운트되는 CSI 프로비저닝 PV를 생성하기 위해 OpenShift Container Platform은 openshift-cluster-csi-drivers 네임스페이스에 OpenStack Cinder CSI 드라이버와 OpenStack Cinder CSI 드라이버를 설치합니다.

  • OpenStack Cinder CSI Driver Operator는 PVC를 생성하는 데 사용할 수 있는 CSI 스토리지 클래스를 제공합니다. 필요한 경우 이 기본 스토리지 클래스를 비활성화할 수 있습니다( 기본 스토리지 클래스 관리참조).
  • OpenStack Cinder CSI 드라이버를 사용하면 OpenStack Cinder PV를 생성 및 마운트할 수 있습니다.
참고

OpenShift Container Platform은 Cinder in-tree 볼륨 플러그인에 대한 자동 마이그레이션을 동등한 CSI 드라이버로 제공합니다. 자세한 내용은 CSI 자동 마이그레이션 을 참조하십시오.

6.17.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 OpenShift Container Platform 사용자 스토리지 옵션을 제공합니다.

중요

OpenShift Container Platform은 기본적으로 CSI 플러그인을 사용하여 vSphere 스토리지를 프로비저닝합니다.

6.17.3. OpenStack Cinder CSI를 기본 스토리지 클래스로 설정

OpenStack Cinder CSI 드라이버는 cinder.csi.openstack.org 매개변수 키를 사용한 동적 프로비저닝을 지원합니다.

OpenShift Container Platform에서 OpenStack Cinder CSI 프로비저닝을 활성화하려면 기본 in-tree 스토리지 클래스를 standard-csi로 덮어쓰는 것이 좋습니다. 다른 방법으로 PVC(영구 볼륨 클레임)를 생성하고 스토리지 클래스를 "standard-csi"로 지정할 수 있습니다.

OpenShift Container Platform에서 기본 스토리지 클래스는 in-tree Cinder 드라이버를 참조합니다. 그러나 CSI 자동 마이그레이션이 활성화된 경우 기본 스토리지 클래스를 사용하여 생성된 볼륨은 실제로 CSI 드라이버를 사용합니다.

프로세스

기본 in-tree 스토리지 클래스를 작성하여 standard-csi 스토리지 클래스를 적용하려면 다음 단계를 사용합니다.

  1. 스토리지 클래스를 나열합니다.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    standard(default)      cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   46h
    standard-csi           kubernetes.io/cinder       Delete          WaitForFirstConsumer   true                   46h
    Copy to Clipboard Toggle word wrap

  2. 기본 StorageClass에 대해 주석 storageclass.kubernetes.io/is-default-class의 값을 false로 변경합니다.

    $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
    Copy to Clipboard Toggle word wrap
  3. 주석을 storageclass.kubernetes.io/is-default-class=true로 추가하거나 수정하여 다른 스토리지 클래스를 기본값으로 설정합니다.

    $ oc patch storageclass standard-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
    Copy to Clipboard Toggle word wrap
  4. PVC가 기본적으로 CSI 스토리지 클래스를 참조하는지 확인합니다.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    standard               kubernetes.io/cinder       Delete          WaitForFirstConsumer   true                   46h
    standard-csi(default)  cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   46h
    Copy to Clipboard Toggle word wrap

  5. 선택 사항: 스토리지 클래스를 지정하지 않고도 새 PVC를 정의할 수 있습니다.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: cinder-claim
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
    Copy to Clipboard Toggle word wrap

    특정 스토리지 클래스를 지정하지 않는 PVC는 기본 스토리지 클래스를 사용하여 자동으로 프로비저닝됩니다.

  6. 선택 사항: 새 파일을 구성한 후 클러스터에서 파일을 생성합니다.

    $ oc create -f cinder-claim.yaml
    Copy to Clipboard Toggle word wrap

6.18. OpenStack Manila CSI Driver Operator

6.18.1. 개요

OpenShift Container Platform은 OpenStack Manila 공유 파일 시스템 서비스의 CSI(Container Storage Interface) 드라이버를 사용하여 PV(영구 볼륨)를 프로비저닝할 수 있습니다.

CSI(Container Storage Interface) Operator 및 드라이버를 사용할 때는 영구 스토리지 및 CSI 볼륨 구성에 대해 숙지하는 것이 좋습니다.

Manila 스토리지 자산에 마운트되는 CSI 프로비저닝 PV를 생성하기 위해 OpenShift Container Platform은 Manila 서비스가 활성화된 모든 OpenStack 클러스터에 Manila CSI Driver Operator 및 Manila CSI 드라이버를 설치합니다.

  • Manila CSI Driver Operator는 사용 가능한 모든 Manila 공유 유형에 대해 PVC를 생성하는 데 필요한 스토리지 클래스를 생성합니다. Operator는 openshift-cluster-csi-drivers 네임스페이스에 설치됩니다.
  • Manila CSI 드라이버를 사용하면 Manila PV를 생성 및 마운트할 수 있습니다. 드라이버는 openshift-manila-csi-driver 네임스페이스에 설치됩니다.

6.18.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. CSI(Container Storage Interface) 구현을 통해 타사 공급자는 코어 Kubernetes 코드를 변경하지 않고 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI Operator는 in-tree 볼륨 플러그인에서 사용할 수 없는 볼륨 스냅샷과 같은 OpenShift Container Platform 사용자 스토리지 옵션을 제공합니다.

6.18.3. Manila CSI Driver Operator 제한 사항

Manila CSI(Container Storage Interface) Driver Operator에 다음과 같은 제한 사항이 적용됩니다.

NFS만 지원됨
OpenStack Manila는 NFS, CIFS, CEPHFS와 같은 많은 네트워크 연결 스토리지 프로토콜을 지원하며 OpenStack 클라우드에서 선택적으로 활성화할 수 있습니다. OpenShift Container Platform의 Manila CSI Driver Operator는 NFS 프로토콜 사용만 지원합니다. 기본 OpenStack 클라우드에서 NFS를 사용할 수 없고 활성화된 경우 Manila CSI Driver Operator를 사용하여 OpenShift Container Platform용 스토리지를 프로비저닝할 수 없습니다.
백엔드가 CephFS-NFS인 경우 스냅샷은 지원되지 않습니다.
PV(영구 볼륨)의 스냅샷을 작성하고 볼륨을 스냅샷으로 되돌리려면 사용 중인 Manila 공유 유형이 이러한 기능을 지원하는지 확인해야 합니다. Red Hat OpenStack 관리자는 사용하려는 스토리지 클래스와 연결된share type extra-spec snapshot_support)과 스냅샷에서 공유를 생성해야 합니다(share type extra-spec create_share_from_snapshot_support).
FSGroups는 지원되지 않습니다.
Manila CSI는 여러 리더 및 여러 작성자가 액세스할 수 있는 공유 파일 시스템을 제공하므로 FSGroups 사용을 지원하지 않습니다. ReadWriteOnce 액세스 모드를 사용하여 생성된 영구 볼륨에도 적용됩니다. 따라서 Manila CSI 드라이버와 함께 사용하기 위해 수동으로 생성한 모든 스토리지 클래스에는 fsType 속성을 지정하지 않는 것이 중요합니다.
중요

Red Hat OpenStack Platform 16.x 및 17.x에서 NFS를 통한 CephFS를 탑재한 공유 파일 시스템 서비스(Manila)는 Manila CSI를 통해 OpenShift Container Platform에 공유를 제공하는 것을 완벽하게 지원합니다. 하지만 이 솔루션은 대규모로 사용하기에는 적합하지 않습니다. Red Hat OpenStack Platform을 위한 CephFS NFS Manila-CSI 워크로드 권장 사항 에서 중요한 권장 사항을 검토하세요.

6.18.4. 동적으로 Manila CSI 볼륨 프로비저닝

OpenShift Container Platform은 사용 가능한 Manila 공유 유형마다 스토리지 클래스를 설치합니다.

생성된 YAML 파일은 Manila와 해당 컨테이너 스토리지 인터페이스(CSI) 플러그인에서 완전히 분리됩니다. 애플리케이션 개발자는 RWX(ReadWriteMany) 스토리지를 동적으로 프로비저닝하고 YAML 매니페스트를 사용하여 스토리지를 안전하게 사용하는 애플리케이션에 Pod를 배포할 수 있습니다.

PVC 정의의 스토리지 클래스 참조는 제외되어 AWS, GCP, Azure 및 기타 플랫폼에서 OpenShift Container Platform과 함께 사용하는 동일한 Pod 및 PVC(영구 볼륨 클레임) 정의를 사용할 수 있습니다.

중요

기본적으로 볼륨에 할당된 액세스 규칙은 0.0.0.0/0으로 설정됩니다. 영구 볼륨(PV)을 마운트할 수 있는 클라이언트를 제한하려면 nfs-shareClient 스토리지 클래스 매개변수에 IP 또는 서브넷 마스크를 사용하여 새 스토리지 클래스를 만듭니다.

참고

Manila 서비스는 선택 사항입니다. Red Hat OpenStack Platform(RHOSP)에서 서비스가 활성화되지 않으면 Manila CSI 드라이버가 설치되지 않고 Manila에 대한 스토리지 클래스가 생성되지 않습니다.

사전 요구 사항

  • RHOSP는 적절한 Manila와 함께 배포되어 OpenShift Container Platform에서 볼륨을 동적으로 프로비저닝 및 마운트하는 데 사용할 수 있습니다.

절차(UI)

웹 콘솔을 사용하여 Manila CSI 볼륨을 동적으로 생성하려면 다음을 수행합니다.

  1. OpenShift Container Platform 콘솔에서 스토리지영구 볼륨 클레임을 클릭합니다.
  2. 영구 볼륨 클레임 생성 개요에서 영구 볼륨 클레임 생성을 클릭합니다.
  3. 결과 페이지에 필요한 옵션을 정의합니다.

    1. 적절한 스토리지 클래스를 선택합니다.
    2. 스토리지 클레임의 고유한 이름을 입력합니다.
    3. 생성 중인 PVC에 대한 읽기 및 쓰기 권한을 지정하려면 액세스 모드를 선택합니다.

      중요

      클러스터의 여러 노드에 있는 여러 포드에 이 PVC를 충족하는 PV를 마운트하려면 RWX를 사용하세요.

  4. 스토리지 클레임의 크기를 정의합니다.
  5. 생성을 클릭하여 PVC를 만들고 PV를 생성합니다.

프로세스(CLI)

CLI(명령줄 인터페이스)를 사용하여 Manila CSI 볼륨을 동적으로 생성하려면 다음을 수행합니다.

  1. 다음 YAML로 설명된 PersistentVolumeClaim 오브젝트를 사용하여 파일을 생성하고 저장합니다.

    pvc-manila.yaml

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc-manila
    spec:
      accessModes: 
    1
    
        - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: csi-manila-gold 
    2
    Copy to Clipboard Toggle word wrap

    1
    클러스터의 여러 노드에 있는 여러 포드에 이 PVC를 충족하는 PV를 마운트하려면 RWX를 사용하세요.
    2
    스토리지 백엔드를 프로비저닝하는 스토리지 클래스의 이름입니다. Manila 스토리지 클래스는 Operator에 의해 프로비저닝되며 csi-manila- 접두사가 적용됩니다.
  2. 다음 명령을 실행하여 이전 단계에서 저장한 오브젝트를 생성합니다.

    $ oc create -f pvc-manila.yaml
    Copy to Clipboard Toggle word wrap

    새 PVC가 생성됩니다.

  3. 볼륨이 생성되고 준비되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc get pvc pvc-manila
    Copy to Clipboard Toggle word wrap

    pvc-manilaBound가 표시됩니다.

이제 새 PVC를 사용하여 Pod를 구성할 수 있습니다.

6.19. 보안 저장소 CSI 드라이버

6.19.1. 개요

Kubernetes 비밀은 Base64 인코딩으로 저장됩니다. etcd는 이러한 비밀에 대해 저장 시에는 암호화를 제공하지만, 비밀을 검색하면 암호가 해독되어 사용자에게 제공됩니다. 클러스터에서 역할 기반 액세스 제어가 제대로 구성되지 않으면 API 또는 etcd 액세스 권한이 있는 모든 사람이 비밀을 검색하거나 수정할 수 있습니다. 또한, 네임스페이스에 포드를 생성할 권한이 있는 사람은 누구나 해당 액세스 권한을 사용하여 해당 네임스페이스의 모든 비밀을 읽을 수 있습니다.

비밀을 안전하게 저장하고 관리하려면 공급자 플러그인을 사용하여 Azure Key Vault와 같은 외부 비밀 관리 시스템에서 비밀을 마운트하도록 OpenShift Container Platform Secrets Store Container Storage Interface(CSI) 드라이버 운영자를 구성할 수 있습니다. 그러면 애플리케이션은 비밀을 사용할 수 있지만 애플리케이션 포드가 파괴된 후에는 비밀이 시스템에 유지되지 않습니다.

Secrets Store CSI 드라이버 오퍼레이터인 secrets-store.csi.k8s.io 를 사용하면 OpenShift Container Platform에서 엔터프라이즈급 외부 비밀 저장소에 저장된 여러 개의 비밀, 키 및 인증서를 볼륨으로 포드에 마운트할 수 있습니다. Secrets Store CSI 드라이버 운영자는 gRPC를 사용하여 공급자와 통신하여 지정된 외부 비밀 저장소에서 마운트 콘텐츠를 가져옵니다. 볼륨이 연결된 후, 볼륨 안의 데이터는 컨테이너의 파일 시스템에 마운트됩니다. 비밀 저장소 볼륨은 인라인으로 마운트됩니다.

CSI 인라인 볼륨에 대한 자세한 내용은 CSI 인라인 임시 볼륨을 참조하세요.

CSI 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해지는 것이 좋습니다.

6.19.1.1. 비밀 저장소 제공업체

Secrets Store CSI Driver Operator는 다음 Secrets Store 공급업체에서 테스트되었습니다.

  • AWS 시크릿 관리자
  • AWS Systems Manager 매개변수 저장소
  • Azure Key Vault
  • Google 시크릿 관리자
  • HashiCorp Vault
참고

Red Hat은 타사 비밀 저장소 공급자 기능과 관련된 모든 요소를 테스트하지 않습니다. 타사 지원에 대한 자세한 내용은 Red Hat 타사 지원 정책을 참조하세요.

6.19.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

6.19.3. 연결이 끊긴 환경 지원

다음 비밀 저장소 공급자는 연결이 끊긴 클러스터에서 Secrets Store CSI 드라이버를 사용할 수 있도록 지원합니다.

  • AWS 시크릿 관리자
  • Azure Key Vault
  • Google 시크릿 관리자
  • HashiCorp Vault

Secrets Store CSI 드라이버와 비밀 저장소 공급자 간의 통신을 활성화하려면 해당 비밀 저장소 공급자, OpenID Connect(OIDC) 발급자 및 보안 토큰 서비스(STS)에 대한 Virtual Private Cloud(VPC) 엔드포인트 또는 동등한 연결을 구성합니다. 정확한 구성은 비밀 저장소 공급자, 인증 방법 및 연결이 끊긴 클러스터의 유형에 따라 달라집니다.

참고

연결이 끊긴 환경에 대한 자세한 내용은 연결이 끊긴 환경 정보를 참조하세요.

6.19.4. Secrets Store CSI 드라이버 설치

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • 클러스터에 대한 관리자 액세스.

프로세스

Secrets Store CSI 드라이버를 설치하려면:

  1. Secrets Store CSI 드라이버 운영자를 설치하세요:

    1. 웹 콘솔에 로그인합니다.
    2. OperatorsOperatorHub를 클릭합니다.
    3. 필터 상자에 "Secrets Store CSI"를 입력하여 Secrets Store CSI 드라이버 운영자를 찾으세요.
    4. Secrets Store CSI Driver Operator 버튼을 클릭하세요.
    5. Secrets Store CSI Driver Operator 페이지에서 설치를 클릭합니다.
    6. Operator 설치 페이지에서 다음을 확인합니다.

      • 클러스터의 모든 네임스페이스(기본값)가 선택됩니다.
      • 설치된 네임스페이스openshift-cluster-csi-drivers로 설정됩니다.
    7. 설치를 클릭합니다.

      설치가 완료되면 Secrets Store CSI Driver Operator가 웹 콘솔의 설치된 운영자 섹션에 나열됩니다.

  2. 드라이버에 대한 ClusterCSIDriver 인스턴스를 생성합니다( secret-store.csi.k8s.io).

    1. 관리CustomResourceDefinitionsClusterCSIDriver를 클릭합니다.
    2. Instances 탭에서 Create ClusterCSIDriver를 클릭합니다.

      다음 YAML 파일을 사용합니다.

      apiVersion: operator.openshift.io/v1
      kind: ClusterCSIDriver
      metadata:
          name: secrets-store.csi.k8s.io
      spec:
        managementState: Managed
      Copy to Clipboard Toggle word wrap
    3. 생성을 클릭합니다.

6.19.5. Secrets Store CSI 드라이버 운영자 제거

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • 클러스터에 대한 관리자 액세스.

프로세스

Secrets Store CSI Driver Operator를 제거하려면:

  1. secrets-store.csi.k8s.io 공급자를 사용하는 모든 애플리케이션 포드를 중지합니다.
  2. 선택한 비밀 저장소에 대한 타사 공급자 플러그인을 제거합니다.
  3. 컨테이너 스토리지 인터페이스(CSI) 드라이버와 관련 매니페스트를 제거합니다.

    1. 관리CustomResourceDefinitionsClusterCSIDriver를 클릭합니다.
    2. 인스턴스 탭에서 secrets-store.csi.k8s.io 의 맨 왼쪽에 있는 드롭다운 메뉴를 클릭한 다음 ClusterCSIDriver 삭제를 클릭합니다.
    3. 메시지가 표시되면 삭제를 클릭합니다.
  4. CSI 드라이버 Pod가 더 이상 실행되지 않는지 확인합니다.
  5. Secrets Store CSI Driver Operator를 설치 제거합니다.

    참고

    Operator를 설치 제거하려면 CSI 드라이버를 먼저 제거해야 합니다.

    1. Operators설치된 Operators를 클릭합니다.
    2. 설치된 운영자 페이지에서 스크롤하거나 이름으로 검색 상자에 "Secrets Store CSI"를 입력하여 운영자를 찾은 다음 클릭합니다.
    3. 설치된 운영자 > 운영자 세부 정보 페이지의 오른쪽 위에서 작업운영자 제거를 클릭합니다.
    4. Operator 설치 제거 창이 표시되면 제거 버튼을 클릭하여 네임스페이스에서 Operator를 제거합니다. 클러스터에 Operator가 배포한 애플리케이션을 수동으로 정리해야 합니다.

      제거 후 Secrets Store CSI Driver Operator는 더 이상 웹 콘솔의 설치된 운영자 섹션에 나열되지 않습니다.

6.20. CIFS/SMB CSI 드라이버 운영자

OpenShift Container Platform은 CIFS(Common Internet File System) 방언/SMB(Server Message Block) 프로토콜에 대한 CSI(Container Storage Interface) 드라이버를 사용하여 영구 볼륨(PV)을 프로비저닝할 수 있습니다.

CSI 운영자와 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해야 합니다.

CIFS/SMB CSI Driver Operator를 설치한 후, OpenShift Container Platform은 기본적으로 openshift-cluster-csi-drivers 네임스페이스에 Operator와 드라이버에 해당하는 Pod를 설치합니다. 이를 통해 CIFS/SMB CSI 드라이버는 CIFS/SMB 공유에 마운트되는 CSI 프로비저닝 영구 볼륨(PV)을 생성할 수 있습니다.

  • CIFS/SMB CSI 드라이버 운영자는 설치된 후 기본적으로 영구 볼륨 클레임(PVC)을 생성하는 데 사용할 스토리지 클래스를 생성하지 않습니다. 하지만 동적 프로비저닝을 위해 CIFS/SMB StorageClass를 수동으로 생성할 수 있습니다 . CIFS/SMB CSI 드라이버 운영자는 스토리지 볼륨을 필요에 따라 생성할 수 있도록 하여 동적 볼륨 프로비저닝을 지원합니다. 이렇게 하면 클러스터 관리자가 스토리지를 미리 프로비저닝할 필요가 없습니다.
  • CIFS/SMB CSI 드라이버를 사용하면 CIFS/SMB PV를 만들고 마운트할 수 있습니다.

6.20.1. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

6.20.2. 제한

다음 제한 사항은 CIFS(Common Internet File System)/SMB(Server Message Block) CSI(Container Storage Interface) 드라이버 운영자에게 적용됩니다.

  • FIPS 모드는 지원되지 않습니다.

    FIPS(연방 정보 처리 표준) 모드가 활성화되면 md4 및 md5 사용이 비활성화되어 사용자가 ntlm, ntlmv2 또는 ntlmssp 인증을 사용할 수 없습니다. 또한 md5를 사용하기 때문에 서명을 사용할 수 없습니다. FIPS 모드가 활성화되어 있으면 이러한 방법을 사용하는 모든 CIFS 마운트가 실패합니다.

  • CSI 드라이버는 클러스터 외부 SMB 서버에 연결하기 위해 HTTP 프록시 구성을 지원하지 않습니다.

    CIFS/SMB는 LAN 프로토콜이기 때문에 서브넷으로 라우팅할 수는 있지만 WAN을 통해 확장하도록 설계되지 않았으며 HTTP 프록시 설정을 지원하지 않습니다.

  • CIFS/SMB CSI 드라이버 운영자는 Windows 분산 파일 시스템(DFS)을 지원 하지 않습니다 .
  • Kerberos 인증은 지원되지 않습니다.
  • SMB CSI는 Samba v4.21.2와 Windows Server 2019, Windows Server 2022에서 테스트되었습니다.

6.20.3. CIFS/SMB CSI 드라이버 운영자 설치

CIFS/SMB CSI Driver Operator(Red Hat Operator)는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. 다음 절차에 따라 클러스터에 CIFS/SMB CSI 드라이버 운영자를 설치하고 구성하세요.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.

프로세스

웹 콘솔에서 CIFS/SMB CSI 드라이버 운영자를 설치하려면:

  1. 웹 콘솔에 로그인합니다.
  2. CIFS/SMB CSI Operator를 설치하세요.

    1. OperatorsOperatorHub를 클릭합니다.
    2. 필터 상자에 CIFS/SMB CSI를 입력하여 CIFS/SMB CSI 연산자를 찾습니다.
    3. CIFS/SMB CSI 드라이버 운영자 버튼을 클릭합니다.
    4. CIFS/SMB CSI 드라이버 운영자 페이지에서 설치를 클릭합니다.
    5. Operator 설치 페이지에서 다음을 확인합니다.

      • 클러스터의 모든 네임스페이스(기본값)가 선택됩니다.
      • 설치된 네임스페이스openshift-cluster-csi-drivers로 설정됩니다.
    6. 설치를 클릭합니다.

      설치가 완료되면 CIFS/SMB CSI Operator가 웹 콘솔의 설치된 운영자 섹션에 나열됩니다.

6.20.4. CIFS/SMB CSI 드라이버 설치

CIFS/SMB 컨테이너 스토리지 인터페이스(CSI) 드라이버 오퍼레이터를 설치한 후 CIFS/SMB CSI 드라이버를 설치합니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • CIFS/SMB CSI 드라이버 운영자가 설치되었습니다.

프로세스

  1. 관리CustomResourceDefinitionsClusterCSIDriver를 클릭합니다.
  2. Instances 탭에서 Create ClusterCSIDriver를 클릭합니다.
  3. 다음 YAML 파일을 사용합니다.

    apiVersion: operator.openshift.io/v1
    kind: ClusterCSIDriver
    metadata:
        name: smb.csi.k8s.io
    spec:
      managementState: Managed
    Copy to Clipboard Toggle word wrap
  4. 생성을 클릭합니다.
  5. 다음 조건이 "참" 상태로 변경될 때까지 기다리세요.

    • SambaDriverControllerServiceControllerAvailable
    • SambaDriverNodeServiceControllerAvailable

6.20.5. 동적 프로비저닝

CIFS(Common Internet File System) 방언/SMB(Server Message Block) 프로토콜 볼륨의 동적 프로비저닝을 위한 스토리지 클래스를 생성할 수 있습니다. 볼륨을 프로비저닝하면 스토리지 클래스에 정의된 소스 아래에 영구 볼륨(PV) 이름이 있는 하위 디렉토리가 생성됩니다.

사전 요구 사항

  • CIFS/SMB CSI 드라이버 운영자와 드라이버가 설치되었습니다.
  • 실행 중인 OpenShift Container Platform 클러스터에 로그인했습니다.
  • SMB 서버를 설치했고 서버에 대한 다음 정보를 알고 있습니다.

    • 호스트 이름
    • 공유 이름
    • 사용자 이름과 비밀번호

프로세스

동적 프로비저닝을 설정하려면:

  1. 다음 명령과 예제 YAML 파일을 사용하여 Samba 서버에 액세스하기 위한 비밀을 만듭니다.

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

    비밀 예제 YAML 파일

    apiVersion: v1
    kind: Secret
    metadata:
      name: smbcreds 
    1
    
      namespace: samba-server 
    2
    
    stringData:
      username: <username> 
    3
    
      password: <password> 
    4
    Copy to Clipboard Toggle word wrap

    1
    Samba 서버의 비밀 이름입니다.
    2
    Samba 서버의 Secret에 대한 네임스페이스입니다.
    3
    Samba 서버의 비밀에 대한 사용자 이름입니다.
    4
    Samba 서버의 Secret에 대한 비밀번호입니다.
  2. 다음 예제 YAML 파일로 다음 명령을 실행하여 스토리지 클래스를 생성합니다.

    $ oc create -f <sc_file_name>.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    저장 클래스 YAML 파일의 이름입니다.

    저장 클래스 예제 YAML 파일

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <sc_name> 
    1
    
    provisioner: smb.csi.k8s.io
    parameters:
      source: //<hostname>/<shares> 
    2
    
      csi.storage.k8s.io/provisioner-secret-name: smbcreds 
    3
    
      csi.storage.k8s.io/provisioner-secret-namespace: samba-server 
    4
    
      csi.storage.k8s.io/node-stage-secret-name: smbcreds 
    5
    
      csi.storage.k8s.io/node-stage-secret-namespace: samba-server 
    6
    
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    mountOptions:
      - dir_mode=0777
      - file_mode=0777
      - uid=1001
      - gid=1001
    Copy to Clipboard Toggle word wrap

    1
    저장 클래스의 이름입니다.
    2
    Samba 서버는 클러스터에서 접근할 수 있는 어딘가에 설치되어 있어야 하며, <`hostname>`은 Samba 서버의 호스트 이름이고 <shares>는 내보낸 공유 중에서 서버가 구성한 경로입니다.
    3 5
    이전 단계에서 설정한 Samba 서버의 비밀 이름입니다. csi.storage.k8s.io/provisioner-secret 이 제공되면 source 아래에 PV 이름으로 하위 디렉토리가 생성됩니다.
    4 6
    이전 단계에서 설정한 Samba 서버의 비밀을 위한 네임스페이스입니다.
  3. PVC 만들기:

    1. 다음 예제 YAML 파일을 사용하여 다음 명령을 실행하여 PVC를 만듭니다.

      $ oc create -f <pv_file_name>.yaml 
      1
      Copy to Clipboard Toggle word wrap
      1
      PVC YAML 파일의 이름입니다.

      PVC YAML 파일 예시

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: <pvc_name> 
      1
      
      spec:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: <storage_amount> 
      2
      
        storageClassName: <sc_name> 
      3
      Copy to Clipboard Toggle word wrap

      1
      PVC의 이름.
      2
      저장 요청 수량.
      3
      이전 단계에서 만든 CIFS/SMB 스토리지 클래스의 이름입니다.
    2. 다음 명령을 실행하여 PVC가 생성되었고 "바인딩" 상태인지 확인하세요.

      $ oc describe pvc <pvc_name> 
      1
      Copy to Clipboard Toggle word wrap
      1
      이전 단계에서 만든 PVC의 이름입니다.

      출력 예

      Name:          pvc-test
      Namespace:     default
      StorageClass:  samba
      Status:        Bound 
      1
      
      ...
      Copy to Clipboard Toggle word wrap

      1
      PVC는 Bound 상태입니다.

6.20.6. 정적 프로비저닝

정적 프로비저닝을 사용하면 기존 SMB(Server Message Block) 프로토콜 공유를 사용하기 위해 영구 볼륨(PV)과 영구 볼륨 클레임(PVC)을 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • CIFS/SMB CSI 드라이버 운영자와 드라이버가 설치되었습니다.
  • SMB 서버를 설치했고 서버에 대한 다음 정보를 알고 있습니다.

    • 호스트 이름
    • 공유 이름
    • 사용자 이름과 비밀번호

프로세스

정적 프로비저닝을 설정하려면:

  1. 다음 명령과 예제 YAML 파일을 사용하여 Samba 서버에 액세스하기 위한 비밀을 만듭니다.

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

    비밀 예제 YAML 파일

    apiVersion: v1
    kind: Secret
    metadata:
      name: smbcreds 
    1
    
      namespace: samba-server 
    2
    
    stringData:
      username: <username> 
    3
    
      password: <password> 
    4
    Copy to Clipboard Toggle word wrap

    1
    Samba 서버의 비밀 이름입니다.
    2
    Samba 서버의 Secret에 대한 네임스페이스입니다.
    3
    Samba 서버의 비밀에 대한 사용자 이름입니다.
    4
    Samba 서버의 Secret에 대한 비밀번호입니다.
  2. 다음 예제 YAML 파일을 사용하여 다음 명령을 실행하여 PV를 만듭니다.

    $ oc create -f <pv_file_name>.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    PV YAML 파일의 이름입니다.

    PV YAML 파일 예시

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        pv.kubernetes.io/provisioned-by: smb.csi.k8s.io
      name: <pv_name> 
    1
    
    spec:
      capacity:
        storage: 100Gi
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      storageClassName: ""
      mountOptions:
        - dir_mode=0777
        - file_mode=0777
      csi:
        driver: smb.csi.k8s.io
        volumeHandle: smb-server.default.svc.cluster.local/share#
    2
    
        volumeAttributes:
          source: //<hostname>/<shares> 
    3
    
        nodeStageSecretRef:
          name: <secret_name_shares> 
    4
    
          namespace: <namespace> 
    5
    Copy to Clipboard Toggle word wrap

    1
    PV의 이름입니다.
    2
    volumeHandle 형식: {smb-server-address}#{sub-dir-name}#{share-name}. 이 값이 클러스터의 모든 공유에 대해 고유한지 확인하세요.
    3
    Samba 서버는 클러스터에서 접근할 수 있는 어딘가에 설치되어 있어야 하며, <hostname>은 Samba 서버의 호스트 이름이고 <shares>는 내보낸 공유 중에서 서버가 구성한 경로입니다.
    4
    주식에 대한 비밀의 이름입니다.
    5
    적용 가능한 네임스페이스.
  3. PVC 만들기:

    1. 다음 예제 YAML 파일을 사용하여 다음 명령을 실행하여 PVC를 만듭니다.

      $ oc create -f <pv_file_name>.yaml 
      1
      Copy to Clipboard Toggle word wrap
      1
      PVC YAML 파일의 이름입니다.

      PVC YAML 파일 예시

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: <pvc_name> 
      1
      
      spec:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: <storage_amount> 
      2
      
        storageClassName: ""
        volumeName: <pv_name> 
      3
      Copy to Clipboard Toggle word wrap

      1
      PVC의 이름.
      2
      저장 요청 수량.
      3
      첫 번째 단계의 PV 이름입니다.
    2. 다음 명령을 실행하여 PVC가 생성되었고 "바인딩" 상태인지 확인하세요.

      $ oc describe pvc <pvc_name> 
      1
      Copy to Clipboard Toggle word wrap
      1
      이전 단계에서 만든 PVC의 이름입니다.

      출력 예

      Name:          pvc-test
      Namespace:     default
      StorageClass:
      Status:        Bound 
      1
      
      ...
      Copy to Clipboard Toggle word wrap

      1
      PVC는 Bound 상태입니다.
  4. 다음 예제 YAML 파일을 사용하여 다음 명령을 실행하여 Linux에 배포를 만듭니다.

    참고

    이전 단계에서 만든 PV와 PVC를 사용하는 경우 다음 배포는 필수가 아닙니다. 이는 사용할 수 있는 방법의 예입니다.

    $ oc create -f <deployment_file_name>.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    배포 YAML 파일의 이름입니다.

    배포 YAML 파일의 예

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: nginx
      name: <deployment_name> 
    1
    
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
          name: <deployment_name> 
    2
    
        spec:
          nodeSelector:
            "kubernetes.io/os": linux
          containers:
            - name: <deployment_name> 
    3
    
              image: quay.io/centos/centos:stream8
              command:
                - "/bin/bash"
                - "-c"
                - set -euo pipefail; while true; do echo $(date) >> <mount_path>/outfile; sleep 1; done 
    4
    
              volumeMounts:
                - name: <vol_mount_name> 
    5
    
                  mountPath: <mount_path> 
    6
    
                  readOnly: false
          volumes:
            - name: <vol_mount_name> 
    7
    
              persistentVolumeClaim:
                claimName: <pvc_name> 
    8
    
      strategy:
        rollingUpdate:
          maxSurge: 0
          maxUnavailable: 1
        type: RollingUpdate
    Copy to Clipboard Toggle word wrap

    1 2 3
    배포의 이름입니다.
    4 6
    볼륨 마운트 경로.
    5 7
    볼륨 마운트의 이름입니다.
    8
    이전 단계에서 생성된 PVC의 이름입니다.
  5. 컨테이너에서 df -h 명령을 실행하여 설정을 확인하세요.

    $ oc exec -it <pod_name> -- df -h 
    1
    Copy to Clipboard Toggle word wrap
    1
    Pod의 이름입니다.

    출력 예

    Filesystem            Size  Used Avail Use% Mounted on
    ...
    /dev/sda1              97G   21G   77G  22% /etc/hosts
    //20.43.191.64/share   97G   21G   77G  22% /mnt/smb
    ...
    Copy to Clipboard Toggle word wrap

    이 예에서는 /mnt/smb 디렉토리가 CIFS(Common Internet File System) 파일 시스템으로 마운트되어 있습니다.

6.21. VMware vSphere CSI Driver Operator

6.21.1. 개요

OpenShift Container Platform은 VMDK(Virtual Machine Disk) 볼륨용 CSI(Container Storage Interface) VMware vSphere 드라이버를 사용하여 영구 볼륨(PV)을 프로비저닝할 수 있습니다.

CSI 운영자와 드라이버를 사용할 때는 영구 저장소CSI 볼륨 구성 에 익숙해야 합니다.

vSphere 스토리지 자산에 마운트되는 CSI 프로비저닝 영구 볼륨(PV)을 생성하기 위해 OpenShift Container Platform은 기본적으로 openshift-cluster-csi-drivers 네임스페이스에 vSphere CSI Driver Operator와 vSphere CSI 드라이버를 설치합니다.

  • vSphere CSI 드라이버 운영자 : 운영자는 지속적 볼륨 클레임(PVC)을 생성하는 데 사용할 수 있는 thin-csi 라는 스토리지 클래스를 제공합니다. vSphere CSI Driver Operator는 필요에 따라 스토리지 볼륨을 생성할 수 있어 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없어 동적 볼륨 프로비저닝을 지원합니다. 원하는 경우 이 기본 저장소 클래스를 비활성화할 수 있습니다( 기본 저장소 클래스 관리 참조).
  • vSphere CSI 드라이버: 이 드라이버를 사용하면 vSphere PV를 생성 및 마운트할 수 있습니다. OpenShift Container Platform 4.19에서 드라이버 버전은 3.3.1입니다. vSphere CSI 드라이버는 XFS 및 Ext4를 포함하여 기본 Red Hat Core 운영 체제 릴리스에서 지원하는 모든 파일 시스템을 지원합니다. 지원되는 파일 시스템에 대한 자세한 내용은 사용 가능한 파일 시스템 개요를 참조하세요.
참고

새로 설치하는 경우 OpenShift Container Platform 4.13 이상에서는 vSphere 인트리 볼륨 플러그인을 해당 CSI 드라이버로 자동 마이그레이션합니다. OpenShift Container Platform 4.15 이상으로 업데이트하면 자동 마이그레이션도 제공됩니다. 업데이트 및 마이그레이션에 대한 자세한 내용은 CSI 자동 마이그레이션을 참조하세요.

CSI 자동 마이그레이션이 원활해야 합니다. 마이그레이션은 영구 볼륨, 영구 볼륨 클레임 및 스토리지 클래스와 같은 기존 API 오브젝트를 사용하는 방법을 변경하지 않습니다.

6.21.2. CSI 정보

스토리지 벤더는 일반적으로 Kubernetes의 일부로 스토리지 드라이버를 제공합니다. 컨테이너 스토리지 인터페이스(CSI)를 구현하면 타사 공급업체는 Kubernetes의 핵심 코드를 변경하지 않고도 표준 인터페이스를 사용하여 스토리지 플러그인을 제공할 수 있습니다.

CSI 운영자는 OpenShift Container Platform 사용자에게 트리 내 볼륨 플러그인으로는 불가능한 볼륨 스냅샷과 같은 저장 옵션을 제공합니다.

6.21.3. vSphere CSI 제한 사항

다음 제한 사항은 vSphere Container Storage Interface(CSI) 드라이버 운영자에게 적용됩니다.

  • vSphere CSI 드라이버는 동적 및 정적 프로비저닝을 지원합니다. 그러나 PV 사양에서 정적 프로비저닝을 사용하는 경우 csi.volumeAttributes 에서 storage.kubernetes.io/csiProvisionerIdentity 키를 사용하지 마세요. 이 키는 동적으로 프로비저닝된 PV를 나타냅니다.
  • vSphere 클라이언트 인터페이스를 사용하여 데이터 저장소 간에 영구 컨테이너 볼륨을 마이그레이션하는 것은 OpenShift Container Platform에서 지원되지 않습니다.

6.21.4. vSphere 스토리지 정책

vSphere CSI Driver Operator 스토리지 클래스는 vSphere의 스토리지 정책을 사용합니다. OpenShift Container Platform은 클라우드 구성에 구성된 데이터 저장소를 대상으로 하는 스토리지 정책을 자동으로 생성합니다.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: thin-csi
provisioner: csi.vsphere.vmware.com
parameters:
  StoragePolicyName: "$openshift-storage-policy-xxxx"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: false
reclaimPolicy: Delete
Copy to Clipboard Toggle word wrap

6.21.5. ReadWriteMany vSphere 볼륨 지원

기본 vSphere 환경이 vSAN 파일 서비스를 지원하는 경우 OpenShift Container Platform에서 설치한 vSphere Container Storage Interface(CSI) Driver Operator는 RWX(ReadWriteMany) 볼륨의 프로비저닝을 지원합니다. vSAN 파일 서비스가 구성되지 않은 경우 사용 가능한 액세스 모드는 RWO(ReadWriteOnce)뿐입니다. vSAN 파일 서비스가 구성되어 있지 않고 RWX를 요청하면 볼륨이 생성되지 않고 오류가 기록됩니다.

사용자 환경에서 vSAN 파일 서비스를 구성하는 방법에 대한 자세한 내용은 vSAN 파일 서비스를 참조하세요.

다음과 같은 영구 볼륨 클레임(PVC)을 수행하여 RWX 볼륨을 요청할 수 있습니다.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
     - ReadWriteMany
  storageClassName: thin-csi
Copy to Clipboard Toggle word wrap

RWX 볼륨 유형의 PVC를 요청하면 vSAN 파일 서비스에서 지원하는 영구 볼륨(PV)이 프로비저닝됩니다.

6.21.6. VMware vSphere CSI Driver Operator 요구 사항

vSphere Container Storage Interface(CSI) 드라이버 운영자를 설치하려면 다음 요구 사항을 충족해야 합니다.

  • VMware vSphere 버전: 7.0 업데이트 2 이상 또는 VMware Cloud Foundation 4.3 이상; 8.0 업데이트 1 이상 또는 VMware Cloud Foundation 5.0 이상
  • vCenter 버전: 7.0 업데이트 2 이상 또는 VMware Cloud Foundation 4.3 이상; 8.0 업데이트 1 이상 또는 VMware Cloud Foundation 5.0 이상
  • 하드웨어 버전 15 이상의 가상 머신
  • 클러스터에 타사 vSphere CSI 드라이버가 아직 설치되어 있지 않습니다.

클러스터에 타사 vSphere CSI 드라이버가 있는 경우 OpenShift Container Platform은 이를 덮어쓰지 않습니다. 타사 vSphere CSI 드라이버가 있으면 OpenShift Container Platform을 OpenShift Container Platform 4.13 이상으로 업데이트할 수 없습니다.

참고

VMware vSphere CSI Driver Operator는 설치 매니페스트에서 platform:vsphere 로 배포된 클러스터에서만 지원됩니다.

CSI(Container Storage Interface) 드라이버, vSphere CSI 드라이버 운영자, vSphere 문제 감지 운영자에 대한 사용자 지정 역할을 만들 수 있습니다. 사용자 지정 역할에는 각 vSphere 개체에 최소한의 권한 집합을 할당하는 권한 집합이 포함될 수 있습니다. 즉, CSI 드라이버, vSphere CSI 드라이버 운영자, vSphere 문제 감지 운영자는 이러한 개체와 기본적인 상호 작용을 설정할 수 있습니다.

중요

vCenter에 OpenShift Container Platform 클러스터를 설치하는 작업은 "필요한 vCenter 계정 권한" 섹션에 설명된 대로 전체 권한 목록에 대해 테스트됩니다. 권한의 전체 목록을 준수하면 제한된 권한 집합으로 사용자 지정 역할을 생성할 때 발생할 수 있는 예상치 못하고 지원되지 않는 동작의 가능성을 줄일 수 있습니다.

타사 CSI 드라이버를 제거하려면 타사 vSphere CSI 드라이버 제거를 참조하십시오.

6.21.7. 타사 vSphere CSI 드라이버 운영자 제거

OpenShift Container Platform 4.10 이상에는 Red Hat에서 지원하는 vSphere Container Storage Interface(CSI) Operator Driver의 기본 제공 버전이 포함되어 있습니다. 커뮤니티 또는 다른 공급업체에서 제공하는 vSphere CSI 드라이버를 설치한 경우 OpenShift Container Platform의 다음 주요 버전(예: 4.13 이상)에 대한 업데이트가 클러스터에서 비활성화될 수 있습니다.

OpenShift Container Platform 4.12 이상에서는 클러스터가 완전히 지원되며 4.12.z와 같은 z-stream 릴리스의 업데이트는 차단되지 않지만 OpenShift Container Platform의 다음 주요 버전으로 업데이트하기 전에 타사 vSphere CSI 드라이버를 제거하여 이 상태를 수정해야 합니다. 타사 vSphere CSI 드라이버를 제거해도 연관된 영구 볼륨(PV) 개체를 삭제할 필요가 없으며 데이터 손실도 발생하지 않습니다.

참고

이러한 지침은 완전하지 않을 수 있으므로 공급업체나 커뮤니티 제공업체의 제거 가이드를 참조하여 드라이버와 구성 요소를 제거하세요.

타사 vSphere CSI 드라이버를 제거하려면:

  1. 타사 vSphere CSI 드라이버(VMware vSphere Container Storage Plugin) 배포 및 Daemonset 개체를 삭제합니다.
  2. 타사 vSphere CSI 드라이버와 함께 이전에 설치된 configmap 및 secret 오브젝트를 삭제합니다.
  3. 타사 vSphere CSI 드라이버 CSIDriver 개체를 삭제합니다.

    $ oc delete CSIDriver csi.vsphere.vmware.com
    Copy to Clipboard Toggle word wrap
    csidriver.storage.k8s.io "csi.vsphere.vmware.com" deleted
    Copy to Clipboard Toggle word wrap

OpenShift Container Platform 클러스터에서 타사 vSphere CSI 드라이버를 제거하면 Red Hat의 vSphere CSI Driver Operator 설치가 자동으로 재개되고, OpenShift Container Platform 4.11 이상으로의 업그레이드를 차단할 수 있는 모든 조건이 자동으로 제거됩니다. 기존 vSphere CSI PV 객체가 있는 경우 이제 해당 객체의 수명 주기는 Red Hat의 vSphere CSI Driver Operator에 의해 관리됩니다.

6.21.8. vSphere 영구 디스크 암호화

vSphere 상에서 실행되는 OpenShift Container Platform에서 가상 머신(VM)과 동적으로 프로비저닝된 영구 볼륨(PV)을 암호화할 수 있습니다.

참고

OpenShift Container Platform은 RWX로 암호화된 PV를 지원하지 않습니다. 암호화된 스토리지 정책을 사용하는 스토리지 클래스에서는 RWX PV를 요청할 수 없습니다.

PV를 암호화하려면 먼저 VM을 암호화해야 하며, 이는 설치 중이나 설치 후에 수행할 수 있습니다.

VM 암호화에 대한 자세한 내용은 다음을 참조하세요.

VM을 암호화한 후 vSphere Container Storage Interface(CSI) 드라이버를 사용하여 동적 암호화 볼륨 프로비저닝을 지원하는 스토리지 클래스를 구성할 수 있습니다. 다음 두 가지 방법 중 하나를 사용하여 이를 달성할 수 있습니다.

  • 데이터 저장소 URL : 이 방법은 그다지 유연하지 않으며 단일 데이터 저장소를 사용해야 합니다. 또한 토폴로지 인식 프로비저닝을 지원하지 않습니다.
  • 태그 기반 배치 : 프로비저닝된 볼륨을 암호화하고 태그 기반 배치를 사용하여 특정 데이터 저장소를 대상으로 지정합니다.
6.21.8.1. 데이터 저장소 URL 사용

프로세스

데이터 저장소 URL을 사용하여 암호화하려면:

  1. 암호화를 지원하는 데이터 저장소의 기본 저장 정책 이름을 찾아보세요.

    이는 VM 암호화에 사용된 정책과 동일합니다.

  2. 이 스토리지 정책을 사용하는 스토리지 클래스를 만듭니다.

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
     name: encryption
    provisioner: csi.vsphere.vmware.com
    parameters:
     storagePolicyName: <storage-policy-name> 
    1
    
     datastoreurl: "ds:///vmfs/volumes/vsan:522e875627d-b090c96b526bb79c/"
    Copy to Clipboard Toggle word wrap
    1
    암호화를 지원하는 데이터 저장소의 기본 저장소 정책 이름
6.21.8.2. 태그 기반 배치 사용

프로세스

태그 기반 배치를 사용하여 암호화하려면:

  1. vCenter에서 이 스토리지 클래스에서 사용할 수 있는 데이터 저장소에 태그를 지정하기 위한 범주를 만듭니다. 또한 StoragePod(Datastore 클러스터) , Datastore (데이터 저장소) 및 폴더 가 생성된 카테고리에 대해 Associable Entities로 선택되어 있는지 확인합니다.
  2. vCenter에서 앞서 만든 카테고리를 사용하는 태그를 만듭니다.
  3. 이전에 생성된 태그를 스토리지 클래스에서 사용할 수 있는 각 데이터 저장소에 할당합니다. 데이터 저장소가 OpenShift Container Platform 클러스터에 참여하는 호스트와 공유되는지 확인하세요.
  4. vCenter의 기본 메뉴에서 정책 및 프로필을 클릭합니다.
  5. 정책 및 프로필 페이지의 탐색 창에서 VM 스토리지 정책을 클릭합니다.
  6. 만들기를 클릭하세요.
  7. 저장 정책의 이름을 입력합니다.
  8. 호스트 기반 규칙 사용태그 기반 배치 규칙 사용을 선택합니다.
  9. 다음 탭에서:

    1. 암호화기본 암호화 속성을 선택합니다.
    2. 앞서 생성한 태그 카테고리를 선택하고, 선택된 태그를 선택합니다. 정책이 일치하는 데이터 저장소를 선택하는지 확인하세요.
  10. 저장 정책을 생성합니다.
  11. 스토리지 정책을 사용하는 스토리지 클래스를 만듭니다.

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
     name:  csi-encrypted
    provisioner: csi.vsphere.vmware.com
    reclaimPolicy: Delete
    volumeBindingMode: WaitForFirstConsumer
    parameters:
     storagePolicyName: <storage-policy-name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    암호화를 위해 생성한 저장 정책의 이름

6.21.9. vSphere CSI에 대한 여러 vCenter 지원

고가용성을 위해 공유 스토리지 없이 여러 vSphere vCenter 클러스터에 OpenShift Container Platform을 배포하는 것이 도움이 될 수 있습니다. OpenShift Container Platform v4.17 이상에서 이 기능을 지원합니다.

참고

여러 개의 vCenter는 설치 중에 만 구성할 수 있습니다. 설치 후에는 여러 개의 vCenter를 구성 할 수 없습니다 .

지원되는 vCenter 클러스터의 최대 수는 3개입니다.

6.21.9.1. 설치 중 여러 vCenter 구성

설치 중에 여러 vCenter를 구성하려면:

  • 설치 중에 여러 개의 vSphere 클러스터를 지정합니다. 자세한 내용은 "vSphere에 대한 설치 구성 매개변수"를 참조하세요.

6.21.10. vSphere CSI 토폴로지 개요

OpenShift Container Platform은 다양한 영역과 지역에 vSphere용 OpenShift Container Platform을 배포할 수 있으므로 여러 컴퓨팅 클러스터 및 데이터 센터에 배포할 수 있으므로 단일 장애 지점을 방지할 수 있습니다.

이 작업은 vCenter에서 영역 및 지역 범주를 정의한 다음 이러한 범주를 컴퓨팅 클러스터와 같은 다양한 장애 도메인에 할당하고 이러한 영역 및 지역 범주에 대한 태그를 생성하여 수행됩니다. 적절한 카테고리를 만들고 vCenter 개체에 태그를 지정한 후에는 장애 도메인에서 포드 일정을 담당하는 가상 머신(VM)을 생성하는 추가 머신 세트를 만들 수 있습니다.

다음 예제에서는 하나의 지역과 두 개의 영역을 갖는 두 개의 실패 도메인을 정의합니다.

Expand
표 6.6. 하나의 리전 및 두 개의 영역이 있는 vSphere 스토리지 토폴로지
컴퓨팅 클러스터실패 도메인설명

컴퓨팅 클러스터: ocp1, 데이터 센터: Atlanta

openshift-region: us-east-1(태그), openshift-zone: us-east-1a(태그)

이는 us-east-1a 영역을 가진 us-east-1 지역의 장애 도메인을 정의합니다.

컴퓨터 클러스터: ocp2, 데이터 센터: Atlanta

openshift-region: us-east-1(태그), openshift-zone: us-east-1b(태그)

이는 us-east-1b라는 동일한 지역 내에 다른 장애 도메인을 정의합니다.

6.21.10.1. vSphere CSI 토폴로지 요구 사항

vSphere CSI 토폴로지에 다음 지침이 권장됩니다.

  • 호스트가 아닌 데이터 센터 및 컴퓨팅 클러스터에 토폴로지 태그를 추가하는 것이 좋습니다.

    vSphere -problem-detectoropenshift-region 또는 openshift-zone 태그가 데이터 센터 또는 컴퓨팅 클러스터 수준에서 정의되지 않은 경우 경고를 제공합니다. 각 토폴로지 태그(openshift-region 또는 openshift-zone)가 계층 구조에서 한 번만 발생해야 합니다.

    참고

    이 권장 사항을 무시하면 CSI 드라이버에서 로그 경고만 발생하고 호스트와 같이 계층 구조에서 더 낮은 중복 태그는 무시됩니다. VMware에서는 이를 잘못된 구성으로 간주하므로 문제를 방지하려면 이 구성을 사용해서는 안 됩니다.

  • 토폴로지 인식 환경에서 볼륨 프로비저닝 요청은 주어진 토폴로지 세그먼트 아래의 모든 호스트가 액세스할 수 있는 데이터 저장소에 볼륨을 생성하려고 시도합니다. 여기에는 Kubernetes 노드 VM이 실행되지 않는 호스트가 포함됩니다. 예를 들어 vSphere Container Storage 플러그인 드라이버가 데이터 센터 dc-1 에 적용된 zone-a 에서 볼륨을 프로비저닝하라는 요청을 수신하는 경우 dc-1 아래의 모든 호스트에서 볼륨 프로비저닝을 위해 선택한 데이터 저장소에 액세스할 수 있어야 합니다. 호스트에는 dc-1 아래에 직접 있는 것과 dc-1 내부의 클러스터의 일부인 호스트가 포함됩니다.
  • 추가 권장 사항을 보려면 토폴로지를 사용한 배포를 위한 VMware 지침 및 모범 사례 섹션을 읽어보세요.
6.21.10.2. 설치 중 vSphere 스토리지 토폴로지 생성
6.21.10.2.1. 프로세스
  • 설치 중에 토폴로지를 지정하세요. VMware vCenter에 대한 지역 및 영역 구성 섹션을 참조하세요.

추가 작업은 필요하지 않으며 OpenShift Container Platform에서 생성된 기본 스토리지 클래스는 토폴로지를 인식하고 다양한 장애 도메인에서 볼륨 프로비저닝을 허용해야 합니다.

6.21.10.3. vSphere 스토리지 토폴로지 후 설치 생성
6.21.10.3.1. 프로세스
  1. VMware vCenter vSphere 클라이언트 GUI에서 적절한 영역 및 지역 카테고리와 태그를 정의합니다.

    vSphere에서는 임의의 이름으로 범주를 생성할 수 있지만, OpenShift Container Platform에서는 토폴로지 범주를 정의할 때 openshift-regionopenshift-zone 이름을 사용하는 것을 강력히 권장합니다.

    vSphere 카테고리 및 태그에 대한 자세한 내용은 VMware vSphere 설명서를 참조하세요.

  2. OpenShift Container Platform에서 장애 도메인을 생성합니다. vSphere에서 클러스터의 여러 리전 및 영역 지정 섹션을 참조하십시오.
  3. 장애 도메인에서 데이터 저장소에 할당할 태그를 생성합니다.

    OpenShift Container Platform이 두 개 이상의 장애 도메인을 확장하면 데이터 저장소가 해당 장애 도메인에서 공유되지 않을 수 있습니다. 여기서 PV(영구 볼륨)의 토폴로지 인식 프로비저닝이 유용합니다.

    1. vCenter에서 데이터 저장소 태그를 지정하는 카테고리를 생성합니다. 예를 들면 openshift-zonal-datastore-cat 입니다. 카테고리가 OpenShift Container Platform 클러스터에 참여하는 데이터 저장소에 태그를 지정하는 데 고유하게 사용되는 경우 다른 카테고리 이름을 사용할 수 있습니다. 또한 StoragePod(Datastore 클러스터) , Datastore (데이터 저장소) 및 폴더 가 생성된 카테고리에 대해 Associable Entities로 선택되어 있는지 확인합니다.
    2. vCenter에서 이전에 생성된 카테고리를 사용하는 태그를 생성합니다. 이 예에서는 태그 이름 openshift-zonal-datastore 를 사용합니다.
    3. 이전에 생성된 태그(이 예에서는 openshift-zonal-datastore)를 동적 프로비저닝으로 간주하는 실패 도메인의 각 데이터 저장소에 할당합니다.

      참고

      데이터 저장소 카테고리 및 태그에 원하는 모든 이름을 사용할 수 있습니다. 이 예제에서 사용되는 이름은 권장 사항으로 제공됩니다. OpenShift Container Platform 클러스터의 모든 호스트와 공유되는 데이터 저장소만 고유하게 정의하는 태그 및 카테고리가 있는지 확인합니다.

  4. 필요에 따라 각 실패 도메인의 태그 기반 데이터 저장소를 대상으로 하는 스토리지 정책을 생성합니다.

    1. vCenter의 주 메뉴에서 정책 및 프로필을 클릭합니다.
    2. 정책 및 프로필 페이지의 탐색 창에서 VM Storage Policies 를 클릭합니다.
    3. 생성을 클릭합니다.
    4. 스토리지 정책의 이름을 입력합니다.
    5. 규칙의 경우 태그 배치 규칙을 선택하고 원하는 데이터 저장소를 대상으로 하는 태그 및 카테고리(이 예에서는 openshift-zonal-datastore 태그)를 선택합니다.

      데이터 저장소는 스토리지 호환성 테이블에 나열됩니다.

  5. 새 영역 스토리지 정책을 사용하는 새 스토리지 클래스를 생성합니다.

    1. 스토리지 > StorageClass 를 클릭합니다.
    2. StorageClasses 페이지에서 StorageClass 만들기 를 클릭합니다.
    3. 이름에 새 스토리지 클래스의 이름을 입력합니다.
    4. Provisioner 에서 csi.vsphere.vmware.com 을 선택합니다.
    5. 추가 매개변수 에서 StoragePolicyName 매개변수의 경우 Value 를 이전에 생성한 새 영역 스토리지 정책의 이름으로 설정합니다.
    6. 생성을 클릭합니다.

      출력 예

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: zoned-sc 
      1
      
      provisioner: csi.vsphere.vmware.com
      parameters:
        StoragePolicyName: zoned-storage-policy 
      2
      
      reclaimPolicy: Delete
      allowVolumeExpansion: true
      volumeBindingMode: WaitForFirstConsumer
      Copy to Clipboard Toggle word wrap

      1
      새 토폴로지 인식 스토리지 클래스 이름입니다.
      2
      영역화된 스토리지 정책을 지정합니다.
      참고

      이전 YAML 파일을 편집하고 oc create -f $FILE 명령을 실행하여 스토리지 클래스를 생성할 수도 있습니다.

6.21.10.4. 인프라 토폴로지 없이 vSphere 스토리지 토폴로지 생성
참고

OpenShift Container Platform은 토폴로지 인식 설정에서 실패 도메인을 지정하는 데 인프라 오브젝트를 사용하는 것이 좋습니다. 인프라 오브젝트에 실패 도메인을 지정하고 ClusterCSIDriver 오브젝트에 topology-categories를 지정하는 것은 지원되지 않는 작업입니다.

6.21.10.4.1. 프로세스
  1. VMware vCenter vSphere 클라이언트 GUI에서 적절한 영역 및 지역 분류 및 태그를 정의합니다.

    vSphere를 사용하면 임의의 이름으로 카테고리를 생성할 수 있지만 OpenShift Container Platform은 토폴로지를 정의하는 데 openshift-regionopenshift-zone 이름을 사용하는 것이 좋습니다.

    vSphere 카테고리 및 태그에 대한 자세한 내용은 VMware vSphere 설명서를 참조하십시오.

  2. CSI(컨테이너 스토리지 인터페이스) 드라이버가 이 토폴로지를 감지할 수 있도록 하려면 clusterCSIDriver 오브젝트 YAML 파일 driverConfig 섹션을 편집합니다.

    • 이전에 생성한 openshift-zoneopenshift-region 카테고리를 지정합니다.
    • driverTypevSphere 로 설정합니다.

      ~ $ oc edit clustercsidriver csi.vsphere.vmware.com -o yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      apiVersion: operator.openshift.io/v1
      kind: ClusterCSIDriver
      metadata:
        name: csi.vsphere.vmware.com
      spec:
        logLevel: Normal
        managementState: Managed
        observedConfig: null
        operatorLogLevel: Normal
        unsupportedConfigOverrides: null
        driverConfig:
          driverType: vSphere 
      1
      
            vSphere:
              topologyCategories: 
      2
      
              - openshift-zone
              - openshift-region
      Copy to Clipboard Toggle word wrap

      1
      driverTypevSphere 로 설정되어 있는지 확인합니다.
      2
      vCenter에서 이전에 생성된 OpenShift -zoneopenshift-region 카테고리입니다.
  3. 다음 명령을 실행하여 CSINode 오브젝트에 토폴로지 키가 있는지 확인합니다.

    ~ $ oc get csinode
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME DRIVERS AGE
    co8-4s88d-infra-2m5vd 1 27m
    co8-4s88d-master-0 1 70m
    co8-4s88d-master-1 1 70m
    co8-4s88d-master-2 1 70m
    co8-4s88d-worker-j2hmg 1 47m
    co8-4s88d-worker-mbb46 1 47m
    co8-4s88d-worker-zlk7d 1 47m
    Copy to Clipboard Toggle word wrap

    ~ $ oc get csinode co8-4s88d-worker-j2hmg -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    spec:
      drivers:
      - allocatable:
          count: 59
      name: csi-vsphere.vmware.com
      nodeID: co8-4s88d-worker-j2hmg
      topologyKeys: 
    1
    
      - topology.csi.vmware.com/openshift-zone
      - topology.csi.vmware.com/openshift-region
    Copy to Clipboard Toggle word wrap

    1
    vSphere openshift-zoneopenshift-region catagories의 토폴로지 키입니다.
    참고

    CSINode 오브젝트는 업데이트된 토폴로지 정보를 수신하는 데 약간의 시간이 걸릴 수 있습니다. 드라이버가 업데이트되면 CSINode 오브젝트에 토폴로지 키가 있어야 합니다.

  4. 장애 도메인에서 데이터 저장소에 할당할 태그를 생성합니다.

    OpenShift Container Platform이 두 개 이상의 장애 도메인을 확장하면 데이터 저장소가 해당 장애 도메인에서 공유되지 않을 수 있습니다. 여기서 PV(영구 볼륨)의 토폴로지 인식 프로비저닝이 유용합니다.

    1. vCenter에서 데이터 저장소 태그를 지정하는 카테고리를 생성합니다. 예를 들면 openshift-zonal-datastore-cat 입니다. 카테고리가 OpenShift Container Platform 클러스터에 참여하는 데이터 저장소에 태그를 지정하는 데 고유하게 사용되는 경우 다른 카테고리 이름을 사용할 수 있습니다. 또한 StoragePod(Datastore 클러스터) , Datastore (데이터 저장소) 및 폴더 가 생성된 카테고리에 대해 Associable Entities로 선택되어 있는지 확인합니다.
    2. vCenter에서 이전에 생성된 카테고리를 사용하는 태그를 생성합니다. 이 예에서는 태그 이름 openshift-zonal-datastore 를 사용합니다.
    3. 이전에 생성된 태그(이 예에서는 openshift-zonal-datastore)를 동적 프로비저닝으로 간주하는 실패 도메인의 각 데이터 저장소에 할당합니다.

      참고

      카테고리 및 태그에 대해 원하는 모든 이름을 사용할 수 있습니다. 이 예제에서 사용되는 이름은 권장 사항으로 제공됩니다. OpenShift Container Platform 클러스터의 모든 호스트와 공유되는 데이터 저장소만 고유하게 정의하는 태그 및 카테고리가 있는지 확인합니다.

  5. 각 실패 도메인의 태그 기반 데이터 저장소를 대상으로 하는 스토리지 정책을 생성합니다.

    1. vCenter의 주 메뉴에서 정책 및 프로필을 클릭합니다.
    2. 정책 및 프로필 페이지의 탐색 창에서 VM Storage Policies 를 클릭합니다.
    3. 생성을 클릭합니다.
    4. 스토리지 정책의 이름을 입력합니다.
    5. 규칙의 경우 태그 배치 규칙을 선택하고 원하는 데이터 저장소를 대상으로 하는 태그 및 카테고리(이 예에서는 openshift-zonal-datastore 태그)를 선택합니다.

      데이터 저장소는 스토리지 호환성 테이블에 나열됩니다.

  6. 새 영역 스토리지 정책을 사용하는 새 스토리지 클래스를 생성합니다.

    1. 스토리지 > StorageClass 를 클릭합니다.
    2. StorageClasses 페이지에서 StorageClass 만들기 를 클릭합니다.
    3. 이름에 새 스토리지 클래스의 이름을 입력합니다.
    4. Provisioner 에서 csi.vsphere.vmware.com 을 선택합니다.
    5. 추가 매개변수 에서 StoragePolicyName 매개변수의 경우 Value 를 이전에 생성한 새 영역 스토리지 정책의 이름으로 설정합니다.
    6. 생성을 클릭합니다.

      출력 예

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: zoned-sc 
      1
      
      provisioner: csi.vsphere.vmware.com
      parameters:
        StoragePolicyName: zoned-storage-policy 
      2
      
      reclaimPolicy: Delete
      allowVolumeExpansion: true
      volumeBindingMode: WaitForFirstConsumer
      Copy to Clipboard Toggle word wrap

      1
      새로운 토폴로지 인식 스토리지 클래스 이름입니다.
      2
      구역화된 저장 정책을 지정합니다.
      참고

      이전 YAML 파일을 편집하고 oc create -f $FILE 명령을 실행하여 스토리지 클래스를 만들 수도 있습니다.

6.21.10.5. 결과

토폴로지 인식 스토리지 클래스에서 영구 볼륨 클레임(PVC)과 PV를 생성하는 것은 실제로 영역별이며, 포드가 예약된 방식에 따라 해당 영역의 데이터 저장소를 사용해야 합니다.

$ oc get pv <pv_name> -o yaml
Copy to Clipboard Toggle word wrap

출력 예

...
nodeAffinity:
  required:
    nodeSelectorTerms:
    - matchExpressions:
      - key: topology.csi.vmware.com/openshift-zone 
1

        operator: In
        values:
        - <openshift_zone>
      - key: topology.csi.vmware.com/openshift-region 
2

        operator: In
        values:
        - <openshift_region>
...
peristentVolumeclaimPolicy: Delete
storageClassName: <zoned_storage_class_name> 
3

volumeMode: Filesystem
...
Copy to Clipboard Toggle word wrap

1 2
PV에는 구역화된 키가 있습니다.
3
PV는 구역별 저장 클래스를 사용합니다.

6.21.11. vSphere의 최대 스냅샷 수 변경

vSphere Container Storage Interface(CSI)에서 볼륨당 스냅샷의 기본 최대 개수는 3개입니다. 볼륨당 최대 32개까지 변경할 수 있습니다.

하지만 스냅샷 최대값을 늘리면 성능 저하가 발생하므로 더 나은 성능을 위해 볼륨당 스냅샷을 2~3개만 사용하세요.

VMware 스냅샷 성능에 대한 자세한 권장 사항은 추가 리소스를 참조하세요.

사전 요구 사항

  • 관리자 권한으로 클러스터에 접근합니다.

프로세스

  1. 다음 명령을 실행하여 현재 비밀번호를 확인하세요.

    $ oc -n openshift-cluster-csi-drivers get secret/vsphere-csi-config-secret -o jsonpath='{.data.cloud\.conf}' | base64 -d
    Copy to Clipboard Toggle word wrap

    출력 예

    # Labels with topology values are added dynamically via operator
    [Global]
    cluster-id = vsphere-01-cwv8p
    
    # Populate VCenters (multi) after here
    [VirtualCenter "vcenter.openshift.com"]
    insecure-flag           = true
    datacenters             = DEVQEdatacenter
    password                = "xxxxxxxx"
    user                    = "xxxxxxxx@devcluster.openshift.com"
    migration-datastore-url = ds:///vmfs/volumes/vsan:52c842f232751e0d-3253aadeac21ca82/
    Copy to Clipboard Toggle word wrap

    이 예에서는 스냅샷의 글로벌 최대 수가 구성되지 않았으므로 기본값 3이 적용됩니다.

  2. 다음 명령을 실행하여 스냅샷 제한을 변경하세요.

    • 글로벌 스냅샷 제한 설정:

      $ oc patch clustercsidriver/csi.vsphere.vmware.com --type=merge -p '{"spec":{"driverConfig":{"vSphere":{"globalMaxSnapshotsPerBlockVolume": 10}}}}'
      
      clustercsidriver.operator.openshift.io/csi.vsphere.vmware.com patched
      Copy to Clipboard Toggle word wrap

      이 예에서 글로벌 제한이 10(globalMaxSnapshotsPerBlockVolume 으로 설정)으로 변경됩니다.

    • 가상 볼륨 스냅샷 제한 설정:

      이 매개변수는 가상 볼륨 데이터 저장소에만 제한을 설정합니다. 가상 볼륨의 최대 스냅샷 한도는 설정된 경우 글로벌 제약 조건을 무시하지만, 설정되지 않은 경우 기본적으로 글로벌 한도가 적용됩니다.

      $ oc patch clustercsidriver/csi.vsphere.vmware.com --type=merge -p '{"spec":{"driverConfig":{"vSphere":{"granularMaxSnapshotsPerBlockVolumeInVVOL": 5}}}}'
      clustercsidriver.operator.openshift.io/csi.vsphere.vmware.com patched
      Copy to Clipboard Toggle word wrap

      이 예에서 가상 볼륨 제한은 5로 변경됩니다( granularMaxSnapshotsPerBlockVolumeInVVOL은 5로 설정됨).

    • vSAN 스냅샷 제한 설정:

      이 매개변수는 vSAN 데이터 저장소에만 한도를 설정합니다. vSAN 최대 스냅샷 한도는 설정된 경우 글로벌 제약 조건을 무시하지만, 설정되지 않은 경우 기본적으로 글로벌 한도가 적용됩니다. vSAN ESA 설정에서 최대값을 32로 설정할 수 있습니다.

      $ oc patch clustercsidriver/csi.vsphere.vmware.com --type=merge -p '{"spec":{"driverConfig":{"vSphere":{"granularMaxSnapshotsPerBlockVolumeInVSAN": 7}}}}'
      clustercsidriver.operator.openshift.io/csi.vsphere.vmware.com patched
      Copy to Clipboard Toggle word wrap

      이 예에서 vSAN 제한은 7로 변경됩니다( granularMaxSnapshotsPerBlockVolumeInVSAN 은 7로 설정됨).

검증

  • 다음 명령을 실행하여 변경 사항이 구성 맵에 반영되었는지 확인하세요.

    $ oc -n openshift-cluster-csi-drivers get secret/vsphere-csi-config-secret -o jsonpath='{.data.cloud\.conf}' | base64 -d
    Copy to Clipboard Toggle word wrap

    출력 예

    # Labels with topology values are added dynamically via operator
    [Global]
    cluster-id = vsphere-01-cwv8p
    
    # Populate VCenters (multi) after here
    [VirtualCenter "vcenter.openshift.com"]
    insecure-flag           = true
    datacenters             = DEVQEdatacenter
    password                = "xxxxxxxx"
    user                    = "xxxxxxxx@devcluster.openshift.com"
    migration-datastore-url = ds:///vmfs/volumes/vsan:52c842f232751e0d-3253aadeac21ca82/
    
    [Snapshot]
    global-max-snapshots-per-block-volume = 10 
    1
    Copy to Clipboard Toggle word wrap

    1
    global-max-snapshots-per-block-volume이 이제 10으로 설정되었습니다.

6.21.12. vSphere용 데이터스토어 간 CNS 볼륨 마이그레이션

현재 데이터스토어의 공간이 부족하거나 성능이 더 뛰어난 데이터스토어로 이동하려는 경우 VMware vSphere Cloud Native Storage(CNS) 볼륨을 데이터스토어 간에 마이그레이션할 수 있습니다. 이는 첨부된 볼륨과 분리된 볼륨 모두에 적용됩니다.

제한

  • VMware vSphere 8.0.2 이상 또는 vSphere 7.0 업데이트 3o 이상이 필요합니다.
  • 한 번에 한 개의 볼륨만 마이그레이션할 수 있습니다.
  • RWX 볼륨은 지원되지 않습니다.
  • CNS 볼륨은 OpenShift Container Platform 클러스터를 구성하는 모든 호스트와 공유되는 데이터 저장소로만 마이그레이션해야 합니다.
  • 서로 다른 데이터 센터의 서로 다른 데이터 저장소 간에 볼륨을 마이그레이션하는 것은 지원되지 않습니다.

데이터스토어 간에 CNS 볼륨을 마이그레이션하는 방법에 대한 자세한 내용은 해당되는 경우 vSphere v8.0 또는 vSphere v7.0 에 대한 설명서를 참조하세요.

6.21.13. vSphere에서 스토리지 비활성화 및 활성화

클러스터 관리자는 2일차 작업으로 VMware vSphere Container Storage Interface(CSI) 드라이버를 비활성화하여 vSphere CSI 드라이버가 vSphere 설정과 상호 작용하지 않도록 할 수 있습니다.

6.21.13.1. vSphere에서 스토리지 비활성화 및 활성화의 결과

다음 표에서는 vSphere에서 스토리지를 비활성화하고 활성화하는 결과에 대해 설명합니다.

Expand
표 6.7. vSphere에서 스토리지 비활성화/활성화의 결과
비활성화활성화
  • vSphere CSI Driver Operator는 CSI 드라이버를 제거합니다.
  • 스토리지 컨테이너 오케스트레이션(CO)이 건강해야 합니다.
  • vSphere 문제 감지기는 계속 실행되지만 경고나 이벤트를 발생시키지 않으며 확인 빈도도 낮습니다(24시간에 한 번).
  • 기존의 모든 영구 볼륨(PV), 영구 볼륨 클레임(PVC) 및 vSphere 스토리지 정책은 변경되지 않습니다.

    • vSphere PV는 새로운 Pod에서 사용할 수 없습니다.
    • vSphere PV는 기존 포드의 기존 노드에 영구적으로 마운트되어 연결되어 있습니다. 이러한 포드는 삭제 후에도 무기한 종료 상태로 남아 있습니다.
  • 저장소 클래스가 제거되었습니다

* vSphere CSI Driver Operator가 CSI 드라이버를 다시 설치합니다.

* 필요한 경우 vSphere CSI Driver Operator가 vSphere 스토리지 정책을 생성합니다.

6.21.13.2. vSphere에서 스토리지 비활성화 및 활성화
중요

이 절차를 실행하기 전에 앞의 "vSphere에서 스토리지 비활성화 및 활성화의 결과" 표와 사용자 환경에 미칠 수 있는 잠재적 영향을 주의 깊게 검토하세요.

프로세스

vSphere에서 스토리지를 비활성화하거나 활성화하려면:

  1. 관리 > CustomResourceDefinitions를 클릭합니다.
  2. CustomResourceDefinitions 페이지의 이름 드롭다운 상자 옆에 "clustercsidriver"를 입력합니다.
  3. CRD ClusterCSIDriver를 클릭합니다.
  4. 인스턴스 탭을 클릭합니다.
  5. csi.vsphere.vmware.com을 클릭합니다.
  6. YAML 탭을 클릭합니다.
  7. spec.managementState 의 경우 값을 Removed 또는 Managed 로 변경합니다.

    • 제거됨 : 저장소가 비활성화되었습니다.
    • 관리됨 : 저장소가 활성화되었습니다.
  8. 저장을 클릭합니다.
  9. 저장소를 비활성화하는 경우 드라이버가 제거되었는지 확인하세요.

    1. 워크로드 > Pod를 클릭합니다.
    2. Pod 페이지에서 이름 필터 상자에 "vmware-vsphere-csi-driver"를 입력합니다.

      나타나야 할 유일한 항목은 운영자입니다. 예: "vmware-vsphere-csi-driver-operator-559b97ffc5-w99fm"

6.21.14. vSphere의 노드당 최대 볼륨 증가

VMware vSphere 버전 7의 경우 OpenShift Container Platform은 노드당 최대 볼륨 수를 59개로 제한합니다.

하지만 vSphere 8 이상 버전에서는 노드당 허용되는 볼륨 수를 최대 255개까지 늘릴 수 있습니다. 그렇지 않으면 기본값은 59로 유지됩니다.

중요

ESXi 8 하이퍼바이저만 포함된 동종 vSphere 8 환경이 있어야 합니다. ESXi 8 이외의 버전이 혼합된 이기종 환경은 허용되지 않습니다. 이처럼 이기종 환경에서 59보다 큰 값을 설정하면 클러스터가 저하됩니다.

제한

  • VMware vSphere 버전 8 이상을 실행해야 합니다.
  • 노드당 최대 볼륨 수를 충분한 수의 노드에서 늘리면 호스트당 2048개의 가상 디스크 제한을 초과할 가능성이 있습니다. 이는 vSphere에 대한 DRS(분산 리소스 스케줄러) 검증이 없어 이 제한을 초과하지 않는지 확인할 수 없기 때문에 발생할 수 있습니다.
중요

노드당 볼륨을 늘리는 것은 기술 미리 보기 기능에만 해당됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

6.21.14.1. vSphere에 대해 노드당 허용되는 최대 볼륨 증가

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • VMware vSphere vCenter에 액세스합니다.
  • vCenter에서 pvscsiCtrlr256DiskSupportEnabled 매개변수가 'True'로 설정되어 있는지 확인하세요.

    중요

    pvscsiCtrlr256DiskSupportEnabled 매개변수를 변경하는 것은 VMware에서 완전히 지원되지 않습니다. 또한, 이 매개변수는 클러스터 전체에 적용되는 옵션입니다.

프로세스

vSphere의 노드당 최대 볼륨 수를 늘리려면 다음 절차를 따르세요.

  1. 관리 > CustomResourceDefinitions를 클릭합니다.
  2. CustomResourceDefinitions 페이지의 이름 드롭다운 상자 옆에 "clustercsidriver"를 입력합니다.
  3. CRD ClusterCSIDriver를 클릭합니다.
  4. 인스턴스 탭을 클릭합니다.
  5. csi.vsphere.vmware.com을 클릭합니다.
  6. YAML 탭을 클릭합니다.
  7. spec.driverConfig.driverType 매개변수를 vSphere 로 설정합니다.
  8. YAML 파일에 spec.driverConfig.vSphere.maxAllowedBlockVolumesPerNode 매개변수를 추가하고 다음 샘플 YAML 파일과 같이 노드당 원하는 최대 볼륨 수에 대한 값을 제공합니다.

    maxAllowedBlockVolumesPerNode 매개변수를 추가하기 위한 샘플 YAML 파일

    ...
    spec:
      driverConfig:
        driverType: vSphere
        vSphere:
          maxAllowedBlockVolumesPerNode: 
    1
    
    ...
    Copy to Clipboard Toggle word wrap

    1
    노드당 볼륨의 최대 개수에 대한 원하는 값을 여기에 입력하세요. 기본값은 59입니다. 최소값은 1이고 최대값은 255입니다.
  9. 저장을 클릭합니다.

6.21.15. 추가 리소스

7장. 일반 임시 볼륨

7.1. 개요

일반 임시 볼륨은 영구 볼륨과 동적 프로비저닝을 지원하는 모든 스토리지 드라이버가 제공할 수 있는 임시 볼륨 유형입니다. 일반적인 임시 볼륨은 스크래치 데이터를 위한 포드별 디렉토리를 제공한다는 점에서 emptyDir 볼륨과 유사하며, 이 디렉토리는 일반적으로 프로비저닝 후에는 비어 있습니다.

일반적인 임시 볼륨은 Pod 사양에 인라인으로 지정되며 Pod의 수명 주기를 따릅니다. 이들은 포드와 함께 생성되고 삭제됩니다.

일반적인 임시 볼륨의 특징은 다음과 같습니다.

  • 저장소는 로컬이거나 네트워크에 연결될 수 있습니다.
  • 볼륨은 포드가 초과할 수 없는 고정된 크기를 가질 수 있습니다.
  • 드라이버와 매개변수에 따라 볼륨에는 일부 초기 데이터가 있을 수 있습니다.
  • 드라이버가 지원한다고 가정하면 스냅샷, 복제, 크기 조정, 저장 용량 추적을 포함한 볼륨의 일반적인 작업이 지원됩니다.
참고

일반적인 임시 볼륨은 오프라인 스냅샷과 크기 조정을 지원하지 않습니다.

이러한 제한으로 인해 다음 컨테이너 스토리지 인터페이스(CSI) 드라이버는 일반적인 임시 볼륨에 대해 다음 기능을 지원하지 않습니다.

  • Azure Disk CSI 드라이버는 크기 조정을 지원하지 않습니다.
  • Cinder CSI 드라이버는 스냅샷을 지원하지 않습니다.

7.2. 수명 주기 및 영구 볼륨 클레임

볼륨 클레임에 대한 매개변수는 포드의 볼륨 소스 내부에서 허용됩니다. 영구 볼륨 클레임(PVC)에 대한 레이블, 주석 및 전체 필드 세트가 지원됩니다. 이러한 포드가 생성되면 임시 볼륨 컨트롤러는 포드와 동일한 네임스페이스에 실제 PVC 객체( 일반 임시 볼륨 생성 절차에서 표시된 템플릿에서)를 생성하고 포드가 삭제되면 PVC도 삭제되도록 합니다. 이렇게 하면 볼륨 바인딩 및 프로비저닝이 두 가지 방법 중 하나로 트리거됩니다.

  • 스토리지 클래스가 즉시 볼륨 바인딩을 사용하는 경우 즉시입니다.

    즉각적 바인딩을 사용하면 스케줄러는 볼륨이 사용 가능해진 후에 볼륨에 액세스할 수 있는 노드를 선택해야 합니다.

  • 포드가 임시로 노드에 예약되는 경우( WaitForFirstConsumervolume 바인딩 모드).

    이 볼륨 바인딩 옵션은 일반적인 임시 볼륨에 권장됩니다. 그 이유는 스케줄러가 포드에 적합한 노드를 선택할 수 있기 때문입니다.

리소스 소유권 측면에서, 일반적인 임시 저장소를 갖춘 포드는 해당 임시 저장소를 제공하는 PVC의 소유자입니다. 포드가 삭제되면 Kubernetes 가비지 수집기가 PVC를 삭제하고, 그러면 일반적으로 볼륨 삭제가 트리거됩니다. 스토리지 클래스의 기본 회수 정책은 볼륨을 삭제하는 것이기 때문입니다. retain이라는 회수 정책이 있는 스토리지 클래스를 사용하여 준일시적 로컬 스토리지를 만들 수 있습니다. 스토리지는 Pod보다 오래 지속되므로 이 경우 볼륨 정리가 별도로 수행되도록 해야 합니다. 이러한 PVC가 존재하는 한, 다른 PVC와 마찬가지로 사용될 수 있습니다. 특히 볼륨 복제나 스냅샷을 만들 때 데이터 소스로 참조할 수 있습니다. PVC 객체는 볼륨의 현재 상태도 보관합니다.

7.3. 보안

일반적인 임시 볼륨 기능을 활성화하면 포드를 생성할 수 있는 사용자가 간접적으로 영구 볼륨 클레임(PVC)도 생성할 수 있습니다. 이 기능은 해당 사용자에게 PVC를 직접 생성할 권한이 없는 경우에도 작동합니다. 클러스터 관리자는 이 점을 알고 있어야 합니다. 이것이 보안 모델에 맞지 않으면 일반적인 임시 볼륨이 있는 포드와 같은 객체를 거부하는 승인 웹훅을 사용하세요.

PVC에 대한 일반 네임스페이스 할당량은 여전히 적용되므로 사용자가 이 새로운 메커니즘을 사용할 수 있더라도 다른 정책을 우회하는 데 사용할 수는 없습니다.

7.4. 영구 볼륨 클레임 명명

자동으로 생성된 영구 볼륨 클레임(PVC)은 포드 이름과 볼륨 이름을 조합하여 명명되며, 가운데에 하이픈(-)이 들어갑니다. 이러한 명명 규칙은 서로 다른 포드 간, 그리고 포드와 수동으로 생성된 PVC 간에 잠재적인 충돌을 야기합니다.

예를 들어, 볼륨 scratch가 있는 pod-a와 볼륨 a-scratch가 있는 pod 는 모두 동일한 PVC 이름인 pod-a-scratch로 끝납니다.

이러한 충돌은 감지되고 PVC는 포드용으로 생성된 경우에만 임시 볼륨에 사용됩니다. 이 확인은 소유권 관계에 기초합니다. 기존 PVC는 덮어쓰거나 수정되지 않지만 충돌은 해결되지 않습니다. 적절한 PVC가 없으면 포드를 시작할 수 없습니다.

중요

동일한 네임스페이스 내에서 포드와 볼륨의 이름을 지정할 때는 이름 충돌이 발생하지 않도록 주의하세요.

7.5. 일반 임시 볼륨 생성

프로세스

  1. Pod 객체 정의를 생성하여 파일에 저장합니다.
  2. 파일에 일반적인 임시 볼륨 정보를 포함합니다.

    my-example-pod-with-generic-vols.yaml

    kind: Pod
    apiVersion: v1
    metadata:
      name: my-app
    spec:
      containers:
        - name: my-frontend
          image: busybox:1.28
          volumeMounts:
          - mountPath: "/mnt/storage"
            name: data
          command: [ "sleep", "1000000" ]
      volumes:
        - name: data 
    1
    
          ephemeral:
            volumeClaimTemplate:
              metadata:
                labels:
                  type: my-app-ephvol
              spec:
                accessModes: [ "ReadWriteOnce" ]
                storageClassName: "gp2-csi"
                resources:
                  requests:
                    storage: 1Gi
    Copy to Clipboard Toggle word wrap

    1
    일반적인 일시적 볼륨 청구.

8장. 영구 볼륨 확장

8.1. 볼륨 확장 지원 활성화

영구 볼륨을 확장하려면 StorageClass 오브젝트에서 allowVolumeExpansion 필드가 true로 설정되어 있어야 합니다.

프로세스

  • 다음 명령을 실행하여 StorageClass 객체를 편집하고 allowVolumeExpansion 속성을 추가합니다.

    $ oc edit storageclass <storage_class_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    저장 클래스의 이름을 지정합니다.

    다음 예시는 스토리지 클래스 구성 하단에 이 행을 추가하는 방법을 보여줍니다.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    ...
    parameters:
      type: gp2
    reclaimPolicy: Delete
    allowVolumeExpansion: true 
    1
    Copy to Clipboard Toggle word wrap
    1
    이 속성을 true로 설정하면 생성 후 PVC가 확장됩니다.

8.2. CSI 볼륨 확장

CSI(Container Storage Interface)를 사용하여 이미 생성된 스토리지 볼륨을 확장할 수 있습니다.

영구 볼륨(PV) 축소는 지원되지 않습니다 .

사전 요구 사항

  • 기본 CSI 드라이버는 크기 조정을 지원합니다. "추가 리소스" 섹션에서 "OpenShift Container Platform에서 지원하는 CSI 드라이버"를 참조하세요.
  • 동적 프로비저닝이 사용됩니다.
  • 제어 StorageClass 오브젝트에 allowVolumeExpansiontrue로 설정되어 있습니다. 자세한 내용은 "볼륨 확장 지원 활성화"를 참조하세요.

프로세스

  1. 영구 볼륨 클레임(PVC)의 경우 .spec.resources.requests.storage를 원하는 새 크기로 설정합니다.
  2. PVC의 status.conditions 필드를 살펴보고 크기 조정이 완료되었는지 확인하세요. OpenShift Container Platform은 확장 중에 PVC에 Resizing 조건을 추가합니다. 확장이 완료된 후 제거됩니다.

8.3. 지원되는 드라이버를 사용한 FlexVolume 확장

FlexVolume을 사용하여 백엔드 스토리지 시스템에 연결할 때 이미 생성된 후 영구 스토리지 볼륨을 확장할 수 있습니다. OpenShift Container Platform에서 PVC(영구 볼륨 클레임)를 수동으로 업데이트하여 수행합니다.

FlexVolume은 RequiresFSResizetrue로 설정된 경우 확장을 허용합니다. Pod를 다시 시작할 때 FlexVolume을 확장할 수 있습니다.

다른 볼륨 유형과 유사하게 Pod에서 사용할 때 FlexVolume 볼륨도 확장할 수 있습니다.

사전 요구 사항

  • 기본 볼륨 드라이버는 크기 조정을 지원합니다.
  • 드라이버에서는 RequiresFSResize 기능이 true로 설정됩니다.
  • 동적 프로비저닝이 사용됩니다.
  • 제어 StorageClass 오브젝트에 allowVolumeExpansiontrue로 설정되어 있습니다.

절차

  • FlexVolume 플러그인에서 크기 조정을 사용하려면 다음 방법을 사용하여 ExpandableVolumePlugin 인터페이스를 구현해야 합니다.

    RequiresFSResize
    true인 경우 용량을 직접 업데이트합니다. false인 경우 ExpandFS 메서드를 호출하여 파일 시스템의 크기 조정을 완료합니다.
    ExpandFS
    true인 경우 ExpandFS를 호출하여 물리 볼륨 확장을 수행한 후 파일 시스템의 크기를 조정합니다. 볼륨 드라이버는 파일 시스템의 크기 조정과 함께 물리 볼륨 크기 조정을 수행할 수도 있습니다.
중요

OpenShift Container Platform은 컨트롤 플레인 노드에 FlexVolume 플러그인 설치를 지원하지 않으므로 FlexVolume의 컨트롤 플레인 확장을 지원하지 않습니다.

8.4. 로컬 볼륨 확장

로컬 스토리지 운영자(LSO)를 사용하여 생성된 영구 볼륨(PV) 및 영구 볼륨 클레임(PVC)을 수동으로 확장할 수 있습니다.

프로세스

  1. 기본 장치를 확장합니다. 이러한 장치에서 적절한 용량을 사용할 수 있는지 확인합니다.
  2. PV의 .spec.capacity 필드를 편집하여 새 장치 크기에 맞게 해당 PV 객체를 업데이트합니다.
  3. PVC를 PVet에 바인딩하는 데 사용되는 스토리지 클래스의 경우 allowVolumeExpansion:true를 설정합니다.
  4. PVC의 경우 .spec.resources.requests.storage를 새 크기에 맞게 설정합니다.

필요한 경우 Kubelet은 볼륨의 기본 파일 시스템을 자동으로 확장하고 PVC의 상태 필드를 업데이트하여 새로운 크기를 반영해야 합니다.

8.5. 파일 시스템을 사용한 PVC(영구 볼륨 클레임) 처리

GCE, EBS 및 Cinder와 같이 파일 시스템 크기 조정이 필요한 볼륨 유형에 따라 PVC를 확장하는 것은 2단계 프로세스입니다. 먼저, 클라우드 공급자의 볼륨 객체를 확장합니다. 둘째, 노드의 파일 시스템을 확장합니다.

노드의 파일 시스템을 배양하는 것은 볼륨으로 새 Pod가 시작될 때만 수행됩니다.

사전 요구 사항

  • 제어 StorageClass 오브젝트에서 allowVolumeExpansiontrue로 설정되어야 합니다.

절차

  1. PVC를 편집하고 spec.resources.requests를 편집하여 새 크기를 요청합니다. 예를 들어, 다음은 ebs PVC를 8Gi로 확장합니다.

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: ebs
    spec:
      storageClass: "storageClassWithFlagSet"
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 8Gi 
    1
    Copy to Clipboard Toggle word wrap
    1
    spec.resources.requests 를 더 큰 양으로 업데이트하면 PVC가 확장됩니다.
  2. 클라우드 공급자 오브젝트 크기 조정이 완료되면 PVC가 FileSystemResizePending로 설정됩니다. 다음 명령을 입력하여 조건을 확인합니다.

    $ oc describe pvc <pvc_name>
    Copy to Clipboard Toggle word wrap
  3. 클라우드 공급자 오브젝트 크기 조정이 완료되면 PersistentVolume 오브젝트가 PersistentVolume.Spec.Capacity의 새로 요청된 크기를 반영합니다. 이 시점에서 PVC에서 새 Pod를 생성하거나 재생성하여 파일 시스템 크기 조정을 완료할 수 있습니다. Pod가 실행되면 새로 요청된 크기를 사용할 수 있으며, FileSystemResizePending 조건이 PVC에서 제거됩니다.

8.6. 볼륨을 분리할 때 실패에서 복구

크기 조정 요청이 실패하거나 보류 상태로 남아 있는 경우 영구 볼륨 클레임(PVC)에 대해 .spec.resources.requests.storage 에 다른 크기 조정 값을 입력하여 다시 시도할 수 있습니다. 새로운 값은 원래 볼륨 크기보다 커야 합니다.

여전히 문제가 있는 경우 다음 절차에 따라 복구하세요.

프로세스

PVC에 대해 .spec.resources.requests.storage 에 더 작은 크기 조정 값을 입력해도 작동하지 않으면 다음을 수행하세요.

  1. PVC에 바인딩된 PV(영구 볼륨)를 Retain 회수 정책으로 표시합니다. persistentVolumeReclaimPolicy를 Retain 으로 변경합니다.
  2. PVC를 삭제합니다.
  3. PV를 수동으로 편집하고 PV 사양에서 claimRef 항목을 삭제하여 새로 생성된 PVC가 Retain 으로 표시된 PV에 바인딩될 수 있도록 합니다. PV가 Available로 표시됩니다.
  4. PVC를 작은 크기로 다시 생성하거나 기본 스토리지 공급자가 할당할 수 있는 크기입니다.
  5. PVC의 volumeName 필드를 PV 이름으로 설정합니다. 이렇게 하면 PVC가 프로비저닝된 PV에만 바인딩됩니다.
  6. PV에서 회수 정책을 복구합니다.

9장. 동적 프로비저닝

9.1. 동적 프로비저닝 소개

StorageClass 리소스 객체는 요청 가능한 스토리지를 설명하고 분류할 뿐 만 아니라 필요에 따라 동적으로 프로비저닝된 스토리지에 대한 매개 변수를 전달하는 수단을 제공합니다. StorageClass 객체는 다른 수준의 스토리지 및 스토리지에 대한 액세스를 제어하기 위한 관리 메커니즘으로 사용될 수 있습니다. 클러스터 관리자 (cluster-admin) 또는 스토리지 관리자 (storage-admin)는 사용자가 기본 스토리지 볼륨 소스에 대한 자세한 지식이 없어도 요청할 수 있는 StorageClass 오브젝트를 정의하고 생성할 수 있습니다.

OpenShift Container Platform 영구 볼륨 프레임 워크를 사용하면이 기능을 사용할 수 있으며 관리자는 영구 스토리지로 클러스터를 프로비저닝할 수 있습니다. 또한 이 프레임 워크를 통해 사용자는 기본 인프라에 대한 지식이 없어도 해당 리소스를 요청할 수 있습니다.

OpenShift Container Platform에서 많은 스토리지 유형을 영구 볼륨으로 사용할 수 있습니다. 모든 저장소는 관리자가 정적으로 프로비저닝할 수 있지만, 일부 유형의 저장소는 내장된 공급자 및 플러그인 API를 사용하여 동적으로 생성됩니다.

9.2. 사용 가능한 동적 프로비저닝 플러그인

OpenShift Container Platform은 클러스터의 구성된 공급자 API를 사용하여 새로운 스토리지 리소스를 생성하는 동적 프로비저닝을 위한 일반적인 구현을 갖춘 다음과 같은 프로비저너 플러그인을 제공합니다.

Expand
스토리지 유형프로비저너 플러그인 이름참고

Red Hat OpenStack Platform(RHOSP) Cinder

kubernetes.io/cinder

 

RHOSP Manila Container Storage Interface (CSI)

manila.csi.openstack.org

설치 완료되면 OpenStack Manila CSI Driver Operator 및 ManilaDriver가 동적 프로비저닝에 필요한 모든 사용 가능한 Manila 공유 유형에 필요한 스토리지 클래스를 자동으로 생성합니다.

Amazon Elastic Block Store(Amazon EBS)

ebs.csi.aws.com

다른 영역에서 여러 클러스터를 사용할 때 동적 프로비저닝의 경우 각 노드에 Key=kubernetes.io/cluster/<cluster_name>,Value=<cluster_id>로 태그를 지정합니다. 여기서 <cluster_name><cluster_id>는 클러스터마다 고유합니다.

Azure Disk

kubernetes.io/azure-disk

 

Azure File

kubernetes.io/azure-file

persistent-volume-binder 서비스 계정에는 Azure 스토리지 계정 및 키를 저장할 시크릿을 생성하고 검색할 수 있는 권한이 필요합니다.

GCE Persistent Disk (gcePD)

kubernetes.io/gce-pd

멀티 존 설정에서는 현재 클러스터에 노드가 없는 영역에서 PV가 생성되지 않도록 GCE 프로젝트 당 하나의 OpenShift Container Platform 클러스터를 실행하는 것이 좋습니다.

IBM Power® 가상 서버 블록

powervs.csi.ibm.com

설치 후 IBM Power® Virtual Server Block CSI Driver Operator와 IBM Power® Virtual Server Block CSI Driver는 동적 프로비저닝에 필요한 스토리지 클래스를 자동으로 생성합니다.

VMware vSphere

kubernetes.io/vsphere-volume

 
중요

선택한 모든 프로비저너 플러그인에는 관련 문서에 따라 해당 클라우드, 호스트 또는 타사 공급자에 대한 구성도 필요합니다.

9.3. 스토리지 클래스 정의

StorageClass 객체는 현재 전역 범위 객체이며 cluster-admin 또는 storage-admin 사용자가 만들어야 합니다.

중요

클러스터 스토리지 작업자는 사용 중인 플랫폼에 따라 기본 스토리지 클래스를 설치할 수 있습니다. 이 스토리지 클래스는 Operator가 소유하고 제어합니다. 주석 및 레이블 정의 외에는 삭제하거나 변경할 수 없습니다. 다른 동작이 필요한 경우 사용자 정의 스토리지 클래스를 정의해야 합니다.

다음 섹션에서는 StorageClass 객체에 대한 기본 정의와 지원되는 각 플러그인 유형에 대한 구체적인 예를 설명합니다.

9.3.1. 기본 StorageClass 개체 정의

다음 리소스는 스토리지 클래스를 구성하는 데 사용되는 매개변수 및 기본값을 보여줍니다. 이 예에서는 AWS ElasticBlockStore (EBS) 객체 정의를 사용합니다.

StorageClass 정의 예

kind: StorageClass 
1

apiVersion: storage.k8s.io/v1 
2

metadata:
  name: <storage-class-name> 
3

  annotations: 
4

    storageclass.kubernetes.io/is-default-class: 'true'
    ...
provisioner: kubernetes.io/aws-ebs 
5

parameters: 
6

  type: gp3
...
Copy to Clipboard Toggle word wrap

1
(필수) API 객체 유형입니다.
2
(필수) 현재 apiVersion입니다.
3
(필수) 스토리지 클래스의 이름입니다.
4
(선택 사항) 스토리지 클래스의 주석입니다.
5
(필수) 이 스토리지 클래스에 연결된 프로비저너의 유형입니다.
6
(선택 사항) 특정 프로비저너에 필요한 매개 변수로, 플러그인에 따라 변경됩니다.

9.3.2. 스토리지 클래스 주석

스토리지 클래스를 클러스터 전체 기본값으로 설정하려면 스토리지 클래스의 메타데이터에 다음 주석을 추가합니다.

storageclass.kubernetes.io/is-default-class: "true"
Copy to Clipboard Toggle word wrap

예를 들면 다음과 같습니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
...
Copy to Clipboard Toggle word wrap

이렇게 하면 특정 스토리지 클래스를 지정하지 않은 모든 PVC(영구 볼륨 클레임)가 기본 스토리지 클래스를 통해 자동으로 프로비저닝됩니다. 하지만 클러스터에는 두 개 이상의 스토리지 클래스가 있을 수 있지만, 그 중 하나만이 기본 스토리지 클래스가 될 수 있습니다.

참고

베타 주석 storageclass.beta.kubernetes.io/is-default-class는 여전히 작동하지만 향후 릴리스에서는 제거될 예정입니다.

스토리지 클래스 설명을 설정하려면 스토리지 클래스의 메타데이터에 다음 주석을 추가합니다.

kubernetes.io/description: My Storage Class Description
Copy to Clipboard Toggle word wrap

예를 들면 다음과 같습니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: My Storage Class Description
...
Copy to Clipboard Toggle word wrap

9.3.3. RHOSP Cinder 오브젝트 정의

cinder-storageclass.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storage-class-name> 
1

provisioner: kubernetes.io/cinder
parameters:
  type: fast  
2

  availability: nova 
3

  fsType: ext4 
4
Copy to Clipboard Toggle word wrap

1
StorageClass의 이름입니다. 영구 볼륨 클래임은 이 스토리지 클래스를 사용하여 관련 영구 볼륨을 프로비저닝합니다.
2
Cinder에서 생성 된 볼륨 유형입니다. 기본값은 비어 있습니다.
3
가용성 영역입니다. 지정하지 않으면 일반적으로 OpenShift Container Platform 클러스터에 노드가 있는 모든 활성 영역에서 볼륨이 라운드 로빈됩니다.
4
동적으로 프로비저닝된 볼륨에서 생성된 파일 시스템입니다. 이 값은 동적으로 프로비저닝된 영구 볼륨의 fsType 필드에 복사되며 볼륨이 처음 마운트될 때 파일 시스템이 작성됩니다. 기본값은 ext4입니다.

9.3.4. RHOSP Manila CSI(Container Storage Interface) 오브젝트 정의

설치 완료되면 OpenStack Manila CSI Driver Operator 및 ManilaDriver가 동적 프로비저닝에 필요한 모든 사용 가능한 Manila 공유 유형에 필요한 스토리지 클래스를 자동으로 생성합니다.

9.3.5. AWS Elastic Block Store (EBS) 객체 정의

aws-ebs-storageclass.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storage-class-name> 
1

provisioner: ebs.csi.aws.com
parameters:
  type: io1 
2

  iopsPerGB: "10" 
3

  encrypted: "true" 
4

  kmsKeyId: keyvalue 
5

  fsType: ext4 
6
Copy to Clipboard Toggle word wrap

1
(필수) 저장 클래스의 이름입니다. 영구 볼륨 클래임은 이 스토리지 클래스를 사용하여 관련 영구 볼륨을 프로비저닝합니다.
2
(필수) io1 , gp3 , sc1 , st1 중에서 선택하세요. 기본값은 gp3 입니다. 유효한 Amazon Resource Name (ARN) 값은 AWS 설명서를 참조하십시오.
3
선택 사항: io1 볼륨만 해당합니다. GiB마다 초당 I/O 작업 수입니다. AWS 볼륨 플러그인은 이것을 요청된 볼륨의 크기에 곱하여 볼륨의 IOPS를 계산합니다. 값의 상한은 AWS가 지원하는 최대치인 20,000 IOPS입니다. 자세한 내용은 AWS 설명서를 참조하십시오.
4
선택 사항: EBS 볼륨을 암호화할지 여부를 나타냅니다. 유효한 값은 true 또는 false입니다.
5
선택 사항: 볼륨을 암호화할 때 사용할 키의 전체 ARN입니다. 값을 지정하지 않는 경우에도 encyptedtrue로 설정되어 있는 경우 AWS가 키를 생성합니다. 유효한 ARN 값은 AWS 설명서를 참조하십시오.
6
선택 사항: 동적으로 프로비저닝된 볼륨에서 생성된 파일 시스템입니다. 이 값은 동적으로 프로비저닝된 영구 볼륨의 fsType 필드에 복사되며 볼륨이 처음 마운트될 때 파일 시스템이 작성됩니다. 기본값은 ext4입니다.

9.3.6. Azure Disk 오브젝트 정의

azure-advanced-disk-storageclass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <storage-class-name> 
1

provisioner: kubernetes.io/azure-disk
volumeBindingMode: WaitForFirstConsumer 
2

allowVolumeExpansion: true
parameters:
  kind: Managed 
3

  storageaccounttype: Premium_LRS 
4

reclaimPolicy: Delete
Copy to Clipboard Toggle word wrap

1
StorageClass의 이름입니다. 영구 볼륨 클래임은 이 스토리지 클래스를 사용하여 관련 영구 볼륨을 프로비저닝합니다.
2
WaitForFirstConsumer를 사용하는 것이 좋습니다. 이렇게 하면 볼륨을 프로비저닝하고 사용 가능한 영역에서 사용 가능한 작업자 노드의 Pod를 예약할 수 있는 충분한 스토리지를 허용합니다.
3
가능한 값은 Shared(기본값), Managed, Dedicated입니다.
중요

Red Hat은 스토리지 클래스에서 kind: Managed의 사용만 지원합니다.

SharedDedicated를 사용하여 Azure는 관리되지 않은 디스크를 생성합니다. 반면 OpenShift Container Platform은 머신 OS(root) 디스크의 관리 디스크를 생성합니다. Azure Disk는 노드에서 관리 및 관리되지 않은 디스크를 모두 사용하도록 허용하지 않으므로 Shared 또는 Dedicated로 생성된 관리되지 않은 디스크를 OpenShift Container Platform 노드에 연결할 수 없습니다.

4
Azure 스토리지 계정 SKU층입니다. 기본값은 비어 있습니다. 프리미엄 VM은 Standard_LRSPremium_LRS 디스크를 모두 연결할 수 있으며 표준 VM은 Standard_LRS 디스크만 연결할 수 있습니다. 관리형 VM은 관리 디스크만 연결할 수 있으며 관리되지 않는 VM은 관리되지 않는 디스크만 연결할 수 있습니다.
  1. kindShared로 설정된 경우 Azure는 클러스터와 동일한 리소스 그룹에 있는 일부 공유 스토리지 계정에서 관리되지 않는 디스크를 만듭니다.
  2. kindManaged로 설정된 경우 Azure는 새 관리 디스크를 만듭니다.
  3. kindDedicated로 설정되고 storageAccount가 지정된 경우 Azure는 클러스터와 동일한 리소스 그룹에서 새로운 관리되지 않는 디스크에 대해 지정된 스토리지 계정을 사용합니다. 이 기능이 작동하려면 다음 사항이 전제가 되어야 합니다.

    • 지정된 스토리지 계정이 같은 지역에 있어야 합니다.
    • Azure Cloud Provider는 스토리지 계정에 대한 쓰기 권한이 있어야 합니다.
  4. kindDedicated로 설정되어 있고 storageAccount가 지정되지 않은 경우 Azure는 클러스터와 동일한 리소스 그룹에 새로운 관리되지 않는 디스크에 대한 새로운 전용 스토리지 계정을 만듭니다.

9.3.7. Azure File 객체 정의

Azure File 스토리지 클래스는 시크릿을 사용하여 Azure 파일 공유를 만드는 데 필요한 Azure 스토리지 계정 이름과 스토리지 계정 키를 저장합니다. 이러한 권한은 다음 절차의 일부로 생성됩니다.

절차

  1. 시크릿을 작성하고 볼 수 있는 액세스를 허용하는 ClusterRole 오브젝트를 정의합니다.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
    #  name: system:azure-cloud-provider
      name: <persistent-volume-binder-role> 
    1
    
    rules:
    - apiGroups: ['']
      resources: ['secrets']
      verbs:     ['get','create']
    Copy to Clipboard Toggle word wrap
    1
    시크릿을 표시하고 작성하는 클러스터 역할의 이름입니다.
  2. 서비스 계정에 클러스터 역할을 추가합니다.

    $ oc adm policy add-cluster-role-to-user <persistent-volume-binder-role> system:serviceaccount:kube-system:persistent-volume-binder
    Copy to Clipboard Toggle word wrap
  3. Azure File StorageClass 오브젝트를 만듭니다.

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: <azure-file> 
    1
    
    provisioner: kubernetes.io/azure-file
    parameters:
      location: eastus 
    2
    
      skuName: Standard_LRS 
    3
    
      storageAccount: <storage-account> 
    4
    
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    Copy to Clipboard Toggle word wrap
    1
    StorageClass의 이름입니다. 영구 볼륨 클래임은 이 스토리지 클래스를 사용하여 관련 영구 볼륨을 프로비저닝합니다.
    2
    eastus와 같은 Azure 스토리지 계정의 위치입니다. 기본값은 비어 있습니다. 즉, OpenShift Container Platform 클러스터 위치에 새 Azure 스토리지 계정이 만들어집니다.
    3
    Azure 스토리지 계정의 SKU 계층입니다 (예: Standard_LRS). 기본값은 비어 있습니다. 즉, Standard_LRS SKU를 사용하여 새 Azure 스토리지 계정이 만들어집니다.
    4
    Azure 스토리지 계정 이름입니다. 스토리지 계정이 제공되면 skuNamelocation이 무시됩니다. 스토리지 계정이 제공되지 않으면 스토리지 클래스는 정의된 skuNamelocation과 일치하는 계정의 리소스 그룹과 연관된 스토리지 계정을 검색합니다.
9.3.7.1. Azure File 사용시 고려 사항

기본 Azure File 스토리지 클래스는 다음 파일 시스템 기능을 지원하지 않습니다.

  • 심볼릭 링크
  • 하드 링크
  • 확장 속성
  • 스파스 파일
  • 명명된 파이프

또한 Azure File이 마운트되는 디렉터리의 소유자 ID (UID)는 컨테이너의 프로세스 UID와 다릅니다. 마운트된 디렉터리에 사용할 특정 사용자 ID를 정의하기 위해 StorageClass 오브젝트에서 uid 마운트 옵션을 지정할 수 있습니다.

다음 StorageClass 오브젝트는 마운트된 디렉터리의 심볼릭 링크를 활성화한 상태에서 사용자 및 그룹 ID를 변경하는 방법을 보여줍니다.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-file
mountOptions:
  - uid=1500 
1

  - gid=1500 
2

  - mfsymlinks 
3

provisioner: kubernetes.io/azure-file
parameters:
  location: eastus
  skuName: Standard_LRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
Copy to Clipboard Toggle word wrap
1
마운트된 디렉터리에 사용할 사용자 ID를 지정합니다.
2
마운트된 디렉터리에 사용할 그룹 ID를 지정합니다.
3
심볼릭 링크를 활성화합니다.

9.3.8. GCE PersistentDisk (gcePD) 오브젝트 정의

gce-pd-storageclass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <storage-class-name> 
1

provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd 
2

  replication-type: none
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete
Copy to Clipboard Toggle word wrap

1
StorageClass의 이름입니다. 영구 볼륨 클래임은 이 스토리지 클래스를 사용하여 관련 영구 볼륨을 프로비저닝합니다.
2
pd-ssd , pd-standard 또는 hyperdisk-balanced를 선택하세요. 기본값은 pd-ssd입니다.

9.3.9. VMware vSphere 개체 정의

vsphere-storageclass.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storage-class-name> 
1

provisioner: csi.vsphere.vmware.com 
2
Copy to Clipboard Toggle word wrap

1
StorageClass의 이름입니다. 영구 볼륨 클래임은 이 스토리지 클래스를 사용하여 관련 영구 볼륨을 프로비저닝합니다.
2
OpenShift Container Platform에서 VMware vSphere CSI를 사용하는 방법에 대한 자세한 내용은 Kubernetes 설명서 를 참조하십시오.

9.4. 기본 스토리지 클래스 변경

다음 절차에 따라 기본 스토리지 클래스를 변경합니다.

예를 들어 두 개의 스토리지 클래스(gp2standard)가 있으며 기본 스토리지 클래스를 gp2 에서 standard로 변경하려고 합니다.

사전 요구 사항

  • cluster-admin 권한으로 클러스터에 액세스합니다.

프로세스

기본 스토리지 클래스를 변경하려면 다음을 수행합니다.

  1. 스토리지 클래스를 나열합니다.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                 TYPE
    gp3 (default)        ebs.csi.aws.com 
    1
    
    standard             ebs.csi.aws.com
    Copy to Clipboard Toggle word wrap

    1
    (default) 는 기본 스토리지 클래스를 나타냅니다.
  2. 원하는 스토리지 클래스를 기본값으로 설정합니다.

    원하는 스토리지 클래스의 경우 다음 명령을 실행하여 storageclass.kubernetes.io/is-default-class 주석을 true 로 설정합니다.

    $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
    Copy to Clipboard Toggle word wrap
    참고

    짧은 시간 동안 여러 기본 스토리지 클래스를 사용할 수 있습니다. 그러나 결국 하나의 기본 스토리지 클래스만 존재하는지 확인해야 합니다.

    여러 기본 스토리지 클래스가 있는 경우 기본 스토리지 클래스 pvc.spec.storageClassName=nil)를 요청하는 모든 영구 볼륨 클레임(PVC)은 해당 스토리지 클래스의 기본 상태와 관계없이 가장 최근에 생성된 기본 스토리지 클래스를 가져옵니다. 경고 대시보드에서 여러 기본 스토리지 클래스인 MultipleDefaultStorageClasses 가 있다는 경고를 받습니다.

  3. 이전 기본 스토리지 클래스에서 기본 스토리지 클래스 설정을 제거합니다.

    이전 기본 스토리지 클래스의 경우 다음 명령을 실행하여 storageclass.kubernetes.io/is-default-class 주석의 값을 false 로 변경합니다.

    $ oc patch storageclass gp3 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
    Copy to Clipboard Toggle word wrap
  4. 변경 사항을 확인합니다.

    $ oc get storageclass
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                 TYPE
    gp3                  ebs.csi.aws.com
    standard (default)   ebs.csi.aws.com
    Copy to Clipboard Toggle word wrap

10장. 비정상적인 노드 종료 후 볼륨 분리

이 기능을 사용하면 노드가 비정상적으로 중단될 때 드라이버가 볼륨을 자동으로 분리할 수 있습니다.

10.1. 개요

kubelet의 노드 종료 관리자가 예정된 노드 종료 작업을 감지하면 정상 노드 종료가 발생합니다. 비정상적인 종료는 kubelet에서 노드 종료 작업을 감지하지 못하면 시스템 또는 하드웨어 오류로 인해 발생할 수 있습니다. 또한 shutdown 명령이 Linux에서 kubelet에서 사용하는 Inhibitor Locks 메커니즘을 트리거하지 않거나 예를 들어 shutdownGracePerioiod 및 shutdownGracePeriodCriticalPods 세부 정보가 올바르게 구성되지 않은 경우 kubelet에서 노드 종료 작업을 감지하지 못할 수 있습니다.

이 기능을 사용하면 비정상적인 노드 종료가 발생하면 노드에서 볼륨이 자동으로 분리될 수 있도록 노드에 out-of-service 테인트를 수동으로 추가할 수 있습니다.

10.2. 자동 볼륨 분리를 위해 서비스 외부 테인트 추가

사전 요구 사항

  • cluster-admin 권한으로 클러스터에 액세스합니다.

프로세스

비정상적인 노드 종료 후 노드에서 볼륨을 자동으로 분리할 수 있도록 하려면 다음을 수행합니다.

  1. 노드가 비정상으로 감지되면 작업자 노드를 종료합니다.
  2. 다음 명령을 실행하고 상태를 확인하여 노드가 종료되었는지 확인합니다.

    $ oc get node <node_name> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> = 정상적으로 종료되지 않은 노드의 이름
    중요

    노드가 완전히 종료되지 않으면 노드에 테인트를 진행하지 마십시오. 노드가 계속 작동 중이고 테인트가 적용되면 파일 시스템 손상이 발생할 수 있습니다.

  3. 다음 명령을 실행하여 해당 노드 오브젝트를 테인트합니다.

    중요

    이렇게 하면 노드를 테인트하면 해당 노드의 모든 Pod가 삭제됩니다. 이로 인해 상태 저장 세트에서 지원하는 모든 Pod가 제거되고 다른 노드에서 Pod 교체도 생성됩니다.

    $ oc adm taint node <node_name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> = 정상적으로 종료되지 않은 노드의 이름

    테인트를 적용한 후 볼륨이 종료 노드에서 분리되므로 디스크를 다른 노드에 연결할 수 있습니다.

    예제

    결과 YAML 파일은 다음과 유사합니다.

    spec:
      taints:
      - effect: NoExecute
        key: node.kubernetes.io/out-of-service
        value: nodeshutdown
    Copy to Clipboard Toggle word wrap
  4. 노드를 재시작합니다.
  5. 다음 명령을 실행하여 해당 노드 오브젝트에서 테인트를 제거합니다.

    $ oc adm taint node <node_name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute- 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> = 정상적으로 종료되지 않은 노드의 이름

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat