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

Trident 설치에 대해 알아보세요

PDF

다양한 환경과 조직에 Trident를 설치할 수 있도록 NetApp에서는 여러 설치 옵션을 제공합니다. Trident 운영자(수동 또는 Helm 사용)를 사용하거나 `tridentctl`를 사용하여 Trident를 설치할 수 있습니다. 이 항목에서는 적합한 설치 프로세스를 선택하는 데 필요한 중요한 정보를 제공합니다.

Trident 25.10에 대한 중요 정보

Trident에 대한 다음 중요 정보를 읽어야 합니다.

<strong>Trident에 대한 중요 정보</strong>

  • Kubernetes 1.34는 이제 Trident에서 지원됩니다. Kubernetes를 업그레이드하기 전에 Trident를 먼저 업그레이드하십시오.

  • Trident는 SAN 환경에서 다중 경로 구성 사용을 엄격하게 시행하며, multipath.conf 파일에 권장 값은 `find_multipaths: no`입니다.

    다중 경로를 사용하지 않는 구성 또는 multipath.conf 파일에서 find_multipaths: yes 또는 find_multipaths: smart 값을 사용하면 마운트가 실패합니다. Trident는 21.07 릴리스부터 find_multipaths: no 사용을 권장해 왔습니다.

시작하기 전에

설치 경로와 관계없이 다음 항목이 반드시 필요합니다.

  • 지원되는 버전의 Kubernetes가 실행되고 기능 요구 사항이 활성화된 지원되는 Kubernetes 클러스터에 대한 모든 권한이 필요합니다. 자세한 내용은 "요구사항"을(를) 참조하십시오.

  • 지원되는 NetApp 스토리지 시스템에 대한 액세스.

  • 모든 Kubernetes 작업자 노드에서 볼륨을 마운트하는 기능.

  • kubectl(또는 OpenShift를 사용하는 경우 oc)가 설치 및 구성되어 사용하려는 Kubernetes 클러스터를 관리하는 Linux 호스트.

  • KUBECONFIG 환경 변수가 Kubernetes 클러스터 구성을 가리키도록 설정되어 있습니다.

  • Docker Enterprise와 함께 Kubernetes를 사용하는 경우 "CLI 액세스를 활성화하려면 해당 단계를 따르십시오".

  • 클러스터는 권한 있는 워크로드를 지원해야 합니다.

팁 "기본 개념"에 대해 아직 잘 모르신다면 지금이 바로 알아볼 좋은 기회입니다.

설치 방법을 선택하십시오

본인에게 맞는 설치 방법을 선택하세요. 결정하기 전에 "방법 간 이동"에 대한 고려 사항도 검토해야 합니다.

Trident 운영자 사용

수동으로 배포하든 Helm을 사용하든, Trident operator는 설치를 간소화하고 Trident 리소스를 동적으로 관리하는 훌륭한 방법입니다. 속성을 사용하여 "Trident 운영자 배포를 사용자 지정하세요"도 할 수 있으며, 이는 TridentOrchestrator 커스텀 리소스(CR)에서 가능합니다.

Trident 운영자 사용의 이점은 다음과 같습니다.

<strong>Trident 객체 생성</strong>

Trident 운영자는 Kubernetes 버전에 대해 다음 개체를 자동으로 생성합니다.

  • 운영자를 위한 ServiceAccount

  • ClusterRole 및 ClusterRoleBinding을 ServiceAccount에 추가합니다

  • 전용 PodSecurityPolicy(Kubernetes 1.25 이하 버전용)

  • 운영자 자체

<strong>리소스 책임</strong>

클러스터 범위의 Trident 오퍼레이터는 클러스터 수준에서 Trident 설치와 관련된 리소스를 관리합니다. 이를 통해 네임스페이스 범위의 오퍼레이터를 사용하여 클러스터 범위 리소스를 관리할 때 발생할 수 있는 오류를 줄일 수 있습니다. 이는 자체 복구 및 패치에 필수적입니다.

<strong>자가 치유 기능</strong>

운영자는 Trident 설치를 모니터링하고 배포가 삭제되거나 실수로 수정되는 등의 문제를 해결하기 위해 적극적으로 조치를 취합니다. trident-operator-<generated-id> Pod가 생성되어 TridentOrchestrator CR을 Trident 설치와 연결합니다. 이를 통해 클러스터에 Trident 인스턴스가 하나만 존재하도록 하고 설정을 제어하여 설치가 멱등성을 갖도록 합니다. 설치에 변경 사항이 발생하면(예: 배포 또는 노드 daemonset 삭제) 운영자는 이를 식별하고 개별적으로 수정합니다.

<strong>기존 설치에 대한 간편한 업데이트</strong>

운영자를 이용하면 기존 배포를 간편하게 업데이트할 수 있습니다. 설치를 업데이트하려면 TridentOrchestrator CR만 편집하면 됩니다.

예를 들어, Trident가 디버그 로그를 생성하도록 설정해야 하는 시나리오를 생각해 보십시오. 이를 위해 `TridentOrchestrator`를 패치하여 `spec.debug`를 `true`로 설정하십시오:

kubectl patch torc <trident-orchestrator-name> -n trident --type=merge -p '{"spec":{"debug":true}}'
`TridentOrchestrator`가 업데이트되면 operator는 업데이트를 처리하고 기존 설치에 패치를 적용합니다. 이로 인해 설치를 적절히 수정하기 위해 새 pod 생성이 트리거될 수 있습니다.
<strong>클린 재설치</strong>

클러스터 범위 Trident 운영자를 사용하면 클러스터 범위 리소스를 깔끔하게 제거할 수 있습니다. 사용자는 Trident를 완전히 제거하고 쉽게 다시 설치할 수 있습니다.

<strong>자동 Kubernetes 업그레이드 처리</strong>

클러스터의 Kubernetes 버전이 지원되는 버전으로 업그레이드되면 운영자는 기존 Trident 설치를 자동으로 업데이트하고 Kubernetes 버전의 요구 사항을 충족하도록 변경합니다.

참고 클러스터가 지원되지 않는 버전으로 업그레이드되면 오퍼레이터는 Trident 설치를 방지합니다. 오퍼레이터를 통해 Trident가 이미 설치된 경우, 지원되지 않는 Kubernetes 버전에 Trident가 설치되었다는 경고 메시지가 표시됩니다.

사용 tridentctl

기존 배포 환경을 업그레이드해야 하거나 배포 환경을 고도로 맞춤 설정하려는 경우 를 고려해야 합니다. 이것은 Trident를 배포하는 기존 방법입니다.

를 사용하여 Trident 리소스에 대한 매니페스트를 생성할 수 있습니다. 여기에는 Trident가 설치의 일부로 생성하는 배포, 데몬셋, 서비스 계정 및 클러스터 역할이 포함됩니다.

참고 22.04 릴리스부터 Trident를 설치할 때마다 AES 키를 다시 생성하지 않습니다. 이 릴리스에서는 Trident가 설치 전반에 걸쳐 유지되는 새로운 secret 객체를 설치합니다. 즉, tridentctl 22.04에서는 이전 버전의 Trident를 제거할 수 있지만 이전 버전에서는 22.04 설치를 제거할 수 없습니다. 적절한 설치 _방법_을 선택하십시오.

설치 모드를 선택하십시오

조직에서 요구하는 설치 모드(표준, 오프라인 또는 원격)에 따라 배포 프로세스를 결정하십시오.

표준 설치

이는 Trident를 설치하는 가장 쉬운 방법이며 네트워크 제한이 없는 대부분의 환경에서 작동합니다. 표준 설치 모드는 기본 레지스트리를 사용하여 필요한 Trident(docker.io 및 CSI(registry.k8s.io 이미지를 저장합니다.

표준 모드를 사용하면 Trident 설치 프로그램은 다음과 같습니다.

  • 인터넷을 통해 컨테이너 이미지를 가져옵니다

  • Kubernetes 클러스터 내의 모든 적합한 노드에 Trident Pod를 실행하는 배포 또는 노드 데몬셋을 생성합니다

오프라인 설치

외부와 완전히 분리된 환경이나 보안이 강화된 장소에서는 오프라인 설치 모드가 필요할 수 있습니다. 이 경우, 필요한 Trident 및 CSI 이미지를 저장하기 위해 단일 개인 미러링 레지스트리 또는 두 개의 미러링 레지스트리를 생성할 수 있습니다.

참고 레지스트리 구성에 관계없이 CSI 이미지는 하나의 레지스트리에 있어야 합니다.
원격 설치

다음은 원격 설치 프로세스에 대한 개략적인 개요입니다.

  • Trident를 배포하려는 원격 시스템에 `kubectl`의 적절한 버전을 배포합니다.

  • Kubernetes 클러스터에서 구성 파일을 복사하고 원격 시스템에 KUBECONFIG 환경 변수를 설정하십시오.

  • kubectl get nodes 명령을 시작하여 필요한 Kubernetes 클러스터에 연결할 수 있는지 확인합니다.

  • 표준 설치 단계를 사용하여 원격 시스템에서 배포를 완료합니다.

방법 및 모드에 따라 프로세스를 선택합니다

결정을 내린 후 적절한 프로세스를 선택합니다.

방법 설치 모드

Trident 운영자(수동)

"표준 설치"

"오프라인 설치"

Trident 운영자(Helm)

"표준 설치"

"오프라인 설치"

tridentctl

"표준 또는 오프라인 설치"

설치 방법 간 이동

설치 방법을 변경할 수도 있습니다. 변경하기 전에 다음 사항을 고려하십시오.

  • Trident를 설치 및 제거할 때는 항상 동일한 방법을 사용하십시오. tridentctl`를 사용하여 배포한 경우 적절한 버전의 `tridentctl 바이너리를 사용하여 Trident를 제거해야 합니다. 마찬가지로 오퍼레이터를 사용하여 배포하는 경우 TridentOrchestrator CR을 편집하고 `spec.uninstall=true`를 설정하여 Trident를 제거해야 합니다.

  • 운영자 기반 배포를 제거하고 대신 `tridentctl`을 사용하여 Trident를 배포하려면 먼저 `TridentOrchestrator`를 편집하고 `spec.uninstall=true`를 설정하여 Trident를 제거해야 합니다. 그런 다음 `TridentOrchestrator`와 운영자 배포를 삭제합니다. `tridentctl`를 사용하여 설치할 수 있습니다.

  • 수동 오퍼레이터 기반 배포 방식을 사용하다가 Helm 기반 Trident 오퍼레이터 배포 방식으로 전환하려면, 먼저 기존 오퍼레이터를 수동으로 제거한 후 Helm을 사용하여 설치해야 합니다. 이렇게 하면 Helm이 필요한 레이블과 어노테이션을 포함하여 Trident 오퍼레이터를 배포할 수 있습니다. 이 단계를 거치지 않으면 Helm 기반 Trident 오퍼레이터 배포 시 레이블 유효성 검사 오류와 어노테이션 유효성 검사 오류가 발생합니다.

  • tridentctl 기반 배포 환경이 있는 경우 Trident를 제거하지 않고 Helm 기반 또는 Operator 기반 배포를 수행할 수 있습니다.

기타 알려진 구성 옵션

VMWare Tanzu Portfolio 제품에 Trident를 설치할 때:

  • --kubelet-dir 플래그는 kubelet 디렉터리의 위치로 설정해야 합니다. 기본적으로 이것은 `/var/vcap/data/kubelet`입니다.

    `--kubelet-dir`을 사용하여 kubelet 위치를 지정하는 것은 Trident Operator, Helm 및  `tridentctl` 배포에서 작동하는 것으로 알려져 있습니다.