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

kubectl로 백엔드를 만듭니다

기여자
PDF

백엔드는 Astra Trident와 스토리지 시스템 간의 관계를 정의합니다. Astra Trident가 스토리지 시스템과 통신하는 방법과 Astra Trident가 스토리지 시스템에서 볼륨을 프로비저닝하는 방법을 알려줍니다. Astra Trident를 설치한 후 다음 단계는 백엔드를 생성하는 것입니다. 를 클릭합니다 TridentBackendConfig CRD(Custom Resource Definition)를 사용하면 Kubernetes 인터페이스를 통해 Trident 백엔드를 직접 생성 및 관리할 수 있습니다. 를 사용하여 이 작업을 수행할 수 있습니다 kubectl 또는 Kubernetes 배포를 위해 동등한 CLI 도구를 사용할 수 있습니다.

TridentBackendConfig

TridentBackendConfig (tbc, tbconfig, tbackendconfig)는 을 사용하여 Astra Trident 백엔드를 관리할 수 있는 프런트엔드, 이름 있는 CRD입니다 kubectl. 이제 Kubernetes 및 스토리지 관리자는 전용 명령줄 유틸리티 없이도 Kubernetes CLI를 통해 직접 백엔드를 생성 및 관리할 수 있습니다 (tridentctl)를 클릭합니다.

를 생성할 때 TridentBackendConfig 오브젝트, 다음과 같은 현상이 발생합니다.

  • 백엔드는 사용자가 제공하는 구성에 따라 Astra Trident에서 자동으로 생성합니다. 이 항목은 내부적으로 로 표시됩니다 TridentBackend (tbe, tridentbackend) CR.

  • 를 클릭합니다 TridentBackendConfig 에 고유하게 바인딩됩니다 TridentBackend Astra Trident가 작성했습니다.

각각 TridentBackendConfig 을 사용하여 일대일 매핑을 유지합니다 TridentBackend. 전자는 백엔드를 설계 및 구성하기 위해 사용자에게 제공되는 인터페이스이며, 후자는 Trident가 실제 백엔드 객체를 나타내는 방법입니다.

경고 TridentBackend CRS는 Astra Trident에서 자동으로 생성합니다. 수정할 수 없습니다. 백엔드를 업데이트하려면 을 수정하여 이 작업을 수행합니다 TridentBackendConfig 오브젝트.

의 형식은 다음 예를 참조하십시오 TridentBackendConfig CR:

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-san
spec:
  version: 1
  backendName: ontap-san-backend
  storageDriverName: ontap-san
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  svm: trident_svm
  credentials:
    name: backend-tbc-ontap-san-secret

의 예를 살펴볼 수도 있습니다 "Trident - 장착 공구" 원하는 스토리지 플랫폼/서비스의 샘플 구성을 위한 디렉토리입니다.

를 클릭합니다 spec 백엔드 관련 구성 매개 변수를 사용합니다. 이 예에서는 백엔드에서 를 사용합니다 ontap-san 여기에 표로 제공된 구성 매개 변수를 사용하여 스토리지 드라이버를 다운로드합니다. 원하는 스토리지 드라이버에 대한 구성 옵션 목록은 를 참조하십시오 "스토리지 드라이버에 대한 백엔드 구성 정보입니다".

를 클릭합니다 spec 섹션에는 도 포함되어 있습니다 credentials 및 deletionPolicy 에 새로 도입된 필드입니다 TridentBackendConfig CR:

  • credentials: 이 매개 변수는 필수 필드이며 스토리지 시스템/서비스를 인증하는 데 사용되는 자격 증명을 포함합니다. 사용자 생성 Kubernetes Secret으로 설정됩니다. 자격 증명을 일반 텍스트로 전달할 수 없으며 오류가 발생합니다.

  • deletionPolicy: 이 필드는 에서 수행해야 하는 작업을 정의합니다 TridentBackendConfig 이(가) 삭제됩니다. 다음 두 가지 값 중 하나를 사용할 수 있습니다.

    • delete: 그러면 두 항목이 모두 삭제됩니다 TridentBackendConfig CR 및 관련 백엔드 이 값이 기본값입니다.

    • retain: 가 TridentBackendConfig CR이 삭제되어도 백엔드 정의가 계속 존재하고 로 관리할 수 있습니다 tridentctl. 삭제 정책을 로 설정합니다 retain 사용자가 이전 릴리스(21.04 이전)로 다운그레이드하고 생성된 백엔드를 유지할 수 있습니다. 이 필드의 값은 이후에 업데이트할 수 있습니다 TridentBackendConfig 이 생성됩니다.

참고 백엔드 이름은 를 사용하여 설정됩니다 spec.backendName. 지정하지 않으면 백엔드 이름이 의 이름으로 설정됩니다 TridentBackendConfig 오브젝트(metadata.name). 을 사용하여 백엔드 이름을 명시적으로 설정하는 것이 좋습니다 spec.backendName.
팁 로 만든 백엔드 tridentctl 연결된 가 없습니다 TridentBackendConfig 오브젝트. 에서 이러한 백엔드를 관리하도록 선택할 수 있습니다 kubectl 을 생성합니다 TridentBackendConfig 있습니다. 동일한 구성 매개 변수(예 spec.backendName, spec.storagePrefix, spec.storageDriverName`등). Astra Trident가 새로 생성된 을 자동으로 바인딩합니다 `TridentBackendConfig 기존 백엔드를 사용합니다.

단계 개요

을 사용하여 새 백엔드를 생성합니다 `kubectl`다음을 수행해야 합니다.

  1. 을 생성합니다 "쿠버네티스 비밀". 비밀에는 Astra Trident가 스토리지 클러스터/서비스와 통신하는 데 필요한 자격 증명이 포함되어 있습니다.

  2. 을 생성합니다 TridentBackendConfig 오브젝트. 스토리지 클러스터/서비스에 대한 자세한 내용과 이전 단계에서 생성한 암호를 참조하십시오.

백엔드를 생성한 후 을 사용하여 해당 상태를 확인할 수 있습니다 kubectl get tbc <tbc-name> -n <trident-namespace> 추가 세부 정보를 수집합니다.

1단계: Kubernetes Secret 생성

백엔드에 대한 액세스 자격 증명이 포함된 암호를 생성합니다. 이는 각 스토리지 서비스/플랫폼마다 다릅니다. 예를 들면 다음과 같습니다.

$ kubectl -n trident create -f backend-tbc-ontap-san-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-san-secret
type: Opaque
stringData:
  username: cluster-admin
  password: t@Ax@7q(>

이 표에는 각 스토리지 플랫폼의 비밀에 포함되어야 하는 필드가 요약되어 있습니다.

스토리지 플랫폼 암호 필드 설명입니다 비밀 필드 설명입니다

Azure NetApp Files

클라이언트 ID입니다

앱 등록에서 클라이언트 ID

AWS 환경을 위한 Cloud Volumes Service

ApiKey

CVS 계정 API 키입니다

AWS 환경을 위한 Cloud Volumes Service

secretKey를 선택합니다

CVS 계정 암호 키입니다

GCP용 Cloud Volumes Service

private_key_id

개인 키의 ID입니다. CVS 관리자 역할을 가진 GCP 서비스 계정에 대한 API 키의 일부

GCP용 Cloud Volumes Service

개인 키

개인 키. CVS 관리자 역할을 가진 GCP 서비스 계정에 대한 API 키의 일부

요소(NetApp HCI/SolidFire)

엔드포인트

테넌트 자격 증명이 있는 SolidFire 클러스터의 MVIP입니다

ONTAP

사용자 이름

클러스터/SVM에 연결할 사용자 이름입니다. 자격 증명 기반 인증에 사용됩니다

ONTAP

암호

클러스터/SVM에 연결하는 암호 자격 증명 기반 인증에 사용됩니다

ONTAP

clientPrivateKey를 선택합니다

Base64 - 클라이언트 개인 키의 인코딩된 값입니다. 인증서 기반 인증에 사용됩니다

ONTAP

챕터 사용자 이름

인바운드 사용자 이름입니다. useCHAP = TRUE인 경우 필수입니다. 용 ontap-san 및 ontap-san-economy

ONTAP

챕터시토시크릿

CHAP 이니시에이터 암호입니다. useCHAP = TRUE인 경우 필수입니다. 용 ontap-san 및 ontap-san-economy

ONTAP

chapTargetUsername 을 선택합니다

대상 사용자 이름입니다. useCHAP = TRUE인 경우 필수입니다. 용 ontap-san 및 ontap-san-economy

ONTAP

챕터타겟이니터시크릿

CHAP 타겟 이니시에이터 암호입니다. useCHAP = TRUE인 경우 필수입니다. 용 ontap-san 및 ontap-san-economy

이 단계에서 생성된 암호는 에서 참조됩니다 spec.credentials 의 필드 TridentBackendConfig 다음 단계에서 만든 개체입니다.

2단계: 을 작성합니다 TridentBackendConfig 있습니다

이제 을 만들 준비가 되었습니다 TridentBackendConfig 있습니다. 이 예에서는 를 사용하는 백엔드를 보여 줍니다 ontap-san 드라이버는 를 사용하여 만듭니다 TridentBackendConfig 아래 개체:

$ kubectl -n trident create -f backend-tbc-ontap-san.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-san
spec:
  version: 1
  backendName: ontap-san-backend
  storageDriverName: ontap-san
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  svm: trident_svm
  credentials:
    name: backend-tbc-ontap-san-secret

3단계: 의 상태를 확인합니다 TridentBackendConfig 있습니다

이제 를 만들었습니다 TridentBackendConfig CR, 상태를 확인할 수 있습니다. 다음 예를 참조하십시오.

$ kubectl -n trident get tbc backend-tbc-ontap-san
NAME                    BACKEND NAME          BACKEND UUID                           PHASE   STATUS
backend-tbc-ontap-san   ontap-san-backend     8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8   Bound   Success

백엔드가 생성되어 에 바인딩되었습니다 TridentBackendConfig 있습니다.

위상은 다음 값 중 하나를 사용할 수 있습니다.

  • Bound: TridentBackendConfig CR은 백엔드에 연결되어 있으며 해당 백엔드에는 가 포함되어 있습니다 configRef 로 설정합니다 TridentBackendConfig CR의 uid.

  • Unbound: 를 사용하여 나타냅니다 "". 를 클릭합니다 TridentBackendConfig 객체가 백엔드에 바인딩되지 않습니다. 모두 새로 생성되었습니다 TridentBackendConfig CRS는 기본적으로 이 단계에 있습니다. 단계가 변경된 후에는 다시 바인딩되지 않은 상태로 되돌릴 수 없습니다.

  • Deleting: TridentBackendConfig CR deletionPolicy 이(가) 삭제되도록 설정되었습니다. 를 누릅니다 TridentBackendConfig CR이 삭제되어 삭제 상태로 전환됩니다.

    • 백엔드에 지속성 용적 클레임(PVC)이 없는 경우 를 삭제합니다 TridentBackendConfig Astra Trident가 백엔드를 삭제할 뿐 아니라 도 삭제합니다 TridentBackendConfig 있습니다.

    • 백엔드에 PVC가 하나 이상 있는 경우 삭제 상태로 전환됩니다. 를 클릭합니다 TridentBackendConfig 이후에 CR은 삭제 단계를 시작합니다. 백엔드 및 TridentBackendConfig 모든 PVC가 삭제된 후에만 삭제됩니다.

  • Lost: 와 연결된 백엔드가 있습니다 TridentBackendConfig CR이 실수로 또는 고의적으로 삭제되었으며 및 이(가) 삭제되었습니다 TridentBackendConfig CR에는 삭제된 백엔드에 대한 참조가 여전히 있습니다. 를 클릭합니다 TridentBackendConfig CR은 와 상관없이 삭제할 수 있습니다 deletionPolicy 값.

  • Unknown: Astra Trident가 와 연결된 백엔드의 상태 또는 존재를 확인할 수 없습니다 TridentBackendConfig 있습니다. 예를 들어, API 서버가 응답하지 않거나 가 응답하지 않는 경우 tridentbackends.trident.netapp.io CRD가 누락되었습니다. 이 경우 사용자의 개입이 필요할 수 있습니다.

이 단계에서는 백엔드가 성공적으로 생성됩니다! 다음과 같은 몇 가지 작업을 추가로 처리할 수 있습니다 "백엔드 업데이트 및 백엔드 삭제".

(선택 사항) 4단계: 자세한 내용을 확인하십시오

다음 명령을 실행하여 백엔드에 대한 자세한 정보를 얻을 수 있습니다.

kubectl -n trident get tbc backend-tbc-ontap-san -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8   Bound   Success   ontap-san        delete

또한 의 YAML/JSON 덤프를 얻을 수도 있습니다 TridentBackendConfig.

$ kubectl -n trident get tbc backend-tbc-ontap-san -o yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  creationTimestamp: "2021-04-21T20:45:11Z"
  finalizers:
  - trident.netapp.io
  generation: 1
  name: backend-tbc-ontap-san
  namespace: trident
  resourceVersion: "947143"
  uid: 35b9d777-109f-43d5-8077-c74a4559d09c
spec:
  backendName: ontap-san-backend
  credentials:
    name: backend-tbc-ontap-san-secret
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  storageDriverName: ontap-san
  svm: trident_svm
  version: 1
status:
  backendInfo:
    backendName: ontap-san-backend
    backendUUID: 8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8
  deletionPolicy: delete
  lastOperationStatus: Success
  message: Backend 'ontap-san-backend' created
  phase: Bound

backendInfo 에 가 포함되어 있습니다 backendName 및 backendUUID 에 대한 응답으로 생성된 백엔드 TridentBackendConfig 있습니다. 를 클릭합니다 lastOperationStatus 필드는 의 마지막 작업 상태를 나타냅니다 TridentBackendConfig CR - 사용자가 트리거할 수 있습니다(예: 사용자가 에서 항목을 변경함) spec) 또는 Astra Trident(예: Astra Trident 재시작 중)에 의해 트리거됩니다. 성공 또는 실패일 수 있습니다. phase 간의 관계 상태를 나타냅니다 TridentBackendConfig CR 및 백엔드 위의 예에서 phase 에 값이 바인딩되어 있습니다. 즉, 이 에 대한 것입니다 TridentBackendConfig CR이 백엔드에 연결되어 있습니다.

를 실행할 수 있습니다 kubectl -n trident describe tbc <tbc-cr-name> 이벤트 로그의 세부 정보를 가져오는 명령입니다.

경고 연결된 가 포함된 백엔드는 업데이트하거나 삭제할 수 없습니다 TridentBackendConfig 오브젝트 사용 tridentctl. 를 사용하여 전환 단계를 이해합니다 tridentctl 및 TridentBackendConfig, "여기 를 참조하십시오".