简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

在后端管理选项之间移动

04/28/2023 提供者

了解如何在 Astra Trident 中管理后端。

用于管理后端的选项

随附 `TridentBackendConfig`现在、管理员可以通过两种独特的方式管理后端。这会提出以下问题：

使用 tridentctl 创建的后端是否可以使用 TridentBackendConfig 进行管理？
使用 TridentBackendConfig 创建的后端是否可以使用 tridentctl 进行管理？

管理 `tridentctl` 后端使用 `TridentBackendConfig`

本节介绍通过创建 TridentBackendConfig 对象直接通过 Kubernetes 界面管理使用 tridentctl 创建的后端所需的步骤。

这适用于以下情形：

预先存在的后端，没有 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 机密

创建一个包含后端凭据的机密，如以下示例所示：

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

下一步是创建一个 TridentBackendConfig CR ，该 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` CR

创建 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 已成功创建并绑定到后端【观察后端的 UUUID] 。

第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` CR

最后一步是删除 TridentBackendConfig CR 。确认 deeltionPolicy 设置为 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 对象后， Astra Trident 只需删除该对象，而无需实际删除后端本身。

Creating your file...

在后端管理选项之间移动

用于管理后端的选项

管理 tridentctl 后端使用 TridentBackendConfig

第 0 步：确定后端

第 1 步：创建 Kubernetes 机密

第2步：创建 TridentBackendConfig CR

第3步：验证的状态 TridentBackendConfig CR

管理 TridentBackendConfig 后端使用 tridentctl

第 0 步：确定后端

第1步：确认 deletionPolicy 设置为 retain

第2步：删除 TridentBackendConfig CR

管理 `tridentctl` 后端使用 `TridentBackendConfig`

第2步：创建 `TridentBackendConfig` CR

第3步：验证的状态 `TridentBackendConfig` CR

管理 `TridentBackendConfig` 后端使用 `tridentctl`

第1步：确认 `deletionPolicy` 设置为 `retain`

第2步：删除 `TridentBackendConfig` CR