在后端管理选项之间移动
了解如何在 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 机密
创建一个包含后端凭据的机密,如以下示例所示:
$ 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 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
已成功创建并绑定到后端[观察后端的UUUUID]。
第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.确认后 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
对象、Astra Trident只需将其删除、而不实际删除后端本身。