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

Trident은 일반적으로 Kubernetes에서 알파 기능을 지원하지 않습니다. Trident는 Kubernetes 베타 릴리즈를 따르는 두 Trident 릴리스 내에서 베타 기능을 지원할 수 있습니다.

Trident는 다른 NetApp 소프트웨어 제품에 의존하지 않으며 독립 실행형 애플리케이션으로 작동합니다. 그러나 NetApp 백엔드 스토리지 디바이스가 있어야 합니다.

명령을 사용하여 tridentctl get Trident 구성에 대한 자세한 정보를 얻을 수 있습니다.

예. Prometheus 끝점은 관리되는 백 엔드 수, 프로비저닝된 볼륨 수, 사용된 바이트 등 Trident 작업에 대한 정보를 수집하는 데 사용할 수 있습니다. 모니터링 및 분석에도 를 "Cloud Insights"사용할 수 있습니다.

아니요. 사용자 환경 및 기능에 관한 한 변경 사항은 없습니다. 사용된 Provisioner 이름은 입니다 csi.trident.netapp.io. 이 Trident 설치 방법은 현재 및 향후 릴리스에서 제공하는 모든 새 기능을 사용하려는 경우에 권장됩니다.

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

예. Trident 18.10 이상에서는 클러스터에 액세스할 수 있는 모든 컴퓨터에서 원격 설치 기능을 kubectl 지원합니다. 액세스가 확인된 후 kubectl(예: 원격 컴퓨터에서 명령을 시작하여 kubectl get nodes 확인) 설치 지침을 따릅니다.

Trident는 하나의 인스턴스가 있는 Kubernetes 배포(ReplicaSet)로 설치되므로 HA가 내장되어 있습니다. 배포에서 복제 수를 늘리면 안 됩니다. Trident가 설치된 노드가 손실되거나 Pod에 액세스할 수 없는 경우 Kubernetes는 이 Pod를 클러스터의 정상 노드로 자동으로 재구축합니다. Trident는 컨트롤 플레인만 해당하므로, 현재 마운트된 Pod를 Trident 재배포하면 영향을 받지 않습니다.

Trident는 애플리케이션이 새로운 PVC를 요청하는 시기를 결정하기 위해 Kubernetes API 서버에서 읽으므로, kube-시스템에 액세스해야 합니다.

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

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

권장하지는 않지만 두 개의 Trident 인스턴스에 대해 동일한 백엔드 SVM을 사용할 수 있습니다. 설치하는 동안 각 인스턴스에 대해 고유한 볼륨 이름을 지정하거나 파일에 고유한 StoragePrefix 매개 변수를 setup/backend.json 지정합니다. 이는 동일한 FlexVol가 두 인스턴스에 모두 사용되지 않도록 하기 위한 것입니다.

Trident는 단순한 Kubernetes Pod로, Kubernetes가 실행 중인 모든 곳에 설치할 수 있습니다.

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

예. Trident은 Azure의 Azure NetApp Files 서비스와 GCP의 Cloud Volumes Service를 지원합니다.

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

지원 케이스를 제기하려면 다음 중 하나를 수행합니다.

tridentctl logs-a를 실행하여 지원 번들을 생성할 수 있습니다. 번들에 캡처된 로그 외에 kubelet 로그를 캡처하여 Kubernetes 측의 마운트 문제를 진단합니다. 쿠벨렛 로그를 얻는 지침은 Kubernetes 설치 방법에 따라 다릅니다.

문제를 "GitTrident 허브" 작성하고 문제에 대한 주제 및 설명에 * RFE * 를 언급합니다.

에서 문제를 "GitTrident 허브" 생성합니다. 문제와 관련된 모든 필수 정보와 로그를 포함해야 합니다.

질문, 문제 또는 요청이 있는 경우 Trident 또는 GitHub를 통해 "불화 채널"문의하십시오.

백엔드의 암호를 로 업데이트합니다 tridentctl update backend myBackend -f </path/to_new_backend.json> -n trident. 대치 myBackend 백엔드 이름을 포함하는 예에서 및 입니다 `/path/to_new_backend.json 올바른 경로를 사용하여 backend.json 파일.

Trident이 Kubernetes 노드를 찾을 수 없는 두 가지 가능한 시나리오가 있습니다. Kubernetes의 네트워킹 문제 또는 DNS 문제 때문일 수 있습니다. 각 Kubernetes 노드에서 실행되는 Trident 노드 데모는 Trident 컨트롤러와 통신하여 노드를 Trident에 등록할 수 있어야 합니다. Trident를 설치한 후 네트워킹이 변경되면 클러스터에 추가되는 새로운 Kubernetes 노드에서만 이 문제가 발생합니다.

Trident POD를 제거할 경우 데이터가 손실되지 않습니다. Trident 메타데이터는 CRD 개체에 저장됩니다. Trident에서 프로비저닝한 모든 PVS가 정상적으로 작동합니다.

NetApp는 하나의 주요 릴리즈에서 다음 주요 릴리즈로 Trident 업그레이드를 지원합니다. 버전 18.xx에서 19.xx, 19.xx에서 20.xx로 업그레이드할 수 있습니다. 운영 구축 전에 연구소에서 업그레이드를 테스트해야 합니다.

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

관리 LIF는 필수입니다. 데이터 LIF는 다양합니다.

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

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

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

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

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

에서 데이터 LIF를 업데이트할 수 있습니다 ontap-nas 및 ontap-nas-economy 만 해당.

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

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

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

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

예.

'ONTAP-NAS-이코노미' 드라이버는 동일한 FlexVol에서 최대 200개의 qtree(50~300 구성 가능), 클러스터 노드당 100,000 qtree, 클러스터당 2.4M qtree를 지원합니다. 이코노미 드라이버가 서비스하는 새 "PersistentVolumeClaim"을 입력하면 운전자는 새 Qtree를 처리할 수 있는 FlexVol가 이미 있는지 확인합니다. Qtree를 처리할 수 있는 FlexVol가 없으면 새 FlexVol가 생성됩니다.

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

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

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

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

ONTAP용 QoS를 구현하려면 'torageClaes'를 사용합니다.

ONTAP 드라이버는 씬 또는 일반 프로비저닝을 지원합니다. ONTAP 드라이버는 기본적으로 씬 프로비저닝입니다. 일반 프로비저닝이 필요한 경우 백엔드 정의 파일 또는 'torageClass'를 구성해야 합니다. 둘 다 구성된 경우 'torageClass'가 우선합니다. ONTAP에 대해 다음을 구성합니다.

PVC 보호는 버전 1.10부터 Kubernetes에서 자동으로 활성화됩니다.

예. Trident에서 만든 PVC를 확장할 수 있습니다. 볼륨 자동 증가 기능은 Trident에 적용되지 않는 ONTAP 기능입니다.

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

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

예. Trident에서는 주문형 볼륨 스냅샷 및 스냅샷에서 영구 볼륨 생성이 지원됩니다. 스냅샷에서 PVS를 생성하려면 VolumeSnapshotDataSource Feature Gate가 활성화되어 있는지 확인합니다.

현재 ONTAP-NAS, ONTAP-NAS-Flexgroup, ONTAP-SAN, ONTAP-SAN-이코노미, 졸idfire-SAN의 온디맨드 스냅샷 지원을 이용할 수 있습니다. GCP-CV와 Azure-NetApp-files 백엔드 드라이버.

ONTAP-NAS, ONTAP-SAN, ONTAP-NAS-Flexgroup 드라이버에서 지원됩니다. FlexVol 레벨에서 ONTAP-SAN-이코노미 드라이버에 대한 스냅샷 정책을 지정할 수도 있습니다.

드라이버에서는 사용할 수도 있지만 FlexVol 레벨의 세분화된 레벨에서는 사용할 수 ontap-nas-economy 없습니다. Trident에서 프로비저닝한 볼륨에 대해 스냅샷을 생성할 수 있도록 하려면 backend 매개 변수 옵션을 snapshotPolicy ONTAP 백엔드에 정의된 대로 원하는 스냅샷 정책으로 설정합니다. 스토리지 컨트롤러에서 생성한 모든 스냅샷은 Trident에서 알 수 없습니다.

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

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

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

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

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

Kubernetes에서는 네임스페이스의 스토리지 클래스를 허용하지 않습니다. 그러나 Kubernetes를 사용하여 네임스페이스당 사용되는 스토리지 리소스 할당량을 사용하여 네임스페이스당 특정 스토리지 클래스의 사용을 제한할 수 있습니다. 특정 스토리지에 대한 특정 네임스페이스 액세스를 거부하려면 해당 스토리지 클래스에 대한 리소스 할당량을 0으로 설정합니다.