在后端管理选项之间移动
建议更改
PDF
了解如何在 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 只需删除该对象，而无需实际删除后端本身。