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

kubectl로 백엔드를 만듭니다

기여자
PDF

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

TridentBackendConfig

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

개체를 만들 때 TridentBackendConfig 다음과 같은 작업이 수행됩니다.

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

  • 은 TridentBackendConfig Astra Trident에서 생성된 에 고유한 바인딩됩니다. TridentBackend

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

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

CR 포맷은 다음 예를 참조하십시오 TridentBackendConfig.

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 섹션에는 CR에 새로 도입된 TridentBackendConfig 및 deletionPolicy 필드도 포함되어 credentials 있습니다.

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

  • deletionPolicy: 이 필드는 가 삭제될 때 어떤 일이 일어나는지 정의합니다. TridentBackendConfig 다음 두 가지 값 중 하나를 사용할 수 있습니다.

    • delete: 이로 인해 CR과 연결된 백엔드가 모두 삭제됩니다 TridentBackendConfig. 이 값이 기본값입니다.

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

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

단계 개요

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

  1. Create a "쿠버네티스 비밀". 비밀에는 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

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

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

2단계: TridentBackendConfig CR을 생성합니다

이제 CR을 만들 준비가 TridentBackendConfig 되었습니다. 이 예에서는 아래 표시된 객체를 사용하여 드라이버를 TridentBackendConfig 사용하는 백엔드를 ontap-san 생성합니다.

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단계: CR의 상태를 확인합니다 TridentBackendConfig

이제 CR을 생성했으므로 TridentBackendConfig 상태를 확인할 수 있습니다. 다음 예를 참조하십시오.

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에 바인딩되었습니다. TridentBackendConfig

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

  • Bound: TridentBackendConfig CR은 백엔드와 연결되며 백엔드에는 configRef CR의 uid로 설정되어 TridentBackendConfig 있습니다.

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

  • Deleting: TridentBackendConfig CR이 deletionPolicy 삭제되도록 설정되었습니다. CR이 삭제되면 TridentBackendConfig 삭제 상태로 전환됩니다.

    • 백엔드에 영구 볼륨 클레임(PVC)이 없는 경우 을 TridentBackendConfig 삭제하면 Astra Trident이 백엔드와 CR이 삭제됩니다 TridentBackendConfig.

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

  • Lost: CR과 연결된 백엔드가 TridentBackendConfig 실수로 또는 의도적으로 삭제되었고 TridentBackendConfig CR은 삭제된 백엔드에 대한 참조를 여전히 가지고 있습니다. TridentBackendConfig`값에 관계없이 CR을 삭제할 수 `deletionPolicy 있습니다.

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

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

(선택 사항) 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 CR에 대한 응답으로 생성된 백엔드의 TridentBackendConfig 및 가 backendUUID 포함되어 backendName 있습니다. lastOperationStatus`이 필드는 CR의 마지막 작업 상태를 나타냅니다. 이 상태는 `TridentBackendConfig 사용자가 트리거하거나(예: 사용자가 변경된 항목을 에서) Astra Trident에 의해 트리거될 수 있습니다 spec(예: Astra Trident 재시작 중). 성공 또는 실패일 수 있습니다. phase CR과 백엔드 간의 관계 상태를 TridentBackendConfig 나타냅니다. 위의 예에서 에는 phase 값이 바인딩되어 있습니다. 즉, CR이 백엔드와 연결되어 있음을 TridentBackendConfig 의미합니다.

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

경고 을 사용하여 연결된 개체가 tridentctl 포함된 백엔드를 업데이트하거나 삭제할 수 TridentBackendConfig 없습니다. 과"여기 를 참조하십시오"(와 TridentBackendConfig) 사이의 전환과 관련된 단계를 이해합니다 tridentctl.