在後端管理選項之間切換
瞭解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
已成功建立、並繫結至後端(觀察後端的UUID)。
步驟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只會移除它、而不會實際刪除後端本身。