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

문제 해결

10/29/2025 기여자

PDF

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

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

일반적인 문제 해결

Trident 포드가 제대로 올라오지 않는 경우(예: Trident 포드가 끼어 있는 경우) ContainerCreating 2개 미만의 준비된 컨테이너가 있는 단계) 실행 중 kubectl -n trident describe deployment trident 그리고 kubectl -n trident describe pod trident--** 추가적인 통찰력을 제공할 수 있습니다. kubelet 로그 얻기(예: journalctl -xeu kubelet )도 도움이 될 수 있습니다.
Trident 로그에 충분한 정보가 없으면 다음을 전달하여 Trident 에 대한 디버그 모드를 활성화해 볼 수 있습니다. -d 설치 옵션에 따라 설치 매개변수에 플래그를 지정합니다.

그런 다음 디버그가 설정되었는지 확인하십시오. ./tridentctl logs -n trident 그리고 검색 중 level=debug msg 로그에.
Operator로 설치됨
kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'

이렇게 하면 모든 Trident 포드가 재시작되는데, 몇 초 정도 걸릴 수 있습니다. 출력에서 'AGE' 열을 관찰하여 이를 확인할 수 있습니다. kubectl get pod -n trident .

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 백엔드 정의에서. 예를 들어 다음을 포함합니다. debugTraceFlags: {"api":true, "method":true,} Trident 로그에서 API 호출과 메서드 탐색을 얻습니다. 기존 백엔드는 다음을 가질 수 있습니다. debugTraceFlags 로 구성됨 tridentctl backend update .
Red Hat Enterprise Linux CoreOS(RHCOS)를 사용하는 경우 다음 사항을 확인하십시오. iscsid 작업자 노드에서 활성화되어 있으며 기본적으로 시작됩니다. 이 작업은 OpenShift MachineConfigs를 사용하거나 점화 템플릿을 수정하여 수행할 수 있습니다.
Trident 를 사용할 때 발생할 수 있는 일반적인 문제 "Azure NetApp Files" 테넌트와 클라이언트 비밀이 권한이 부족한 앱 등록에서 나오는 경우입니다. Trident 요구 사항의 전체 목록은 다음을 참조하세요."Azure NetApp Files" 구성.
컨테이너에 PV를 장착하는 데 문제가 있는 경우 다음을 확인하십시오. rpcbind 설치 및 실행 중입니다. 호스트 OS에 필요한 패키지 관리자를 사용하여 확인하십시오. rpcbind 실행 중입니다. 상태를 확인할 수 있습니다 rpcbind 서비스를 실행하여 systemctl status rpcbind 또는 이에 상응하는 것.
Trident 백엔드가 다음 위치에 있다고 보고하는 경우 failed 이전에는 작동했던 상태이지만 백엔드와 관련된 SVM/관리자 자격 증명을 변경한 것으로 인해 발생한 것일 가능성이 높습니다. 백엔드 정보 업데이트 tridentctl update backend 또는 Trident 포드를 튀기면 이 문제가 해결됩니다.
컨테이너 런타임으로 Docker를 사용하여 Trident 설치할 때 권한 문제가 발생하는 경우 다음을 사용하여 Trident 를 설치해 보세요. --in cluster=false 깃발. 이렇게 하면 설치 프로그램 포드를 사용하지 않으므로 다음과 같은 권한 문제가 발생하지 않습니다. 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 배포하는 경우 상태 TridentOrchestrator 변경 사항 Installing 에게 Installed . 당신이 관찰한다면 Failed 상태가 좋지 않고 운영자가 스스로 복구할 수 없는 경우 다음 명령을 실행하여 운영자의 로그를 확인해야 합니다.

tridentctl logs -l 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'

이 오류는 이미 존재함을 나타냅니다. TridentOrchestrator Trident 설치하는 데 사용되었습니다. 각 Kubernetes 클러스터에는 Trident 인스턴스가 하나만 있을 수 있으므로 운영자는 주어진 시간에 활성 인스턴스가 하나만 존재하도록 보장합니다. TridentOrchestrator 창조할 수 있다는 것입니다.

또한, Trident 포드의 상태를 관찰하면 무언가 잘못되었을 때를 알 수 있는 경우가 많습니다.

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

컨테이너 이미지 하나 이상을 가져오지 못했기 때문에 포드가 완전히 초기화되지 않았다는 것을 명확하게 알 수 있습니다.

문제를 해결하려면 다음을 편집해야 합니다. TridentOrchestrator 크.알. 또는 삭제할 수 있습니다 TridentOrchestrator , 수정되고 정확한 정의를 사용하여 새 정의를 만듭니다.

Trident 배포 실패 `tridentctl`

무엇이 잘못되었는지 알아내려면 다음을 사용하여 설치 프로그램을 다시 실행할 수 있습니다.-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을 사용하여 Trident 제거하고 CRD를 완전히 제거하려면:

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

<code>트라이던트ctl</code>

Trident 제거한 후 CRD를 완전히 제거하려면 다음을 사용하십시오. tridentctl

tridentctl obliviate crd

Kubernetes 1.26에서 RWX 원시 블록 네임스페이스로 인한 NVMe 노드 언스테이징 실패

Kubernetes 1.26을 실행하는 경우 RWX 원시 블록 네임스페이스와 함께 NVMe/TCP를 사용하면 노드 스테이징 취소가 실패할 수 있습니다. 다음 시나리오는 이러한 오류에 대한 해결 방법을 제공합니다. 또는 Kubernetes를 1.27로 업그레이드할 수 있습니다.

네임스페이스와 포드를 삭제했습니다.

Pod에 Trident 관리 네임스페이스(NVMe 영구 볼륨)가 연결된 시나리오를 생각해 보세요. 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.
.해결 방법
모든 기능을 복원하려면 dataLIFS를 불러오세요.

삭제된 네임스페이스 매핑

 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` 하위 시스템으로 돌아갑니다.

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

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