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

백엔드 관리 옵션 간 이동

04/27/2023 기여자

Astra Trident에서 백엔드를 관리하는 다양한 방법에 대해 알아보십시오. 을 소개합니다 `TridentBackendConfig`이제 관리자는 두 가지 고유한 방식으로 백엔드를 관리할 수 있습니다. 이 질문은 다음과 같습니다.

을(를) 사용하여 만들 수 있습니다 tridentctl 을 사용하여 관리합니다 TridentBackendConfig?
을(를) 사용하여 만들 수 있습니다 TridentBackendConfig 을 사용하여 관리합니다 tridentctl?

관리 `tridentctl` 을 사용하여 백엔드를 만듭니다 `TridentBackendConfig`

이 섹션에서는 을 사용하여 만든 백엔드를 관리하는 데 필요한 단계를 설명합니다 tridentctl Kubernetes 인터페이스를 통해 직접 작성합니다 TridentBackendConfig 오브젝트.

이 내용은 다음 시나리오에 적용됩니다.

기존 백엔드는 가 없습니다 TridentBackendConfig 을 사용하여 생성되었기 때문입니다 tridentctl.
로 만든 새 백 엔드 tridentctl`기타 `TridentBackendConfig 객체가 있습니다.

두 시나리오 모두 Astra Trident가 볼륨을 예약하고 운영하면서 백엔드가 계속 존재할 것입니다. 관리자는 다음 두 가지 옵션 중 하나를 선택할 수 있습니다.

를 계속 사용합니다 tridentctl 를 사용하여 만든 백엔드를 관리합니다.
을 사용하여 만든 백엔드 바인딩 tridentctl 새로운 제품으로 TridentBackendConfig 오브젝트. 이렇게 하면 백엔드가 를 사용하여 관리됩니다 kubectl 그렇지 않습니다 tridentctl.

를 사용하여 기존 백엔드를 관리합니다 kubectl`을 만들어야 합니다 `TridentBackendConfig 기존 백엔드에 바인딩합니다. 작동 방식에 대한 개요는 다음과 같습니다.

Kubernetes 암호를 생성하십시오. 비밀에는 Astra Trident가 스토리지 클러스터/서비스와 통신하는 데 필요한 자격 증명이 포함되어 있습니다.
을 생성합니다 TridentBackendConfig 오브젝트. 스토리지 클러스터/서비스에 대한 자세한 내용과 이전 단계에서 생성한 암호를 참조하십시오. 동일한 구성 매개 변수(예 spec.backendName, spec.storagePrefix, spec.storageDriverName`등). `spec.backendName 기존 백엔드의 이름으로 설정해야 합니다.

단계 0: 백엔드를 식별합니다

을(를) 생성합니다 TridentBackendConfig 이 경우 기존 백엔드에 바인딩되므로 백엔드 구성을 확보해야 합니다. 이 예에서는 다음과 같은 JSON 정의를 사용하여 백엔드를 생성했다고 가정합니다.

tridentctl get backend ontap-nas-backend -n trident
+---------------------+----------------+--------------------------------------+--------+---------+
|          NAME       | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+---------------------+----------------+--------------------------------------+--------+---------+
| ontap-nas-backend   | ontap-nas      | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online |      25 |
+---------------------+----------------+--------------------------------------+--------+---------+

cat ontap-nas-backend.json

{
    "version": 1,
    "storageDriverName": "ontap-nas",
    "managementLIF": "10.10.10.1",
    "dataLIF": "10.10.10.2",
    "backendName": "ontap-nas-backend",
    "svm": "trident_svm",
    "username": "cluster-admin",
    "password": "admin-password",

    "defaults": {
        "spaceReserve": "none",
        "encryption": "false"
    },
    "labels":{"store":"nas_store"},
    "region": "us_east_1",
    "storage": [
        {
            "labels":{"app":"msoffice", "cost":"100"},
            "zone":"us_east_1a",
            "defaults": {
                "spaceReserve": "volume",
                "encryption": "true",
                "unixPermissions": "0755"
            }
        },
        {
            "labels":{"app":"mysqldb", "cost":"25"},
            "zone":"us_east_1d",
            "defaults": {
                "spaceReserve": "volume",
                "encryption": "false",
                "unixPermissions": "0775"
            }
        }
    ]
}

1단계: Kubernetes Secret 생성

이 예에 표시된 것처럼 백엔드에 대한 자격 증명이 포함된 암호를 생성합니다.

cat tbc-ontap-nas-backend-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: ontap-nas-backend-secret
type: Opaque
stringData:
  username: cluster-admin
  password: admin-password

kubectl create -f tbc-ontap-nas-backend-secret.yaml -n trident
secret/backend-tbc-ontap-san-secret created

2단계: A를 작성합니다 `TridentBackendConfig` 있습니다

다음 단계는 을 생성하는 것입니다 TridentBackendConfig 기존 에 자동으로 바인딩되는 CR입니다 ontap-nas-backend (이 예에서와 같이) 다음 요구 사항이 충족되는지 확인합니다.

에 동일한 백엔드 이름이 정의되어 있습니다 spec.backendName.
구성 매개 변수는 원래 백엔드와 동일합니다.
가상 풀(있는 경우)은 원래 백엔드와 동일한 순서를 유지해야 합니다.
자격 증명은 일반 텍스트가 아닌 Kubernetes Secret을 통해 제공됩니다.

이 경우, 입니다 TridentBackendConfig 다음과 같이 표시됩니다.

cat backend-tbc-ontap-nas.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-ontap-nas-backend
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: 10.10.10.1
  dataLIF: 10.10.10.2
  backendName: ontap-nas-backend
  svm: trident_svm
  credentials:
    name: mysecret
  defaults:
    spaceReserve: none
    encryption: 'false'
  labels:
    store: nas_store
  region: us_east_1
  storage:
  - labels:
      app: msoffice
      cost: '100'
    zone: us_east_1a
    defaults:
      spaceReserve: volume
      encryption: 'true'
      unixPermissions: '0755'
  - labels:
      app: mysqldb
      cost: '25'
    zone: us_east_1d
    defaults:
      spaceReserve: volume
      encryption: 'false'
      unixPermissions: '0775'

kubectl create -f backend-tbc-ontap-nas.yaml -n trident
tridentbackendconfig.trident.netapp.io/tbc-ontap-nas-backend created

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

를 누릅니다 TridentBackendConfig 이(가) 생성되었으며 해당 단계는 이어야 합니다 Bound. 또한 기존 백엔드의 백엔드 이름과 UUID도 동일하게 반영되어야 합니다.

kubectl -n trident get tbc tbc-ontap-nas-backend -n trident
NAME                   BACKEND NAME          BACKEND UUID                           PHASE   STATUS
tbc-ontap-nas-backend  ontap-nas-backend     52f2eb10-e4c6-4160-99fc-96b3be5ab5d7   Bound   Success

#confirm that no new backends were created (i.e., TridentBackendConfig did not end up creating a new backend)
tridentctl get backend -n trident
+---------------------+----------------+--------------------------------------+--------+---------+
|          NAME       | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+---------------------+----------------+--------------------------------------+--------+---------+
| ontap-nas-backend   | ontap-nas      | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online |      25 |
+---------------------+----------------+--------------------------------------+--------+---------+

이제 백엔드는 를 사용하여 완전히 관리됩니다 tbc-ontap-nas-backend TridentBackendConfig 오브젝트.

관리 `TridentBackendConfig` 을 사용하여 백엔드를 만듭니다 `tridentctl`

`tridentctl` 을 사용하여 만든 백엔드를 나열하는 데 사용할 수 있습니다 `TridentBackendConfig`. 또한 관리자는 에서 이러한 백엔드를 완전히 관리하도록 선택할 수도 있습니다 `tridentctl` 삭제합니다 `TridentBackendConfig` 그리고 확실합니다 `spec.deletionPolicy` 가 로 설정되어 있습니다 `retain`.

단계 0: 백엔드를 식별합니다

예를 들어, 다음 백엔드가 를 사용하여 생성되었다고 가정해 보겠습니다 TridentBackendConfig:

kubectl get tbc backend-tbc-ontap-san -n trident -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   81abcb27-ea63-49bb-b606-0a5315ac5f82   Bound   Success   ontap-san        delete

tridentctl get backend ontap-san-backend -n trident
+-------------------+----------------+--------------------------------------+--------+---------+
|       NAME        | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+-------------------+----------------+--------------------------------------+--------+---------+
| ontap-san-backend | ontap-san      | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online |      33 |
+-------------------+----------------+--------------------------------------+--------+---------+

출력에서 해당 결과가 표시됩니다 TridentBackendConfig 성공적으로 생성되었으며 백엔드에 바인딩되었습니다[백엔드의 UUID 확인].

1단계: 확인 `deletionPolicy` 가 로 설정되어 있습니다 `retain`

의 가치를 살펴보겠습니다 deletionPolicy. 이 설정은 로 설정해야 합니다 retain. 이렇게 하면 가 다음과 같은 경우에 사용할 수 있습니다 TridentBackendConfig CR이 삭제되어도 백엔드 정의가 계속 존재하고 로 관리할 수 있습니다 tridentctl.

kubectl get tbc backend-tbc-ontap-san -n trident -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   81abcb27-ea63-49bb-b606-0a5315ac5f82   Bound   Success   ontap-san        delete

# Patch value of deletionPolicy to retain
kubectl patch tbc backend-tbc-ontap-san --type=merge -p '{"spec":{"deletionPolicy":"retain"}}' -n trident
tridentbackendconfig.trident.netapp.io/backend-tbc-ontap-san patched

#Confirm the value of deletionPolicy
kubectl get tbc backend-tbc-ontap-san -n trident -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   81abcb27-ea63-49bb-b606-0a5315ac5f82   Bound   Success   ontap-san        retain

다음 단계를 진행하지 마십시오 deletionPolicy 가 로 설정되어 있습니다 retain.

2단계: 를 삭제합니다 `TridentBackendConfig` 있습니다

마지막 단계는 를 삭제하는 것입니다 TridentBackendConfig 있습니다. 를 확인한 후 deletionPolicy 가 로 설정되어 있습니다 `retain`삭제 작업을 계속 수행할 수 있습니다.

kubectl delete tbc backend-tbc-ontap-san -n trident
tridentbackendconfig.trident.netapp.io "backend-tbc-ontap-san" deleted

tridentctl get backend ontap-san-backend -n trident
+-------------------+----------------+--------------------------------------+--------+---------+
|       NAME        | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+-------------------+----------------+--------------------------------------+--------+---------+
| ontap-san-backend | ontap-san      | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online |      33 |
+-------------------+----------------+--------------------------------------+--------+---------+

를 삭제할 때 TridentBackendConfig Object, Astra Trident는 실제로 백엔드 자체를 삭제하지 않고 간단히 제거합니다.

백엔드 관리 옵션 간 이동

Creating your file...

관리 tridentctl 을 사용하여 백엔드를 만듭니다 TridentBackendConfig

단계 0: 백엔드를 식별합니다

1단계: Kubernetes Secret 생성

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

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

관리 TridentBackendConfig 을 사용하여 백엔드를 만듭니다 tridentctl

단계 0: 백엔드를 식별합니다

1단계: 확인 deletionPolicy 가 로 설정되어 있습니다 retain

2단계: 를 삭제합니다 TridentBackendConfig 있습니다

관리 `tridentctl` 을 사용하여 백엔드를 만듭니다 `TridentBackendConfig`

2단계: A를 작성합니다 `TridentBackendConfig` 있습니다

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

관리 `TridentBackendConfig` 을 사용하여 백엔드를 만듭니다 `tridentctl`

1단계: 확인 `deletionPolicy` 가 로 설정되어 있습니다 `retain`

2단계: 를 삭제합니다 `TridentBackendConfig` 있습니다