24.02 릴리스부터 Trident는 2월, 6월, 10월에 4개월마다 릴리스됩니다.

Trident는 일반적으로 Kubernetes의 알파 기능을 지원하지 않습니다. Trident는 Kubernetes 베타 릴리스 이후 출시되는 두 번의 Trident 릴리스에서 베타 기능을 지원할 수 있습니다.

Trident는 다른 NetApp 소프트웨어 제품에 대한 종속성이 없으며 독립형 애플리케이션으로 작동합니다. 단, NetApp 백엔드 스토리지 장치가 있어야 합니다.

예. Prometheus 엔드포인트를 사용하면 관리되는 백엔드 수, 프로비저닝된 볼륨 수, 사용된 바이트 수 등 Trident 운영에 대한 정보를 수집할 수 있습니다. 모니터링 및 분석을 위해 "Cloud Insights"를 사용할 수도 있습니다.

아니요. 사용자 경험 및 기능 측면에서 변경 사항은 없습니다. 사용되는 프로비저너 이름은 `csi.trident.netapp.io`입니다. 현재 및 향후 릴리스에서 제공하는 모든 새로운 기능을 사용하려면 이 Trident 설치 방법을 권장합니다.

예, Trident는 오프라인으로 설치할 수 있습니다. "Trident 설치에 대해 알아보세요"을(를) 참조하십시오.

예. Trident 18.10 이상 버전은 클러스터에 대한 kubectl 액세스 권한이 있는 모든 컴퓨터에서 원격 설치 기능을 지원합니다. kubectl 액세스 권한이 확인되면(예: 원격 컴퓨터에서 kubectl get nodes 명령을 실행하여 확인), 설치 지침을 따르십시오.

Trident는 하나의 인스턴스로 구성된 Kubernetes Deployment(ReplicaSet)로 설치되므로 고가용성(HA)이 내장되어 있습니다. Deployment의 복제본 수를 늘리지 않는 것이 좋습니다. Trident가 설치된 노드에 장애가 발생하거나 Pod에 접근할 수 없는 경우, Kubernetes는 자동으로 Pod를 클러스터 내의 정상적인 노드에 재배포합니다. Trident는 컨트롤 플레인 전용이므로 Trident가 재배포되더라도 현재 마운트된 Pod에는 영향을 미치지 않습니다.

Trident는 애플리케이션이 새 PVC를 요청하는 시기를 확인하기 위해 Kubernetes API Server에서 읽으므로 kube-system에 대한 액세스가 필요합니다.

Trident 설치 프로그램은 Kubernetes ClusterRole을 생성하며, 이 역할은 클러스터의 PersistentVolume, PersistentVolumeClaim, StorageClass 및 Secret 리소스에 대한 특정 액세스 권한을 가집니다. "tridentctl 설치 사용자 지정"를 참조하십시오.

필요한 경우 Trident가 설치에 사용하는 정확한 매니페스트 파일을 로컬에서 생성하고 수정할 수 있습니다. "tridentctl 설치 사용자 지정"을 참조하십시오.

권장되지는 않지만, 두 개의 Trident 인스턴스에 동일한 백엔드 SVM을 사용할 수 있습니다. 설치 중 각 인스턴스에 고유한 볼륨 이름을 지정하고/또는 StoragePrefix 매개변수를 setup/backend.json 파일에 고유하게 지정하십시오. 이는 동일한 FlexVol 볼륨이 두 인스턴스 모두에 사용되지 않도록 하기 위함입니다.

Trident는 단순히 Kubernetes Pod이며 Kubernetes가 실행되는 모든 곳에 설치할 수 있습니다.

네, Trident는 AWS, Google Cloud 및 Azure에서 지원됩니다.

Trident는 오픈 소스이며 무료로 제공되지만, NetApp 백엔드가 지원되는 경우 NetApp에서 완벽하게 지원합니다.

지원 케이스를 제기하려면 다음 중 하나를 수행하십시오.

질문, 문제 또는 요청 사항이 있으시면 Trident "Discord 채널" 또는 GitHub를 통해 문의하십시오.

Trident가 Kubernetes 노드를 찾지 못하는 이유는 크게 두 가지입니다. Kubernetes 내부의 네트워킹 문제이거나 DNS 문제일 수 있습니다. 각 Kubernetes 노드에서 실행되는 Trident 노드 데몬셋은 Trident 컨트롤러와 통신하여 노드를 Trident에 등록할 수 있어야 합니다. Trident 설치 후 네트워킹 변경이 발생한 경우, 이 문제는 클러스터에 추가된 새 Kubernetes 노드에서만 발생합니다.

Trident Pod가 삭제되더라도 데이터는 손실되지 않습니다. Trident 메타데이터는 CRD 객체에 저장됩니다. Trident에서 프로비저닝한 모든 PV는 정상적으로 작동합니다.

NetApp은 Trident를 한 주요 릴리스에서 바로 다음 주요 릴리스로 업그레이드하는 것을 지원합니다. 18.xx에서 19.xx로, 19.xx에서 20.xx로 등 버전 간에 업그레이드할 수 있습니다. 운영 구축 전에 랩에서 업그레이드를 테스트해야 합니다.

업그레이드 후 발견된 버그, 종속성 문제 또는 업그레이드 실패나 불완전한 업그레이드에 대한 수정이 필요한 경우, "Trident 제거" 해당 버전의 특정 지침을 사용하여 이전 버전을 다시 설치해야 합니다. 이것이 이전 버전으로 다운그레이드하는 유일하게 권장되는 방법입니다.

관리 LIF는 필수입니다. DataLIF는 다양합니다.

예. Trident는 ONTAP 백엔드에 대해 양방향 CHAP를 지원합니다. 이를 위해서는 백엔드 구성에서 `useCHAP=true`를 설정해야 합니다.

Trident는 버전 20.04부터 동적으로 내보내기 정책을 생성하고 관리할 수 있습니다. 이를 통해 스토리지 관리자는 백엔드 구성에서 하나 이상의 CIDR 블록을 제공할 수 있으며, Trident는 이러한 범위에 속하는 노드 IP를 생성되는 내보내기 정책에 추가합니다. 이러한 방식으로 Trident는 지정된 CIDR 내의 IP를 가진 노드에 대한 규칙 추가 및 삭제를 자동으로 관리합니다.

Trident는 다음에 대한 IPv6 주소 정의를 지원합니다.

Trident는 IPv6에서 작동하려면 --use-ipv6 플래그( tridentctl 설치용), IPv6(Trident 운영자용) 또는 tridentTPv6(Helm 설치용)를 사용하여 설치해야 합니다.

예, tridentctl update backend 명령을 사용하여 백엔드 관리 LIF를 업데이트할 수 있습니다.

Trident는 동일한 드라이버 또는 서로 다른 드라이버를 사용하여 여러 백엔드를 동시에 지원할 수 있습니다.

Trident는 백엔드 자격 증명을 Kubernetes Secrets로 저장합니다.

백엔드 속성을 사용하여 클래스에 적합한 풀을 자동으로 선택할 수 없는 경우 storagePools 및 additionalStoragePools 매개변수를 사용하여 특정 풀 세트를 선택합니다.

동일한 유형의 백엔드가 여러 개 구성된 경우 Trident는 StorageClass 및 PersistentVolumeClaim`에 있는 매개변수를 기반으로 적절한 백엔드를 선택합니다. 예를 들어 ontap-nas 드라이버 백엔드가 여러 개 있는 경우 Trident는 `StorageClass 및 PersistentVolumeClaim`의 매개변수를 조합하여 일치시키고 `StorageClass 및 `PersistentVolumeClaim`에 나열된 요구 사항을 제공할 수 있는 백엔드를 찾습니다. 요청과 일치하는 백엔드가 여러 개 있는 경우 Trident는 그중 하나를 임의로 선택합니다.

예.

백엔드 정의 파일에서 매개변수를 설정하여 Trident에서 프로비저닝한 볼륨에 대한 Unix 권한을 설정할 수 있습니다.

기본적으로 Trident는 Kubernetes에서 마운트 옵션을 아무 값으로도 설정하지 않습니다. Kubernetes 스토리지 클래스에서 마운트 옵션을 지정하려면 "여기"에 제공된 예제를 따르세요.

적절한 호스트가 볼륨에 액세스할 수 있도록 하려면 백엔드 정의 파일에 구성된 exportPolicy 매개변수를 사용하십시오.

백엔드 정의 파일의 암호화 매개변수를 사용하여 Trident에서 프로비저닝한 볼륨에 암호화를 설정할 수 있습니다. 자세한 내용은 다음을 참조하십시오. "Trident가 NVE 및 NAE와 작동하는 방식"

ONTAP 드라이버는 씬 프로비저닝 또는 씩 프로비저닝을 지원합니다. ONTAP 드라이버는 기본적으로 씬 프로비저닝을 사용합니다. 씩 프로비저닝을 사용하려면 백엔드 정의 파일 또는 `StorageClass`를 구성해야 합니다. 둘 다 구성된 경우 `StorageClass`이 우선 적용됩니다. ONTAP에 대해 다음을 구성합니다.

Kubernetes 버전 1.10부터 PVC 보호 기능이 자동으로 활성화됩니다.

예. Trident에서 생성한 PVC를 확장할 수 있습니다. 단, 볼륨 자동 확장은 ONTAP 기능이며 Trident에는 적용되지 않습니다.

외부 볼륨이 DP 모드이거나 오프라인 상태인 경우 볼륨 가져오기가 실패합니다. 다음과 같은 오류 메시지가 표시됩니다.

Kubernetes 스토리지 리소스 할당량은 NetApp 스토리지 용량이 충분한 한 정상적으로 작동해야 합니다. NetApp 스토리지가 용량 부족으로 인해 Kubernetes 할당량 설정을 준수할 수 없는 경우, Trident가 프로비저닝을 시도하지만 오류가 발생합니다.

예. 주문형 볼륨 스냅샷 생성 및 스냅샷에서 영구 볼륨 생성은 Trident에서 지원됩니다. 스냅샷에서 PV를 생성하려면 VolumeSnapshotDataSource 기능 게이트가 활성화되어 있어야 합니다.

오늘부터 당사의 ontap-nas, ontap-nas-flexgroup, ontap-san, ontap-san-economy, solidfire-san 및 azure-netapp-files 백엔드 드라이버에 대해 온디맨드 스냅샷 지원이 제공됩니다.

이것은 ontap-nas, ontap-san 및 ontap-nas-flexgroup 드라이버에서 사용할 수 있습니다. 또한 FlexVol 레벨에서 ontap-san-economy 드라이버에 대해 `snapshotPolicy`를 지정할 수도 있습니다.

이 기능은 ontap-nas-economy 드라이버에서도 사용할 수 있지만 qtree 수준 세분성이 아닌 FlexVol 볼륨 수준 세분성으로 제공됩니다. Trident에서 프로비저닝한 볼륨을 스냅샷으로 생성하려면 백엔드 매개변수 옵션 `snapshotPolicy`을 ONTAP 백엔드에 정의된 원하는 스냅샷 정책으로 설정하십시오. 스토리지 컨트롤러에서 생성한 스냅샷은 Trident에서 인식되지 않습니다.

예, 백엔드 정의 파일에서 snapshotReserve 속성을 설정하여 Trident를 통해 스냅샷 복사본을 저장하기 위한 특정 디스크 공간 비율을 예약할 수 있습니다. 백엔드 정의 파일에서 snapshotPolicy 및 snapshotReserve`를 구성한 경우 백엔드 파일에 언급된 `snapshotReserve 비율에 따라 스냅샷 예약 비율이 설정됩니다. snapshotReserve 비율 번호가 언급되지 않은 경우 ONTAP는 기본적으로 스냅샷 예약 비율을 5로 설정합니다. snapshotPolicy 옵션이 none으로 설정된 경우 스냅샷 예약 비율은 0으로 설정됩니다.

예, 백엔드 정의 파일에서 snapshotDir 매개변수를 설정하면 Trident로 프로비저닝된 볼륨의 스냅샷 디렉터리에 액세스할 수 있습니다.

현재 SnapMirror는 ONTAP CLI 또는 OnCommand System Manager를 사용하여 외부에서 설정해야 합니다.

볼륨을 ONTAP 스냅샷으로 복원하려면 다음 단계를 수행하십시오.

NFS를 통해 데이터를 제공하는 SVM의 루트 볼륨에 대해 로드 공유 미러를 생성할 수 있습니다. ONTAP는 Trident에서 생성한 볼륨에 대한 로드 공유 미러를 자동으로 업데이트합니다. 이로 인해 볼륨 마운트가 지연될 수 있습니다. Trident를 사용하여 여러 볼륨을 생성하는 경우 볼륨 프로비저닝은 ONTAP가 로드 공유 미러를 업데이트하는 것에 따라 달라집니다.

Kubernetes는 네임스페이스의 스토리지 클래스를 허용하지 않습니다. 그러나 네임스페이스별 스토리지 리소스 할당량을 사용하여 네임스페이스당 특정 스토리지 클래스의 사용을 제한할 수 있습니다. 특정 네임스페이스가 특정 스토리지에 액세스하지 못하도록 하려면 해당 스토리지 클래스의 리소스 할당량을 0으로 설정하십시오.