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

kubectl로 백엔드를 만듭니다

기여자
PDF

백엔드는 Astra Trident와 스토리지 시스템 간의 관계를 정의합니다. Astra Trident가 스토리지 시스템과 통신하는 방법과 Astra Trident가 스토리지 시스템에서 볼륨을 프로비저닝하는 방법을 알려줍니다. Astra Trident를 설치한 후 다음 단계는 백엔드를 생성하는 것입니다. '트리펜엔드구성' 사용자 정의 리소스 정의(CRD)를 사용하면 Kubernetes 인터페이스를 통해 Trident 백엔드를 직접 생성하고 관리할 수 있습니다. 쿠베틀이나 이와 동등한 CLI 툴을 사용하여 Kubernetes를 배포할 수 있습니다.

TridentBackendConfig

트리젠벤디Config('tbc', 'tbconfig', 'tbackendconfig')는 쿠벡틀로 아스트라 트리덴트 백엔드를 관리할 수 있는 프론트이자 이름있는 CRD입니다. 이제 Kubernetes 및 스토리지 관리자는 전용 명령줄 유틸리티('tridentctl')를 사용하지 않고 Kubernetes CLI를 통해 직접 백엔드를 생성 및 관리할 수 있습니다.

'트리펜엔드구성' 객체가 생성되면 다음과 같은 현상이 발생합니다.

  • 백엔드는 사용자가 제공하는 구성에 따라 Astra Trident에서 자동으로 생성합니다. 이는 내부적으로 트리덴백엔드(트리덴백엔드) CR로 표현된다.

  • 트리젠트백엔드구성은 아스트라 트리덴트(Astra Trident)가 만든 트리젠백엔드(트리젠백엔드)에 고유하게 바인딩됩니다.

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

경고 트리젠백엔드 CRS는 아스트라 트리덴트(Astra Trident)에 의해 자동으로 생성됩니다. 수정할 수 없습니다. 백엔드에 대한 업데이트를 하려면 '트리엔백구성' 개체를 수정하여 이 작업을 수행하십시오.

'트리엔백엔드구성' 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 - 장착 공구" 원하는 스토리지 플랫폼/서비스의 샘플 구성을 위한 디렉토리입니다.

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

이번 시기에는 트리젠백엔드Config CR에 새로 도입된 자격 증명과 delitionPolicy 필드가 포함되어 있습니다.

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

  • "설명 정책": 이 필드는 트리젠BackendConfig가 삭제될 때 발생하는 동작을 정의합니다. 다음 두 가지 값 중 하나를 사용할 수 있습니다.

    • 삭제(Delete): 이 경우 트리엔백엔드Config CR과 관련 백엔드가 모두 삭제됩니다. 이 값이 기본값입니다.

    • [Tain]: 트리덴트Config CR이 삭제되면 백엔드 정의가 계속 존재하고 tridentctl로 관리될 수 있다. 삭제 정책을 "보존"으로 설정하면 사용자는 이전 릴리스(21.04 이전)로 다운그레이드하고 생성된 백엔드를 유지할 수 있습니다. 이 필드의 값은 '트리엔백엔드구성'이 생성된 후에 업데이트할 수 있습니다.

참고 백엔드 이름은 'pec.backendName'을 사용하여 설정됩니다. 지정하지 않으면 백엔드 이름이 '트리엔백엔드구성' 객체(metadata.name 지정합니다. 'pec.backendName'을 사용하여 백엔드 이름을 명시적으로 설정하는 것이 좋습니다.
팁 tridentctl로 만든 백엔드에는 관련된 트리젠BackendConfig 객체가 없습니다. 트리젠백엔드Config CR을 만들어 kubctl로 백엔드를 관리할 수 있습니다. 동일한 구성 매개 변수(예: 'pec.backendName', 'pec.storagePrefix', 'pec.storageDriverName' 등)를 지정할 때는 주의해야 합니다. Astra Trident는 새로 생성된 '트리젠백엔드구성'을 기존 백엔드와 자동으로 바인딩합니다.

단계 개요

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

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

  2. '트리멘백엔드구성' 객체를 만듭니다. 스토리지 클러스터/서비스에 대한 자세한 내용과 이전 단계에서 생성한 암호를 참조하십시오.

백엔드를 생성한 후 "kubbtl 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 경제입니다

ONTAP

챕터시토시크릿

CHAP 이니시에이터 암호입니다. useCHAP = TRUE인 경우 필수입니다. ONTAP-SAN과 ONTAP-SAN 경제입니다

ONTAP

chapTargetUsername 을 선택합니다

대상 사용자 이름입니다. useCHAP = TRUE인 경우 필수입니다. ONTAP-SAN과 ONTAP-SAN 경제입니다

ONTAP

챕터타겟이니터시크릿

CHAP 타겟 이니시에이터 암호입니다. useCHAP = TRUE인 경우 필수입니다. ONTAP-SAN과 ONTAP-SAN 경제입니다

이 단계에서 만든 암호는 다음 단계에서 만든 트리젠백엔드Config 개체의 '증명서' 필드에 참조됩니다.

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

이제 '트리엔백구성' CR을 만들 준비가 되었습니다. 이 예에서 '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 있습니다

이제 '트리펜엔드구성' 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

백엔드가 성공적으로 생성되어 '트리엔백엔드구성' CR에 바인딩되었습니다.

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

  • 바운드: 트리젠백엔드Config CR은 백엔드와 연결되며 백엔드에는 트리젠백엔드Config CR의 uid로 설정된 configRef가 포함되어 있습니다.

  • 'Unbound': ''로 표현됨. 트리젠백엔드Config 객체가 백엔드에 바인딩되지 않습니다. 새로 만든 트리젠백엔드Config CRS는 기본적으로 이 단계에 있습니다. 단계가 변경된 후에는 다시 바인딩되지 않은 상태로 되돌릴 수 없습니다.

  • "트리엔테구성" CR의 "설명 정책"이 삭제되도록 설정되었습니다. 트리젠백엔드Config CR이 삭제되면 삭제 상태로 전환됩니다.

    • 백엔드에 영구 볼륨 클레임(PVCs)이 없는 경우, 트리엔백엔드구성을 삭제하면 Astra Trident가 백엔드를 삭제하고 '트리엔백구성' CR을 삭제합니다.

    • 백엔드에 PVC가 하나 이상 있는 경우 삭제 상태로 전환됩니다. 이후 트리젠백엔드Config CR도 삭제 단계로 진입한다. 모든 PVC가 삭제된 후에만 백엔드 및 트리젠백엔드구성이 삭제됩니다.

  • 손실: 트리젠백엔드Config CR과 관련된 백엔드가 실수로 또는 고의적으로 삭제되었고, 트리젠백엔드Config CR에는 삭제된 백엔드에 대한 참조가 여전히 있습니다. 이 경우에도 '항목 정책' 값에 관계없이 '트리멘백엔드구성' CR은 삭제할 수 있습니다.

  • 알 수 없음: Astra Trident가 ' Trident' CR과 연관된 백엔드의 상태 또는 존재를 확인할 수 없습니다. 예를 들어, 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 덤프를 얻을 수도 있습니다.

$ 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'에는 '트리젠BackendConfig' CR에 대응하여 만든 백엔드의 'backendName'과 'backendUUID'가 포함되어 있습니다. 'lastOperationStatus' 필드는 사용자 트리거(예: 사용자가 'spec'에서 무언가를 변경한 경우) 또는 Astra Trident(예: Astra Trident 재시작 시)에 의해 트리거될 수 있는 '트리엔백엔드 Config' CR의 마지막 작업 상태를 나타냅니다. 성공 또는 실패일 수 있습니다. 단계 는 트리젠백엔드Config CR과 백엔드 간의 관계를 나타냅니다. 위의 예에서 'phase'는 값이 바인딩되어 있어 '트리젠백엔드구성' CR이 백엔드와 연결되어 있음을 의미합니다.

"kubbctl -n trident tbc <tbc-cr-name>" 명령을 실행하여 이벤트 로그의 세부 정보를 확인할 수 있습니다.

경고 tridentctl을 사용하여 연결된 'TrientBackendConfig' 객체가 포함된 백엔드는 업데이트하거나 삭제할 수 없습니다. tridentctl과 트리멘BackendConfig의 전환 단계를 이해하려면 "여기 를 참조하십시오".