본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

문제 해결

02/25/2026

PDF

Trident를 설치하고 사용하는 동안 발생할 수 있는 문제를 해결하기 위해 여기에 제공된 포인터를 사용하십시오.

Trident에 대한 도움이 필요하면 `tridentctl logs -a -n trident`을 사용하여 지원 번들을 생성하고 NetApp 지원팀으로 보내주십시오.

일반적인 문제 해결

Trident Pod가 제대로 시작되지 않는 경우(예: Trident Pod가 ContainerCreating 단계에서 준비된 컨테이너가 두 개 미만인 상태로 멈추는 경우), kubectl -n trident describe deployment trident 및 `kubectl -n trident describe pod trident--**`를 실행하면 추가적인 정보를 얻을 수 있습니다. kubelet 로그를 얻는 것(예: `journalctl -xeu kubelet`를 통해)도 도움이 될 수 있습니다.
Trident 로그에 충분한 정보가 없는 경우 설치 옵션에 따라 설치 매개변수에 -d 플래그를 전달하여 Trident의 디버그 모드를 활성화해 볼 수 있습니다.

그런 다음 `./tridentctl logs -n trident`을 사용하여 디버그가 설정되어 있는지 확인하고 로그에서 `level=debug msg`를 검색하십시오.
Operator와 함께 설치됨
kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'

이렇게 하면 모든 Trident Pod가 다시 시작되며 몇 초 정도 걸릴 수 있습니다. `kubectl get pod -n trident`의 출력에서 'AGE' 열을 확인하여 이를 확인할 수 있습니다.

Trident 20.07 및 20.10에서는 tprov`을(를) `torc 대신 사용하십시오.
Helm으로 설치됨
helm upgrade <name> trident-operator-21.07.1-custom.tgz --set tridentDebug=true`
tridentctl로 설치됨
./tridentctl uninstall -n trident ./tridentctl install -d -n trident
각 백엔드 정의에 `debugTraceFlags`를 포함하여 각 백엔드의 디버그 로그를 얻을 수도 있습니다. 예를 들어, Trident 로그에서 API 호출 및 메서드 트래버설을 얻으려면 `debugTraceFlags: {"api":true, "method":true,}`를 포함하세요. 기존 백엔드는 `debugTraceFlags`를 `tridentctl backend update`와 함께 구성할 수 있습니다.
Red Hat Enterprise Linux CoreOS(RHCOS)를 사용하는 경우 `iscsid`이 워커 노드에서 활성화되어 기본적으로 시작되도록 해야 합니다. 이는 OpenShift MachineConfigs를 사용하거나 ignition 템플릿을 수정하여 수행할 수 있습니다.
Trident를 "Azure NetApp Files" 사용할 때 발생할 수 있는 일반적인 문제는 테넌트 및 클라이언트 암호가 권한이 부족한 앱 등록에서 제공되는 경우입니다. Trident 요구 사항의 전체 목록은 "Azure NetApp Files" 구성을 참조하십시오.
PV를 컨테이너에 마운트하는 데 문제가 있는 경우, rpcbind`가 설치되어 실행 중인지 확인하십시오. 호스트 OS에 맞는 패키지 관리자를 사용하여 `rpcbind`가 실행 중인지 확인하십시오. `rpcbind 서비스의 상태는 systemctl status rpcbind 또는 이에 상응하는 명령어를 실행하여 확인할 수 있습니다.
Trident 백엔드가 이전에는 정상적으로 작동했음에도 불구하고 failed 상태를 보고하는 경우, 이는 백엔드와 연결된 SVM/관리자 자격 증명이 변경되었기 때문일 가능성이 높습니다. `tridentctl update backend`를 사용하여 백엔드 정보를 업데이트하거나 Trident Pod를 재시작하면 이 문제가 해결됩니다.
Docker를 컨테이너 런타임으로 사용하여 Trident를 설치할 때 권한 문제가 발생하는 경우 --in cluster=false 플래그를 사용하여 Trident 설치를 시도하십시오. 이렇게 하면 설치 프로그램 Pod를 사용하지 않으므로 trident-installer 사용자로 인해 발생하는 권한 문제를 방지할 수 있습니다.
실행 실패 후 정리 작업에 `uninstall parameter <Uninstalling Trident>`를 사용하세요. 기본적으로 이 스크립트는 Trident에서 생성한 CRD를 제거하지 않으므로 실행 중인 배포 환경에서도 안전하게 제거하고 다시 설치할 수 있습니다.
Trident의 이전 버전으로 다운그레이드하려면 먼저 tridentctl uninstall 명령을 실행하여 Trident를 제거하십시오. 원하는 "Trident 버전"를 다운로드하고 tridentctl install 명령을 사용하여 설치하십시오.
설치가 성공적으로 완료된 후 PVC가 Pending 단계에서 멈춰 있는 경우 `kubectl describe pvc`를 실행하면 Trident가 해당 PVC에 대한 PV 프로비저닝에 실패한 이유에 대한 추가 정보를 얻을 수 있습니다.

운영자를 사용한 Trident 배포 실패

Trident 오퍼레이터를 사용하여 Trident를 배포하는 경우 TridentOrchestrator`의 상태가 `Installing`에서 `Installed`로 변경됩니다. `Failed 상태를 확인했는데 오퍼레이터가 자체적으로 복구되지 않으면 다음 명령을 실행하여 오퍼레이터 로그를 확인해야 합니다.

tridentctl logs -l trident-operator

trident-operator 컨테이너의 로그를 추적하면 문제가 있는 위치를 파악할 수 있습니다. 예를 들어, 이러한 문제 중 하나는 에어갭 환경에서 업스트림 레지스트리로부터 필요한 컨테이너 이미지를 가져올 수 없는 경우일 수 있습니다.

Trident 설치가 실패한 이유를 이해하려면 TridentOrchestrator 상태를 확인해야 합니다.

kubectl describe torc trident-2
Name:         trident-2
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  trident.netapp.io/v1
Kind:         TridentOrchestrator
...
Status:
  Current Installation Params:
    IPv6:
    Autosupport Hostname:
    Autosupport Image:
    Autosupport Proxy:
    Autosupport Serial Number:
    Debug:
    Image Pull Secrets:         <nil>
    Image Registry:
    k8sTimeout:
    Kubelet Dir:
    Log Format:
    Silence Autosupport:
    Trident Image:
  Message:                      Trident is bound to another CR 'trident'
  Namespace:                    trident-2
  Status:                       Error
  Version:
Events:
  Type     Reason  Age                From                        Message
  ----     ------  ----               ----                        -------
  Warning  Error   16s (x2 over 16s)  trident-operator.netapp.io  Trident is bound to another CR 'trident'

이 오류는 Trident를 설치하는 데 사용된 `TridentOrchestrator`이(가) 이미 있음을 나타냅니다. 각 Kubernetes 클러스터에는 Trident 인스턴스가 하나만 있을 수 있으므로 운영자는 언제든지 생성할 수 있는 활성 `TridentOrchestrator`이(가) 하나만 존재하도록 보장합니다.

또한 Trident Pod의 상태를 관찰하면 문제가 있는지 여부를 파악하는 데 도움이 될 수 있습니다.

kubectl get pods -n trident

NAME                                READY   STATUS             RESTARTS   AGE
trident-csi-4p5kq                   1/2     ImagePullBackOff   0          5m18s
trident-csi-6f45bfd8b6-vfrkw        4/5     ImagePullBackOff   0          5m19s
trident-csi-9q5xc                   1/2     ImagePullBackOff   0          5m18s
trident-csi-9v95z                   1/2     ImagePullBackOff   0          5m18s
trident-operator-766f7b8658-ldzsv   1/1     Running            0          8m17s

하나 이상의 컨테이너 이미지를 가져오지 못했기 때문에 Pod가 완전히 초기화되지 못하는 것을 명확하게 확인할 수 있습니다.

이 문제를 해결하려면 TridentOrchestrator CR을 편집해야 합니다. 또는 `TridentOrchestrator`를 삭제하고 수정된 정확한 정의로 새 CR을 생성할 수도 있습니다.

`tridentctl`을 사용한 Trident 배포 실패

무엇이 잘못되었는지 파악하는 데 도움이 되도록 -d 인수를 사용하여 설치 프로그램을 다시 실행할 수 있습니다. 이렇게 하면 디버그 모드가 활성화되어 문제가 무엇인지 이해하는 데 도움이 됩니다.

./tridentctl install -n trident -d

문제를 해결한 후에는 다음과 같이 설치를 정리하고 tridentctl install 명령을 다시 실행하십시오.

./tridentctl uninstall -n trident
INFO Deleted Trident deployment.
INFO Deleted cluster role binding.
INFO Deleted cluster role.
INFO Deleted service account.
INFO Removed Trident user from security context constraint.
INFO Trident uninstallation succeeded.

Trident 및 CRD를 완전히 제거합니다

Trident와 생성된 모든 CRD 및 관련 사용자 지정 리소스를 완전히 제거할 수 있습니다.

이 작업은 되돌릴 수 없습니다. Trident를 완전히 새로 설치하려는 경우가 아니면 이 작업을 수행하지 마십시오. CRD를 제거하지 않고 Trident를 제거하려면 "Trident 제거"을(를) 참조하십시오.

Trident 운영자

Trident 운영자를 사용하여 Trident를 제거하고 CRD를 완전히 삭제하려면 다음을 수행합니다.

kubectl patch torc <trident-orchestrator-name> --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'

Helm

Helm을 사용하여 Trident를 제거하고 CRD를 완전히 제거하려면 다음을 수행합니다.

kubectl patch torc trident --type=merge -p '{"spec":{"wipeout":["crds"],"uninstall":true}}'

<code>tridentctl</code>

`tridentctl`을 사용하여 Trident를 제거한 후 CRD를 완전히 제거하려면

tridentctl obliviate crd

Kubernetes 1.26에서 RWX raw 블록 네임스페이스를 사용하는 NVMe 노드 언스테이징 실패

Kubernetes 1.26을 실행 중인 경우 RWX raw 블록 네임스페이스와 함께 NVMe/TCP를 사용할 때 노드 언스테이징이 실패할 수 있습니다. 다음 시나리오는 장애에 대한 해결 방법을 제공합니다. 또는 Kubernetes를 1.27로 업그레이드할 수 있습니다.

네임스페이스와 Pod를 삭제했습니다

Trident 관리형 네임스페이스(NVMe 영구 볼륨)가 Pod에 연결되어 있는 시나리오를 생각해 보겠습니다. ONTAP 백엔드에서 네임스페이스를 직접 삭제하면 Pod 삭제 시도 후 스테이징 해제 프로세스가 멈춥니다. 이 시나리오는 Kubernetes 클러스터 또는 다른 기능에는 영향을 미치지 않습니다.

해결 방법

해당 네임스페이스에 해당하는 영구 볼륨을 해당 노드에서 마운트 해제하고 삭제하십시오.

차단된 데이터 LIF

 If you block (or bring down) all the dataLIFs of the NVMe Trident backend, the unstaging process gets stuck when you attempt to delete the pod. In this scenario, you cannot run any NVMe CLI commands on the Kubernetes node.
.해결 방법
dataLIF를 가동하여 전체 기능을 복원하십시오.

삭제된 네임스페이스 매핑

 If you remove the `hostNQN` of the worker node from the corresponding subsystem, the unstaging process gets stuck when you attempt to delete the pod. In this scenario, you cannot run any NVMe CLI commands on the Kubernetes node.
.해결 방법
 `hostNQN`을 서브시스템에 다시 추가하세요.

NFSv4.2 클라이언트는 ONTAP 업그레이드 후 "v4.2-xattrs"가 활성화될 것으로 예상할 때 "잘못된 인수"를 보고합니다

ONTAP 업그레이드 후 NFSv4.2 클라이언트가 NFSv4.2 내보내기를 마운트하려고 할 때 "잘못된 인수" 오류를 보고할 수 있습니다. 이 문제는 SVM에서 v4.2-xattrs 옵션이 활성화되지 않은 경우 발생합니다. .해결 방법 SVM에서 v4.2-xattrs 옵션을 활성화하거나 ONTAP 9.12.1 이상으로 업그레이드하십시오. 이 옵션은 기본적으로 활성화되어 있습니다.