문제 해결
변경 제안
PDF
Astra Trident를 설치 및 사용하는 동안 발생할 수 있는 문제를 해결하려면 여기에 제공된 포인터를 사용하십시오.
|
Astra Trident에 대한 도움을 받으려면 'tridentctl logs-a-n tri덴트'를 사용하여 지원 번들을 생성한 후 'NetApp Support<Getting Help>'로 보내십시오. |
|
문제 해결 문서의 전체 목록을 보려면 을 참조하십시오 "NetApp Knowledgebase(로그인 필요)". Astra와 관련된 문제 해결에 대한 정보도 찾을 수 있습니다 "여기". |
일반 문제 해결
-
Trident 포드가 제대로 표시되지 않으면(예: 두 개 미만의 준비된 컨테이너로 'ContainerCreating' 단계에 Trident 포드가 들러붙은 경우) kubeck-n trident t덴트 설명 배포 트리덴트를 실행하고 'kebctl-n trident tor stand' kudl- 를 실행합니다 이 밖에도 많은 정보를 얻을 수 있습니다. 쿠벨렛 로그(예: 저널링ctl-xeu kubelet)를 얻는 것도 도움이 될 수 있습니다.
-
Trident 로그에 충분한 정보가 없으면 설치 옵션에 따라 설치 매개 변수에 '-d' 플래그를 전달하여 Trident에 대한 디버그 모드를 활성화할 수 있습니다.
그런 다음 디버그가 "./tridentctl logs -n triment"를 사용하여 설정되었는지 확인하고 로그에서 level=debug msg를 검색합니다.
- 운영자와 함께 설치됩니다
-
# kubectl patch torc trident -n <namespace> --type=merge -p '{"spec":{"debug":true}}'그러면 모든 Trident 포드가 다시 시작됩니다. 이 작업은 몇 초 정도 걸릴 수 있습니다. 'kubeck get pod-n trident'의 출력에서 '나이' 열을 관찰하여 이를 확인할 수 있습니다.
Astra Trident 20.07 및 20.10의 경우 Torc 대신 tprov를 사용합니다.
- 헬름과 함께 설치
-
$ 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 호출 및 메서드 트래버스된 메서드를 가져옵니다. 기존 백엔드는 tridentctl 백엔드 업데이트로 debugTraceFlags를 구성할 수 있습니다.
-
RedHat CoreOS를 사용할 때는 작업자 노드에서 iscsid가 활성화되어 있고 기본적으로 시작되는지 확인합니다. 이 작업은 OpenShift MachineConfigs를 사용하거나 점화 템플릿을 수정하여 수행할 수 있습니다.
-
에서 Trident를 사용할 때 일반적으로 발생할 수 있는 문제입니다 "Azure NetApp Files" 테넌트 및 클라이언트 암호가 권한이 부족한 앱 등록에서 나오는 경우 입니다. Trident 요구사항의 전체 목록은 를 참조하십시오 "Azure NetApp Files" 구성.
-
PV를 컨테이너에 마운트하는 데 문제가 있는 경우 rpcbind가 설치되어 실행되고 있는지 확인합니다. 호스트 OS에 필요한 패키지 관리자를 사용하고 rpcbind가 실행 중인지 확인합니다. 'stemctl status rpcbind' 또는 이와 동등한 기능을 실행하여 rpcbind 서비스의 상태를 확인할 수 있습니다.
-
Trident 백엔드가 이전에 작업을 수행했음에도 불구하고 "실패" 상태에 있다고 보고할 경우 백엔드와 연결된 SVM/관리 자격 증명을 변경하면 원인일 수 있습니다. 'tridentctl update backend'를 사용하여 백엔드 정보를 업데이트하거나 Trident POD를 바운딩하면 이 문제가 해결됩니다.
-
베타 볼륨 스냅샷을 사용하도록 Kubernetes 클러스터 및/또는 Trident를 업그레이드할 경우 기존의 모든 알파 스냅샷 CRS가 완전히 제거되었는지 확인합니다. 그런 다음 "tridentctl oblividate alpha-snapshot-crd" 명령을 사용하여 알파 스냅샷 CRD를 삭제할 수 있습니다. 을 참조하십시오 "블로그입니다" 알파 스냅샷 마이그레이션 단계를 이해합니다.
-
Docker를 컨테이너 런타임으로 사용하여 Trident를 설치할 때 권한 문제가 발생하면 '--in cluster=false' 플래그를 사용하여 Trident를 설치해 보십시오. 설치자 포드는 사용하지 않고 설치자 이용으로 인한 권한 문제를 피한다.
-
실패한 실행 후 정리 작업을 위해 'uninstall parameter <uninstall Trident>'를 사용합니다. 기본적으로 이 스크립트는 Trident에서 만든 CRD를 제거하지 않으므로 실행 중인 구축에서도 안전하게 제거한 후 다시 설치할 수 있습니다.
-
Trident의 이전 버전으로 다운그레이드하려는 경우 먼저 'tridenctl uninstall' 명령을 실행하여 Trident를 제거합니다. 원하는 를 다운로드합니다 "Trident 버전" tridentctl install 명령을 사용하여 설치합니다. 새로 생성된 PVS가 없고 기존 PVS/백엔드/스토리지 클래스가 변경되지 않은 경우에만 다운그레이드를 고려하십시오. Trident는 이제 CRD를 사용하여 상태를 유지하므로 생성된 모든 스토리지 엔터티(백엔드, 스토리지 클래스, PVS 및 볼륨 스냅샷)에는 이전 버전의 Trident에서 사용한 PV에 기록된 데이터 대신 연결된 CRD 객체 <Kubernetes CustomResourceDefinition Objects>"가 있습니다. * 이전 버전으로 되돌릴 때 새로 생성된 PVS를 사용할 수 없습니다. * * 다운그레이드 시 백엔드, PVS, 스토리지 클래스 및 볼륨 스냅샷(생성/업데이트/삭제)과 같은 객체에 대한 변경 사항은 Trident에 표시되지 않습니다 *. 설치된 Trident의 이전 버전에서 사용된 PV는 여전히 Trident에 표시됩니다. 이전 버전으로 돌아가면 업그레이드되지 않은 경우 이전 릴리즈를 사용하여 이미 생성된 PVS에 대한 액세스가 중단되지 않습니다.
-
Trident를 완전히 제거하려면 'tridentctl oblividate CRD' 명령을 실행합니다. 그러면 모든 CRD 객체가 제거되고 CRD의 정의가 해제됩니다. Trident는 이미 프로비저닝한 PVS를 더 이상 관리하지 않습니다.
이 후 Trident를 처음부터 다시 구성해야 합니다. -
설치가 성공적으로 완료된 후 PVC가 보류 단계에 고착되면 kubeck tl t설명해 PVC를 실행하면 Trident가 이 PVC에 대한 PV를 프로비저닝하지 못한 이유에 대한 추가 정보가 제공됩니다.
연산자를 사용하여 실패한 Trident 배포 문제 해결
연산자를 사용하여 Trident를 배포하는 경우 트리펜터터의 상태가 Installing에서 Installed로 변경됩니다. 'Failed(실패)' 상태를 확인하고 운용자가 자체적으로 복구할 수 없는 경우 다음 명령어를 실행해 운용자의 로그를 확인해야 한다.
tridentctl logs -l trident-operator
삼원 운영자 컨테이너의 로그를 뒤로하면 문제가 있는 위치를 가리킬 수 있습니다. 예를 들어, 이러한 문제 중 하나는 Airgapped 환경의 업스트림 등록부에서 필요한 컨테이너 이미지를 가져올 수 없는 것일 수 있습니다.
Trident의 설치가 실패한 이유를 이해하려면 '트리엔트오케스트레이터' 상태를 살펴보아야 합니다.
$ 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:
Enable Node Prep:
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를 설치하는 데 사용된 '트리엔오케스트레이터'가 이미 있음을 나타냅니다. 각 Kubernetes 클러스터에는 Trident의 인스턴스가 하나만 있을 수 있으므로 운영자는 언제든지 생성할 수 있는 활성 'Trident Orchestrator'가 하나만 존재하도록 합니다.
또한 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
하나 이상의 컨테이너 이미지를 가져오지 않았기 때문에 포드를 완전히 초기화할 수 없다는 것을 분명히 알 수 있습니다.
이 문제를 해결하려면 트리엔오케스트레이터 CR을 편집해야 합니다. 또는 '트리엔오케스트레이터'를 삭제하고 수정되고 정확한 정의를 가진 새 정의를 만들 수 있습니다.
를 사용하여 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.