검색

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

download PDF

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

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

중요

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

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

추가 리소스

  • OpenStack Block Storage가 가상 하드 드라이브의 영구 블록 스토리지 관리를 제공하는 방법에 대한 자세한 내용은 OpenStack Cinder를 참조하십시오.

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

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

사전 요구 사항

  • RHOSP(Red Hat OpenStack Platform)용으로 구성된 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

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

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

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

    $ oc create -f cinder-persistentvolume.yaml

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>
    $ oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>
  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
    1
    실행할 Pod의 사본 수입니다.
    2
    실행할 Pod의 레이블 선택기입니다.
    3
    컨트롤러가 생성하는 Pod용 템플릿입니다.
    4
    Pod의 레이블입니다. 선택기 레이블에서 제공되는 레이블이 포함되어야 합니다.
    5
    매개변수를 확장한 후 최대 이름 길이는 63자입니다.
    6
    생성한 서비스 계정을 지정합니다.
    7
    Pod에 대한 fsGroup을 지정합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.