오브젝트, 목표 및 상호 작용 방식을 이해하는 가장 쉬운 방법은 Kubernetes 사용자의 스토리지에 대한 단일 요청을 따르는 것입니다.

Kubernetes PersistentVolumeClaim 개체는 Kubernetes 클러스터 사용자가 만든 스토리지에 대한 요청입니다.

Trident는 표준 사양 외에도 사용자가 백엔드 구성에서 설정한 기본값을 무효화하려는 경우 다음 볼륨별 주석을 지정할 수 있도록 합니다.

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

Trident는 CSI 사양을 사용하여 볼륨 스냅샷 생성을 지원합니다. 볼륨 스냅샷을 생성하고 이를 데이터 소스로 사용하여 기존 PVC를 복제할 수 있습니다. 이렇게 하면 PVS의 시점 복제본을 스냅샷 형태로 Kubernetes에 표시할 수 있습니다. 그런 다음 스냅샷을 사용하여 새 PVS를 생성할 수 있습니다. `On-Demand Volume Snapshots`이 방법이 어떻게 작동하는지 살펴보십시오.

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

예를 들어, 사용자가 이미 PVC를 호출한 경우 mysql 와 같은 주석을 사용하여 trident.netapp.io/cloneFromPVC: mysql 호출된 새 PVC를 생성할 수 mysqlclone 있습니다. 이 주석을 설정하면 Trident가 볼륨을 처음부터 프로비저닝하는 대신 MySQL PVC에 해당하는 볼륨을 클론합니다.

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

Kubernetes PersistentVolume 오브젝트는 Kubernetes 클러스터에 사용할 수 있는 스토리지 부분을 나타냅니다. 사용 포드와 독립적인 라이프 사이클이 있습니다.

Trident 기반 PVC를 생성할 때 StorageClass 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 개체는 이미 프로비저닝된 볼륨에서 생성된 스냅샷을 나타냅니다. 이 스냅샷은 A와 유사하며 PersistentVolume 스토리지 클러스터에서 프로비저닝된 스냅샷을 나타냅니다. 및 PersistentVolume 객체와 마찬가지로 PersistentVolumeClaim 스냅샷이 생성될 때 VolumeSnapshotContent 객체는 스냅샷 생성을 요청한 객체에 대한 일대일 매핑을 VolumeSnapshot 유지합니다.

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

Kubernetes 사용자 지정 리소스는 관리자가 정의하며 비슷한 객체를 그룹화하는 데 사용되는 Kubernetes API의 엔드포인트입니다. Kubernetes에서는 오브젝트 컬렉션을 저장하기 위한 사용자 지정 리소스의 생성을 지원합니다. 을 실행하여 이러한 리소스 정의를 가져올 수 kubectl get crds 있습니다.

사용자 정의 리소스 정의(CRD) 및 관련 오브젝트 메타데이터는 Kubernetes에서 메타데이터 저장소에 저장됩니다. 따라서 Trident를 위한 별도의 저장소가 필요하지 않습니다.

Astra Trident는 오브젝트를 사용하여 CustomResourceDefinition Trident 백엔드, Trident 스토리지 클래스 및 Trident 볼륨과 같은 Trident 오브젝트의 ID를 유지합니다. 이러한 오브젝트는 Trident에서 관리합니다. 또한 CSI 볼륨 스냅샷 프레임워크는 볼륨 스냅샷을 정의하는 데 필요한 일부 CRD를 소개합니다.

CRD는 Kubernetes를 구성하는 것입니다. 위에 정의된 리소스의 객체는 Trident에 의해 생성됩니다. 간단히 말해, 을 사용하여 백엔드를 생성하면 tridentctl Kubernetes에서 사용할 수 있도록 해당 tridentbackends CRD 개체가 생성됩니다.

다음은 Trident의 CRD에 대해 고려해야 할 몇 가지 사항입니다.

Trident은 Provisioner 필드에 지정된 csi.trident.netapp.io Kubernetes 오브젝트와 일치하는 스토리지 클래스를 StorageClass 생성합니다. 스토리지 클래스 이름은 이 클래스가 나타내는 Kubernetes 개체의 이름과 StorageClass 일치합니다.

스토리지 클래스는 볼륨에 대한 일련의 요구 사항으로 구성됩니다. Trident는 이러한 요구 사항을 각 스토리지 풀에 있는 속성과 일치시킵니다. 일치하는 경우 해당 스토리지 풀이 해당 스토리지 클래스를 사용하여 볼륨을 프로비저닝할 수 있는 유효한 타겟입니다.

REST API를 사용하여 스토리지 클래스를 직접 정의하는 스토리지 클래스 구성을 생성할 수 있습니다. 하지만 Kubernetes 구축의 경우 새 Kubernetes 오브젝트를 등록할 때 새 Kubernetes 오브젝트를 생성할 것으로 StorageClass 예상됩니다.

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

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

스토리지 풀은 각 백엔드에서 용량 할당에 사용할 수 있는 고유한 위치를 나타냅니다. ONTAP의 경우 SVM에 있는 애그리게이트와 대응합니다. NetApp HCI/SolidFire의 경우 관리자 지정 QoS 밴드에 해당합니다. Cloud Volumes Service의 경우 클라우드 공급자 지역에 해당합니다. 각 스토리지 풀에는 고유한 스토리지 특성 세트가 있으며, 이 특성 집합은 성능 특성과 데이터 보호 특성을 정의합니다.

다른 오브젝트와 달리 스토리지 풀 후보 는 항상 자동으로 검색되고 관리됩니다.

볼륨은 NFS 공유 및 iSCSI LUN과 같은 백엔드 엔드포인트로 구성된 기본 프로비저닝 단위입니다. Kubernetes에서 이러한 항목은 에 직접 PersistentVolumes 대응합니다. 볼륨을 생성할 때 볼륨의 용량을 할당할 수 있는 위치와 크기를 결정하는 스토리지 클래스가 있는지 확인합니다.

볼륨 구성은 프로비저닝된 볼륨에 있어야 하는 속성을 정의합니다.

Trident는 internalName 볼륨을 생성할 때 생성됩니다. 이 단계는 두 단계로 구성됩니다. 먼저 저장소 접두사(백엔드 구성의 기본값 또는 접두사)를 볼륨 이름에 접두사로 붙이고 trident 양식 이름이 <prefix>-<volume-name> 만들어집니다. 그런 다음 백엔드에서 허용되지 않는 문자를 대체하여 이름을 삭제하는 작업을 진행합니다. ONTAP 백엔드의 경우 하이픈을 밑줄로 바꿉니다(따라서 내부 이름은 이 됨 <prefix>_<volume-name>). 요소 백엔드의 경우 밑줄을 하이픈으로 바꿉니다.

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

스냅샷은 볼륨의 시점 복제본으로, 새 볼륨을 용량 할당하거나 복구 상태를 복구하는 데 사용할 수 있습니다. Kubernetes에서 이들 항목은 오브젝트에 직접 VolumeSnapshotContent 대응합니다. 각 스냅샷은 스냅샷에 대한 데이터의 소스인 볼륨에 연결됩니다.

각 Snapshot 개체에는 아래 나열된 속성이 있습니다.

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

Trident deamonset은 system-node-critical Trident가 정상적인 노드 종료 중에 볼륨을 식별 및 정리하고, Trident demonset Pod가 리소스 압력이 높은 클러스터에서 낮은 우선 순위로 워크로드를 사전 설정할 수 있도록 하기 위해 Kubernetes에서 사용 가능한 가장 높은 우선 순위 클래스인 우선 순위 클래스를 사용합니다.

이를 위해 Astra Trident는 객체를 사용하여 ResourceQuota Trident demonset의 "시스템 노드 중요" 우선 순위 클래스가 충족되도록 합니다. 구축 및 demonset 생성 전에 Astra Trident가 오브젝트를 찾고 ResourceQuota 있지 않은 경우 이를 적용합니다.

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

다음은 Trident 데모의 우선 순위를 지정하는 'ResourceQuota' 개체의 예입니다.

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