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

Trident 설치에 대해 알아봅니다

기여자

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

Trident 24.06에 대한 중요 정보입니다

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

<strong> Trident </strong>에 대한 중요 정보입니다
  • Kubernetes 1.31가 이제 Trident에서 지원됩니다. Kubernetes를 업그레이드하기 전에 Trident를 업그레이드하십시오.

  • Trident은 multipath.conf 파일에서 권장 값을 값으로 하여 SAN 환경에서 다중 경로 구성을 엄격히 적용합니다 find_multipaths: no.

    비 경로 다중화 구성 또는 의 사용 find_multipaths: yes 또는 find_multipaths: smart multipath.conf 파일의 값으로 인해 마운트 오류가 발생합니다. Trident에서 의 사용을 권장했습니다 find_multipaths: no 21.07 릴리스 이후.

시작하기 전에

설치 경로에 관계없이 다음 항목이 있어야 합니다.

  • 지원되는 버전의 Kubernetes 및 기능 요구 사항을 실행하는 지원되는 Kubernetes 클러스터에 대한 모든 권한이 활성화됩니다. 를 검토합니다 "요구 사항" 를 참조하십시오.

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

  • 모든 Kubernetes 작업자 노드에서 볼륨을 마운트할 수 있습니다.

  • 가 설치된 Linux 호스트 kubectl (또는 oc, OpenShift를 사용하는 경우) 사용하려는 Kubernetes 클러스터를 관리하도록 설치 및 구성한 것입니다.

  • 를 클릭합니다 KUBECONFIG Kubernetes 클러스터 구성을 가리키도록 설정된 환경 변수입니다.

  • Docker Enterprise와 함께 Kubernetes를 사용하는 경우, "다음 단계에 따라 CLI 액세스를 설정합니다".

팁 에 익숙하지 않은 경우 "기본 개념"이제 아주 좋은 시간입니다.

설치 방법을 선택합니다

적합한 설치 방법을 선택합니다. 의 고려 사항도 검토해야 합니다 "방법 간 이동" 결정을 내리기 전에

Trident 연산자 사용

수동으로 배포하든 Helm을 사용하든 Trident 운영자는 설치를 단순화하고 Trident 리소스를 동적으로 관리할 수 있는 훌륭한 방법입니다. "Trident 운영자 배포를 사용자 지정합니다"사용자 정의 리소스(CR)의 특성을 사용할 TridentOrchestrator 수도 있습니다.

Trident 연산자를 사용하면 다음과 같은 이점이 있습니다.

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

Trident 운영자가 Kubernetes 버전에 대해 다음 오브젝트를 자동으로 생성합니다.

  • 운영자용 ServiceAccount입니다

  • ServiceAccount에 대한 ClusterRole 및 ClusterRoleBinding

  • 전용 PodSecurityPolicy(Kubernetes 1.25 이하)

  • 작업자 자체

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

클러스터 범위의 Trident 운전자가 클러스터 수준에서 Trident 설치와 관련된 리소스를 관리합니다. 이렇게 하면 네임스페이스 범위 연산자를 사용하여 클러스터 범위 리소스를 유지 관리할 때 발생할 수 있는 오류가 줄어듭니다. 이는 자가 복구 및 패치에 필수적입니다.

<strong> 자동 복구 기능 </strong>

운영자는 Trident 설치를 모니터링하고 배포가 삭제되거나 실수로 수정된 경우와 같은 문제를 해결하기 위한 조치를 적극적으로 수행합니다. trident-operator-<generated-id>`CR을 Trident 설치와 연결하는 POD가 `TridentOrchestrator 생성됩니다. 이렇게 하면 클러스터에 Trident 인스턴스가 하나만 존재하고 해당 설정이 제어되므로 설치가 제대로 이루어지는지 확인할 수 있습니다. 설치 변경(예: 배포 또는 노드 반점 삭제)이 수행되면 운영자가 이를 식별하고 개별적으로 수정합니다.

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

기존 배포를 운영자로 쉽게 업데이트할 수 있습니다. 를 편집하기만 하면 됩니다 TridentOrchestrator CR을 사용하여 설치를 업데이트합니다.

예를 들어 디버그 로그를 생성하기 위해 Trident를 활성화해야 하는 경우를 생각해 보십시오. 이렇게 하려면 를 패치하여 TridentOrchestrator 로 설정합니다 spec.debug true.

kubectl patch torc <trident-orchestrator-name> -n trident --type=merge -p '{"spec":{"debug":true}}'

이후 TridentOrchestrator 이 업데이트되면 운영자가 업데이트를 처리하고 기존 설치를 패치합니다. 이 경우 새 Pod가 생성되어 적절히 설치가 수정될 수 있습니다.

<strong> Clean </strong> 재설치

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

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

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

참고 클러스터가 지원되지 않는 버전으로 업그레이드되면 운영자는 Trident를 설치할 수 없습니다. Trident를 운영자와 함께 이미 설치한 경우 Trident가 지원되지 않는 Kubernetes 버전에 설치되었음을 나타내는 경고가 표시됩니다.

사용 tridentctl

업그레이드해야 하는 기존 배포가 있거나 배포를 고도로 사용자 지정하려는 경우 고려해야 합니다. 이것이 기존의 Trident 구축 방법입니다.

Trident 리소스에 대한 매니페스트를 생성할 수 있습니다. 여기에는 배포, demonset, 서비스 계정 및 Trident가 설치 과정에서 생성하는 클러스터 역할이 포함됩니다.

참고 22.04 릴리스부터는 Trident를 설치할 때마다 AES 키가 더 이상 재생성되지 않습니다. 이 릴리스에서는 Trident가 설치 전반에 걸쳐 유지되는 새 비밀 개체를 설치합니다. 즉 tridentctl, 22.04에서는 이전 버전의 Trident를 제거할 수 있지만 이전 버전에서는 22.04 설치를 제거할 수 없습니다. 적절한 installation_method_를 선택합니다.

설치 모드를 선택합니다

조직에서 요구하는 installation mode(Standard, Offline 또는 Remote)를 기반으로 배포 프로세스를 결정합니다.

표준 설치

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

표준 모드를 사용하는 경우 Trident 설치 프로그램은 다음을 수행합니다.

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

  • 구축 또는 노드 데몬을 생성하여 Kubernetes 클러스터의 모든 적격 노드에서 Trident Pod를 구동합니다

오프라인 설치

오프라인 설치 모드는 공기 박수나 안전한 위치에 필요할 수 있습니다. 이 시나리오에서는 필요한 Trident 및 CSI 이미지를 저장하기 위해 단일 전용 미러된 레지스트리 또는 두 개의 미러링된 레지스트리를 만들 수 있습니다.

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

다음은 원격 설치 프로세스에 대한 상위 수준의 개요입니다.

  • Trident를 배포하려는 원격 컴퓨터에 적절한 버전의 를 kubectl 배포합니다.

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

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

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

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

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

방법 설치 모드

Trident 운영자(수동)

Trident 운영자(제어)

tridentctl

설치 방법 간 이동

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

  • 항상 동일한 방법으로 Trident를 설치 및 제거합니다. 과 함께 를 배포한 경우 tridentctl 적절한 버전의 바이너리를 사용하여 Trident를 제거해야 tridentctl 합니다. 마찬가지로 운영자와 함께 를 배포하는 경우 CR을 편집하고 spec.uninstall=true Trident를 제거하도록 설정해야 TridentOrchestrator 합니다.

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

  • 작업자 기반의 수동 배포를 사용하고 H제어 기반 Trident 연산자 배포를 사용하려는 경우 먼저 수동으로 연산자를 제거한 다음 Helm 설치를 수행해야 합니다. 이를 통해 Helm은 필요한 레이블 및 주석을 사용하여 Trident 연산자를 배포할 수 있습니다. 이렇게 하지 않으면 레이블 유효성 검사 오류 및 주석 유효성 검사 오류와 함께 H제어 기반 Trident 연산자 배포가 실패합니다. 가 있는 경우 `tridentctl`기반 배포에서는 문제 없이 Helm 기반 배포를 사용할 수 있습니다.

기타 알려진 구성 옵션

VMware Tanzu 포트폴리오 제품에 Trident를 설치하는 경우:

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

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

    Trident 연산자, Hrom 및 tridentctl 배포에서는 -kubelet -dir 을 사용하여 kubelet 위치를 지정하는 작업이 알려져 있습니다.