아마도 객체를 이해하고, 객체의 용도와 상호 작용을 파악하는 가장 쉬운 방법은 Kubernetes 사용자의 단일 저장소 요청을 따르는 것입니다.

쿠버네티스 PersistentVolumeClaim 객체는 Kubernetes 클러스터 사용자가 만든 저장소 요청입니다.

Trident 사용하면 표준 사양 외에도 백엔드 구성에서 설정한 기본값을 재정의하려는 경우 다음과 같은 볼륨별 주석을 지정할 수 있습니다.

생성된 PV에 다음이 있는 경우 Delete 회수 정책에 따라, Trident PV가 해제되면(즉, 사용자가 PVC를 삭제하면) PV와 백업 볼륨을 모두 삭제합니다. 삭제 작업이 실패하면 Trident PV를 삭제로 표시하고 성공하거나 PV를 수동으로 삭제할 때까지 주기적으로 작업을 다시 시도합니다. PV가 사용하는 경우 Retain 정책에 따라 Trident 이를 무시하고 관리자가 Kubernetes와 백엔드에서 이를 정리하여 볼륨을 제거하기 전에 백업하거나 검사할 수 있다고 가정합니다. PV를 삭제해도 Trident 백업 볼륨을 삭제하지는 않습니다. REST API를 사용하여 제거해야 합니다.(tridentctl ).

Trident CSI 사양을 사용하여 볼륨 스냅샷 생성을 지원합니다. 볼륨 스냅샷을 생성하고 이를 데이터 소스로 사용하여 기존 PVC를 복제할 수 있습니다. 이런 방식으로 PV의 특정 시점 복사본을 스냅샷 형태로 Kubernetes에 노출할 수 있습니다. 그런 다음 스냅샷을 사용하여 새로운 PV를 만들 수 있습니다. 살펴보세요 On-Demand Volume Snapshots 이것이 어떻게 작동하는지 알아보려고요.

Trident 또한 다음을 제공합니다. cloneFromPVC 그리고 splitOnClone 클론을 생성하기 위한 주석. 이러한 주석을 사용하면 CSI 구현을 사용하지 않고도 PVC를 복제할 수 있습니다.

다음은 예입니다. 사용자가 이미 PVC를 가지고 있는 경우 mysql 사용자는 새로운 PVC를 생성할 수 있습니다. mysqlclone 예를 들어 주석을 사용하여 trident.netapp.io/cloneFromPVC: mysql . 이 주석 세트를 사용하면 Trident 볼륨을 처음부터 프로비저닝하는 대신 MySQL PVC에 해당하는 볼륨을 복제합니다.

다음 사항을 고려하세요.

그만큼 sample-input 디렉토리에는 Trident 와 함께 사용할 수 있는 PVC 정의의 예가 포함되어 있습니다. 참조하다 Trident 볼륨과 관련된 매개변수와 설정에 대한 전체 설명을 확인하세요.

쿠버네티스 PersistentVolume 객체는 Kubernetes 클러스터에서 사용할 수 있는 저장소를 나타냅니다. 포드를 사용하는 포드와 독립적인 수명 주기를 갖습니다.

Trident 기반을 참조하는 PVC를 생성할 때 StorageClass Trident 해당 스토리지 클래스를 사용하여 새 볼륨을 프로비저닝하고 해당 볼륨에 대한 새 PV를 등록합니다. 프로비저닝된 볼륨과 해당 PV를 구성할 때 Trident 다음 규칙을 따릅니다.

쿠버네티스 StorageClass 객체는 이름으로 지정됩니다. PersistentVolumeClaims 속성 집합으로 저장소를 프로비저닝합니다. 스토리지 클래스 자체는 사용될 프로비저너를 식별하고 프로비저너가 이해하는 용어로 해당 속성 집합을 정의합니다.

이는 관리자가 만들고 관리해야 하는 두 가지 기본 객체 중 하나입니다. 다른 하나는 Trident 백엔드 객체입니다.

쿠버네티스 StorageClass Trident 사용하는 객체는 다음과 같습니다.

이러한 매개변수는 Trident에만 적용되며 Trident 클래스에 대한 볼륨을 프로비저닝하는 방법을 알려줍니다.

저장 클래스 매개변수는 다음과 같습니다.

저장소 속성과 가능한 값은 저장소 풀 선택 속성과 Kubernetes 속성으로 분류할 수 있습니다.

쿠버네티스 VolumeSnapshotClass 객체는 다음과 유사합니다 StorageClasses . 이러한 스냅샷은 여러 스토리지 클래스를 정의하는 데 도움이 되며 볼륨 스냅샷에서 참조되어 스냅샷을 필요한 스냅샷 클래스와 연결합니다. 각 볼륨 스냅샷은 단일 볼륨 스냅샷 클래스와 연결됩니다.

에이 VolumeSnapshotClass 스냅샷을 생성하려면 관리자가 정의해야 합니다. 다음 정의를 사용하여 볼륨 스냅샷 클래스가 생성됩니다.

그만큼 driver Kubernetes에 볼륨 스냅샷에 대한 요청을 지정합니다. csi-snapclass 클래스는 Trident 에 의해 처리됩니다. 그만큼 deletionPolicy 스냅샷을 삭제해야 할 때 수행할 작업을 지정합니다. 언제 deletionPolicy 로 설정됩니다 Delete 스냅샷이 삭제되면 볼륨 스냅샷 개체와 스토리지 클러스터의 기본 스냅샷도 제거됩니다. 또는 다음과 같이 설정합니다. Retain 즉, VolumeSnapshotContent 그리고 물리적 스냅샷은 보존됩니다.

쿠버네티스 VolumeSnapshot 객체는 볼륨의 스냅샷을 생성하라는 요청입니다. PVC가 사용자가 볼륨에 대해 한 요청을 나타내는 것처럼 볼륨 스냅샷은 사용자가 기존 PVC의 스냅샷을 생성해 달라는 요청입니다.

볼륨 스냅샷 요청이 들어오면 Trident 백엔드에서 볼륨에 대한 스냅샷 생성을 자동으로 관리하고 고유한 스냅샷을 생성하여 스냅샷을 노출합니다.
VolumeSnapshotContent 물체. 기존 PVC에서 스냅샷을 생성하고 새 PVC를 생성할 때 해당 스냅샷을 DataSource로 사용할 수 있습니다.

쿠버네티스 VolumeSnapshotContent 객체는 이미 프로비저닝된 볼륨에서 가져온 스냅샷을 나타냅니다. 이것은 다음과 유사합니다. PersistentVolume 스토리지 클러스터에 프로비저닝된 스냅샷을 나타냅니다. 와 유사하다 PersistentVolumeClaim 그리고 PersistentVolume 스냅샷이 생성되면 개체 VolumeSnapshotContent 객체는 일대일 매핑을 유지합니다. VolumeSnapshot 스냅샷 생성을 요청한 객체입니다.

그만큼 VolumeSnapshotContent 개체에는 스냅샷을 고유하게 식별하는 세부 정보(예: snapshotHandle . 이것 snapshotHandle PV 이름과 VolumeSnapshotContent 물체.

스냅샷 요청이 들어오면 Trident 백엔드에서 스냅샷을 생성합니다. 스냅샷이 생성된 후 Trident 다음을 구성합니다. VolumeSnapshotContent 객체를 생성하여 Kubernetes API에 스냅샷을 노출합니다.

쿠버네티스 VolumeGroupSnapshotClass 객체는 다음과 유사합니다 VolumeSnapshotClass . 이러한 스냅샷은 여러 스토리지 클래스를 정의하는 데 도움이 되며 볼륨 그룹 스냅샷에서 참조되어 스냅샷을 필요한 스냅샷 클래스와 연결합니다. 각 볼륨 그룹 스냅샷은 단일 볼륨 그룹 스냅샷 클래스와 연결됩니다.

에이 VolumeGroupSnapshotClass 스냅샷 그룹을 생성하려면 관리자가 정의해야 합니다. 다음 정의를 사용하여 볼륨 그룹 스냅샷 클래스가 생성됩니다.

그만큼 driver 볼륨 그룹 스냅샷에 대한 요청을 Kubernetes에 지정합니다. csi-group-snap-class 클래스는 Trident 에 의해 처리됩니다. 그만큼 deletionPolicy 그룹 스냅샷을 삭제해야 할 때 수행할 작업을 지정합니다. 언제 deletionPolicy 로 설정됩니다 Delete 스냅샷이 삭제되면 볼륨 그룹 스냅샷 개체와 스토리지 클러스터의 기본 스냅샷도 제거됩니다. 또는 다음과 같이 설정합니다. Retain 즉, VolumeGroupSnapshotContent 그리고 물리적 스냅샷은 보존됩니다.

쿠버네티스 VolumeGroupSnapshot 객체는 여러 볼륨의 스냅샷을 생성하라는 요청입니다. PVC가 사용자가 볼륨에 대해 한 요청을 나타내는 것처럼 볼륨 그룹 스냅샷은 사용자가 기존 PVC의 스냅샷을 생성해 달라는 요청입니다.

볼륨 그룹 스냅샷 요청이 들어오면 Trident 백엔드의 볼륨에 대한 그룹 스냅샷 생성을 자동으로 관리하고 고유한 스냅샷을 생성하여 스냅샷을 노출합니다. VolumeGroupSnapshotContent 물체. 기존 PVC에서 스냅샷을 생성하고 새 PVC를 생성할 때 해당 스냅샷을 DataSource로 사용할 수 있습니다.

쿠버네티스 VolumeGroupSnapshotContent 개체는 이미 프로비저닝된 볼륨에서 가져온 그룹 스냅샷을 나타냅니다. 이것은 다음과 유사합니다. PersistentVolume 스토리지 클러스터에 프로비저닝된 스냅샷을 나타냅니다. 와 유사하다 PersistentVolumeClaim 그리고 PersistentVolume 스냅샷이 생성되면 개체 VolumeSnapshotContent 객체는 일대일 매핑을 유지합니다. VolumeSnapshot 스냅샷 생성을 요청한 객체입니다.

그만큼 VolumeGroupSnapshotContent 개체에는 스냅샷 그룹을 식별하는 세부 정보(예: volumeGroupSnapshotHandle 그리고 개별 볼륨 스냅샷 핸들이 스토리지 시스템에 존재합니다.

스냅샷 요청이 들어오면 Trident 백엔드에 볼륨 그룹 스냅샷을 생성합니다. 볼륨 그룹 스냅샷이 생성된 후 Trident 다음을 구성합니다. VolumeGroupSnapshotContent 객체를 생성하여 Kubernetes API에 스냅샷을 노출합니다.

Kubernetes 사용자 정의 리소스는 관리자가 정의한 Kubernetes API의 엔드포인트이며 유사한 객체를 그룹화하는 데 사용됩니다. Kubernetes는 객체 컬렉션을 저장하기 위한 사용자 정의 리소스 생성을 지원합니다. 다음 리소스 정의는 다음을 실행하여 얻을 수 있습니다. kubectl get crds .

사용자 정의 리소스 정의(CRD)와 관련 개체 메타데이터는 Kubernetes의 메타데이터 저장소에 저장됩니다. 이로 인해 Trident 위한 별도의 매장이 필요 없게 되었습니다.

Trident 사용 CustomResourceDefinition Trident 백엔드, Trident 스토리지 클래스, Trident 볼륨 등 Trident 객체의 ID를 보존하는 객체입니다. 이러한 객체는 Trident 에서 관리합니다. 또한 CSI 볼륨 스냅샷 프레임워크는 볼륨 스냅샷을 정의하는 데 필요한 일부 CRD를 도입합니다.

CRD는 Kubernetes 구성 요소입니다. 위에 정의된 리소스의 객체는 Trident 에 의해 생성됩니다. 간단한 예로, 백엔드가 생성될 때 tridentctl , 해당 tridentbackends CRD 객체는 Kubernetes에서 사용하기 위해 생성됩니다.

Trident의 CRD에 대해 염두에 두어야 할 몇 가지 사항은 다음과 같습니다.

Trident Kubernetes에 맞는 스토리지 클래스를 생성합니다. StorageClass 지정하는 객체 csi.trident.netapp.io 해당 프로비저닝 필드에 있습니다. 스토리지 클래스 이름은 Kubernetes의 이름과 일치합니다. StorageClass 그것이 나타내는 대상.

저장 클래스는 볼륨에 대한 요구 사항 집합으로 구성됩니다. Trident 이러한 요구 사항을 각 스토리지 풀에 있는 속성과 일치시킵니다. 속성이 일치하면 해당 스토리지 풀은 해당 스토리지 클래스를 사용하여 볼륨을 프로비저닝하기 위한 유효한 대상이 됩니다.

REST API를 사용하여 스토리지 클래스를 직접 정의하기 위해 스토리지 클래스 구성을 생성할 수 있습니다. 그러나 Kubernetes 배포의 경우 새 Kubernetes를 등록할 때 생성될 것으로 예상합니다. StorageClass 사물.

백엔드는 Trident 가 볼륨을 프로비저닝하는 스토리지 공급자를 나타냅니다. 단일 Trident 인스턴스는 아무리 많은 백엔드라도 관리할 수 있습니다.

이러한 객체를 구성하는 방법에 대한 자세한 내용은 다음을 참조하세요."백엔드 구성" .

스토리지 풀은 각 백엔드에서 프로비저닝에 사용할 수 있는 고유한 위치를 나타냅니다. ONTAP 의 경우 이는 SVM의 집계에 해당합니다. NetApp HCI/ SolidFire 의 경우 이는 관리자가 지정한 QoS 대역에 해당합니다. Cloud Volumes Service 의 경우 이는 클라우드 공급자 지역에 해당합니다. 각 스토리지 풀에는 성능 특성과 데이터 보호 특성을 정의하는 일련의 고유한 스토리지 속성이 있습니다.

여기의 다른 객체와 달리 스토리지 풀 후보는 항상 자동으로 검색되고 관리됩니다.

볼륨은 NFS 공유, iSCSI 및 FC LUN과 같은 백엔드 엔드포인트를 포함하는 기본 프로비저닝 단위입니다. Kubernetes에서는 이것이 직접적으로 대응합니다. PersistentVolumes . 볼륨을 생성할 때는 볼륨을 프로비저닝할 수 있는 위치와 크기를 결정하는 스토리지 클래스가 있는지 확인하세요.

볼륨 구성은 프로비저닝된 볼륨이 가져야 하는 속성을 정의합니다.

Trident 생성 internalName 볼륨을 생성할 때. 이는 두 단계로 구성됩니다. 첫째, 저장 접두사(기본값)를 추가합니다. trident 또는 백엔드 구성의 접두사)를 볼륨 이름에 추가하여 다음과 같은 형식의 이름을 생성합니다. <prefix>-<volume-name> . 그런 다음 백엔드에서 허용되지 않는 문자를 대체하여 이름을 정리합니다. ONTAP 백엔드의 경우 하이픈을 밑줄로 바꿉니다(따라서 내부 이름은 다음과 같습니다. <prefix>_<volume-name> ). Element 백엔드의 경우 밑줄을 하이픈으로 바꿉니다.

REST API를 사용하여 볼륨 구성을 사용하여 볼륨을 직접 프로비저닝할 수 있지만 Kubernetes 배포에서는 대부분의 사용자가 표준 Kubernetes를 사용할 것으로 예상합니다. PersistentVolumeClaim 방법. Trident 프로비저닝 프로세스의 일부로 이 볼륨 객체를 자동으로 생성합니다.

스냅샷은 볼륨의 특정 시점 복사본으로, 새로운 볼륨을 프로비저닝하거나 상태를 복원하는 데 사용할 수 있습니다. Kubernetes에서는 이것이 직접적으로 대응합니다. VolumeSnapshotContent 사물. 각 스냅샷은 볼륨과 연결되며, 볼륨은 스냅샷의 데이터 소스입니다.

각 Snapshot 개체에는 아래 나열된 속성이 포함됩니다.

쿠버네티스가 VolumeSnapshot 객체 요청이 생성되면 Trident 백업 스토리지 시스템에 스냅샷 객체를 생성하여 작동합니다. 그만큼 internalName 이 스냅샷 객체의 접두사를 결합하여 생성됩니다. snapshot- 와 함께 UID 의 VolumeSnapshot 객체(예를 들어, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660 ). volumeName 그리고 volumeInternalName 백업 볼륨의 세부 정보를 얻어서 채워집니다.

Trident 데몬셋은 다음을 소모합니다. system-node-critical 우선순위 클래스는 Kubernetes에서 사용할 수 있는 가장 높은 우선순위 클래스로, Trident 가 노드를 정상적으로 종료하는 동안 볼륨을 식별하고 정리할 수 있도록 하며, Trident 데몬셋 포드가 리소스 압박이 높은 클러스터에서 우선순위가 낮은 워크로드를 우선적으로 처리할 수 있도록 합니다.

이를 달성하기 위해 Trident 다음을 사용합니다. ResourceQuota Trident 데몬셋에서 "시스템 노드에 중요한" 우선 순위 클래스가 충족되는지 확인하기 위한 객체입니다. 배포 및 데몬셋 생성 전에 Trident 다음을 찾습니다. ResourceQuota 객체를 찾고, 발견되지 않으면 이를 적용합니다.

기본 리소스 할당량 및 우선 순위 클래스에 대한 더 많은 제어가 필요한 경우 다음을 생성할 수 있습니다. custom.yaml 또는 구성 ResourceQuota Helm 차트를 사용하여 객체를 생성합니다.

다음은 Trident 데몬셋의 우선순위를 지정하는 ResourceQuota 객체의 예입니다.

리소스 할당량에 대한 자세한 내용은 다음을 참조하세요."쿠버네티스: 리소스 할당량" .