kubectl을 사용하여 백엔드 생성
변경 제안
PDF
백엔드는 Trident와 스토리지 시스템 간의 관계를 정의합니다. 백엔드는 Trident가 해당 스토리지 시스템과 통신하는 방법과 Trident가 해당 스토리지 시스템에서 볼륨을 프로비저닝하는 방법을 알려줍니다. Trident 설치 후 다음 단계는 백엔드를 생성하는 것입니다. TridentBackendConfig Custom Resource Definition(CRD)을 사용하면 Kubernetes 인터페이스를 통해 Trident 백엔드를 직접 생성하고 관리할 수 있습니다. kubectl 또는 Kubernetes 배포판에 맞는 CLI 도구를 사용하여 수행할 수 있습니다.
TridentBackendConfig
TridentBackendConfig (tbc, tbconfig, tbackendconfig)는 프런트엔드 네임스페이스 CRD로, kubectl`를 사용하여 Trident 백엔드를 관리할 수 있도록 해줍니다. 이제 Kubernetes 및 스토리지 관리자는 별도의 명령줄 유틸리티(`tridentctl 없이 Kubernetes CLI를 통해 백엔드를 직접 생성하고 관리할 수 있습니다.
`TridentBackendConfig` 객체가 생성될 때 다음과 같은 일이 발생합니다.
-
백엔드는 사용자가 제공하는 구성을 기반으로 Trident에 의해 자동으로 생성됩니다. 이는 내부적으로
TridentBackend(tbe,tridentbackend) CR로 표현됩니다. -
`TridentBackendConfig`는 Trident에 의해 생성된 `TridentBackend`에 고유하게 바인딩됩니다.
각 `TridentBackendConfig`은 `TridentBackend`와 일대일 매핑을 유지합니다. 전자는 백엔드를 설계하고 구성하기 위해 사용자에게 제공되는 인터페이스이며, 후자는 Trident가 실제 백엔드 객체를 표현하는 방식입니다.
|
TridentBackend CR은 Trident에 의해 자동으로 생성됩니다. CR을 수정해서는 안 됩니다. 백엔드를 업데이트하려면 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-installer" 디렉터리의 예제를 참조하십시오.
`spec`는 백엔드별 구성 매개변수를 사용합니다. 이 예에서 백엔드는 `ontap-san` 스토리지 드라이버를 사용하며 여기에 표로 정리된 구성 매개변수를 사용합니다. 원하는 스토리지 드라이버에 대한 구성 옵션 목록은 link:backends.html["스토리지 드라이버에 대한 백엔드 구성 정보"^]를 참조하십시오.
`spec` 섹션에는 또한 `credentials` 및 `deletionPolicy` 필드가 포함되어 있으며, 이는 `TridentBackendConfig` CR에서 새롭게 도입되었습니다.
-
credentials: 이 매개변수는 필수 입력 항목이며 스토리지 시스템/서비스 인증에 사용되는 자격 증명을 포함합니다. 이 값은 사용자가 생성한 Kubernetes Secret으로 설정됩니다. 자격 증명을 일반 텍스트로 전달할 수 없으며, 그렇게 할 경우 오류가 발생합니다. -
deletionPolicy: 이 필드는 `TridentBackendConfig`가 삭제될 때 발생해야 하는 작업을 정의합니다. 다음 두 가지 값 중 하나를 사용할 수 있습니다.-
delete: 이렇게 하면TridentBackendConfigCR과 관련 백엔드가 모두 삭제됩니다. 이것이 기본값입니다. -
retain:TridentBackendConfigCR이 삭제되더라도 백엔드 정의는 계속 남아 있으며tridentctl`를 사용하여 관리할 수 있습니다. 삭제 정책을 `retain`로 설정하면 사용자는 이전 릴리스(21.04 이전 버전)로 다운그레이드하고 생성된 백엔드를 유지할 수 있습니다. 이 필드의 값은 `TridentBackendConfig생성 후 업데이트할 수 있습니다.
-
|
백엔드의 이름은 spec.backendName`를 사용하여 설정합니다. 지정하지 않으면 백엔드 이름은 `TridentBackendConfig 객체의 이름(metadata.name)으로 설정됩니다. `spec.backendName`를 사용하여 백엔드 이름을 명시적으로 설정하는 것이 좋습니다.
|
|
tridentctl`로 생성된 백엔드는 연결된 `TridentBackendConfig 오브젝트가 없습니다. 이러한 백엔드는 kubectl`를 사용하여 `TridentBackendConfig CR을 생성함으로써 관리할 수 있습니다. spec.backendName, spec.storagePrefix, spec.storageDriverName 등과 같은 동일한 구성 파라미터를 지정해야 하므로 주의가 필요합니다. Trident는 새로 생성된 `TridentBackendConfig`를 기존 백엔드와 자동으로 바인딩합니다.
|
단계 개요
`kubectl`를 사용하여 새 백엔드를 생성하려면 다음을 수행해야 합니다.
-
"Kubernetes Secret"을 생성합니다. 이 secret에는 Trident가 스토리지 클러스터/서비스와 통신하는 데 필요한 자격 증명이 포함되어 있습니다.
-
TridentBackendConfig객체를 생성합니다. 이 객체에는 스토리지 클러스터/서비스에 대한 세부 정보가 포함되며 이전 단계에서 생성한 비밀 키를 참조합니다.
백엔드를 생성한 후 `kubectl get tbc <tbc-name> -n <trident-namespace>`를 사용하여 상태를 확인하고 추가 세부 정보를 수집할 수 있습니다.
1단계: Kubernetes Secret 생성
백엔드에 대한 액세스 자격 증명이 포함된 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: password이 표는 각 스토리지 플랫폼의 Secret에 포함되어야 하는 필드를 요약한 것입니다.
| 스토리지 플랫폼 Secret Fields 설명 | 비밀 | 필드 설명 |
|---|---|---|
Azure NetApp Files |
clientID |
앱 등록의 클라이언트 ID |
요소(NetApp HCI/SolidFire) |
엔드포인트 |
테넌트 자격 증명이 있는 SolidFire 클러스터의 MVIP |
ONTAP |
사용자 이름 |
클러스터/SVM에 연결하는 데 사용할 사용자 이름입니다. 자격 증명 기반 인증에 사용됩니다. |
ONTAP |
비밀번호 |
클러스터/SVM에 연결하는 데 사용되는 비밀번호입니다. 자격 증명 기반 인증에 사용됩니다. |
ONTAP |
clientPrivateKey |
클라이언트 개인 키의 Base64 인코딩 값입니다. 인증서 기반 인증에 사용됩니다. |
ONTAP |
chapUsername |
인바운드 사용자 이름. useCHAP=true인 경우 필수입니다. |
ONTAP |
chapInitiatorSecret |
CHAP 개시자 비밀 키. useCHAP=true인 경우 필수입니다. |
ONTAP |
chapTargetUsername |
대상 사용자 이름. useCHAP=true인 경우 필수입니다. |
ONTAP |
chapTargetInitiatorSecret |
CHAP 대상 시작자 비밀 키. useCHAP=true인 경우 필수입니다. |
이 단계에서 생성된 Secret은 다음 단계에서 생성되는 spec.credentials 객체의 TridentBackendConfig 필드에서 참조됩니다.
2단계: TridentBackendConfig CR 생성
이제 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-secret3단계: TridentBackendConfig CR의 상태를 확인합니다
`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 CR에 바인딩되었습니다.
Phase는 다음 값 중 하나를 사용할 수 있습니다.
-
Bound:TridentBackendConfigCR은 백엔드와 연결되어 있으며, 해당 백엔드에는configRef`가 `TridentBackendConfigCR의 uid로 설정되어 있습니다. -
Unbound:""`로 표현됩니다. `TridentBackendConfig객체는 백엔드에 바인딩되지 않았습니다. 새로 생성되는 모든TridentBackendConfigCR은 기본적으로 이 단계에 있습니다. 단계가 변경된 후에는 다시 Unbound 상태로 되돌릴 수 없습니다. -
Deleting:TridentBackendConfig`CR의 `deletionPolicy삭제가 설정되었습니다. `TridentBackendConfig`CR이 삭제되면 삭제 중 상태로 전환됩니다.-
백엔드에 영구 볼륨 클레임(PVC)이 없는 경우
TridentBackendConfig`를 삭제하면 Trident가 백엔드와 `TridentBackendConfigCR을 삭제합니다. -
백엔드에 하나 이상의 PVC가 존재하면 삭제 상태로 전환됩니다.
TridentBackendConfigCR도 이후 삭제 단계로 들어갑니다. 백엔드와 `TridentBackendConfig`는 모든 PVC가 삭제된 후에만 삭제됩니다.
-
-
Lost:TridentBackendConfigCR과 연결된 백엔드가 실수로 또는 의도적으로 삭제되었지만TridentBackendConfigCR에는 여전히 삭제된 백엔드에 대한 참조가 남아 있습니다.TridentBackendConfigCR은deletionPolicy값과 관계없이 삭제할 수 있습니다. -
Unknown: Trident는TridentBackendConfigCR과 연결된 백엔드의 상태 또는 존재 여부를 확인할 수 없습니다. 예를 들어 API 서버가 응답하지 않거나tridentbackends.trident.netapp.ioCRD가 없는 경우입니다. 이 경우 개입이 필요할 수 있습니다.
이 단계에서 백엔드가 성공적으로 구축되었습니다! "백엔드 업데이트 및 백엔드 삭제"와 같이 추가로 처리할 수 있는 몇 가지 작업이 있습니다.
(선택 사항) 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
또한 `TridentBackendConfig`의 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: BoundbackendInfo`에는 `backendName 및 backendUUID`가 해당 `TridentBackendConfig CR에 대한 응답으로 생성된 백엔드의 정보가 포함되어 있습니다. lastOperationStatus 필드는 TridentBackendConfig CR의 마지막 작업 상태를 나타내며, 이는 사용자가 트리거한 경우(예: 사용자가 spec`에서 무언가를 변경한 경우) 또는 Trident에 의해 트리거된 경우(예: Trident 재시작 중)에 발생할 수 있습니다. 이 값은 Success 또는 Failed 중 하나일 수 있습니다. `phase`는 `TridentBackendConfig CR과 백엔드 간의 관계 상태를 나타냅니다. 위 예시에서, phase`의 값은 Bound이며, 이는 `TridentBackendConfig CR이 백엔드와 연결되어 있음을 의미합니다.
`kubectl -n trident describe tbc <tbc-cr-name>` 명령을 실행하여 이벤트 로그의 세부 정보를 확인할 수 있습니다.
|
|
연결된 TridentBackendConfig 객체가 포함된 백엔드는 tridentctl`를 사용하여 업데이트하거나 삭제할 수 없습니다. `tridentctl`와 `TridentBackendConfig 간 전환에 필요한 단계들을 이해하려면 "여기를 참조하십시오".
|