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

백엔드 관리 옵션 간 이동

기여자 netapp-aruldeepa
PDF

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

백엔드 관리 옵션

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

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

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

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

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

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

  • 에서 만들어졌기 때문에 tridentctl 가 없는 기존 백엔드가 TridentBackendConfig 있습니다.

  • 다른 오브젝트가 있는 동안 TridentBackendConfig 로 만들어진 새 백엔드가 tridentctl 있습니다.

두 시나리오 모두에서 Trident의 볼륨 예약 및 운영 기능과 함께 백엔드가 계속 표시됩니다. 관리자는 다음 두 가지 옵션 중 하나를 선택할 수 있습니다.

  • 를 계속 사용하여 tridentctl 만든 백엔드를 관리합니다.

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

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

  1. Kubernetes 암호를 생성하십시오. 비밀에는 Trident가 스토리지 클러스터/서비스와 통신하는 데 필요한 자격 증명이 포함되어 있습니다.

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