객체, 그 용도, 그리고 상호 작용 방식을 이해하는 가장 쉬운 방법은 아마도 Kubernetes 사용자의 스토리지 요청 하나를 따라가는 것일 겁니다.

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`를 가지고 있다면, 주석을 사용하여 `mysqlclone`라는 새 PVC를 `trident.netapp.io/cloneFromPVC: mysql`와 같이 생성할 수 있습니다. 이 주석이 설정되면, Trident는 새로 볼륨을 프로비저닝하는 대신 mysql PVC에 해당하는 볼륨을 복제합니다.

다음 사항을 고려하십시오.

Kubernetes PersistentVolume 객체는 Kubernetes 클러스터에서 사용할 수 있도록 제공되는 스토리지 영역을 나타냅니다. 이 객체는 해당 객체를 사용하는 Pod와는 독립적인 수명 주기를 가집니다.

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

Kubernetes StorageClass 객체는 `PersistentVolumeClaims`에서 이름으로 지정되어 속성 집합을 가진 스토리지를 프로비저닝합니다. 스토리지 클래스 자체는 사용할 프로비저너를 식별하고 프로비저너가 이해할 수 있는 용어로 속성 집합을 정의합니다.

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

Trident를 사용하는 Kubernetes StorageClass 객체는 다음과 같습니다.

이러한 매개변수는 Trident에 특화되어 있으며 Trident에 해당 클래스에 대한 볼륨을 프로비저닝하는 방법을 알려줍니다.

스토리지 클래스 매개변수는 다음과 같습니다.

스토리지 속성과 해당 속성의 가능한 값은 스토리지 풀 선택 속성과 Kubernetes 속성으로 분류할 수 있습니다.

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

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

Kubernetes VolumeSnapshot 객체는 볼륨의 스냅샷 생성을 요청하는 것입니다. PVC가 사용자가 볼륨을 요청하는 것을 나타내는 것처럼, 볼륨 스냅샷은 사용자가 기존 PVC의 스냅샷 생성을 요청하는 것입니다.

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

Kubernetes VolumeSnapshotContent 객체는 이미 프로비저닝된 볼륨에서 생성된 스냅샷을 나타냅니다. 이는 PersistentVolume`와 유사하며 스토리지 클러스터에 프로비저닝된 스냅샷을 의미합니다. `PersistentVolumeClaim 및 PersistentVolume 객체와 마찬가지로 스냅샷이 생성되면 VolumeSnapshotContent 객체는 스냅샷 생성을 요청한 VolumeSnapshot 객체와 일대일 매핑을 유지합니다.

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

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

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

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

Kubernetes VolumeGroupSnapshotContent 객체는 이미 프로비저닝된 볼륨에서 생성된 그룹 스냅샷을 나타냅니다. 이는 PersistentVolume`와 유사하며 스토리지 클러스터에 프로비저닝된 스냅샷을 의미합니다. `PersistentVolumeClaim 및 PersistentVolume 객체와 마찬가지로 스냅샷이 생성되면 VolumeSnapshotContent 객체는 스냅샷 생성을 요청한 VolumeSnapshot 객체와 일대일 매핑을 유지합니다.

스냅샷 요청이 들어오면 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`을 사용하여 백엔드를 생성하면 Kubernetes에서 사용할 수 있는 해당 `tridentbackends CRD 객체가 생성됩니다.

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

Trident는 프로비저너 필드에 csi.trident.netapp.io`를 지정하는 Kubernetes `StorageClass 오브젝트에 대해 일치하는 스토리지 클래스를 생성합니다. 스토리지 클래스 이름은 해당 Kubernetes StorageClass 오브젝트의 이름과 일치합니다.

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

REST API를 사용하여 스토리지 클래스 구성을 생성하면 스토리지 클래스를 직접 정의할 수 있습니다. 하지만 Kubernetes 배포의 경우, 새로운 Kubernetes StorageClass 객체를 등록할 때 스토리지 클래스 구성이 생성될 것으로 예상합니다.

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

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

스토리지 풀은 각 백엔드에서 프로비저닝에 사용할 수 있는 개별 위치를 나타냅니다. ONTAP의 경우 이는 SVM의 애그리게이트에 해당합니다. NetApp HCI/SolidFire의 경우 이는 관리자가 지정한 QoS 대역에 해당합니다. 각 스토리지 풀에는 성능 특성과 데이터 보호 특성을 정의하는 여러 가지 스토리지 속성이 있습니다.

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

볼륨은 프로비저닝의 기본 단위로, 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 객체는 아래에 나열된 속성을 포함합니다.

Kubernetes VolumeSnapshot 객체 요청이 생성되면 Trident는 백업 스토리지 시스템에서 스냅샷 객체를 생성하여 작동합니다. 이 스냅샷 객체의 internalName`는 접두사 `snapshot-`와 `UID 객체의 VolumeSnapshot`를 결합하여 생성됩니다(예: `snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660). volumeName 및 `volumeInternalName`는 백업 볼륨의 세부 정보를 가져와 채워집니다.

Trident 데몬셋은 system-node-critical 우선순위 클래스(Kubernetes에서 사용 가능한 가장 높은 우선순위 클래스)를 사용하여 정상적인 노드 종료 중에 Trident가 볼륨을 식별하고 정리할 수 있도록 하며, 리소스 부하가 높은 클러스터에서 Trident 데몬셋 파드가 우선순위가 낮은 워크로드를 선점할 수 있도록 합니다.

이를 위해 Trident는 ResourceQuota 객체를 사용하여 Trident 데몬셋에서 "system-node-critical" 우선순위 클래스가 충족되도록 합니다. 배포 및 데몬셋 생성 전에 Trident는 ResourceQuota 객체를 찾고, 찾지 못하면 적용합니다.

기본 리소스 할당량 및 우선순위 클래스를 더 세밀하게 제어해야 하는 경우 custom.yaml`를 생성하거나 Helm 차트를 사용하여 `ResourceQuota 객체를 구성할 수 있습니다.

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

리소스 할당량에 대한 자세한 내용은 "Kubernetes: 리소스 할당량"을 참조하십시오.