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

백엔드 관리 옵션 간 이동

10/30/2024 기여자

PDF

Astra Trident에서 백엔드를 관리하는 다양한 방법에 대해 알아보십시오.

백엔드 관리 옵션

의 도입으로 TridentBackendConfig 관리자는 이제 두 가지 고유한 방식으로 백엔드를 관리할 수 있습니다. 이 질문은 다음과 같습니다.

을 사용하여 만든 백엔드를 와 함께 관리할 TridentBackendConfig 수 tridentctl 있습니까?
을 사용하여 만든 백엔드를 사용하여 관리할 tridentctl 수 TridentBackendConfig 있습니까?

을 사용하여 백엔드 `TridentBackendConfig` 관리 `tridentctl`

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

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

에서 만들어졌기 때문에 tridentctl 가 없는 기존 백엔드가 TridentBackendConfig 있습니다.
다른 오브젝트가 있는 동안 TridentBackendConfig 로 만들어진 새 백엔드가 tridentctl 있습니다.

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

를 계속 사용하여 tridentctl 만든 백엔드를 관리합니다.
을 사용하여 만든 백엔드를 새 TridentBackendConfig 개체에 바인딩합니다. tridentctl 이렇게 하면 백엔드가 을 사용하여 관리되고, 그렇지 않습니다 kubectl tridentctl.

을 사용하여 기존 백엔드를 관리하려면 kubectl 기존 백엔드에 바인딩되는 을 TridentBackendConfig 생성해야 합니다. 작동 방식에 대한 개요는 다음과 같습니다.

Kubernetes 암호를 생성하십시오. 비밀에는 Astra Trident가 스토리지 클러스터/서비스와 통신하는 데 필요한 자격 증명이 포함되어 있습니다.
개체를 만듭니다. TridentBackendConfig 스토리지 클러스터/서비스에 대한 자세한 내용과 이전 단계에서 생성한 암호를 참조하십시오. 동일한 구성 매개 변수( spec.storagePrefix,, spec.storageDriverName 등)를 지정할 때 주의를 기울여야 spec.backendName 합니다. 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단계: `TridentBackendConfig` CR을 생성합니다

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

동일한 백엔드 이름이 에 정의되어 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단계: CR의 상태를 확인합니다 `TridentBackendConfig`

를 생성한 후에는 TridentBackendConfig 해당 단계가 되어야 `Bound`합니다. 또한 기존 백엔드의 백엔드 이름과 UUID도 동일하게 반영되어야 합니다.

kubectl 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 관리됩니다.

을 사용하여 백엔드 `tridentctl` 관리 `TridentBackendConfig`

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

단계 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`설정해야 합니다. 이렇게 하면 CR이 삭제되어도 `TridentBackendConfig 백엔드 정의가 계속 존재하며 로 관리할 수 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

가 로 설정되지 retain 않은 경우 다음 단계를 진행하지 마십시오. deletionPolicy

2단계: `TridentBackendConfig` CR을 삭제합니다

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

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 Astra Trident는 백엔드 자체를 실제로 삭제하지 않고 기존 오브젝트를 단순히 제거합니다.

백엔드 관리 옵션 간 이동

Creating your file...

백엔드 관리 옵션

을 사용하여 백엔드 TridentBackendConfig 관리 tridentctl

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

1단계: Kubernetes Secret 생성

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

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

을 사용하여 백엔드 tridentctl 관리 TridentBackendConfig

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

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

2단계: TridentBackendConfig CR을 삭제합니다

을 사용하여 백엔드 `TridentBackendConfig` 관리 `tridentctl`

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

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

을 사용하여 백엔드 `tridentctl` 관리 `TridentBackendConfig`

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

2단계: `TridentBackendConfig` CR을 삭제합니다